Reverse Engineering der NLT II

[siebenstreich]

Ich sehe plötzlich nur noch "Differing Bytes in CODE = 19"! Da war doch vorher immer 20. Zuerst war ich der Meinung, dass das nach aktuellen Änderungen passiert ist. Ich habe das jetzt aber auch mit dem Code von vor einer Woche probiert, und bekomme auch da 19.

Das ist sehr merkwürdig. Kann es sein, dass der BCC bzw. der Linker an diesen ominösen Bytes einen Zeitstempel in das Binary einbaut? Anders ist die Sache eigentlich kaum zu erklären.

[llm]

hast du eine Exe mit den 20 und eine mit den 19 Bytes unterschied?
dann kann ich mal den IDA drauf jagen und dir sagen was das(an der Stelle) ist - Coder oder Daten

[siebenstreich]

Von der 20 Byte Version habe ich leider keine BLADEM.EXE mehr, die wurde überschrieben. Ich werde mir aber die 19er Version aufheben. Wenn wirklich der Compilierzeitpunkt mit reinspielt, sollte das ja demnächst (morgen?) wieder auf 20 Byte umspringen. Ich habe gerade nochmal compiliert: Die erzeugte BLADEM.EXE ist identisch zu der von vor ein paar Stunden, also insbesondere immer noch nur 19 Bytes Unterschied.

Die aktuelle 19er Version kannst du auch selbst mit src/schick/tools/build.sh bauen (der Borland Compiler muss unter drive_c/BCC31 installiert sein).

[llm]

kannst du mir die 19er und die original-Exe anhängen - bin gerade in der Firma, da hab ich IDA - kann da aber kein Borland installieren/"besorgen"  oder PM

[siebenstreich]

Ich hab jetzt selber mal mit einfachen Linux-Bordmitteln draufgeschaut:

Code:

cmp -bl SCHICKM.EXE build/BLADEM.EXE
  17  0 ^@  200 M-^@
  18  20 ^P    0 ^@
86331 260 M-0  52 *
86332 367 M-w  347 M-g
86411 377 M-^? 200 M-^@
86412 377 M-^?  0 ^@
86413  4 ^D    0 ^@
86419 377 M-^?  0 ^@
86420 377 M-^?  20 ^P
86421  4 ^D    0 ^@
86425 102 B    142 b
86426 114 L    154 l
86427 101 A    141 a
86428 104 D    144 d
86429 105 E    145 e
86430 115 M    155 m
86432 105 E    145 e
86433 130 X    170 x
86434 105 E    145 e
86438  1 ^A    13 ^K
86439 312 M-J  351 M-i

Hehe. 

Ein Teil der Bytes hat also eine sehr klare Bedeutung. Im Original steht BLADEM.EXE (Großbuchstaben) drin und im Nachbau bladem.exe (Kleinbuchstaben). Da scheint irgendwie ein kleingeschriebener Dateiname über die dosbox an den BCC durchzusickern! (obwohl als Ausgabe die Datei BLADEM.EXE in Großbuchstaben erzeugt wird). Wenn es gelingt, das zu korrigieren, vielleicht verschwinden dann noch ein paar Bytes mehr.

EDIT: Wie war das, das DOS von damals hat doch gar nicht zwischen Groß- und Kleinbuchstaben unterschieden, wenn ich mich richtig erinnere. Kann es sein, dass die dosbox ein zu neues DOS emuliert, das diese Unterscheidung macht? (anders als das DOS, auf dem Attic 1992 mit dem BCC compiliert hat.)

Außerdem werden bei den 19 Bytes Unterschied offenbar die beiden vorderen Unterschiede (Position 17 und 18, also im Header) nicht mitgezählt.

[llm]

schon mal ein Teil gelöst

kannst du mir die exen noch als zip zukommen lassen?
ich sitz hier bestimmt noch 5h in einem 80 Personen Laber-Meeting und mein Hirn stirbt langsam ab

[siebenstreich]

ich sitz hier bestimmt noch 5h in einem 80 Personen Laber-Meeting und mein Hirn stirbt langsam ab

Verstehe, quasi ein Notfall! Hab dir eine PM geschickt.

[llm]

so siehts bei mir aus:

Exe-Header Unterschied: der Stack ist bei SCHICKM etwas größer, denke der Linker ist dafür verantwortlich

Code:

exe                 ss:sp
SCHICKM.EXE  0x236f:0x1000
BLADEM.EXE    0x236f:0x0080

und der Diff weiter unten ist im IDA in seg014 [exe-fileoffset: 0x14BC0-0x151A7] - leider finde ich das Segment gar nicht im Source (weil wohl Overlay related)
in dem Segment findet sich der String "VDISK", "VDISK FAKE" und weiter unten eben der String BLADEM.EXE oder bladem.exe - wird wohl alles komplett vom Linker erzeugt

   

ich hab mal die Ausgabe von IDA mit angehängt - in Zeile 44396 kommt das seg014

in Zeile 40382 steht auch

Code:

__OVRGROUP dw seg seg014

seg014 scheint also irgendwas mit Overlays zu tun zu haben

ChatGPT sagt zu der Gross/Kleinschreibung

Wenn du keinen Parameter an _ovrinit() übergibst, oder z. B. _ovrinit(NULL)
benutzt, dann ruft der Overlay-Manager intern die DOS-Funktion Get PSP → Command Tail → Program Name
auf und trägt das ein.
Dabei wird der Name aus dem Disketten-/Dateisystem übernommen, genau so, wie DOS ihn geliefert hat — und das kann je nach Quelle Groß- oder Kleinschreibung haben.

[HenneNWH]

Genau so ist es. Das kommt alles vom Linker.

Es gibt 2 unterschiedliche Bytes im EXE-Header für die Initialisierung des Stack-Pointers.

Das seg014 ist das Datensegment für die Overlays.
Die Unterschiede dort sind bladem.exe <> BLADEM.EXE und noch ein paar unrealistische Größen für andere Segmente.

Hab beschlossen da erstmal keine Zeit rein zu investieren und schau mir eure Ergebnisse heute Abend an.

Meetings sind bisher in Angestellteverhältnissen immer eine Katastrophe gewesen. Zuviele Selbstdarsteller, zuwenig Kompetenz.
Meist geht es darum Kompetenz vorzugaukeln, anderen die Zeit zu stehlen und wenig bis gar nichts produktives zu Stande zu bringen.
BTW: Die Meetings mit Siebenstreich waren sehr produktiv und das mit dir Llm sehr informativ.

[Crystal]

BTW: Die Meetings mit Siebenstreich waren sehr produktiv und das mit dir Ilm sehr informativ.

Ich vermute, dass sich unser llm nicht ilm schreibt, sondern eher LLM.
So wie bei "Large Language Model" oder "Legum Magister"...

[HenneNWH]

Danke. Oder wie "Lautstark Lärmendes Monokel".

[llm]

Ist ein Spitzname mit leichtem Dialekt: "Low Level Mahn" - wurde mir ~1998 gegeben

[siebenstreich]

Jetzt sind es wieder 20 Bytes Unterschied, wie ich es vermutet hatte.

Am Offset 00:01:51:A4 steht

• In der originalen SCHICKM.EXE: 0C:01:CA:07
  
• In der am 12.11.2025 compilierten BLADEM.EXE: 0C:0B:E9:07
  
• In der am 13.11.2025 compilierten BLADEM.EXE: 0D:0B:E9:07
  

Damit ist der Fall klar: Das ist das Datum im Format Tag (1 Byte), Monat (1 Byte), Jahr (2 Bytes little endian). Die originale SCHICKM.EXE wurde demzufolge am 12. Januar 1994 compiliert. (Warum 1994 und nicht 1992? -- Weil es sich um die deutlich später erschienene CD-Version handelt.)

Gestern hat also zufälligerweise der Tag des Monats mit dem vom originalen Compilierzeitpunkt übereingestimmt, womit wir nur 19 Bytes Differenz gesehen haben und nicht 20. Im Januar wird das den ganzen Monat lang so sein, und am 12. Januar sind es sogar nur 18 Bytes Differenz.

[llm]

und noch ein paar Bytes weniger die unklar sind - nicht relevant für den Port aber trotzdem sehr interessant das dir das aufgefallen ist

wenn man 

die Stack-Size im Header, 
den 8.3 Dateiname(wobei nicht klar ist ob sich das nach vorne/hinten verschiebt wenn man wirklich einen 12-Zeichen-Dateinamen verwendet)
und das Datum 

ignoriert sind es nur noch sehr wenige Bytes unterschied

[llm]

seg090.cpp Zeile 450

wenn man die sprintf-Zeile so schreibt meckert der gcc/clang und cl nicht wegen Kodierungsfehler - weil neuere Kompiler \x9a nicht als einzelnes Zeichen erkennen und warnen

alt

Code:

sprintf(g_dtp2,
"ALS %s MIT DER BARRIERE KOLLIDIERT, BRICHT SIE IN ST\x9aCKE.\x40"
"DAS GANZE WAR NUR EIN BILD!\x40"
"SCHADE DASS IHR DAS NICHT FR\x9aHER BEMERKT HABT.\0",
hero->alias);

fixed

Code:

sprintf(g_dtp2,
"ALS %s MIT DER BARRIERE KOLLIDIERT, BRICHT SIE IN ST""\x9a""CKE.\x40"
"DAS GANZE WAR NUR EIN BILD!\x40"
"SCHADE DASS IHR DAS NICHT FR""\x9a""HER BEMERKT HABT.\0",
hero->alias);

[llm]

ja, ich sitze wieder in einem Meeting aber hab mir die Clang Warnungs-Liste gemailt  - Sicherheitsvorschriften für die Fertigung - in der ich nie sein werde - weil ich in einem ganz anderen Produkt-Team bin - und Externer, Algorithmen in C++ schreibe, ich muss nicht wissen was ich nach der Inbetriebnahme eines Fertigungs-Roboters tun muss - never

[siebenstreich]

Cool, dass du dir um die Fehlermeldungen Gedanken machst! (Und auch Danke für deine Nachforschungen gestern...)

Es muss halt ggf. sichergestellt sein, dass der BCC die Sachen noch binäräquivalent verarbeiten kann.
An der einen Codestelle oben ist das irrelevant, weil der BCC die gar nicht zu sehen bekommt (ein FEATURE_MOD gegenüber dem Original).

Ich habe deine Änderung mal an meinen aktuellen pull-Request angehängt

[llm]

Es muss halt ggf. sichergestellt sein, dass der BCC die Sachen noch binäräquivalent verarbeiten kann.

das ist alter C Standard mit dem unterbrochenen Strings, du solltest da schön bei deinen 19 oder 20 bytes unterschied bleiben - wenn es denn überhaupt kompiliert werden würde

[siebenstreich]

Es muss halt ggf. sichergestellt sein, dass der BCC die Sachen noch binäräquivalent verarbeiten kann.

das ist alter C Standard mit dem unterbrochenen Strings, du solltest da schön bei deinen 19 oder 20 bytes unterschied bleiben - wenn es denn überhaupt kompiliert werden würde

Das war von mir eigentlich als genereller Kommentar gedacht, was man beim Nachdenken über das Beseitigen der Warnungen im Hinterkopf haben sollte.

Wie gesagt, diese Stelle ist schon allein deswegen aus dem Schneider, weil der BCC sie gar nicht zu Gesicht bekommt.

[HenneNWH]

Großartig, ab jetzt gibt es eine baubare schick_clang.