Dekompilacja programu z PC i re-kompilacja go na PSP?

0

Witam, od ponad roku aktywnie uczę się programowania i szukam ciekawych sposobów na rozszerzenie swojej wiedzy. Pisałem proste gierki 3D na platformę Playstation 2 i PSP, i zamierzam do tego wrócić. Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?) i napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera. Z assemblerem jeszcze nie miałem do czynienia, ale nie jest problem się tego nauczyć; natomiast pisanie aplikacji 3D na PSP nie stanowi dla mnie jako tako trudności. Myślicie że zderzenie się z DirectX może mocno utrudnić całą sprawę? Z góry dzięki za odpowiedź.

6

Skoro zadajesz te pytanie to sobie na 100% z tym nie poradzisz. Samo mówienie, że asembler to nie jest żaden problem już mówi o tym jak dużo wiesz o kodowaniu. Odpuść takie rzeczy, tego się po prostu nie robi. Idź krok po kroku. Teraz powinieneś zacząć robić jakieś gry korzystając z silnika graficznego. Znajdziesz tutaj tematy mówiąc od jakiego silnika zacząć. Pytanie czy w ogóle znasz jakikolwiek język programowania?

0

Wybacz, ale robisz ze mnie idiotę. Przecież piszę, że pisałem aplikacje 3D na SDK dla PS2 i PSP, co za tym idzie, znam język C i C++, który jest wymagany dla kompilatora, znam podstawy kodowania w grafice 3D, ręczne używanie kompilatora oraz wiele innych pomniejszych elementów, które pojawiają się przy tworzeniu programu 3D w pełni działającego na konsoli, a takowy JUŻ NAPISAŁEM. Poza tym piszę na początku, że to forma nauki i eksperymentowania, więc nie interesuje mnie fakt, że na silniku graficznym osiągnę lepsze rezultaty.

0

Szybciej i lepiej wyjdzie napisać taką grę od początku. Poza tym takie przenoszenie gry byłoby pewnie pogwałceniem licencji.

0
Kacper Gutowski napisał(a):

Witam, od ponad roku aktywnie uczę się programowania i szukam ciekawych sposobów na rozszerzenie swojej wiedzy. Pisałem proste gierki 3D na platformę Playstation 2 i PSP, i zamierzam do tego wrócić.

Dla kogo chcesz wspierać konsole, których już nikt nie wspiera?

Wiem, że czasem znajdują się zapaleńcy robiący non-profit nowe gry na archaiczne sprzęty (C64, NES, Sega Mega Drive..), ale Ty dopiero od ponad roku programujesz... Dlaczego od samego początku chcesz dziwaczyć?

Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?) i napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera.

j.w.
Skoro chcesz poszerzać swoją wiedzę, to czemu by nie napisać własnych szachów zamiast dekompilować?
Uczysz się programowania, czy piracenia?

5

Reversowanie nie jest takie proste ;) https://hack.cert.pl/challenges masz tu całą masę zadań z kategorii "re". Większość z nich to są binarki których źródła miały < 100 linijek kodu w C. Spróbuj rozwiązać któreś z tych zadań na początek i przekonasz się ile pracy potrzeba żeby przeanalizować nawet bardzo prostą aplikację.

0

Generalnie uznałem, że jeśli rekompilacja nie byłaby super czasochłonna i/lub wykonalna przez dość początkującego to byłoby to ciekawe doświadczenie. Wszystko na użytek własny, w celach edukacyjnych. Ale skoro odradzacie, to zajmę się czymś innym.

Mam też pomysł nieco inny i nie związany z PSP - napisanie emulatora jakiejś starej konsoli, na podstawie poradników dostępnych w internecie (dużo tego jest). Chyba jest to bardziej realne do zrobienia?

Wiem, dziwne mam hobby.

2
Kacper Gutowski napisał(a):

Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?)

Czy ja wiem, parę minut na wygooglowanie narzędzia typu Snowman, kolejne parę minut na wyklikanie żeby zdekompilował binarkę... :)

Schody zaczną się, jak już zdekompilujesz i dostaniesz te kilkadziesiąt - kilkaset tysięcy linii kodu w asmie, prawdopodobnie bez śladu po pierwotnym kodzie źródłowym w postaci choćby nazw etykiet :P

napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera.

Wiesz ile SLoC w C miała ta procedura?

dot_product:
        testl   %edx, %edx
        je      .L7
        cmpl    $1, %edx
        je      .L8
        movl    %edx, %ecx
        xorl    %eax, %eax
        pxor    %xmm0, %xmm0
        shrl    %ecx
        salq    $4, %rcx
.L4:
        movupd  (%rdi,%rax), %xmm1
        movupd  (%rsi,%rax), %xmm3
        addq    $16, %rax
        mulpd   %xmm3, %xmm1
        movapd  %xmm1, %xmm2
        unpckhpd        %xmm1, %xmm1
        addsd   %xmm0, %xmm2
        movapd  %xmm1, %xmm0
        addsd   %xmm2, %xmm0
        cmpq    %rax, %rcx
        jne     .L4
        movl    %edx, %eax
        andl    $-2, %eax
        andl    $1, %edx
        je      .L11
.L3:
        cltq
        movsd   (%rsi,%rax,8), %xmm1
        mulsd   (%rdi,%rax,8), %xmm1
        addsd   %xmm1, %xmm0
        ret
.L11:
        ret
.L7:
        pxor    %xmm0, %xmm0
        ret
.L8:
        xorl    %eax, %eax
        pxor    %xmm0, %xmm0
        jmp     .L3

Dokładnie 4, jeśli liczyć tylko cialo funkcji ;)

double dot_product(double* a, double* b, unsigned int n) {
    double x = 0.0;
    int i=0;
    for(;i<n; i++) x += a[i] * b[i];
    return x;
}

Zgadnij, jak będzie wyglądać po dekompilacji prosta gierka, która w C miała tylko 4k linii... ;)

Z assemblerem jeszcze nie miałem do czynienia, ale nie jest problem się tego nauczyć

Zależy którego ;]

  • ARM - do ogarnięcia
  • Nios2 - jak wyżej, ~96 instrukcji (w R1, R2 + rozszerzenia dokładają jeszcze z parędziesiąt), każda pełni ściśle określoną rolę, wykonuje podstawową czynność
  • x86/x86-64 - dzieło sadysty, dziecko szatana, nie dość, że 12347627369 instrukcji, to jeszcze dwie składnie (Intelowska i AT&T, żeby było śmieszniej w jednej operandy podajesz w kolejności cel, [źródło [...]], w drugiej [źródło, [...]], cel), do tego instrukcje używane przez kompilatory niezgodnie z pierwotnym przeznaczeniem / znaczeniem żeby zoptymalizować kod np. instrukcje do obliczania adresów używane jak FMA dla integerów... styczność z nim na 1 roku studiów skutecznie obrzydziła mi assembly na długi czas.

EDIT

Ogólnie jak chcesz się na szybko pobawić bez instalowania narzędzi i popatrzeć, jaki assembly wyplują różne kompilatory / różne wersje kompilatorów dla jakichś procedur pisanych w językach kompilowanych, to tu jest taka fajna zabawka online

0

Dzięki za rzeczową odpowiedź. Programuję wysokopoziomowo, najniżej w C, a assemblera x86 ani ARM ani jakiegokolwiek innego nie tykałem bo nie było mi to do niczego potrzebne. Stąd też moja niewiedza w tej kwestii. Googlowałem temat dekompilacji i znalazłem narzędzia, które dekompilują program do postaci pseudokodu C, co podobno jest mniej wydajne, ale bardziej "ogarniable" dla człowieka. Rzecz jasna taki kod i tak trzeba by było zmodyfikować na własne potrzeby. Czy takie rozwiązanie miałoby szansę, czy jest to pic na wodę?

1
Kacper Gutowski napisał(a):

Mam też pomysł nieco inny i nie związany z PSP - napisanie emulatora jakiejś starej konsoli, na podstawie poradników dostępnych w internecie (dużo tego jest). Chyba jest to bardziej realne do zrobienia?

No to już prędzej. Nawet czasem się widzi współczesne emulatory NES'a napisane w Unity z wizualizacją 3D:

Jak uda Ci się napisać w pełni funkcjonalny emulator dosa, wydajniejszy niż DOSBOX... albo chociaż pogrzebiesz w źródłach DOSBOXa i sprawisz, żeby Dungeon Keeper chodził płynnie na współczesnych maszynach, to będę Ci wdzięczny ;) Bo na razie pełna rozdzielczość (Alt+R) ze wszystkimi opcjami cienia itp. zamula nawet na PC za 7k, a na Raspberry (który ma procek niezgodny z DOSem) jeszcze trudniej jest DOSBOXowi tłumaczyć kod aplikacji.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0