Il developer Shiny Quagsire ha pubblicato due rapidi aggiornamenti per de_fuse, il modchip ancora in sviluppo per la modifica della console Wii U.
Il modchip open source ci permette di ottenere l’esecuzione del boot1 iniettando un problema nella tensione poco dopo il ripristino, prima che la console inizi ad eseguire il codice.
OK todays minute haul:
– SEEPROM restoring
– OTP dumping for all CDN boot1 versions
– BOOT1_SLC.RAW backups/restores
– The ability to sync SEEPROM boot1 versions w/ the versions on NANDhttps://t.co/FWeczb4sr2— Shiny Quagsire (@ShinyQuagsire) April 26, 2023
Lo sviluppo del modchip de_Fuse ha avuto inizio su console Wii Mini, all’epoca dei fatti non ancora hackerata, nato con lo scopo di eseguire il glitch sul boot0.
La versione 0.2 ha introdotto il supporto per il ripristino SLC attraverso minute
(un fork di MINI e sostituto open source per IOS realizzato dal team fail0verflow) e il dumping dell’OTP tramite PRSH hax.
Da tenere a mente che questo non funzionerà per le console con NAND SLC non funzionanti (se il LED di un’unità diventa blu, la NAND risulterà abbastanza operativa da scaricare l’OTP, qualsiasi altra cosa potrebbe richiedere il reflash/sostituzione).
Dalla versione 0.3 si sono resi disponibili anche il ripristino della SEEPROM, il dumping OTP per tutte le versioni CDN boot1, backup e ripristino del BOOT1_SLC.RAW
e la possibilità di sincronizzare le versioni SEEPROM boot1 con le versioni su NAND.
Il modchip è attualmente nelle sue prime fasi di sviluppo e attualmente richiede una sorta di FPGA, ma non è stato standardizzato in termini di schemi o parti, si pensa di utilizzare anche un microcontrollore RP2040, la stessa utilizzata su console Switch dal modchip PicoFly.
Molte cose attualmente non sono implementate e/o necessitano di miglioramenti. Tuttavia, quanto fornito è sufficiente per verificare che il Pico sia installato correttamente.
Changelog v0.3
-
boot1.img
ora verifica BoardConfig CRC32 e, se non è valido, la DRAM viene inizializzata utilizzando le impostazioni predefinite di fallback.- Aggiunto il supporto per il dumping OTP basato su PRSHhax per tutte le versioni boot1 disponibili su CDN (prod e dev).
- Aggiunto il dumping e il ripristino di
BOOT1_SLC.RAW
. - Aggiunto il supporto per il ripristino di seeprom.bin.
- Questa opzione può comportare l’impossibilità di scaricare OTP tramite PRSH hax se fai qualcosa di stupido!
- Ho aggiunto quante più misure di verifica/sicurezza possibili per assicurarmi che PRSH hax non venisse bloccato, ma alla fine è responsabilità dell’utente mantenere
otp.bin
eseeprom.bin
al sicuro. - Un elenco incompleto di cose che possono smettere di funzionare in modo irreversibile se si perde il backup del file
seeprom.bin
e si esegue il flashing di qualcosa di errato include:- L’unità disco.
- Salvataggi memorizzati su unità USB.
- Aggiunto il supporto per la sincronizzazione delle versioni SEEPROM boot1 con NAND dopo il flashing di
BOOT1_SLC.RAW
.- Questa opzione richiede una copia del file
otp.bin
dalla stessa console (e questo è verificato).
- Questa opzione richiede una copia del file
- Modificato il partizionamento redNAND per posizionare 1 MiB di spazio libero all’inizio della scheda SD per le immagini Ancast.
- Vari miglioramenti dell’affidabilità.
Changelog v0.2
- Hotfix: Corretto OTP che non scaricava senza
otp.bin
sulla scheda SD (lol). - Dumping OTP tramite
Backup and Restore
>Dump OTP via PRSHhax
. - Ripristino di
SLC.RAW
eSLCCMPT.RAW
, tramiteBackup and Restore
. - Input console seriale più veloce/più affidabile.
- Un chainloader seriale
fw.img
per minute_minute dev.- Imposta env var MINUTE_MINUTE_FW_IMG sul percorso assoluto di fw.img.
File richiesti
boot1.img
: Immagine della scheda SD per minute_minute.fw.img
: Bootloader principale, minute.ios.patch
: de_Fuse_iosuhax patch per 5.5.1ish, penso che tecnicamente funzionerà anche su 5.5.5?otp.bin
: Questo può essere scaricato tramite il menu di minute, sottoBackup and Restore
>Dump OTP via PRSHhax
. Il menu sarà ancora disponibile seotp.bin
non è presente, tuttavia IOS non sarà in grado di avviarsi.
All’interno dell’archivio .zip
vengono fornite le seguenti versioni:
- pico_defuse @ 07afb41
- de_Fuse_iosuhax @3f32c2ab234f7371794738a1135ee65b8d753801
- minute_minute @4e23ca71d225f40bf9fa6ef518715806fd22f04f
Passaggi
- Flashare il file
pico_defuse.uf2
sul Raspberry Pi Pico tramite USB. Questo può essere fatto copiando il file sul dispositivo di archiviazione di massa USB che appare. - Flashare il file
boot1.img
su di una scheda SD con almeno 1 GB di spazio di archiviazione. Alcune schede da 2 GB potrebbero funzionare, ma 1 GB sembra essere il punto debole: deve solo essere non SDHC.boot1.img
include un’intestazione MBR, quindi potrebbe essere necessario formattare la partizione in FAT32 dopo il flashing per continuare. Il flashing può essere eseguito tramite win32diskimager, dd o qualsiasi altro formattatore di schede SD. - Copiare i tre file
fw.img
,ios.patch
eotp.bin
nella root della scheda SD. Se non si dispone del fileotp.bin
, questo può essere scaricato tramiteBackup and Restore
>Dump OTP via PRSHhax
. - Accendere la console Wii U. Se funziona correttamente, il LED di alimentazione lampeggerà e diventerà viola. Per impostazione predefinita, il menu minute verrà visualizzato sulla console seriale, tuttavia è possibile posizionare un file INI sulla scheda SD per attivare l’avvio automatico.
Accesso al menu minute
Per il momento è necessaria una console seriale per utilizzare il menu. Su Windows è possibile utilizzare PuTTY, su Linux/macOS è possibile utilizzare minicom (ad esempio: minicom -b 115200 -o -D /dev/cu.usbmodem11101
).
minute
può essere configurato per l’avvio automatico in IOS tramite sdmc:/minute/minute.ini
. Per attivare il menu manualmente, premere (ma non tenere premuto) il pulsante di accensione 3-10 volte (come se stessi tentando di accedere al BIOS su un computer) o finché il menu non viene visualizzato sulla console seriale.
Da qui è possibile scambiare la scheda SD ed eseguire il backup della NAND. Per eseguire il backup di MLC, attualmente si consiglia di formattare la redNAND con una scheda SD da 64 GB, quindi copiare le partizioni dalla scheda SD.
Un esempio di avvio automatico in minute.ini
è il seguente:
[boot]
autoboot = 1
autoboot_timeout = 3
Ripristino dei backup NAND
minute ora supporta il ripristino dei backup NAND, tuttavia potrebbero esserci ancora alcuni bug persistenti. fintanto che si dispone di un backup dei file SLC.RAW
e SLCCMPT.RAW
da qualche parte al SICURO, STARAI BENE!!
Sono riuscito a cancellare completamente il mio SLCCMPT e ripristinarlo, ma ho anche eseguito un ripristino in cui alcuni settori non si sono programmati per qualche motivo. Potrebbe essere stata solo la mia scheda SD però.
Ho intenzione di continuare a lavorare su questo, dal momento che voglio anche ripristinare un’unità la cui NAND è stata completamente cancellata senza backup. Tuttavia, lo stato attuale delle cose è come ho detto.
Una NAND corrotta apparirà come segue nei log IOSU:
- “Attached volume to slc01 (raw)”.
- “Attached volume to slccmpt01 (raw)”.
- Un sacco di spam su hash errati (questo accade anche se
otp.bin
non è valido o azzerato).
Risoluzione dei problemi
Avrai bisogno di una console seriale collegata per questo, vedere sopra per aiuto.
Se il LED della console rimane rosso dopo aver premuto il pulsante di accensione e si avvia normalmente dopo circa 30 secondi, significa che de_Fuse non è riuscito a rilevare correttamente o che la scheda SD non è valida.
Un de_Fuse riuscito ha questo aspetto:
[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...
- Se le righe iniziali non sono
01
,02
,03
,...
, significa che i GPIO DEBUG non sono cablati correttamente. - Se l’ultima riga è
0x1E
e il codice di errore è0x00
, si tratta di una scheda SD non valida. Le schede SD non valide sembrano bloccarsi in boot0. - Se la riga finale è
0x25
e nell’output sono presenti1e
e1f
, significa che la scheda SD era valida, ma non è stata flashata correttamente (o altrimenti non è stata letta). - Se la riga finale è
0x25
e1e
e1f
NON sono nell’output, significa che il cavo EXI CLK non è collegato correttamente o c’è un problema con il cavo dati EXI.
Download: de_fuse v0.3
Download: Source code de_fuse v0.3
Fonte: twitter.com