Reverse Engineering der NLT II

[HenneNWH]

Ob ich mir das nochmal antue weiß ich noch nicht. Das wird die Zeit zeigen.

[llm]

Wirklich schön das an dem Projekt wieder mit voller Kraft gearbeitet wird!

das Spiel selbst habe ich noch nie gespielt aber ich interessiere mich sehr für Reverse-Engineering von alten DOS-Games (ich hab teilweise an Re-Stunts und einem AlphaWaves reversing gearbeitet)

ich hab ein paar Kompilier/Test-Fragen:

1.
Hab ihr schon mal (am einfachsten unter Linux mit clang/gcc) mit dem ASAN (AddressSanitizer: https://github.com/google/sanitizers/wik...ssanitizer) gearbeitet
der erkennt zuverlässig (fast) jeden Speicher/Pointer-Missbrauch und ist bei mir in der Entwicklung schon seit mind. 10 Jahren Standard in allen Projekten

dafür muss man in der CMake nur folgende Optionen setzen

add_compile_options(-fsanitize=address -fno-omit-frame-pointer -O0 -g)
add_link_options(-fsanitize=address)

und das Programm laufen lassen - der ASAN beendet dann (per default) das Programm beim ersten Auftreten von einem Problem mit detallierter Info was passiert ist
(wird durch den Kompiler instrumentiert, ist viel schneller und hat keine false-Positives im Vergleich zu Valgrind)

===> aber das lohnt sich nur wenn ein grossteil der Variablen sauber vom Kompiler im Source erkennbar sind - wenn die meisten Speicherzugriffe mit casts auf irgendwelche DSeg-Like Speicherbereiche passiert bringt der noch nicht so viel - aber spätestens wenn alles sauber ist

2. gibt es eine kleine Doku was und wie man bauen kann?
ich sehe das der alte Borland Kompiler eingesetzt wird und irgendwo ist auch CMake im Einsatz aber ich werden noch nicht schlau draus welche Tools/Kompiler ich wo brauche und aufrufen muss damit ich alles von dem ihr hier so erzählt bauen kann

3. warum braucht ihr eine gesonderte WinMain in src/gen?
wenn ihr in der CMakeLists noch die SDL2Main zieht reicht eine übliche main(...) 

target_link_libraries(ngen PUBLIC SDL2::SDL2main)

dann ist der main Code für Windows/Linux schon mal gleich

4. das Programm src/gen lässt sich mit ein paar kleine Änderungen auch mit VS2022 kompilieren und dann auch in der IDE debuggen - ist der Kompiler für euch relevant?
(ich bin mir aber nicht sicher ob alles richtig funktioniert weil ich keine Ahnung habe wie "richtig" aussieht)

mein technischer Hintergrund: Ich arbeite seit fast 30 Jahren unter Windows/Linux mit gcc/clang/MSVC,msys2,BCC,OpenWatcom V2, msys2,git,IDA Pro etc.

[HenneNWH]

Hey Ilm, willkommen im Forum.

1. Danke für den Tip mit ASAN. Habs heute gleich mal mit einem selbst erzeugten Fehler ausprobiert und bin begeistert.
Das sind Features, die wirklich für stabile Anwendungen sorgen. Valgrind hab ich auch schon probiert, aber das zeigt scheinbar nur Speicherlecks aus der SDL an.

2. Ich habe vor in den nächsten Wochen einen kleinen Workshop für technisch Interessierte zu machen. Der Termin steht noch nicht fest.
Vieles hat sich seit über 15 Jahren entwickelt und wird langsam so, wie es mich zufriedenstellt.
Kurz: Bright-Eyes ist ein DOSBox-Klon in welchem ich zwei Programme per Hand reverse-engineered habe.
BrightEyes (ohne Bindestrich) ist eine Umgebung in welcher die Programme ohne DOSBox nativ mit SDL2 laufen sollen und auf Binäräquivalenz getestet werden.
DOS.Builds mit dem BCC inbegriffen!

3. Die beiden Programme gen/schick gehören zusammen. Ich habe angedacht später daraus ein einziges Programm zu machen.
Unter Windows schien mir die WinMain() notwendig, da gen die Parameter argc und argv benutzt.
Wenn ich da jetzt draufschaue mutet es seltsam an, aber ist für mich erstmal in Ordnung.

4. VS2022 ist für mich eher mäßig interessant, da GCC/Clang qualitätsmäßig ganz klar die Nase vorn haben.
Für dieses Projekt ist es notwendig, dass du eine legale Kopie des Spiels besitzt,
da ich "nur" den Quellcode der Programme der interessierten Öffentlichkeit zugänglich mache.

Dein technischer Hintergrund klingt gut. Hab auch ungefähr vor 30 Jahren angefangen und bin 2000 auf Linux gewechselt.
IDEs sind weniger meins: Ich habe lieber 8 Terminals auf zwei Bildschirmen offen an denen ich parallel arbeite.
Das erklärt unter anderem meine Arbeitsgeschwindigkeit. (Und meinen Appetit!)

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3942 Bytes
* auskommentierte Zeilen in der symbols.h = 48.6 %
* es kompilieren auch schon einige Dateien (73 / 112) mit dem GCC

[llm]

1. Danke für den Tip mit ASAN. Habs heute gleich mal mit einem selbst erzeugten Fehler ausprobiert und bin begeistert.
Das sind Features, die wirklich für stabile Anwendungen sorgen. Valgrind hab ich auch schon probiert, aber das zeigt scheinbar nur Speicherlecks aus der SDL an.

die Sanitizer wurden von google eingeführt weil die ihre C/C++ Memory-Probleme (bei deren "Skalierung" ca. 2 Milliarden(English: Billon) Zeilen C/C++) nicht unter kontrolle gebracht haben - interessant sind
vielleicht auch noch der UBSAN(Undefined behavior-Sanitizer) und TSAN(Thread-Sanitizer) die auch eine grosse Hilfe sein können

2. Ich habe vor in den nächsten Wochen einen kleinen Workshop für technisch Interessierte zu machen. Der Termin steht noch nicht fest.

ich hoffe ich habe dann Zeit dabei zu sein

Unter Windows schien mir die WinMain() notwendig, da gen die Parameter argc und argv benutzt.
Wenn ich da jetzt draufschaue mutet es seltsam an, aber ist für mich erstmal in Ordnung.

alte Linux-Hasen denken immer das unter Windows alles irgendwie anders sein muss  - ist es heute aber kaum noch so

4. VS2022 ist für mich eher mäßig interessant, da GCC/Clang qualitätsmäßig ganz klar die Nase vorn haben.

unter Windows ist MSVC immer noch der Platzhirsch - und MSVC hat den schnellsten Debugger auf dem Mark (leider kommt nichts von Linux da bisher dran - und deswegen sind die unter Linux auch so unbeliebt) 
und z.B. alle AAA-Games mit hunderten von Mio Budget werden primär mit MSVC gemacht (u.a. ein Grund warum der Debugger so brutal schnell ist, die Branche macht das sehr viel Druck, mit riesigen Projekten - z.B. GTA6 - tausende Entwickler, Millarden-Buget, völlig verrückt)

auch interessant ist der clang-cl (ein Clang mit MSVC cl frontend, der direkt in VStudio verwenden werden kann (wurde von google für die chrome-Entwicklung im VStudio gebaut und ist auch Teil des normalen LLVM releases)

auch in Sache Standard-Umsetzung gibt Microsoft seit ein paar Jahren schon den Ton an - die haben den weitesten C++ Support in Sprachfeatures und deren Open-Source STL ist auch immer am schnellsten in Umsetzung neuer Standards - aber hier wird ja nur C gesprochen

ausserdem ist der VTune Profiler (von Intel, kostenlos) auch sehr angenehm in die IDE integriert - das spart viel Zeit wenn man in der Performance-Optimierung steckt

Dein technischer Hintergrund klingt gut. Hab auch ungefähr vor 30 Jahren angefangen und bin 2000 auf Linux gewechselt.

angefangen habe ich schon früher  aber seit der Zeit verdiene ich, vornehmlich mit C/C++, mein Geld

IDEs sind weniger meins: Ich habe lieber 8 Terminals auf zwei Bildschirmen offen an denen ich parallel arbeite.
Das erklärt unter anderem meine Arbeitsgeschwindigkeit. (Und meinen Appetit!)

jeder wie er es braucht und gut arbeiten kann - ich muss mich oft in fremden Code einarbeiten das ist eine IDE und ein schneller Debugger manchmal Gold wert

[cmfrydos]

Ich habe vor in den nächsten Wochen einen kleinen Workshop für technisch Interessierte zu machen.

Das fände ich auch sehr spannend! Kann leider nicht viel beitragen; meine ersten Reverse-Engineering-Schritte habe ich hier in Riva gemacht und bisher BrightEyes nur zu Recherchezwecken genutzt. Wäre aber gespannt, ein paar Einblicke zu erhaschen.

[HenneNWH]

@cmfrydos: Gerne. Riva hab ich nur mal angetestet. Das wurde mit dem Watcom C++ 10.x Compiler übersetzt und hat ein völlig anderes Format.
Falls du einen Compiler mit Originalverpackung möchtest: ich hab noch einen zu verkaufen. ;-)

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3942 Bytes
* auskommentierte Zeilen in der symbols.h = 50.0 %
* es kompilieren auch schon einige Dateien (75 / 112) mit dem GCC

[llm]

baut ihr auch mit anderen DOS- Kompilern um zu (versuchen zu)prüfen ob die erstellte Exe frei von Borland-Code-Generator-Bugs/Undefined-behavior ist - also z.B. Open Watcom V2?

[HenneNWH]

Bis jetzt noch nicht, hab BrightEyes so strukturiert, dass die Benutzung von anderen Compilern möglich ist.
Der BCC hat aus meiner Sicht einen Mängel: Die maximale Größe des Stacks kann nicht angepasst werden. Es gibt ein Compilerflag um während der Laufzeit zu Prüfen ob ein Stacküberlauf stattgefunden hat. Benutzt man das mit Gen wird ziemlich schnell abgebrochen.

[llm]

Der BCC hat aus meiner Sicht einen Mängel: Die maximale Größe des Stacks kann nicht angepasst werden.

du meinst das setzen der Stackgröße?



geht das nicht mit 

Code:

unsigned _stklen = 4096;

in http://www.bitsavers.org/pdf/borland/bor...e_1992.pdf auf Seite 608



Bild: https://imgur.com/ro8CQMU https://imgur.com/ro8CQMUhttps://imgur.com/ro8CQMUhttps://imgur.com/ro8CQMU



"extern" aber nur wenn man die Stackgröße lesen will, will man ändern dann ohne extern, vor der main und global

aber so richtig verstanden hab ich das nie bei Borland, hätte ja wie bei Microsoft C ein einfacher Kompiler/Linker Parameter reichen könne, aber das wäre ja zu einfach

der Runtime-Code reagiert auf die _stklen und allociert den Stack irgenwo anders oder vergrößert ihn zur Laufzeit, deswegen sieht man die Stacksize nicht richtig im EXE-Header



https://imgur.com/ro8CQMU

[HenneNWH]

Mit angepasster _stklen und dem Laufzeittest hab ich schon einmal herum experimentiert, hab aber immer Fehlermeldung und Programmabbrüche erhalten.
Der Parameter für TLink ist noch einen Versuch Wert, Danke!

[llm]

Mit angepasster _stklen und dem Laufzeittest hab ich schon einmal herum experimentiert, hab aber immer Fehlermeldung und Programmabrüche erhalten.
Der Parameter für TLink ist noch einen Versuch Wert, Danke!

das hat leider nicht funktioniert - ich dachte das wäre so möglich bei TLink - aber das ist noch vom Microsoft Linker und die TLink-Fehlerausgabe bei Murks-Parametern ist altersgerecht sehr dürftig

[HenneNWH]

Der OpenWatcom könnte auch noch einen weiteren Vorteil bringen: Mit dem BCC funktioniert die C-Implementierung des PowerPack2.0 Dekompressors nicht. Der AssemblerCode hat zwar nur um die 600 Zeilen, aber wenn mir das ersparen kann ist das auch schon viel Wert.

[llm]

Der OpenWatcom könnte auch noch einen weiteren Vorteil bringen: Mit dem BCC funktioniert die C-Implementierung des PowerPack2.0 Dekompressors nicht. Der AssemblerCode hat zwar nur um die 600 Zeilen, aber wenn mir das ersparen kann ist das auch schon viel Wert.

d.h. du hoffst das der OpenWatcom (V2) das einfach richtiger mit dem C code macht als der Borland Kompiler?
läuft der richtig unter gcc/clang/whatever 32/64bit aber spinnt mit Borland unter DOS?


FYI: der OpenWatcom V2 ist ein Crosscompiler der baut DOS EXEn von Windows/Linux und DOS aus - und der wir auch aktiv gepflegt
https://github.com/open-watcom/open-watcom-v2
https://github.com/open-watcom/open-watc...rent-build

[llm]

mir ist noch aufgefallen das in der src/gen/hero.h die packings nicht gleichmaessig sind - clang hat da eine Warnung ausgespuckt

wäre es nicht besser solche PACK_BEGIN/END macros zu machen?

Code:

#if defined(_MSC_VER)
#define PACK_BEGIN __pragma(pack(push, 1))
#define PACK_END __pragma(pack(pop))
#elif defined(__GNUC__)
#define PACK_BEGIN
#define PACK_END __attribute__((packed))
#else
#error "Compiler not supported"
#endif

PACK_BEGIN
struct struct_attribs {
    signed char normal;
    signed char current;
    signed char mod;
}
PACK_END;

....

wichtig - das Semikolon muss ans Ende von PACK_END

[HenneNWH]

d.h. du hoffst das der OpenWatcom (V2) das einfach richtiger mit dem C code macht als der Borland Kompiler?

läuft der richtig unter gcc/clang/whatever 32/64bit aber spinnt mit Borland unter DOS?

Genauso isses! Seit Jahren keine Probleme mit GCC/Clang, aber der BCC (der Lümmel) macht einfach nicht was er soll.

Der Tip mit den Packings ist super!


Zwischenstand:
* Binäräquivalenzcodedifferenz = 3932 Bytes
* auskommentierte Zeilen in der symbols.h = 53.1 %
* es kompilieren auch schon einige Dateien (75 / 112) mit dem GCC

[llm]

Genauso isses! Seit Jahren keine Probleme mit GCC/Clang, aber der BCC (der Lümmel) macht einfach nicht was er soll.

würdest du dann src/gen oder src/gen_dos mit Watcom kompilieren? oder beide?

[HenneNWH]

Nur gen. Das ist die geplante Weiterentwicklung des Charaktergenerators.

gen_dos ist ausschließlich für den BCC gedacht um ältere Versionen binär äquivalent zu rekonstruieren und hat eher historischen Charakter.

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3916 Bytes
* auskommentierte Zeilen in der symbols.h = 54.4 %
* es kompilieren auch schon einige Dateien (79 / 112) mit dem GCC

[llm]

ok ich probier mich mal am src/gen bauen

mit BCC 3.1 baut alles

für Watcom fehlen noch ein paar defines und inline-asm Überarbeitung
wasm baut die powerp20.asm problemlos scheitert aber an der AIL (weil die direkt TASM syntax ist) aber man kann ja auch TASM weiterverwenden (oder AIL MASM/WASM kompatible machen) wie die powerp20.asm

mit MVSC,linux/msys2:gcc,clang sieht es gut aus - baut, läuft

und dann bring ich noch die PACK_BEIN/END und die MSVC Kompatibilitäts mini changes rein

[llm]

@HenneNWH

Pull-Request: https://github.com/Henne/BrightEyes/pull/16 - hab mal den Header pack cleanup gemacht
Pull-Request: https://github.com/Henne/BrightEyes/pull/17 - MSVC port (sind nur ein paar Zeilen)

[Obi-Wahn]

@llm: Da ich nicht weiß, wie weit du im Thema zurückgegangen bist: Für dich ist vielleicht das Repo von NewProggie interessant: https://github.com/NewProggie/BrightEyes/actions