ROM-Hacking Tutorial

Wir sammeln alle Infos der Bonusepisode von Pokémon Karmesin und Purpur für euch!

Zu der Infoseite von „Die Mo-Mo-Manie“

    Alle Teile dieses Tutorials werden auf memoryresources.de, board.romresources.net und bisaboard.de veröffentlicht. Spreche ich das Forum an, so meine ich damit board.romresources.net und bisaboard.de, da ich auf meiner Homepage zZ keines habe. Feedback und Fragen könnt ihr aber auf jeder der drei Seiten nach dem Tutorial/dem Teil des Tutorials posten. Ggf werde ich dann die Fragen auch als FAQ ans Ende des entsprechenden Kapitels/Teils anhängen.


    Auch wird sich das Tutorial zu Beginn auf das Hacken der Pokemonspiele der GBA-Generation beschränken und erst im späteren Verlauf Wissen vermitteln, um andere Games und ggf auch Games anderer Konsolen zu hacken.


    Und allgemein, für alle Teile des Tutorials, gilt: das Copyright liegt bei mir. Das Copyright der Bilder, die aus anderen Quellen bezogen wurden, sowie das der verwendeten Tools, liegt bei den Erstellern bzw Rechteinhabern. Das Kopieren, in jeglicher Form ist ohne zuvorige Absprache untersagt, Verlinken geht in Ordnung.
    Dieses Tutorial/Teile bzw Kapitel dieses Tutorials sind für memoryresources.de, board.romresources.net und bisaboard.de gedacht.


    0 [Vorwort] Und so erschuf Arceus das Universum...


    0.1 Inhaltsangabe



    0.2 Einleitung


    Bevor wir zum eigentlichen Tutorial kommen, muss ich noch ein paar Dinge loswerden, die sich auch jeder durchlesen sollte, der vorhat, dieses Tutorial oder einen Teil davon zu lesen. Das Wichtigste wohl zuerst: ROM Hacking ist nicht immer einfach, ein guter Hack mit neuer Story, neuen Maps, Grafiken usw. dauert meist Jahre, es gibt oft Rückschläge, da etwas nicht so funktioniert wie es soll, und die ROMs können crashen.


    Ok, jetzt habe ich wohl viele verschreckt, die bisher noch nichts mit dem ROM Hacking zu tun hatten, aber dies musste sein, damit ihr nicht mit falschen Erwartungen an die Sache herangeht. Wer glaubt in einer Woche ein ganzes Spiel auf die Beine zu stellen, ist hier fehl am Platz, ebenso wie die Leute, die 20 User suchen, die ihnen den Hack/ein Spiel nach ihren Wünschen erstellen.


    Nach dem ich nun nochmals einige Leser verloren habe, können wir mit den wirklich motivierten Hackern zu einigen Tipps kommen, die euch helfen können, den Weltuntergang zu überleben. Natürlich nicht den echten Weltuntergang, aber einen ROM Crash, was je nach Fortschritt des Hacks einem Weltuntergang gleich kommen kann.
    Da ich alles auch für User ohne jegliche Vorkenntnisse im ROM Hacken erklären möchte, klären wir zunächst den Begriff des ROM Crashes. Was ist also ein "ROM Crash"? Wie ein Auto nach einem Crash nicht mehr richtig funktioniert, so funktioniert auch eine ROM nach einem Crash nicht mehr richtig. Es gibt dabei verschiedene Arten des ROM Crashes, einmal kann die ROM einfach nicht mehr starten, dies kann durch das Überschreiben (eines Teils) des ROM Headers (in etwa die ersten 256 Bytes einer ROM) geschehen, aber auch durch das Überschreiben einer anderen Routine, die für den Start der ROM zuständig ist, das Fehlen von Ressourcen, sprich Grafiken, Sounds, usw., oder fehlerhafte Ressourcen. Dann gibt es die weniger auffälligen Crashes, dass z.B. plötzlich das Pokemon keine EP mehr erhält und die Crashes, die man meist erst sehr spät bemerkt, z.B. wenn eine selten genutzte Routine davon betroffen ist und somit ein Script nicht mehr so funktioniert wie es sollte, da eine Variable vom System nicht mehr gesetzt wird.
    Nach dem nun also die drei Arten der Crashes bekannt sind, stellt sich nun die Frage, wie man etwas dagegen unternehmen kann. Einfachste Lösung: Macht Backups. Startet die ROM nicht mehr oder gibt es sonstige Freezes nach einer Änderung, nehmt das letzte Backup. Dies setzt zwar Tests nach Änderungen in der ROM voraus, aber es ist immer noch besser, als dass ein halbfertiger Hack nicht mehr funktioniert und man wieder alles neu einfügen darf. Solltet ihr eine Fehlfunktion in der ROM bemerken, so könnt ihr natürlich auch hier ein Backup verwenden, ggf kann man auch aber auch im Forum weiterhelfen.
    Solltet ihr den Crash erst sehr spät bemerken, die Backups haben nichts genützt und im Forum konnte euch auch nicht geholfen werden, so gibt es wohl nur noch die Möglichkeit, alles in eine clear ROM (nicht modifizierte/gehackte ROM) zu übertragen.


    Damit hätten wir nun eigentlich auch schon die/den wichtigen Tipp(s) für den Anfang. Um jedoch nun überhaupt hacken zu können braucht man ein paar Tools und eine ROM.


    Es gibt mehrere Wege an eine ROM zu kommen. Einmal kann man sie sich downloaden. Das ist jedoch illegal und Links zu entsprechenden Seiten sind verboten, googlet einfach danach, wenn ihr so an eine ROM kommen wollt. Eine andere Möglichkeit wäre dann noch, dass man selbst von seinem Spielmodul eine Sicherungskopie (= ROM) erstellt. Dies ist je nach Spielmodul in der Grauzone oder legal, wie genau das geht werde ich hier nicht erklären, da es nicht wirklich etwas mit dem ROM Hacking zu tun hat, Google ist aber auch hier euer Freund.


    Nach dem wir nun also eine Sicherungskopie unseres Spielmoduls erstellt haben, benötigen wir eigentlich nur noch zwei Tools:

    • Der VBA (Link im BB aufgrund der Regeln nicht verfügbar -> Google), ein Emulator für GBA, GBC und GB ROMs.
    • Einen Hexeditor. Der Hexeditor kann euch die ROM anzeigen und war früher das wichtigste und auch einzige Tool zu hacken. Ihr könnt natürlich auch einen anderen Hexeditor nehmen, aber ich verwende den HexeditMX und habe somit auch auf ihn verlinkt.


    Es gibt natürlich noch eine ganze Palette an anderen Tools, jedoch braucht man die meisten davon nicht und wenn doch, so werde ich auf die entsprechenden Tools in den entsprechenden Kapiteln des Tutorials hinweisen.


    Damit könnten wir nun eigentlich auch schon gleich mit dem Tutorial beginnen, jedoch möchte ich zuvor noch anmerken, dass ich einige Grundlagen voraussetze, so also das Wissen, was ein Bit, ein Byte, ein Prozessor/CPU und die RAM ist. ROM werde ich selbst kurz erklären, da der ausgeschriebene Name "Read Only Memory" eigentlich schon sagt, um was es sich handelt: einen Speicher, von dem nur gelesen werden kann. (mit Ausnahmen, die aber erst später angesprochen werden)


    Und bevor ich es vergesse: Ich erwarte von niemandem, das ihm jedes Gebiet, das ich in diesem Tutorial durchnehme, liegt. Jedoch solltet ihr euch dennoch alles durchlesen, da die einzelnen Bereiche aufeinander aufbauen. Sollte etwas nicht wichtig für ein anderes Gebiete sein, so werde ich das ggf in dem entsprechenden Teil erwähnen, aber etwas mehr zu wissen kann eigentlich nicht schaden.




    FAQ zu Kapitel 0


    ---

    1 [Grundkenntnisse] Von 0en und 1en

    [align='right']/align]


    1.1 Zahlensysteme


    Nach den ganzen Einschüben am Anfang muss ich euch leider enttäuschen, es geht noch immer nicht an die ROM, da es noch ein paar weitere Begriffe zu klären gibt. Solltet ihr schon wissen, um was es in den entsprechenden Punkten geht, könnt ihr sie natürlich überspringen.


    In diesem Punkt möchte ich zwei Zahlensysteme ansprechen, die relativ häufig im Hacking verwendet werden. Einmal das hexadezimale und einmal das binäre Zahlensystem. Dass ihr es im Kopf umrechnen könnt, setzt dabei niemand voraus, auch wenn es bei kleinen Zahlen durchaus nützlich ist, nicht auf einen Rechner wie calc.exe unter Windows (ihr braucht die wissenschaftliche Ansicht) zurückgreifen zu müssen.


    Beginnen wir also mit dem Hexadezimalsystem oder auch kurz "Hex". Eine Zahl, die in Hex geschrieben ist, wird meist mit 0x angeführt, etwas seltener auch $, &h oder sie endet auf h. Da jede Stelle einer Zahl im Hexsystem einen Wert von 0 bis 15 annehmen kann, es aber bei uns lediglich 10 verschiedene Ziffern gibt, werden die Buchstaben a bis f wie Ziffern behandelt mit dem Werten 10 bis 15. Ob Groß- oder Kleinbuchstaben verwendet werden spielt dabei übrigens keine Rolle.
    Da ein paar Beispiele wohl das Zahlensystem leichter verständlich machen:

    Code
    0x0 = 00x1 = 10x9 = 90xA = 100xB = 110xC = 120xD = 130xE = 140xF = 150x10 = 160xA0 = 1600xFF = 2550x100 = 256...


    Etwas seltener gebraucht, aber dennoch wichtig ist das Binärsystem. Hier werden nur die Ziffern 0 und 1 verwendet und es wird durch ein b am Ende definiert. Zur Umrechnung würde ich euch hier einen Rechner empfehlen, da es schnell unübersichtlich wird, aber dennoch einige Beispiele, damit ihr versteht, wie das System funktioniert:

    Code
    0b = 01b = 110b = 211b = 3100b = 4101b = 5110b = 6111b = 71000b = 8...


    Damit würde ich dann auch schon diese kleine Lektion abschließen und zur nächsten übergehen. Wirklich verstanden haben müsst ihr hier ja nur, wie man das Zahlensystem, in dem eine Zahl geschrieben ist, feststellt und dass ihr dann die Zahlen über diverse Rechner wie calc.exe unter Windows umrechnen könnt. Die kleinen und wichtigen Zahlen werdet ihr dann schon im Laufe der Zeit lernen, wenn ihr sie denn in eurem Gebiet benötigt.



    1.2 Little und Big Endian


    Diese Lektion ist nur für die User interessant, die tief in die ROM eintauchen, selbst Tools schreiben, Strukturen und andere Dinge researchen und/oder mit dem Hexeditor arbeiten wollen. In jedem anderen Fall nehmen Tools dem Hacker die Arbeit ab, jedoch ist dies nur eine kurze Lektion und ich würde sie wirklich jedem empfehlen kurz durchzulesen.


    Die Begriffe Little und Big Endian werden in der RH Szene zwar selten verwendet, jedoch möchte ich das, was sich dahinter verbirgt, hier mal bei seinem richtigen Namen nennen. Big Endian ist, wenn man eine Zahl, wie gewohnt mit der höchsten Stelle zuerst abspeichert, z.B. 0x1234 würde im Big Endian Format abgespeichert zwei Bytes so füllen: 0x12 0x34. Wir würden es als normal bezeichnen. Little Endian oder auch byteverkehrt abgespeichert würde 0x1234 so die beiden Bytes füllen: 0x34 0x12. In GBA ROMs sind praktisch alle Daten byteverkehrt abgespeichert. Beachtet aber: nur eine ganze Zahl wird im Little Endian Format umgedreht. Will man zwei Bytes 0x12 und 0x34 hintereinander speichern, so dreht man diese nicht um, da jedes für sich eine Zahl darstellt. Auch werden die Zahlen nach Bytes getrennt, wenn man sie umdreht (byteverkehrt eben), daher habe ich hier Hex Zahlen verwendet.


    Etwas schematischer Dargestellt:



    1.3 Offsets & Pointer


    Am einfachsten sind diese beiden Begriffe wohl so zu betrachten:

    • Offset
      Das Offset wird, wie so ziemlich alles beim ROM Hacken, als ein hexadezimaler Wert angegeben und beschreibt eine Position im Speicher. Dies kann somit sowohl die ROM als auch die RAM betreffen. Schaut man sich die ROM im Hexeditor an, so wird man (zumindest in dem, den ich vorgeschlagen habe) das Offset auf der linken Seite finden (s. Bild)

      Achtet im Übrigen immer auf jede Stelle beim Offset, es kann leicht passieren, das man einmal einen 0 vergisst und dann plötzlich ein ganz anderes hat.
    • Pointer
      Pointer, eng. Zeiger, zeigen, wie ihr Name schon sagt, auf etwas. Dies kann ein Bild, ein Script, eine andere Routine oder etwas Ähnliches sein. Um diese Funktion zu erfüllen, stellen sie RAM-Offsets (wird gleich erklärt) dar. Des weiteren sind alle Pointer byteverkehrt abgespeichert.
    • relative Offsets
      Wir haben schon "normale" ROM-Offsets (kurz Offset) kennen gelernt, Pointer, also RAM-Offsets, die an sich gleich aussehen wie die normalen Offsets und deren Unterschiede gleich noch geklärt werden, die auf Daten zeigen, aber es gibt noch relative Offsets.
      Um euch zu beruhigen: Es hat nichts mit der Relativitätstheorie zu tun und solange ihr euch nicht gerade mit ASM (so ziemlich dem Schwersten beim Hacken) beschäftigen wollt, könntet ihr diesen Punkt auch auslassen, ich werde ihn so oder so nun aber auch nur kurz an sprechen und später nochmals aufgreifen, wenn wir es mit ASM zu tun bekommen. Relative Offsets ergeben sich aus dem Ziel-Offset minus dem Offset im Code, an dem der Pointer "angewendet" wird. Diese Art von Offset/Pointer findet aber nur in ASM-Routinen Gebrauch und dort eigentlich auch nur beim Springen auf eine andere (Sub-)Routine.


    Das RAM-Offset ist der Verbindungspunkt zwischen dem Pointer und dem Offset. Die ROM wird entweder teilweise oder komplett in die RAM geladen oder selbst als Teil der RAM betrachtet. In jedem Fall unterscheiden sich somit die Offsets, die während des Spielens für die Daten gelten von denen, die man im Hexeditor oder in diversen Tools angezeigt bekommt. Zum Glück ist aber eine Umrechnung des RAM-Offsets in das Offset nicht wirklich schwer, man muss einfach vom RAM-Offset 0x8000000 abziehen, um zum ROM-Offset zu gelangen (aus dem RAM-Offset 0x08162240 wird dann z.B. 0x00162240).


    Hackt man nun, wird es immer wieder passieren, das man etwas "repointen" muss; den Pointer auf ein Offset ändern muss. Dies geschieht in der Regel, da neue Daten größer sind als alte und man die hinter den alten liegenden Daten nicht überschrieben will. Hierzu muss man nun die Pointer/RAM-Offsets aus den Offsets berechnen. Als Beispiel: Offset 0x1DE98A0 wird zu 0x9DE98A0. Dies macht man mit dem Offset der alten Daten und dem der neuen, schreibt das RAM-Offset byteverkehrt auf und sucht nun einfach im Hexeditor nach dem Pointer. Hat man ihn gefunden, ersetzt man ihn durch den byteverkehrte Pointer auf die neuen Daten. Fertig.


    Auch dies ist keine wirklich lange Lektion. Sollte es noch Fragen geben, so könnt ihr sie gerne stellen.


    Da wir gerade von Offsets reden und gewissermaßen damit auch die Größe einer ROM verbunden ist: Man kann eine ROM vergrößern, in dem man einfach über den Hexeditor ans Ende einige Zahlen anfügt, oder verkleinern, in dem man nicht benutzte Bytes vom Ende löscht. Aus der Mitte heraus löschen geht nicht, da dadurch andere Daten nachrutschen und somit ihre Offsets und dadurch ihre RAM-Offsets nicht mehr stimmen. Man kann dann natürlich die Daten repointen, jedoch ist das ein zu großer Aufwand für einen eher geringen Nutzen und es wird bei ASM-Scripts teilweise etwas schwer, da in diesen, wie schon gesagt wurde, relative Offsets verwendet werden und somit nicht verschobener ASM-Code nun womöglich auf eine Stelle im Verschobenen zeigt, an der sich nicht mehr der richtige Code befindet.
    Die Größe der ROM könnt ihr also frei wählen, jedoch darf sie nie größer als 0x2000000B (32MB) werden. Optional könnt ihr dann aber auch die Größe der ROM an 8MB, 16MB oder 32MB anpassen, was wohl auch bei einigen Flashcards und Emulatoren nötig sein wird, beim VBA aber keine Rolle spielt.



    1.4 Freier Platz


    Wir nähern uns langsam aber sicher dem Hacken, bevor wir damit aber beginnen sollten wir wissen, wohin wir neue Daten schreiben können. Wir wollen ja auch etwas neues einfügen.
    Einige Tools verwenden eine automatische Offsetsuche und es gibt auch Tools, z.B. den FSF (Free Space Finder), mit dem man nach freiem Speicher suchen kann, jedoch würde ich letztere Tools niemandem empfehlen und bei ersteren die Offsetsuche deaktivieren, da sie ganz gern mal Fehler machen und belegten Speicher als freien anzeigen und benutzen. Beachtet man nur ein paar kleine Regeln, kann man den freien Speicher auch ganz leicht und meist auch sicher über den Hexeditor selbst finden.


    Wir öffnen also den Hexeditor - an all jene, die die ROM bisher noch nicht mit ihm geöffnen haben: lasst euch nicht von den Zahlen und Zeichen erschlagen - und wenden direkt die erste Regel an: nehmt unter keinen Umständen ein Offset < 0x100. Diese beinhalten Daten für den Header und dadurch kann die ROM extrem leicht crashen, bzw sie crasht immer, nur manche Emulatoren achten nicht so sehr auf den Header und bemerken somit den Crash nicht. Nun können wir es uns einfach machen und zum Offset 0x800000 gehen, R/S/FR/LG hat dort einiges an freiem Speicher, in Smaragd sieht es schon etwas anders aus, das spielt aber wieder keine Rolle, wenn man es sich nicht so leicht macht und über die Suchfunktion des Hexeditors nach freiem Speicher sucht.
    Bevor wir aber danach suchen, müssen wir wissen, was frei ist. In Smaragd ist er etwas schwerer zu finden, da dort auch 0x00-Bytes frei sein können, jedoch würde ich euch raten diese nicht zu verwenden, da man nicht so sonderlich leicht unterscheiden kann, welche Bytes noch zu einem Bild, einem Script oder einer Routine gehören und welche wirklich frei sind, es kann also zu Fehlern kommen. Sucht also nach 0xFF-Bytes. Diese sind immer frei, wenn sie in größeren Mengen auftreten, sprich bei 0x1000 mal 0xFF oder mehr sollte man auf der sicheren Seite sein. Dies wäre btw die zweite Regel. Also einfach danach suchen und schon habt ihr einen entsprechenden freien Platz gefunden. Am besten schreibt ihr euch auf, wo ihr ihn gefunden habt, da es in den ROMs meist zwei große Bereich gibt, die nicht benutzt werden und somit ist es unwahrscheinlich, das der freie Platz schon nach einmaliger Benutzung voll ist.



    1.5 Patchen


    Da es leider immer wieder passiert, das jemand nicht patchen kann, es aber mit eine der wichtigsten Sachen ist, wenn ihr hacken oder einen Hack spielen wollt, werde ich es hier auch mal erklären.


    Zu Beginn noch die Information, das es mehrere Patchformate gibt. Beim GBA-Hacking wird meist das IPS-Format verwendet - die Erstellung eines IPS-Patches wird auch hier erklärt -, sollte die ROM größer als 16MB (0x100000B) oder ihre Größe geändert worden sein, so kann man keinen normalen IPS-Patch mehr von der ROM erstellen. In dem Fall wird dann meist auf ups zurück gegriffen, da dieses Format jedoch nicht so sehr verbreitet ist, wäre es ratsam bei Verwendung einen Patcher (Programm zum Patchen des Patch-Files auf die ROM, kann aber auch ein Programm bezeichnen, mit dem ein Patchfile aus einer modifizierten Datei erstellt wird. Wobei meist eh beide Funktionen in einem Tool vereint sind) und eine Anleitung mitzuschicken.


    Da ich aber Einschübe so sehr mag, kommt nun vor dem kurzen Tutorial im Tutorial zum Patchen noch etwas Theorie :D
    Was genau ist ein Patch?
    Würden man die gesamte gehackte ROM uploaden, würden wir auch urheberrechtlich geschütztes Material verbreiten -> illegal. Somit kam man also auf die Idee, dass man nur die Änderungen und damit sein eigenes oder allgemein zur Verfügung stehendes Material verbreitet. Dies ist legal und hier kommt der Patchfile ins Spiel. Dieser File enthält alle Unterschiede zur unmodifizierten ROM und kann somit eine andere unmodifizierte ROM über einen Patcher wie den Hack abändern. (Ist etwas schwer auszudrücken... ich hoffe, man versteht, was ich meine.)


    Bevor man etwas patchen kann, braucht man einen Patchfile, somit werde ich zuerst zeigen, wie man einen Patch erstellt und anschließend, wie man patcht.


    Für beide Vorgänge werde ich Lunar IPS verwenden. Dieses Tool könnt ihr hier downloaden: http://fusoya.eludevisibility.org/lips/
    Weitere Tools werden nicht benötigt, jedoch braucht ihr eine unmodifizierte ROM und eine modifizierte um den Patch zu erstellen und eine unmodifizierte ROM sowie einen Patchfile um die Daten zu patchen.


    Das Erstellen eines Patchfiles:

    • Öffnet man also Lunar IPS, sieht es so aus:

      Wir klicken hier nun auf "Create IPS Patch", da wir einen IPS-Patch erstellen wollen.
    • Zuerst wählen wir die unmodifizierte ROM...
    • ... anschließend die gehackte ROM...
    • ... bevor wir den Speicherort des IPS-Files angeben:
    • Nach dem Bestätigen kann es einen Moment dauern, je nachdem wie viele Daten verändert wurden und wie groß die ROM ist. Am Ende sollte jedoch folgende Meldung erscheinen, die es zu bestätigen gilt:
    • Der Patchfile kann nun verwendet oder geuploadet werden.


    Das Patchen einer ROM:

    • Auch hier muss man zuerst Lunar IPS öffnen, nun jedoch auf "Apply IPS Patch" klicken.
    • Als Nächstes muss man die unmodifizierte ROM wählen. Es muss sich dabei um die gleiche ROM handeln, die beim Erstellen des Patches als unmodifizierte ROM (=Base) verwendet wurde. Und die gewählte ROM wird überschrieben, macht also zuvor von euer ROM ein Backup.
    • Nun noch den IPS-File wählen und alles bestätigen:
    • Wieder kann es einen Moment dauern, dann ist die ROM aber auch schon gepatcht und ihr könnt sie verwenden.


    Damit wäre auch diese Lektion zu ende und Teil 0 und 1 des Tutorials abgeschlossen. Nun kommt noch die FAQ zum Kapitel, falls es denn Fragen gibt, bei denen es sich lohnt sie einzutragen und demnächst folgt der nächste Teil, falls dieser nicht schon zum Zeitpunkt des Lesens des Tutorials erschienen ist.




    FAQ zu Kapitel 1


    ---

  • Trikeyyy

    Hat den Titel des Themas von „Mastertutorial“ zu „ROM-Hacking Tutorial“ geändert.