Home Homebrew Pubblicati due rapidi aggiornamenti di de_fuse, il modchip per la modifica...

[Scena Wii U] Pubblicati due rapidi aggiornamenti di de_fuse, il modchip per la modifica della console Wii U

532
0

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.

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 e seeprom.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).
    • 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 e SLCCMPT.RAW, tramite Backup 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, sotto Backup and RestoreDump OTP via PRSHhax. Il menu sarà ancora disponibile se otp.bin non è presente, tuttavia IOS non sarà in grado di avviarsi.

All’interno dell’archivio .zip vengono fornite le seguenti versioni:

Passaggi

  1. 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.
  2. 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.
  3. Copiare i tre file fw.img, ios.patch e otp.bin nella root della scheda SD. Se non si dispone del file otp.bin, questo può essere scaricato tramite Backup and RestoreDump OTP via PRSHhax.
  4. 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 presenti 1e e 1f, significa che la scheda SD era valida, ma non è stata flashata correttamente (o altrimenti non è stata letta).
  • Se la riga finale è 0x25 e 1e e 1f 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

LASCIA UN COMMENTO

Per favore inserisci il tuo commento!
Per favore inserisci il tuo nome qui

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.