[TUT] ISO- und WBFS-Tutorial

Wiimm

Developer

(309)

Posts: 1,447

Location: Dortmund

Occupation: Software-Entwicklung

Wednesday, July 27th 2011, 6:04pm

[TUT] ISO- und WBFS-Tutorial

ISO- und WBFS-Tutorial

Einleitung

Dieses Tutorial vermittelt einfach nur Wissen und ist im Gegensatz zu den meisten anderen Tutorials keinerlei Bedienungsanleitung. Auf die Idee zu diesem Tutorial bin ich gekommen, weil ich hier und auch in anderen Foren schon mehrfach die folgenden technischen Dinge erklärt habe. Und so dachte ich mir: Um es mir in Zukunft einfacher zu machen, schreibe ich mal kurz ein kleines Tutorial und verweise einfach immer d'rauf.

Zu meiner Reputation:
Ich habe mich bei der Entwicklung meiner ISO Tools sehr intensiv mit dem Aufbau der Wii-Images (Kopien der Wii-DVDs) beschäftigt, um z.B. auch ohne Vorlage neue Images erstellen zu können. Das angeeignete Wissen reicht vom internen Dateisystem bis zu den externen Archiven wie z.B. WBFS, CISO und WDF. Letzteres habe ich sogar selbst entworfen. Ich bin wahrscheinlich einer der ganz wenigen, die sich bis ins letzte Detail mit WBFS und dem internen Aufbau von Wii-Discs auskennen.

Themen

Die folgenden Themen werden durch dieses Tutorial berührt:

Dateiformate ISO, CISO, WBI, WBFS, WDF, WIA und FST.
Aufbau einer Wii-Disc (Disc-Header, Partitionen, IDs, Verschlüsselung, Prüfsummen und Signatur)
Klärung der Begriffe "Scrubbing", "Trimming", "Fake Signing" und "Sparse Files".
LIBWBFS, USB-Loader und WBFS-Manager.
Wie rippt man (oder besser ich) eine DVD.
Überprüfen von Wii-Images und WBFS-Partitionen.

Definitionen

Ich halte mich bei Byte-Mengenangaben an die schon seit 15 Jahren bestehende IEC-Norm und verwende die Dezimalpräfixe und Binärpräfixe entsprechend:

1 GB = 1000 MB = 1000*1000 kB = 1000*1000*1000 Bytes
1 GiB = 1024 MiB = 1024*1024 KiB = 1024*1024*1024 Bytes

Dateiformate

Die Kopie einer Wii-DVD (im weiteren Verlauf "Wii-Image" oder kurz "Image" genannt) ist in der Regel 4 699 979 776 Bytes (= 4,7 GB = 4,38 GiB = 4482 MiB) lang. Ich kenne nur 3 Ausnahmen: Kopien der drei Double-Layer-DVDs Super Smash Bros. Brawl (oder kurz SSBB), Metroid Prime Trilogy und Metroid: Other M. Dabei SSBB hat noch eine weitere Besonderheit, über die ich weiter unten berichten werde.

Kopien dieser DVDs werden in verschiedenen Formaten gespeichert. Bei den Entwicklungen der meisten Formate geht es insbesondere darum, Plattenplatz zu sparen. Daher werden die Inhalte der Wii-Images untersucht und nicht benötigte Datenbereiche ignoriert (=scrubbing). Dieses scrubbing wird näher in den nächsten Abschnitten erklärt.

Mir sind die folgenden Dateiformate bekannt:

ISO

Kopiert man einer beliebigen DVD 1:1 und legt sie auf einer Festplatte ab, so erhält eine sogenannte ISO-Datei. Und dieses gilt natürlich auch für eine Wii-DVDs. Bei ISO-Images ist die Anzahl Verteilung der Nutz- und Füllbytes unerheblich, weil komplett alles abgespeichert wird.

CISO oder WBI

CISO steht for "Compressed ISO", ich finde jedoch die Bezeichnung "Compact ISO" besser, weil genau genommen keinerlei Komprimierung stattfindet. Stattdessen werden einfach Blöcke ohne Nutzdaten heim Speichern ausgelassen. Eine typische Blockgröße ist 2 MiB. In den ersten 32 KiB einer CISO befindet sich eine Mapping-Liste, in der steht, welcher Datenblock der Datei zu welchen Datenblock der ISO gehört. Genaugenommen handelt es sich nur um eine Tabelle, die aussagt: ISO-Block vorhanden (Wert 1) oder ignoriert (Wert 0).

Da Windows die Dateitypen anhand der Endungen ausmacht und dar Dateityp ".ciso" unabhängig von der Wii als tatsächlich komprimiertes Dateiformat vorkommt, haben einige Tools stattdessen die Endung ".wbi" (könnte Wii Backup Image heißen?) verwendet. WBI Dateien sind also nichts anderes als CISO Dateien mit anderer Dateiendung.

Übrigens: Meine Tools schauen in alter Unix-Tradition immer in die Datei hinein um den Dateityp automatisch zu erkennen; Dateiendungen interessieren beim Lesen nicht.

WBFS (Wii Backup File System)

WBFS ist genau genommen kein Image-Format, sondern ein Archiv-Format, da mehrere Images zu einer WBFS-Datei zusammengefasst werden können.

Angefangen hat alles mit WBFS-Partitionen (alternativ zu FAT, NTFS, ext2, ...). Die ersten USB-Loader konnten Spiele nur von solchen WBFS-Partitionen lesen. Als ich damals mit der Entwicklung meines WBFS-Managers für Linux begonnen habe, habe ich auch WBFS-Dateien eingeführt, um besser Tests machen zu können. Und so enstanden WBFS Dateien, die intern identisch zu WBFS-Partitionen sind, nur auf eine andere Art (einfache Datei anstatt Block-Device) gespeichert werden. Es war dann Oggzee, der Autor des beliebten CFG-Loaders, der diese WBFS-Dateien mit nur einem Image als Alternative für komplette WBFS-Partitionen entdeckte und damit den FAT/NTFS-Support für USB-Loader einführte. Dabei hat er auch gleich meine Imagebezeichnung ("Titel [ID6]") als Standard übernommen.

WDF (Wii(mms) Disc File)

WDF ist eine eigene Entwicklung von mir. Damals kannte ich noch das CISO-Format nicht, welches einen ähnlichen Gedanken verfolgt. Ich wollte eine möglichst platzsparende Art haben, um Wii-Images auf einer Festplatte abzulegen. WDF ist im Gegensatz zu CISO und WBFS nicht blockorientiert, sondern teilt das komplette Image in beliebig langen Blöcken von Nutz- und Fülldaten auf. Damit sind die Dateien noch kleiner.

WDF-Dateien sind sogar kleiner als die komprimierten RAR/ZIP Images. Außerdem umgehen sie einen riesen Nachteil dieser komprimierten Images: Auf WDF-Dateien ist der wahlfreie Zugriff (Random Access) auf jede Datenposition möglich. Damit sind WDF-Dateien nicht nur ein wenig kleiner als ihr RAR-Gegenstück, sondern erheblich schneller beim Erzeugen und Lesen. Somit gibt es keinen Grund mehr, reine ISO-Images mittels RAR oder ZIP zu komprimieren.

WIA (Wii(mms) ISO Archive)

Das war mehr ein akademisches Projekt von mir. Ich wusste, das man entschlüsselte Images viel besser komprimieren kann. Und so entwicklete ich dieses Format, indem Images zuerst entschlüsselt und danach komprimiert werden, vozugsweise mit LZMA, dem 7zip Algorithmus. Ein WIA-Archiv nimmt üblicherweise 20-50% weniger Platz ein als eine WDF-Datei; Animal Crossing schrumpft sogar um 83%. Weitere Details zu WIA.

FST (File SysTem)

FST ist genau genommen kein Dateiformat, sondern ein extrahiertes Dateisystem. Dieses bedeutet, dass alle Dateien eines Wii-Images entpackt in einer Verzeichnisstruktur auf der lokalen Platte abgelegt worden sind. Diese Dateien können dann einzeln betrachtet oder modifiziert werden.

Meine Tools erkennen ein solches Verzeichnis, wie jedes andere Dateiformat auch, als Wii-Image und akzeptieren es demnach auch als Quelle. Dabei wird transparent im Hintergrund ein virtuelles Images aufgebaut, was dann kopiert oder analysiert werden kann. Und so ist jedes meiner Tools automatisch ein so genannter Image Builder.

Interner Aufbau eines Images

Eine Wii-Disc besteht aus 2 Datenbereichen: Dem Disc-Header und dem Partitionsbereich.

Disc-Header

Der Disc-Header belegt immer die ersten 320 KiB (Offsetbereich 0-0x4ffff) eines Images. Anhand der aller ersten 6 Zeichen kann man eine Disc identifizieren; es ist das, wass im allgemeinen als ID6 bezeichnet wird. In den ersten 128 Bytes stecken noch diverse Infos z.B. der Disc-Titel und eine Magic (eindeutige Kennung eine Wii-Disc). Im dem dünn benutzen Bereich dahinter befinden sich dann noch bis zu 4 Partitionstabellen, Regionaleinteilung und Infos zur Altersbeschränkung. Der Datenbereich wird dann in den letzten 4 Bytes (Offset 0x4fffc) mit einer weiteren Magic beendet.

Der Disc-Header ist weder verschlüsselt noch signiert noch gibt es irgendwelche Prüfsummen. Alle nicht mit NULL gefüllten Bereiche sollten immer komplett in einer Image-Kopie abgespeichert werden. WBFS und CISO erfüllen dieses augrund ihrer Blockgröße von >=2MiB automatisch.

Partitionen

Der restliche Teil der Disc enthält die Partitionen. Die Offset-Adressen und Partitionstypen (UPDATE, DATA, CHANNEL) sind durch die Partitionstabellen festgelegt. Die Partitionen selbst sind in Blöcke zu je 32 KiB aufgeteilt. Die ersten 4 Blöcke bilden eine Verwaltungseinheit und enthalten TICKET, TMD, H3, CERT und weitere Geometriedaten. Diese Daten werden benötigt, um die Prüfsummen und Signaturen der anderen Blöcke auf ihre Gültigkeit zu untersuchen. Diese anderen Blöcke sind verschlüsselt. Der Schlüssel ist eine Kombination aus einem Teil des Tickets und dem GLOBAL_KEY, der allen Wii gemeinsam ist, allerdings nutzen Korea-Wiis einen anderen GLOBAL_KEY.

Die Partitionen können frei über das Image (die DVD) verteilt werden. Allerdings gibt es offensichtlich ein paar Richtlinien, die von Nintendo bei der Herstellung vorgegeben worden sind:

Ab dem Datenbereich ab Offset 0x50000 (als unmittelbar hinter dem Disc-Header) wird die Update-Partition abgelegt.
Die DATA-Partition (eigentliches Spiel) beginnt immer ab Offset 0xf800000 und geht meistens bis zum Ende der DVD. Bei kleineren Spielen wird nach den Systemdateien ein Loch (unbenutzter Bereich) gelassen, damit die eigentlichen Spieldaten auf den äußeren und damit schnelleren Bereich der DVD gepresst werden.
Die CHANNEL- und weitere Partitionen folgen der DATEN-Partition. Hierzu muss die Datenpartition entsprechend verkleinert werden (Ausnahme Double-Layer DVDs).

Partitionsüberblick von Mario Kart Wii

Source code

index      type    offset ..   end off   size/hex =   size/dec =  MiB
----------------------------------------------------------------------
 0     part.tab     40020 ..     40038         18 =         24
----------------------------------------------------------------------
 0.0   UPDATE 1     50000 ..   aea8000    ae58000 =  182812672 =  174
 0.1     DATA 0   f800000 .. 1155c8000  105dc8000 = 4393304064 = 4190
 0.2  CHANNEL 2 1155d0000 .. 1173f0000    1e20000 =   31588352 =   30
----------------------------------------------------------------------

Der verschlüsselte Teil einer Partition besteht aus einer Reihe von Systemdateien gefolgt von einem modifizierten U8-Archiv, welches schon vor der Wii von Nintendo verwendet wurde. Die Systemdateien sind BOOT.BIN, BI2.BIN, APPLOADER.IMG, MAIN.DOL und FST.BIN, und zwar in der genannten Reihenfolge. MAIN.DOL ist das Hauptprogramm und FST.BIN eine Liste der Verzeichnisse und Dateien im U8-Format, bestehend aus Name, Offset und Größe. Im Grunde ist ein U8-Archiv nichts anderes als die üblichen bekannten Dateisysteme FAT oder ext2, nur halt anders organisiert und vor allem abgemagert und als Readonly realisiert.

Beispiel-Listing von Mario Kart Wii

Source code

  offset     size      size
     hex      hex       dec  path + file
---------------------------------------------------------------
 f800000      2a4       676  ./ticket.bin
 f8002c0      208       520  ./tmd.bin
 f8004e0      a00      2560  ./cert.bin
 f808000    18000     98304  ./h3.bin

       0+     440      1088  ./sys/boot.bin
     440+    2000      8192  ./sys/bi2.bin
    2440+   3b7dc    243676  ./sys/apploader.img
   3dd00+  2a36a0   2766496  ./sys/main.dol
  2e1400+    fae0     64224  ./sys/fst.bin

5dc429d4+    7280     29312  ./files/Boot/savebanner.tpl
5dc49c54+   4a6ee    304878  ./files/Boot/Strap/eu/Dutch.szs
5dc94344+   493c1    299969  ./files/Boot/Strap/eu/English.szs
...

Die mit + gekennzeichneten Offsets sind relativ zum Partitionsbeginn unter Auslassung der eingebetteten Prüfsummen. Man erkennt sofort das Loch hinter der letzten System-Datei.

ID4 und ID6

Ob GameCube- oder Wii-DVD, alle beginnen mit der so genannten ID6. Die folgende C-Definition verdeutlicht den Aufbau:

Aufbau einer ID6

	Source code
1 2 3 4	char disc_id; char game_code[2]; char region_code; char marker_code[2];

Auch BOOT.BIN (Teil jeder Wii-Partition) enthält eine solche ID6 in den ersten 6 Zeichen, TICKET und TMD dagegen nur eine ID4 in der Mitte. So haben wir 4 Stellen, an denen IDs gespeichert werden. Genaugenommen sind es noch mehr, da BOOT.BIN, TICKET und TMD in jeder Partition unterschiedlich sind:

IDs von Mario Kart Wii

Source code

  Disc & part IDs:   disc=RMCP01, ticket=RMCP, tmd=RMCP, boot=RMCP01

  Partition table #0, partition #0, type 1 [UPDATE]:
    Partition IDs:    ticket=.UPP, tmd=.UPP, boot=RELSAB

  Partition table #0, partition #1, type 0 [DATA]:
    Partition IDs:    ticket=RMCP, tmd=RMCP, boot=RMCP01

  Partition table #0, partition #2, type 2 [CHANNEL]:
    Partition IDs:    ticket=.INS, tmd=.INS, boot=_INSZZ

IDs von Super Smash Bros. Brawl

Source code

  Disc & part IDs:   disc=RSBP01, ticket=RSBP, tmd=RSBP, boot=RSBP01

  Partition table #0, partition #0, type 1 [UPDATE]:
    Partition IDs:    ticket=.UPP, tmd=.UPP, boot=RELSAB

  Partition table #0, partition #1, type 0 [DATA]:
    Partition IDs:    ticket=RSBP, tmd=RSBP, boot=RSBP01

  Partition table #1, partition #0, type 0x50384148 ["HA8P"]:
    Partition IDs:    ticket=HA8P, tmd=HA8P, boot=HA8P01

  Partition table #1, partition #1, type 0x50394148 ["HA9P"]:
    Partition IDs:    ticket=HA9P, tmd=HA9P, boot=HA9P01

  Partition table #1, partition #2, type 0x50414248 ["HBAP"]:
    Partition IDs:    ticket=HBAP, tmd=HBAP, boot=HBAP01

  Partition table #1, partition #3, type 0x46424248 ["HBBF"]:
    Partition IDs:    ticket=HBBF, tmd=HBBF, boot=HBBF01

  Partition table #1, partition #4, type 0x50424248 ["HBBP"]:
    Partition IDs:    ticket=HBBP, tmd=HBBP, boot=HBBP01

  Partition table #1, partition #5, type 0x50434248 ["HBCP"]:
    Partition IDs:    ticket=HBCP, tmd=HBCP, boot=HBCP01

  Partition table #1, partition #6, type 0x50444248 ["HBDP"]:
    Partition IDs:    ticket=HBDP, tmd=HBDP, boot=HBDP01

  Partition table #1, partition #7, type 0x50454248 ["HBEP"]:
    Partition IDs:    ticket=HBEP, tmd=HBEP, boot=HBEP01

  Partition table #1, partition #8, type 0x50464248 ["HBFP"]:
    Partition IDs:    ticket=HBFP, tmd=HBFP, boot=HBFP01

  Partition table #1, partition #9, type 0x50474248 ["HBGP"]:
    Partition IDs:    ticket=HBGP, tmd=HBGP, boot=HBGP01

  Partition table #1, partition #10, type 0x50494248 ["HBIP"]:
    Partition IDs:    ticket=HBIP, tmd=HBIP, boot=HBIP01

  Partition table #1, partition #11, type 0x504b4248 ["HBKP"]:
    Partition IDs:    ticket=HBKP, tmd=HBKP, boot=HBKPZZ

  Partition table #1, partition #12, type 0x504c4248 ["HBLP"]:
    Partition IDs:    ticket=HBLP, tmd=HBLP, boot=HBLPZZ

Die relevanten IDs sind die der Datenpartition. Deren ID6 der BOOT.BIN ist identisch mit der ID6 im Disc-Header und deren ID4 in TICKET und TMD sind identisch mit den ersten 4 Zeichen der ID6. Diese Partitions-ID4s legen auch die Savegame-Datei fest.

Im Inhaltsverzeichnis einer WBFS-Partitionen bzw. Datei wird die ID6 übrigens ein weiteres Mal abgespeichert.

Verschlüsselung und Prüfsummen

Die Partitionen sind verschlüsselt, mit Prüfsummen abgesichert und signiert.

Die Verschlüsselung basiert auf AES-128-CBC und soll uns Sterbliche davon abhalten, die Inhalte genauer zu betrachten. Diese Verschlüsselung sorgt auch dafür, dass alle Daten wie Zufallsdaten aussehen. Und mit allen Daten sind auch die ungenutzen Löcher gemeint, die deswegen häufig als Datenmüll bezeichnet werden, obwohl es z.B. einfach nur ein mit NULL gefüllter, aber verschlüsselter, Datenbereich ist.

Mit dem Prüfsummen und Signaturen soll verhindert werden, dass wir Inhalte ändern oder sogar eigene und unlizensierte Produkte erstellen. Anhand der Prüfsummen lassen sich Images auch auf Korrektheit (Stichwort Bad Dumps) untersuchen.

Die Prüfsummen (SHA-1, jeweils 20 Bytes groß) selbst sind in 5 Ebenen organisiert und werden H0..H4 genannt (Hash level 0..4). Dabei wird ein Datensektor von 32 KiB in 32 Blöcke mit je einem KiB aufgeteilt. Im ersten Block werden die Prüfsummen H0 bis H2 abgespeichert, die restlichen 31 KiB enthalten die Inhalte der Dateien.

H0: Für jeweils 1024 Bytes wird eine Prüfsumme gebildet.
H1: Prüfsumme über jeweils 31 H0-Prüfsummen (also über 1 Sektor).
H2: Prüfsumme über jeweils 8 H1-Prüfsummen (also über 8 Sektoren).
H3: Prüfsumme über jeweils 8 H2-Prüfsummen. Diese Prüfsummen werden im Header-Bereich als große Liste gespeichert. Der H3-Bereich ist 0x18000 (=98304) Bytes groß und reicht für 4915 Prüfsummen. Hierdurch wird eine Partition auf maximal 9,5 GiB beschränkt.
H4: Prüfsumme über den kompletten H3-Bereich. Diese H4-Prüfsumme wird in der TMD als Anhang mit Index #0 (content #0) abgelegt.

Die TMD (wie auch das TICKET) ist dann durch eine Signaturkette abgesichert. Durch die hierarchische Anordung kann die Gültigkeit von Daten schnell überprüft werden, ohne dass die ganze DVD durchgerechnet werden muss. Bei einer Datenänderung müssen alle betroffenen Prüfsummen der Hierarchie neu berechnet und damit die Partition neu signiert werden.

Scrubbing und Sparse Files

Komprimiert man ein ISO Image nun mit RAR, ZIP oder Co, dann wird es kaum kleiner. Das liegt an der Verschlüsselung, durch den die Daten wie Zufallswerte aussehen. Und Zufallswerte lassen sich nun mal nicht komprimieren. Es war aber schnell klar, dass Spiele wie Animal Crossing nur 517 MiB der 4482 MiB eine DVD verwenden, und wenn man auf die Update-Partion verzichtet, sogar nur 337 MiB. Und so nahmen Sicherheitskopien auf FAT/NTFS/ext2 unnötiger Weise zu viel Platz weg.

Und hier setzte der WiiScrubber an. Er füllt einfach die unbenutzten Datenbereiche mit dem Wert 0xff auf. Eine solch behandeltes ISO Image war immer noch 4482 MiB (=4,7 GB) groß, konnte aber durch RAR/ZIP nun komprimiert werden, allerdings sehr zeitaufwendig. Der Wert 0xff ist aber unglücklich gewählt, weil es den Sparse-Effekt nicht unterstützt. Bei allen modernen Dateisystemem wie NTFS und ext* (nicht aber FAT) können Sparse-Dateien platzsparend gespeichert werden. Sparse-Dateien sind Dateien, die große Blöcke mit dem konstanten Wert 0x00 enthalten. Diese Blöcke werden dann verwaltet, belegen aber keine Plattenplatz. Allerdings ist die Handhabung etwas problematisch, weil beim einfachen Kopieren häufig die Sparse-Informationen verloren gehen. Andere Programme (z.B. fast alle WBFS Manager) kopieren einfach die ungenutzten Dateien nicht mit und springen einfach an die neue Schreibposition. Hierduch legt das das Betriebssystem ganz automatisch Sparse-Dateien an.

Zurück zum Scrubbing, was bedeutet dies nun im Detail und welche Teile werden gelöscht bzw. ignoriert? Es gibt drei Arten von Scrubbing:

Wie oben beschrieben, kann man die Partitionen nach Belieben ab Offset 0x50000 anordnen. Bei fast allen Spielen befindet sich eine große Lücke zwischen UPDATE- und DATA/GAME-Partition, aber auch zwischen anderen Partitionen, sofern vorhanden. Die erste Scrubbing-Art ist nun das Ignorieren dieser Zwischenräume.
Es hat sich herausgestellt, dass die Wii immer nur eine Partition zu einem Zeittaum nutzt und während des Spieles ist dieses die DATA-Partition. Daher werden die UPDATE-Partitionen und anderen nicht DATA-Partitionen zum Spielen nicht benötigt. Diese können dann einfach komplett ignoriert werden. Allerdings müssen dann auch die Partitionstabellen angepasst werden.
Die dritte und meist wirkungsvollste Art des Scrubbings ist das Ignorieren der ungenutzten Datensektoren innerhalb einer Partition. Dazu wird einfach das Dateisystem der Partition analysiert und Sektoren, die von keiner internen Datei genutzt werden, herausgesucht. Dieses Sektoren können dann ignoriert bzw. mit einer Konstanten wie 0x00 überschrieben werden. Hierbei spielt das optimierte Überwachungssystem der Wii ein Rolle, da es Sektoren nur dann entschlüsselt und die Prüfsummen vergleicht, wenn diese Sektoren tatsächlich benötigt werden.

Üblicher Weise werden alle drei Arten von Scrubbing automatisch angewendet. Viele Programme lassen es aber zu, die verwendeten Methoden auszuwählen (Vergleiche wit: Scrubbing). Es ist bisher nicht bekannt, dass korrektes Scrubbing irgendeinen negativen Einfluss auf ein Spiel genommen hat.

Sonderfall SSBB

Das Spiel Super Smash Bros. Braw (kurz SSBB) stellt in 2 Aspekten einen Sonderfall da. Zum einen ist es eine Double-Layer-DVD, die durch Bugs in älteren cIOS am so genannten Layer-Break falsch eingelesen wurden. Damit war dann auch jeder Dump fehlerhaft.

Partitionen von SSBB

Source code

index      type    offset ..   end off   size/hex =   size/dec =  MiB
----------------------------------------------------------------------
 0     part.tab     40020 ..     40030         10 =         16
 1     part.tab     40040 ..     400a8         68 =        104
----------------------------------------------------------------------
 0.0   UPDATE 1     50000 ..   aea8000    ae58000 =  182812672 =  174
 0.1     DATA 0   f800000 .. 1da550000  1cad50000 = 7697924096 = 7341
 1.0     "HA8P" 1da550000 .. 1daff0000     aa0000 =   11141120 =   11
 1.1     "HA9P" 1daff0000 .. 1dbaa0000     ab0000 =   11206656 =   11
 1.2     "HBAP" 1dbaa0000 .. 1dc568000     ac8000 =   11304960 =   11
 1.3     "HBBF" 1dc570000 .. 1dd0e0000     b70000 =   11993088 =   11
 1.4     "HBBP" 1dd0e0000 .. 1ddc50000     b70000 =   11993088 =   11
 1.5     "HBCP" 1ddc50000 .. 1de718000     ac8000 =   11304960 =   11
 1.6     "HBDP" 1de720000 .. 1df1c8000     aa8000 =   11173888 =   11
 1.7     "HBEP" 1df1d0000 .. 1dfcc0000     af0000 =   11468800 =   11
 1.8     "HBFP" 1dfcc0000 .. 1e08a8000     be8000 =   12484608 =   12
 1.9     "HBGP" 1e08b0000 .. 1e1490000     be0000 =   12451840 =   12
 1.10    "HBIP" 1e1490000 .. 1e2490000    1000000 =   16777216 =   16
 1.11    "HBKP" 1e2490000 .. 1e5d38000    38a8000 =   59408384 =   57
 1.12    "HBLP" 1e5d40000 .. 1e8160000    2420000 =   37879808 =   36
----------------------------------------------------------------------

Ein weiterer Dump-Fehler betrifft das Scrubben. SSBB ist das einzig (mir) bekannte Spiel, welches die zweite Partitionstabelle (Index #1) nutzt. Es gibt eine Programmbibliothek namens LIBWBFS, die von nahezu allen WBFS-Managern und USB-Loadern genutzt wird. Und diese enthält einen schwerwiegenden Fehler: Nur die Partitonstablle mit Index #0 wird beachtet, alle weiteren werden ignoriert. Beim Scrubben werden daher die Datenbereiche der 13 letzten Partitionen beginnend ab einer Blockgrenze komplett ignoriert, allerdings ohne die zweite Partitionstabelle anzupassen. Damit erhält man dann ganz automatisch einen Bad Dump, der natürlich nur Programmen auffällt, die die anderen Partitionstabellen auswerten. Dummerweise sind die IOS der Wii solche Programme, was dann zu Hängern (engl. freeze) führen kann. Ganz allgemein kann man SSBB nur im 1:1 Modus (Scrubbing deaktiviert) richtig rippen.

Trimming

Während beim Scrubbing Datenbereiche ignoriert werden, werden beim Trimming Datenbereiche an neue Positionen verschoben. Ziel hierbei ist es, dass Ende des letzten genutzen Datenbereiches nach vorne zu verschieben und das Image dann am Ende zu kürzen. Es drei Arten des Trimmings:

Das Verschieben ganzer Partitionen. Dieses ist sehr einfach, da nur die Offsets in den Partitionstabelle korrigiert werden müssen, Prüfsummen und Signaturen bleiben intakt.
Das Verschieben von Sektoren inerhalb einer Partition. Es werden also nur die sonst ignorierten Sektoren ausgelassen. Im Inhaltverzeichnis (FST.BIN) müssen dann die Offsetzt der Dateien neu berechnet werden. Außerdem müssen Prüfsiummen und Signatur erneuert werden, was zu einem Fake Signed Image führt.
Die dritte Variante arbeitet sehr ähnlich wie die vorherige Sektor-Trim-Variante, jedoch werden die einzelnen Dateien verschoben. Dieses ist aufwendiger zu programmieren und spart nur gering mehr Platz ein.

Trimming ist nur interessant, wenn man das Image als ISO-Datei speichert. Alle anderen Formate verwalten die Löcher ja automatisch, so dass das Trimming nur eine geringe oder sogar keine Platzersparnis mit sich bringt.

Hinweise zum Rippen

Ich persönlich sehe 2 gute Varianten zum perfekten Rippen von Spielen, wobei ich die 2. nur experimentell genutzt habe:

Alle aktuellen USB-Loader können Original-DVDs schnell einlesen und auf die WBFS-Platte oder als WBFS-Image abspeichern.
CleanRip scheint auch ein sehr gutes Homebrew-Tool zum Rippen zu sein. Ich selbst hatte es nur angetestet.

Bei allen Ripping-Varianten ist es wichtig, aktuelle cIOS zu verwenden, die keine systematischen Fehler wie den Layer-Break-Bug enthalten.

Ich selbst nutze den CFG-Loader mit der Einstellung "install_partitions=1:1" in der Datei config.txt und mache das Scrubben später mit meinem eigenen Tool wit. Denn alleine aus analytischen Gründen liegt mir viel daran, dass alle Partitionen erhalten bleiben. Außerdem führe ich immer ein VERIFY (siehe nächsten Abschnitt) durch um einen korrekten Dump sicherzustellen.

Überprüfen von WBFS und Wii-Images

Meine ISO Tools können einzelne Images auf Bad Dumps, aber auch ganze WBFS-Partitionen auf Konsistenz überprüfen.

Images verifizieren

Genauso wie die Wii die Korrektheit der Daten anhand der Prüfsummen und Signaturen testen kann, können das auch eigene Tools machen, aber mit dem Ziel, Bad Dumps aufzuspüren.

Das Verfahren ist ganz einfach: Man entschlüsselt das Image, berechnet die Prüfsummen neu und vergleicht diese mit den abgespeicherten Prüfsummen. Auch die Signatur kann überprüft werden. Und genau das machen die VERIFY-Kommandos der beiden Tools wit und wwt. Dieser Vorgang ist allerdings sehr zeitaufwendig, da pro 1 MiB Daten 64 AES-128-CBC Entschlüsselungen und 1029 SHA-1 Prüfsummenberechnungen vorgenommen werden müssen. Für ein rund 4 GiB großes Spiel bedeutet das rund 262 Tausend Entschlüsselungen und die Berechnung von rund 4,2 Millionen Prüfsummen.

wit kann übrigens auch alle Images eines kompletten Verzeichnisse überprüfen, auch rekursiv. Dazu muss nur das Verzeichnis als Quelle angegeben werden. Und wwt überprüft automatisch die komplette WBFS-Partition, wenn es nicht durch Optionen eingegrenzt wird.

Nach meinem Kenntnisstand kann nur noch der Wii Back Manager derartige Prüfsummern-Tests durchführen. Ich habe ihn nie genutzt, Stand aber em Autor fig2k4 mit Rat zur Seite. Weitere Ausnahmen sind natürlich die diversen GUIs, die auf meinen Tools aufbauen.

WBFS-Partitionen überprüfen

Neben den Fehlern in den Images können WBFS-Partitionen wie jedes andere Dateisystem Fehler bei den Dateizuordnungen und Blockreservierungen haben. Insbesondere ältere USB-Loader und WBFS-Manager, die nicht die später gefundenen Bugs in der LIBWBFS korrigiert haben, können schnell Schaden anrichten.

Mein Tool wwt kann eine WBFS-Partition auf Konsistenz und Korrektheit überprüfen und reparieren, und das in Sekundenschnelle. Die Fehler in der Free Block Table werden übrigens in Bruchteil einer Sekunde erkannt und still beseitigt.

Fehler in der LIBWBFS

Die bereits erwähnte LIBWBFS (Bibliothek, die fast alle Tools und USB-Loader nutzen)) enthält einige kleinere und größere Fehler, so dass ich sie für meine Tools komplett neu und auch erweitert implementiert habe. Die Fehler reichen von falschen Berechnung der WBFS-Größe bei der Initialisierung über das Vergessen von Sektoren beim Scrubbing (seltener Sonderfall) bis hin zum krassen Fehlverhalten, falls die WBFS-Partition (z.B. beim Rippen) voll wird. Weiter oben hatte ich ja schon die fehlende Erkennung der zusätzlichen Partitionstabellen gennant. Insgesamt wurden Ende 2009 bis Mitte 2010 rund ein Dutzend Bugs gefunden, gut die Hälfte von mir. Alle Fehler wurden bei GBAtemp dokumentiert und diskutiert. Dieses bedeutet auch, dass alle Tools, die vor dem genannten Zeitraum zuletzt aktualisiert worden sind, garantiert die Fehler noch drin haben; der beliebte WBFS-Manager 3.0 gehört dazu.

Hinweise zu meinen Tools

In diesem Tutorial habe ich mehrfach von meinen Tools gesprochen, die sehr mächtig sind. So habe ich alle hier gezeigten Listings mit ihnen erstellt. Daher widme ich ganz selbstlos den letzten Abschnitt meinen eigenen ISO Tools.

Wiimms ISO Tools sind Kommandozeilentools. Das bedeutet, dass in einer Kommandozeile genau beschrieben werden muss, was zu erledigen ist. Während der Ausführung öffnet sich ein Text-Fenster (es handelt sich NICHT um ein DOS-Fenster!) und die eingestellten Ausgaben erscheinen. Nach Beenden des Programmes schließt sich dieses Textfenster wieder automatisch. Das Programm wartet also niemals auf eine Benutzerbestätigung; und das ist so gewollt, weil nur so der automatische Betrieb in Batchdateien und Scripte möglich ist. Benutzer sollten daher eine Textkonsole öffnen, unter Windows geschieht dieses durch das Starten des Programmes cmd.

Erschwerend kommt hinzu, dass ich die Tools unter Linux entwickle und die Windows-Version ein Cygwin-Portierung ist. Daher müssen alle Dateipfade mit einem Vorwärtsschrägstrich '/' angegeben werden, z.B. E:/images/wii/mkw.wdf. Außerdem müssen Dateinamen, die Leerzeichen enthalten, in Anführungszeichen eingeschlossen werden. Weitere Details zur Kommandozeile in englisch

Alternativ kann man auch GUIs für meine Tools verwenden, was die Bedienung für ungeübte Nutzer erheblich vereinfacht. Es gibt mehrere GUIs, die aktuellen sind auf der wit-Homepage (wit.wiimm.de) aufgeführt. Ich persönlich verwende diese GUIs nicht und kenne auch nicht deren Funktionsumfang. Im Grunde weiß ich nur, dass sie existieren. Daher kann ich keinerlei Support für die GUIs geben und werde auch alle diesbezüglichen Anfragen stillschweigend ignorieren. Desweiteren gebe ich auch keinen Privatsupport via PN, und das steht so auch in meiner Signatur.

Für Rückfragen stehe ich bereit, Wiimm

Turnier

Wiimms Mario Kart Fun 2012-01
Mittwochs & Donnerstags ab 19 Uhr

Wiimms Mario Kart Boost 2012-03
Jeden 1. Mittwoch im Monat

mit Team-Speak (freiwillig)
FC: Wiimm=0432-5226-7951, AndyK=2966-7682-2066
Wiimms Tools

WIT: Wiimms ISO Tools
Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

SZS: Wiimms SZS Tools
Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.
MKW Custom Tracks

Wiimms Mario Kart Boost 2012-03
Wiimms Mario Kart Fun 2012-01
Neue MKW Custom Tracks
Mario Kart Fun -- Turnier-Serie

PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.

This post has been edited 7 times, last edit by "Wiimm" (Apr 14th 2012, 11:08am)

Wii Freund

Homebrew-User

(23)

Posts: 133

Thursday, July 28th 2011, 7:31am

Quoted from "Wiimm"

schreibe ich mal kurz ein kleines Tutorial

Wie sehen denn dann große Tutorials aus?
Aber auch dieses kleine Tutorial ist nicht schlecht. Evtl. könntest du die funktionsweise des trucha bugs noch erklären, dann ist es perfekt.

Fan von CFG Loader und WIT (ISO und WBFS Manager)