+- Crystals-DSA-Foren (https://www.crystals-dsa-foren.de)
+-- Forum: Allgemeines zur Nordlandtrilogie DOS (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=20)
+--- Forum: Technische Werkstatt (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=34)
+--- Thema: Reverse Engineering der NLT II (/showthread.php?tid=5383)
RE: Reverse Engineering der NLT II - llm - 14.08.2025
(14.08.2025, 14:11)Obi-Wahn schrieb: @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
ja das repo kenn ich - bin soweit zurück bis HenneNWH wieder aktiv geworden ist
und HennenNWH pusht so viel das das Repo schon >300 commits behind ist
RE: Reverse Engineering der NLT II - HenneNWH - 14.08.2025
Das ist bei diesem Projekt auch absolut notwendig.
Der heutige Tag stand unter dem Motto "besondere Schatztruhen und Funktionspointer".
In diesem Bereich ist viel geschafft, obwohl noch viel zu tun ist.
Ein Commit von Ilm wurde auch schon integriert. :-)
@Ilm: PowerPack20 und Watcom. Das ist schonmal gut, dass das funzt.
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3916 Bytes
* auskommentierte Zeilen in der symbols.h = 56.9 %
* es kompilieren auch schon einige Dateien (78 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - llm - 15.08.2025
(14.08.2025, 21:40)HenneNWH schrieb: Ein Commit von Ilm wurde auch schon integriert. :-)
aber es fehlt noch einer
(14.08.2025, 21:40)HenneNWH schrieb: @Ilm: PowerPack20 und Watcom. Das ist schonmal gut, dass das funzt.
ja einige Sachen lassen sich schon mit Watcom kompilieren - aber ist noch nicht vollständig
muss noch ein paar #if defined anpassen und hoffe das der Watcom sich weiter so kompatibel verhält wie bisher
(14.08.2025, 21:40)HenneNWH schrieb: Zwischenstand:
* Binäräquivalenzcodedifferenz = 3916 Bytes
* auskommentierte Zeilen in der symbols.h = 56.9 %
* es kompilieren auch schon einige Dateien (78 / 112) mit dem GCC
kommst gut voran
RE: Reverse Engineering der NLT II - HenneNWH - 15.08.2025
@Ilm: Dein 2-ter Commit ist integriert!
Bei BrightEyes ist kleinschrittiges Arbeiten notwendig. Es soll ja nichts kaputt gehen.
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3870 Bytes
* auskommentierte Zeilen in der symbols.h = 61.4 %
* es kompilieren auch schon einige Dateien (82 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - llm - 16.08.2025
ich hab ein Branch für den OpenWatcom V2 DOS gen.exe built aufgesetzt und meine ersten Änderungen gepusht (noch nicht PR ready)
https://github.com/LowLevelMahn/BrightEyes/tree/llm/watcom_build
relativ liebevoll die Änderungen eingebracht - vielleicht mag ja jemand mit drauf schauen - ich weiss noch gar nicht so genau wie ich testen kann ob das Ergebnis dann auch richtig läuft
das sind noch Kompilierfehler
Code:
CDA_CODE.C(493): Warning! W131: No prototype found for function 'harderr'
CDA_CODE.C: 515 lines, included 3250, 1 warnings, 0 errors
NGEN.C(1965): Error! E1151: Parameter count does not agree with previous definition
NGEN.C(1965): Note! N2002: 'mouse_isr' defined in: NGEN.C(1911)
NGEN.C: 7826 lines, included 4638, 0 warnings, 1 errors
VGALIB.C: 693 lines, included 1817, 0 warnings, 0 errors
POWERP20.C(26): Warning! W135: Shift amount too large
POWERP20.C(26): Warning! W135: Shift amount too large
POWERP20.C(31): Warning! W135: Shift amount too large
POWERP20.C: 141 lines, included 818, 3 warnings, 0 errorsbeim Linken bin ich noch nicht
mein bisheriges Build-Script (build_ow2.bat) liegt so im Repo
Code:
@echo off
set tools_dir=f:\projects\fun\dos_games_rev\tools
set WATCOM=%tools_dir%\open-watcom-2_0-c-win-x64
set WATCOM_BIN=%watcom%\binnt64
set INCLUDE=%watcom%\h
set PATH=%WATCOM_BIN%;%PATH%
echo start dos build > doscomp.txt
wcc -bt=dos -ml -ox -2 -s -fp3 CDA_CODE.C >> doscomp.txt 2>&1
wcc -bt=dos -ml -ox -2 -s -fp3 -IAIL NGEN.C >> doscomp.txt 2>&1
wcc -bt=dos -ml -ox -2 -s -fp3 VGALIB.C >> doscomp.txt 2>&1
wcc -bt=dos -ml -ox -2 -s -fp3 POWERP20.C >> doscomp.txt 2>&1
rem TASM.EXE /os /z POWERP20.ASM POWERP20.OBJ >> doscomp.txt 2>&1
rem TASM.EXE /m /w+ /ml /iAIL AIL\AIL.ASM AIL.OBJ >> doscomp.txt 2>&1
rem TLINK @TLINK.RES >> doscomp.txt 2>&1RE: Reverse Engineering der NLT II - llm - 16.08.2025
Hätte jemand interesse meinen VS2022 build der gen.exe zu testen?
hier kann hier keine Anhänge einstellen also habs ichs mal unter (https://www.file.io/ -> limewire) hochgeladen
https://limewire.com/d/96IKR#dLBhyZ6kwo
RE: Reverse Engineering der NLT II - Crystal - 16.08.2025
7zip-Dateien sind erlaubt. Du bist berechtigt, Attachments hochzuladen, aber das Archiv bei Limewire scheint kaputt zu sein. Kein Wunder, dass es dann hier auch nicht geht.
RE: Reverse Engineering der NLT II - Obi-Wahn - 16.08.2025
Bei mir schlägt der Virenscanner an, wenn ich versuche die Datei herunterzuladen. Vermutlich gibt es irgendeine False-Positive-Erkennung. Komisch, das gab es bei meinen gen.exe vorher nie.
RE: Reverse Engineering der NLT II - llm - 16.08.2025
Zitat:7zip-Dateien sind erlaubt. Du bist berechtigt, Attachments hochzuladen, aber das Archiv bei Limewire scheint kaputt zu sein. Kein Wunder, dass es dann hier auch nicht geht.
Danke - hab das Upload-Feld unten übersehen
Zitat:Bei mir schlägt der Virenscanner an, wenn ich versuche die Datei herunterzuladen. Vermutlich gibt es irgendeine False-Positive-Erkennung.
dann denke ich das LimeWire da was verändert hat - lokal ist die 7zip durch den Defender und VirusTotal ohne Meldungen
Zitat:Komisch, das gab es bei meinen gen.exe vorher nie.
abhängig vom Kompiler ist der gen.exe Maschinen-Code stark unterschiedlich und so wie ich das sehe gab es bisher keine VS2022 builds, oder?
ausserdem hat scheinbar dieses "LimeWire" irgendwas mit der 7z gemacht
hab jetzt die Datei angehängt (ngen_cl.exe - cl ist der Microsoft Kompiler und SDL2 2.30.11.0, SDL2_mixer 2.8.1.0 dlls) - und noch meinen Borland C++ 3.1 DOS build (ncgen.bc.7z) - aus meinem Watcom-Branch (mit kleinen Assembler-Fixes für die Kompatibilität mit dem Watcom Kompiler)
wäre schön wenn die einer "richtig" testen könnte und mir sagen ob sich beide normal verhalten
RE: Reverse Engineering der NLT II - HenneNWH - 16.08.2025
Aus verlässlicher Quelle kann ich bestätigen, dass der Quellcode von BrightEyes keinerlei Schadcode enthält.
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3854 Bytes
* auskommentierte Zeilen in der symbols.h = 64.4 %
* es kompilieren auch schon einige Dateien (80 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - llm - 18.08.2025
und noch als wichtige Info zu Unterschieden DOS/Windows/Linux, bcc/watcom/gcc/clang/msvc
-wenn das enstehende Excutable (z.B. gen.exe) komisches Verhalten zeigt liegt es sehr wahrscheinlich am Source-Code
-alle meine beruflichen Projekte (mehrere Mio Zeilen Code) werden grunsätzlich unter Windows/Linux und gcc/clang/msvc gebaut - bisher habe ich in >10 Jahren nur teilweise Performanz/Optimizer-Unterschiede - und ganz selten Kompiler-Fehler gefunden (vornehmlich in gcc und msvc)
-ich kann mir gut vorstellen das die alten EXE die hier reversed werden recht viel "Undefined Behavior" beinhalten die sich dann stäker auf unterschiedlichen Platformen/Kompilern zeigen
-bei den alten DOS Kompilern können Fehler auch häufiger vorkommen/akzeptiert werden, weil es zu der Zeit recht unüblich war wild zwischen Platformen und Kompilern zu wechseln, d.h. die Fehler wurden einfach lange nicht erkannt, als Normalverhalten empfunden und drum herum gebaut
RE: Reverse Engineering der NLT II - HenneNWH - 18.08.2025
Oha, meine Erfahrung:
(18.08.2025, 07:30)llm schrieb: -wenn das enstehende Excutable (z.B. gen.exe) komisches Verhalten zeigt liegt es sehr wahrscheinlich am Source-CodeEs liegt am Zusammenspiel zwischen Entwicklern, Compiler, Betriebssystem, Source-Code und definierten Zielen.
Am Source-Code kann man jedoch was ändern, ...
(18.08.2025, 07:30)llm schrieb: -alle meine beruflichen Projekte (mehrere Mio Zeilen Code) werden grunsätzlich unter Windows/Linux und gcc/clang/msvc gebaut - bisher habe ich in >10 Jahren nur teilweise Performanz/Optimizer-Unterschiede - und ganz selten Kompiler-Fehler gefunden (vornehmlich in gcc und msvc)Im Studium habe ich mich u.A. mit Rechnerarchitektur und Compilerbau (theoretisch und praktisch) beschäftigt.
Aus meiner Sicht liegen Welten zwischen der etablierten und der Open-Source-Welt.
Die Compileroptimierungen von MSVC/Delphi sind vergleichsweise mager im Vergleich zu GCC/Clang, welche wiederum mager gegenüber dem ICC von Intel ist.
(18.08.2025, 07:30)llm schrieb: -ich kann mir gut vorstellen das die alten EXE die hier reversed werden recht viel "Undefined Behavior" beinhalten die sich dann stäker auf unterschiedlichen Platformen/Kompilern zeigenUm dem Vorzubeugen wird in BrightEyes zwischen 'gen_dos' (BCC-only, nur Rekonstruktion, keine Neuentwicklung, Fehler haben Bestandsschutz) und
'gen' (Weiterentwicklung, Korrekturen, ...) unterschieden.
Und genau das ist eines meiner Anliegen mit BrightEyes, solche unentdeckten Fehler zu entfernen, da unter DOS z.B. kein Speicherschutz vorhanden war,
die Compilermeldungen besser geworden sind und heute mehr Platz auf dem Bildschirm ist.
Es kann und wird passieren, dass die Schicksalsklinge auf modernen Betriebssystemen auch mal abstürzt.
Das gehört zu meinem Plan.
(18.08.2025, 07:30)llm schrieb: -bei den alten DOS Kompilern können Fehler auch häufiger vorkommen/akzeptiert werden, weil es zu der Zeit recht unüblich war wild zwischen Platformen und Kompilern zu wechseln, d.h. die Fehler wurden einfach lange nicht erkannt, als Normalverhalten empfunden und drum herum gebaut
Richtig: Aus Fehlern wird man klug, deshalb ist einer nicht genug!
RE: Reverse Engineering der NLT II - llm - 19.08.2025
HenneNWH schrieb:Es liegt am Zusammenspiel zwischen Entwicklern, Compiler, Betriebssystem, Source-Code und definierten Zielen.
Am Source-Code kann man jedoch was ändern, ...
bei der geringen Menge an Library/OS dependencies von BrightEyes oder gen werden Fehler wohl vornehmlich aus dem Source kommen, die verwendeten Libs sind schon sehr Battle-Proofed auf den enstprechenden Platformen - SDL2 ist da wirklich eine gute Wahl
HenneNWH schrieb:Die Compileroptimierungen von MSVC/Delphi sind vergleichsweise mager im Vergleich zu GCC/Clang, welche wiederum mager gegenüber dem ICC von Intel ist.
der ICC wird seit Jahren immer schwächer gegenüber Clang - aber der Mythos "der Intel" macht den besten Code hält sich hartnäckig
- im Grund haben viele Entwickler kaum Ahnung davon was "Performant" bedeutet oder wie man da hin kommt - auch ein Grund für die Entwicklung von Clang-CL - Microsoft Frontend/Clang Backend, volle integration ins VStudio weil der sich eben wie der Microsoft CL verhält, nebst PDB(Debug Symbole) Erzeugung für den VStudio Debugger und mischbarer Builds mit CL und Clang-CL für Libs/Dlls/ExenHenneNWH schrieb:Und genau das ist eines meiner Anliegen mit BrightEyes, solche unentdeckten Fehler zu entfernen, da unter DOS z.B. kein Speicherschutz vorhanden war,
die Compilermeldungen besser geworden sind und heute mehr Platz auf dem Bildschirm ist.
hast du mal an einen Coverity-Einsatz gedacht - für Open-Source Github Projekte ist das ja kostenfrei und Coverity ist schon sehr mächtig - auch wenn die anderen statischen Analyser da draussen (PVS-Studio, Clang-Tidy, CppCheck etc.) auch keine schlechte Arbeit machen - aber Coverity ist schon noch mal stärker - aber eben super teuer für kommerzielle Entwicklung (ein Kunden von mir hat das im Einsatz und da wird a' 100.000 Zeilen oder so gezahlt - war mal was mit 15-20TEUR im Jahr)
hier anmelden: https://scan.coverity.com/github
HenneNWH schrieb:Richtig: Aus Fehlern wird man klug, deshalb ist einer nicht genug!
meine Erfahrung ist - je mehr unterschiedliche Betriebssystem und Kompiler drauf geworfen werden um so mehr findet man
Bei einem meiner Kunden bauen wir von alt gcc/clang/msvc bis neu und alt Linux/Windows/FreeBSD bis neu, x86/x64/ARM32/64(/früher sogar noch Sparc) alles automatisch durch mit Tests, das alles mit ASAN/TSAN und statischer Analyse - das ergibt schon ein sehr sicheres Gefühl - obwohl klar ist das es immer noch Fehler gibt - oder neue rein kommen
RE: Reverse Engineering der NLT II - HenneNWH - 19.08.2025
(19.08.2025, 07:01)llm schrieb: die verwendeten Libs sind schon sehr Battle-Proofed auf den enstprechenden Platformen - SDL2 ist da wirklich eine gute Wahl
Wenige, verlässliche Abhängigkeiten sind bei mir ein Erfolgsrezept. (19.08.2025, 07:01)llm schrieb: der ICC wird seit Jahren immer schwächer gegenüber Clang - aber der Mythos "der Intel" macht den besten Code hält sich hartnäckig
Vor 10-12 Jahren war ich an einem High-Performance-Computing Wettbewerb beteiligt.
Damals war der ICC messbar weit vorn, aber der Code war in diesem Fall für unser System hochoptimiert "von Intel für Intel".
CLang konnte damals noch kein OpenMP für die Anwendungen zwingend notwendig war.
(19.08.2025, 07:01)llm schrieb: hast du mal an einen Coverity-Einsatz gedacht
Ja, allerdings will ich BrightEyes mit meinen Fähigkeiten alleine durchrocken.
Es sind ja nicht mal 100k betagter Software mit einigen Besonderheiten, die ich selbst noch nicht ganz verstanden hab.
Nach über 15 Jahren kann ich es kaum erwarten "die Schicksalsklinge" zum ersten Mal zu starten und zu gucken ob ich weiterhin alles richtig gemacht hab.
Wenn ich mit meiner Arbeit zufrieden bin, dürfen dann im Nachgang "die Maschinen" drüberschauen und mir mitteilen ob ich etwas übersehen hab.
HenneNWH schrieb:Richtig: Aus Fehlern wird man klug, deshalb ist einer nicht genug!
(19.08.2025, 07:01)llm schrieb: meine Erfahrung ist - je mehr unterschiedliche Betriebssystem und Kompiler drauf geworfen werden um so mehr findet man
Bei einem meiner Kunden bauen wir von alt gcc/clang/msvc bis neu und alt Linux/Windows/FreeBSD bis neu, x86/x64/ARM32/64(/früher sogar noch Sparc) alles automatisch durch mit Tests, das alles mit ASAN/TSAN und statischer Analyse - das ergibt schon ein sehr sicheres Gefühl - obwohl klar ist das es immer noch Fehler gibt - oder neue rein kommen
Wohl Wahr! Darum hab ich mich im Studium auch mit formalen Beweisen und formaler Verifikation beschäftigt:
Wenn's nicht funktionieren kann, muss es auch keiner implementieren und testen. Sehr effizient.
RE: Reverse Engineering der NLT II - llm - 19.08.2025
Howto: Mit CMake + VS2022 IDE die gen.exe bauen/ausführen/debuggen
man braucht SDL2 und SDL2_mixer Libs/Dlls - diese werden direkt vom SDL Projekt zum download angeboten (man kann das auch z.B. direkt über vcpkg machen - dann ist das Package-Management fast wie es unter Linux/Msys2 gemacht wird)
https://github.com/libsdl-org/SDL/releases/tag/release-2.32.8
https://github.com/libsdl-org/SDL/releases/download/release-2.32.8/SDL2-devel-2.32.8-VC.zip <---
https://github.com/libsdl-org/SDL_mixer/releases/tag/release-2.8.1
https://github.com/libsdl-org/SDL_mixer/releases/download/release-2.8.1/SDL2_mixer-devel-2.8.1-VC.zip <---
dann noch die freie oder Pro Variante von Visual Studio 2022 (VS2019,VS2017 sollten auch gehen)
und eine CMake Version von https://cmake.org/download/
dann bauen wir folgende Verzeichnis-Struktur (oder wie es beliebt wenn man sich auskennt)
Code:
C:\temp\BrightEyes_dev
__build <-- wir machen hier einen Out-of-Repo aka Out-of-Source build damit wir keine build-Artefake oder sonstiges in die .gitignore stecken müssen
BrightEyes <- github Repo
3rd_party
SDL2-2.32.8
cmake
docs
...
SDL2_mixer-2.8.1
cmake
docs
...dann per Kommandozeile, es geht auch mit dem CMake-GUI oder direkt in der IDE - aber ich bevorzuge die CMake Basis-Generierung direkt in der Konsole (weitere Änderungen in der CMakeLists.txt werden dann vom VStudio selbständig erkannt und in der Projektansicht/settings nachgezogen - Projektsettings-Änderungen direkt in der IDE überleben maximal den nächsten CMake lauf bei CMakeLists.txt-Änderung)
Code:
cd C:\temp\BrightEyes_dev\__build
cmake -G "Visual Studio 17 2022" -DCMAKE_PREFIX_PATH="C:\Temp\BrightEyes_dev\3rd_party\SDL2-2.32.8;C:\Temp\BrightEyes_dev\3rd_party\SDL2_mixer-2.8.1" ..\BrightEyes\src\genOptional kann man auch -T ClangCL mit abgeben dann wird das ganzen Projekt schon mit dem Clang-CL als Kompiler gesetzt - kann man aber auch in der IDE umstellen
das sollte folgenden Ausgabe ergeben
Code:
C:\Temp\BrightEyes_dev\__build>cmake -G "Visual Studio 17 2022" -DCMAKE_PREFIX_PATH="C:\Temp\BrightEyes_dev\3rd_party\SDL2-2.32.8;C:\Temp\BrightEyes_dev\3rd_party\SDL2_mixer-2.8.1" ..\BrightEyes\src\gen
-- Selecting Windows SDK version 10.0.26100.0 to target Windows 6.2.9200.
-- The C compiler identification is MSVC 19.44.35214.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found OpenMP_C: -openmp (found version "2.0")
-- Found OpenMP: TRUE (found version "2.0")
-- Configuring done (4.9s)
-- Generating done (0.0s)
-- Build files have been written to: C:/Temp/BrightEyes_dev/__buildnoch die beiden Dlls C:\Temp\BrightEyes_dev\3rd_party\SDL2_mixer-2.8.1\lib\x64\SDL2_mixer.dll und C:\Temp\BrightEyes_dev\3rd_party\SDL2-2.32.8\lib\x64\SDL2.dll
in C:\Temp\BrightEyes_dev\__build\Debug
kopieren damit die ngen_cl.exe.exe laufen kann
dann mit der VS2022 IDE die C:/Temp/BrightEyes_dev/__build/NGen.sln öffnen
Fertig!
RE: Reverse Engineering der NLT II - llm - 19.08.2025
QtCreator 17.x unter Windows geht mit direktem Öffnen der CMakeLists.txt von src\gen und setzen des DCMAKE_PREFIX_PATH in den QtCreator Projekt settings
Konfiguration:
Debuggen in IDE:
unter Linux reicht das öffnen der CMakeLists.txt um kompilieren/debuggen zu können
RE: Reverse Engineering der NLT II - HenneNWH - 20.08.2025
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3857 Bytes
* auskommentierte Zeilen in der symbols.h = 67.0 %
* es kompilieren auch schon einige Dateien (86 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - HenneNWH - 21.08.2025
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3849 Bytes
* auskommentierte Zeilen in der symbols.h = 72.6 %
* es kompilieren auch schon einige Dateien (87 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - HenneNWH - 22.08.2025
Zwischenstand:
* Binäräquivalenzcodedifferenz = 3815 Bytes
* auskommentierte Zeilen in der symbols.h = 75.4 %
* es kompilieren auch schon einige Dateien (90 / 112) mit dem GCC
RE: Reverse Engineering der NLT II - Obi-Wahn - 22.08.2025
Die Vorfreude wird immer größer! :-)