Wii-Image

Aus Wiiki
(Weitergeleitet von Wii Image)
Wechseln zu:Navigation, Suche

Ein Wii Image ist ein Datei-Abbild (eine Sicherheitskopie) einer Wii-DVD. Je nach Größe und Dateisystem wird das Image in einer oder mehrere Dateien abgespeichert.



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. Es gibt auch sogenannte Double-Layer-DVD mit nahezu doppelter Größe. Bekannt sind hier die Spiele Super Smash Bros. Brawl (oder kurz SSBB), Metroid Prime Trilogy und Metroid: Other M.

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).

ISO

Kopiert man eine beliebige 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-DVD. Bei ISO-Images ist die Anzahl Verteilung der Nutz- und Füllbytes unerheblich, weil komplett alles abgespeichert wird.

CISO & WBI

CISO steht für Compressed ISO, jedoch ist die Bezeichnung Compact ISO besser, weil genau genommen keinerlei Komprimierung stattfindet. Stattdessen werden einfach Blöcke ohne Nutzdaten beim 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. Im Detail handelt es sich nur um eine Tabelle, die aussagt: ISO-Block in CISO vorhanden (Wert 1) oder ignoriert (Wert 0).

Da Windows die Dateitypen anhand der Endungen ausmacht und der 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.

WBFS

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 Wiimm mit der Entwicklung des WBFS-Managers für Linux (Wiimms ISO Tools) begonnen hatte, hat er auch WBFS-Dateien eingeführt, um besser testen zu können. Und so entstanden 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 Wiimms Imagebezeichnung ("Titel [ID6]") als Standard übernommen.

→ Weitere Details zu WBFS

WDF

WDF ist eine eigene Entwicklung von Wiimm. Er 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

Die Entwicklung des Dateiformates WIA war ein akademisches Projekt von Wiimm. Er wusste, dass man entschlüsselte Images viel besser komprimieren kann. Und so entwickelte er dieses Format, in dem Images zuerst entschlüsselt und danach komprimiert werden, vorzugsweise 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.

GCZ

Das Dateiformat GCZ wurde für den GameCube- und Wii-Emulator Dolphin entwickelt. Dabei wird ein Image in Blöcke von 16 KiB aufgeteilt und jeder Block dann mittels deflate (Hauptkomprimierung von ZIP) komprimiert. GCZ wurde ursprünglich für GameCube-Images entwickelt und kann diese sehr gut komprimieren. Da Wii-Images aber verschlüsselt sind, ist eine Komprimierung nutzlos (vergleiche Abschnitt Scrubbing). Daher unterstützt Dolphin auch das für Wii-Images bessere WBFS.

FST

FST steht für File-System und 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.

Wiimms ISO Tools sind die einzigen, die aus einem solchen Dateisystem wieder ein neues Image erstellen können. Dabei ist es egal, ob Dateien verändert, entfernt oder hinzugefügt wurden. Der Patcher von Wiimms Mario Kart Fun nutzt genau diese Fähigkeit.

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, was 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 aufgrund ihrer Blockgröße von >=2MiB automatisch.

Partitionen

Der restliche Teil der Disc enthält die Partitionen. Die Offset-Adressen und Partitions-Typen (UPDATE, DATA, CHANNEL) sind durch die Partitions-Tabellen 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 (also 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).

Beispiel: Partitionsüberblick von Mario Kart Wii:

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: Datei-Listing von Mario Kart Wii:

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:

 char disc_id;
 char game_code[2];
 char region_code;
 char maker_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. Genau genommen sind es noch mehr, da BOOT.BIN, TICKET und TMD in jeder Partition unterschiedlich sind,

Beispiel 1: IDs von Mario Kart Wii:

  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

Beispiel 2: IDs von Super Smash Bros. Brawl:

  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 #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.

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

Savegame

Die Savegame-Datei innerhalb der Wii wird durch die ID4 von TICKET und TMD festgelegt, die immer identisch sein müssen. Relevant hierfür sind die IDs der Daten-Partition. Hieraus ergeben sich zwei besondere Möglichkeiten:

  • Möchte man z.B. einen Clone eines Spieles haben um weitere Profile zu erhalten, dann muss man eines der ersten 3 Zeichen (das 4. ist der Regional-Kode) der IDs von TICKET und TMD der Daten-Partition ändern. Hier empfiehlt sich, den bisher als erstes Zeichen unbenutzten Buchstaben K (Eselsbrücke: K wie Klon) zu verwenden. Lässt man die Disk-ID unverändert, dann bleiben auch die Online-Fähigkeiten erhalten.
  • Ändert man dagegen nur die letzten beiden Zeichen der ID6 im Disk-Header, dann kann man Varianten mit anderen Texturen und Eigenschaften nebeneinander verwenden, die ein Savegame-Datei gemeinsam nutzen. Dieses wird z.B. von Wiimms Mario Kart Fun genutzt.

Bei beiden Varianten scheint die ID6 von BOOT.BIN keine Rolle zu spielen. Bei WBFS-Dateien und WBFS-Partitionen solle die WBFS-ID immer identisch zur Disc-ID sein; alles andere kann USB-Loader und andere Tools verwirren. Auch die Existenz von zwei Dateien mit identischer ID6 verwirrt USB-Loader.

Wiimms ISO Tools sind die einzig bekannten Tools, mit denen man die verschiedenen IDs einzelnen verändern kann.

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 ungenutzten 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 nicht lizenzierte 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 Anordnung kann die Gültigkeit von Daten schnell überprüft werden, ohne dass die ganze DVD durch gerechnet werden muss. Bei einer Datenänderung müssen alle betroffenen Prüfsummen der Hierarchie neu berechnet und damit die Partition neu signiert werden.

Scrubbing

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 setzt der WiiScrubber an. Er füllt einfach die unbenutzten Datenbereiche mit dem Wert 0xff auf. Ein solch behandeltes ISO Image ist immer noch 4482 MiB (=4,7 GB) groß, kann aber nun 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 Dateisystemen 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. Hierdurch 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:

  1. 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.
  2. Es hat sich herausgestellt, dass die Wii immer nur eine Partition zu einem Zeitraum 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.
  3. 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. Es ist bisher nicht bekannt, dass korrektes Scrubbing irgendeinen negativen Einfluss auf ein Spiel genommen hat.

Bei Verwendung eines der oben genannten Dateiformate (WBFS, WDF, ...) werden genau die gescrubbten Blöcke ignoriert und nicht gespeichert. Dieses macht dann die Images unabhängig vom Sparse-Effekt kleiner.

Weiterführende Seiten im Wiiki