Jäger und Sammler von Speicheradressen
Bachaalany begann, in mühsamer Kleinarbeit alle Speicheradressen zu sammeln, die von den EUD-Karten genutzt wurden. Dafür startete er die Karten wieder und wieder und führte verschiedene Aktionen aus. "Ich habe diese Karten Hunderte Mal geladen. Die Tastenkombinationen, um mich durch das Menü zu navigieren, kenne ich auswendig", sagte Bachaalany Golem.de. Leider sei es nicht möglich, bestimmte Karten und Ereignisse über die Kommandozeile aufzurufen, was die Arbeit erleichtert hätte.
Im Hintergrund zeichnete Bachaalany auf, welche Befehle und Aktionen ausgeführt wurden und auf welchen Speicherbereich zugegriffen wurde. Außerdem nutzte er den Debugger und Decompiler Ida Pro von Hex-Rays, um Anweisungen des Programms nachzuvollziehen und zu verstehen. An einigen Stellen konnte er auch auf Quellcode von Blizzard zugreifen und diesen mit der Ida-Ausgabe vergleichen.
Als Nächstes mussten die Speicherzugriffe der EUD-Karten erkannt werden. Die Datenbank mit den Speicheradressen diente dabei als Grundlage, um ein neues Speichermanagement zu entwerfen. Dabei werden die hardcodierten Adressen der Karten dann an das eigentliche Interface des modernen Programms weitergegeben, um die Zugriffe zu ermöglichen. Am Ende der sechsmonatigen Entwicklungszeit enthielt die Datenbank etwa 800 Einträge.
Der Emulator verknüpft dann die 'alte' Speicheradresse mit der, an der die entsprechenden Daten im neuen Spiel abgelegt werden, und gibt den erwarteten Wert zurück, damit die Karte weiterhin funktioniert. Diese Datenbank bezeichnet Bachaalany als Shadow Table. Doch das war nur der einfache Teil der Arbeit.
Datenbank mit Speicherzugriffen reicht nicht aus
Die Datenbank zur Übersetzung der Speicheradressen reicht nicht aus, um die Karten lauffähig zu halten. Denn an manchen Stellen wird der Speicherbereich nicht direkt aufgerufen, sondern indirekt von einem Pointer oder einem Trigger. Hier sollte neuer Code die Zuweisung von Speicheradressen vornehmen. Von den Karten aufgerufene Out-of-Bounds-Speicherbereiche analysierte Bachaalany also und wies den entsprechenden Aufrufen Variablennamen zu, um eine dauerhafte Lösung zu schaffen.
An anderen Stellen werden zudem EUD-Adressen aufgerufen, die vom neuen Spiel gar nicht mehr adressiert werden. Hier musste Bachaalany das Verhalten in der alten Spielversion studieren und an einigen Stellen nicht nur den Speicherbereich, sondern auch den Rückgabewerte emulieren.
Neben den Speicheraufrufen waren zahlreiche weitere Anpassungen notwendig, weil Datenstrukturen und Architekturen sich mit dem neuen Release geändert hatten. So waren in Starcraft 1.16.1 Trigger in einer Storm Linked List abgelegt.
Bei Storm handelt es sich um eine Bibliothek, die plattformunabhängige Container für die Listenverwaltung bereitstellt. In Starcraft Remastered werden die Daten hingegen in einem Format abgelegt, das mit den Standard Template Libraries (STL) von C++ kompatibel ist. Auch hier waren also Anpassungen und Übersetzungen notwendig.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Die Karten sind selbst komplexe Programme | Modder bauten einen eigenen Compiler |
und hätte Blizzard die Sicherheitslücke sofort nach bekanntwerden gepatcht, hätten sich...
Also unser Unternehmen kann auf über 20 Jahre alten Code zurückgreifen. Irgendwann wurde...
DANKE. Die Begründung ist herrlich :-D Ich bin also wie C 8-)
In dem Fall wird das per Mapping entschieden.
Was würdest du denn erwarten? Die Präsi von dem hätte ich mir auf jeden Fall gar nicht...