Auf der 33C3 wurde Sighax gezeigt und am 20. Mai 2017 veröffentlicht. Dabei handelt es sich um einen Bootrom-Exploit für den 3DS. Da es immer noch viele Missverständnisse gibt, was Sighax eigentlich genau ist und wo der Unterschied zu arm9loaderhax ist, hat SciresM mal aufgeklärt.
Sighax ist ein Exploit, der einen Fehler in der ARM9-Bootrom ausnutzt, um invalide Signaturen für fremde Firmware als valide erscheinen zu lassen. Das heißt, dass der 3DS dann eine modifizierte Firmware bootet, die nicht von Nintendo stammt, aber die Konsole selbst "denkt", dass dies so wäre. Normalerweise wird eine modifizierte Firmware abgelehnt, wenn der Header der Firmware-Partition im NAND geändert wird. Sighax erlaubt es jedoch, jeden modifizierten Firmware-Header valide zu machen und so kann eigener Code von den Firmware-Partitionen im NAND ausgeführt werden.
Für eher nicht so technisch-begabte: Eine Signatur ist ein "Beweis der Echtheit", welche normalerweise nur Nintendo generieren kann. Eine valide Signatur heißt demzufolge, dass dieser Inhalt von Nintendo stammt/stammen sollte.
Wieso hat die Veröffentlichung so lange gedauert?
Dazu musste eine "perfekte" Signatur gefunden werden, die für jede Firmware valide ist. Um zu wissen, welche Signaturen perfekt sind, muss der Code, der die Signaturen in der geschützten ARM9-Bootrom parst, angesehen werden. Das Dumpen der ARM9-Bootrom ist nur mit spezieller Hardware möglich gewesen, was sehr lange gedauert hat.
Was kann man mit Sighax tun?
Um zu verstehen, was uns mit Sighax ermöglicht wird, müssen wir zuerst verstehen, was passiert, wenn der 3DS angeschaltet wird und was arm9loaderhax tut. Es wird kompliziert, also aufmerksam lesen! Wenn der 3DS angeschaltet wird, liest die Bootrom die Firmware in den Speicher, validiert sie, sperrt sich selbst bei erfolgreicher Validierung und startet die Firmware.
Arm9loaderhax nutzt eine "Eigenart" in einer bestimmten Firmware-Revision aus. Der New3DS hat ein Stück Code, eine Art Mittelsmann, der vor der eigentlichen Firmware geladen wird – der arm9loader/kernel9loader. Dieser ist dafür zuständig, die New3DS-Firmware zu entschlüsseln. Er tut dies mit Schlüsseln, die im NAND gespeichert sind (aus der OTP-Region generiert, die danach gesperrt wird); danach wird die Firmware gestartet. Arm9loaderhax nutzt die fehlerhafte Validierung in einer bestimmten Revision vom arm9loader aus, um Kontrolle zu erlangen, bevor die Firmware gestartet wird.
Sighax ersetzt die Firmware-Partition direkt – die Bootrom lädt damit unsere Firmware, anstatt der arm9loader.
Hier eine kleine Übersicht über den Bootprozess:
- Normaler Start: Bootrom -> Bootrom sperrt sich -> Arm9loader -> OTP sperrt sich -> Firmware
- Mit arm9loaderhax: Bootrom -> Bootrom sperrt sich -> Arm9loader -> OTP sperrt sich -> Unser Hax
- Mit Sighax: Bootrom -> Bootrom sperrt sich -> Unser Hax
Damit ist es viel einfacher zu verstehen, wie sich Sighax von arm9loaderhax unterscheidet. Sehr wichtig ist, dass bei beiden Hacks die originale Nintendo-Firmware nicht geladen wird – stattdessen wird unser Hack geladen. Mit arm9loaderhax erlangen wir nach dem arm9loader und OTP-Lockout Zugriff, aber noch vor der Firmware. Mit Sighax erlangen wir Zugriff, wenn der arm9loader gestartet wird – also noch vor dem OTP-Lockout.
Da Sighax so früh startet, braucht es weniger Vorbereitung für die Installation. Ihr kennt alle das nervige Prozedere: Bei der Installation von arm9loaderhax muss zuerst die OTP gedumpt werden, was nur auf 2.1 geht, da die OTP-Region dort nicht gesperrt wird. Damit lassen sich dann Berechnungen durchführen, um die "gefälschten" Schlüssel zu erstellen. Sighax braucht keinen Dump der OTP. Mit Sighax kann außerdem die geschützte ARM11-Bootrom gedumpt werden.
Für Endnutzer läuft es am Ende auf das gleiche hinaus – ein Payload wird einfach von der SD-Karte geladen und gestartet. Lediglich der Installationsprozess wird stark vereinfacht.
Dinge, die Sighax erlaubt, aber arm9loaderhax nicht:
- Ausführen, ohne, dass die OTP-Region gesperrt wird
- Nintendo kann die Installation nicht verhindern, außer mit einer neuen Hardware-Revision
- Trotzdem werden entweder ein Hardmod oder ein ARM9 Kernel-Exploit benötigt
- Einfachere Installation ohne 2.1-Downgrade
- Dumpen der geschützten ARM11-Bootrom
- Mit anderen Sicherheitslücken ist es vielleicht möglich, die ARM9-Bootrom zu dumpen – das wäre zwar lustig, aber sinnlos, da Sighax für die Installation schon einen Dump dieser braucht
- Eine saubere Umgebung für Entwickler
Dinge, die Sighax NICHT erlaubt, aber die User glauben es, dass dies möglich ist:
- Eine "echte CFW", anstatt die "Firmware zu patchen" – Arm9loaderhax läuft, bevor die Firmware geladen wird, wie man oben lesen konnte. Eine "echte CFW" ist auch mit arm9loaderhax möglich, es hat nur noch keiner eine gemacht
- Quasi alles, was nicht in der Liste oben steht
Dieser Beitrag ist eine Übersetzung aus dem Englischen, plus ein paar kleine Ergänzungen. Der Originalpost stammt von SciresM.
Hey 🙂
Ich habe nur nochmal kurz ne Frage
Ich habe meinen Arm9LoaderHax New3DS geupdated auf Boot9strap.
Da man mit Arm9 ja auf 2.1 downgraded um die otp auszulesen.
Jetzt habe ich mal 3dsident geöffnet und die Kernel version ist auf 2.54-0 und die FIRM version auch ist das normal ? Danke im vorraus
Das passt schon so, die Version des Kernel und der FIRM ist immer anders – Kernel != 3DS-Firmware und NATIVE_FIRM != 3DS-Firmware
Du benutzt Dudenlinks :D? Finde ich schön
Nunja, da war ne schöne einzeilige Erklärung, was das bedeutet und Wikipedia kannste ja bei sowas vergessen mit den Besserwisser-Autoren, die sich mit ihrem Wissen profilieren, indem sie hier so drei Absätze mit irgendwelchen Fachbegriffen vollpumpen 😀
Kleine Korrektur:
"Arm9loaderhax nutzt einen “Trick” in einer bestimmten Firmware-Revision
aus. Der 3DS hat ein Stück Code, eine Art Mittelsmann, der vor der
eigentlichen Firmware geladen wird – der arm9loader/kernel9loader. Dieser ist dafür zuständig, die 3DS-Firmware zu entschlüsseln."
FYI:
Die Konsole hat FIRM0 und FIRM1, normal ist diese identisch aber es wird Code eingefügt um vor dem laden der Firmware zu einem leeren unbenutzten Offset zu springen der die payload_stage2.bin enthält.
Falls du das "Tick" meinst: das ist schon so gewollt, erschien mir die einzig brauchbare Übersetzung für "quirk" und "Fehler" wäre falsch.
Es ist kein Tick, eher eine Eigenart die ausgenutzt wird. Ich vermute SciresM spielt nicht nur besonders auf den new3DS an, denn das funktioniert für 2DS und 3DS 😉
Stimmt, "Eigenart" wäre wohl eine bessere Bezeichnung.
Er schreibt explizit nur vom New3DS, aber derrek zeigte ja auch, dass es auf dem Old3DS geht – da bin ich allerdings leider überfragt. Der Key-Sektor existiert ja zumindest nur auf dem New3DS (und wird auf dem Old3DS mit a9lh installiert)
Der Key-Sektor ist beim new3DS im Speicher geblieben und so kam es auch zum OTP losen arm9loaderhax. Allerdings ist das nicht zuverlässig gewesen und in nicht reproduzierbaren Einzelfällen wurde der "geflusht" > Brick bei A9LH Installation. Ein 2DS/old3DS hat keinen Key-Sektor und aus Sicherheitsgründen wurde das verworfen beim new3DS.
So weit hab ich das auch noch mitbekommen, danke aber nochmal für die genauere Erklärung! 🙂
Ich bin mir noch nicht sicher ob sighax die Mutter aller Lösungen seien wird, und wirklich Nintendo nur in neuer Hardware Revision etwas dagegen unternehmen kann.
Ich spiele lediglich hier auf das verwenden von kommenden Firmwareupdates an sowie das nutzen der Onlinedienste.
Die Frage bleibt natürlich ob Nintendo wirklich was dagegen unternehmen will, denn schliesslich hätten Sie schon viele komplett ausperren können mit wenig Änderungen selbst an dem moroden System das Sie verwenden.
Nun, solange es keinen neuen ARM9 Kernel-Exploit gibt, kann Sighax sowieso nicht installiert werden, was auch wohl eher das Ziel von Nintendo ist (sie haben ja safehax und fasthax vor soundhax gefixt, also liegt der Fokus wohl eher auf Kernel-Exploits).
Arm9loaderhax ließe sich auch "einfach" fixen, wenn Nintendo ein zweites Set an FIRM-Update-Code einfügt, welcher von Luma erst Mal nicht erkannt und gepatcht wird. Allerdings müssten sie auch den Secret-Sector auf dem New3DS wiederherstellen, sonst käme es zum Brick. Allerdings ist das Ganze so low-level, das hat schon beim Löschen von BootMii nicht richtig geklappt und reihenweise Wiis gebrickt.
Insofern wird Nintendo eben das schwächste Glied attackieren: das Fixen von ARM9-Exploits.
Derzeitiges A9LH kann nur funktionieren weil es im NAND leere Offsets gibt die wir uns zu nutze machen. Auch für erste Installationen muss eine Software die im NAND liegt durch z.B. FBI ersetzt werden.
Es wäre ein leichtes auf bekannte Daten zu prüfen durch neue Software die im Startvorgang geladen wird und Abfragen macht. Z.B. auf fremde Software die sich auf der Speicherkarte befindet die nur jemand der gegen TOS verstösst verwendet
Nach Update einfach einen Blackscreen, jeder der A9LH supportet (Dev’s etc.) würde zeitweise nicht wissen wieso das Booten nicht möglich ist oder was dagegen zu unternehmen.
Da alle mit A9LH in der Lage sind eine Firmware einzuspielen selbst wenn die Konsole nicht mehr bootet, lässt sich das leicht beheben mit älterer Firmware oder Spende CTR Transfer Dateien.
Die einfachste Methode wäre allerdings einfach sämmtliche Zugriffe der Online Dienste zu sperren.
Updates kann der Nutzer weiter per gekaufte Spiele erhalten.
Bin zwar mit A9LH bestens ausgerüstet und habe von Sighax auch noch nie aktiv gehört, dennoch sehr informativ. Danke.