Reverse Engineering der NLT II

[gaor]

Wo ist das Problem? Wurde der Code in C-Code übersetzt, müsste sich doch ohne Weiteres (durch Compilieren) der Binärcode wieder herstellen lassen.

So einfach ist das nicht. Nur weil zwei C-Quellcodes exakt das gleiche tun, heißt es nicht, dass der Compiler sie auch in den gleichen Maschinencode übersetzt. Und umgekehrt gibt es auch mehrere verschiedene C-Quellcodes, die beim Kompilieren den gleichen Maschinencode ergeben. Fakt ist, dass wir C-Code haben, der exakt das tut, was die SCHICK.EXE tut. Aber wenn man kompiliert, kommt etwas heraus, das im Maschinencode leicht vom Original abweicht (tut aber effektiv das gleiche), weil der Compiler irgendwelche "Optimierungen" vornimmt. Glücklicherweise sind das aktuell nur noch 5 Funktionen, die solche Abweichungen aufweisen.

Wie sieht so ein "Durchtesten" aus? Kann man denn einzelne Bereiche des Binärcodes isolieren, einzelne Bereiche des C-Codes übersetzen und dann beides miteinander vergleichen? Braucht man vielleicht BrightEyes dafür?

Genau, man kann einzelne C-Quellcode-Dateien getrennt voneinander kompilieren. In Bright-Eyes sind die nötigen Befehle bzw. Skripte dafür enthalten. Aber der Compiler selbst (BCC.EXE) ist nicht in Bright-Eyes enthalten, weil er proprietär lizensiert ist.