1. A breve aggiorneremo la piattaforma di Reboot per risolvere alcuni problemi con i plug-in, quindi chiediamo ancora un po' di pazienza, Lo staff di Reboot

LE PROTEZIONI NELLE CONSOLES - NINTENDO 3DS

Discussione in 'Discussione generale 3DS' iniziata da student, 13 Set 2017.

  1. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    3.940
    Like ricevuti:
    3.941
    [​IMG]

    Ve la ricordate la pubblicità della Telefunken degli inizi degli anni 80?



    Ecco, Nintendo nel 2011 ha voluto stupire i suoi fan con qualcosa di simile: una console capace di offrire il 3D SENZA dover utilizzare occhiali o ammenicoli vari per gustarlo ! Il suo product code è CTR-001, dal significato tuttora oscuro, mentre il suo sistema operativo fu chiamato in fase di sviluppo "Horizon". Stiamo parlando del Nintendo 3DS !

    [​IMG]

    Differisce dal DSi per alcune caratteristiche:
    - La risoluzione dello schermo superiore è aumentata a 400x240 (rispetto ai 300x240 delle console precedenti - in modalità 3D lo schermo superiore ha una risoluzione di 800x240)
    - La memoria NAND è di 2GB (8 volte di più di quella del DSi)
    - Un processore ARM11 ed un processore ARM9
    - Supporto al 3D
    - GPU PICA200 da 268MHz (il DSi usava la CPU per il rendering grafico)

    Per rimanere compatibile con le console precedenti il 3DS virtualizza le istruzioni che esegue il processore ARM7 (del DSi) in quello ARM11 e quelle del processore ARM9 nello stesso.

    Ne sono state prodotte nel tempo alcune varianti le più recenti delle quali (modelli 2D) perdono, come dice il nome, la capacità di gestire il 3D mentre le versioni "NEW" hanno un SoC più veloce ed uno slot per microSD anzichè per SD:
    [​IMG]


    PROTEZIONI


    FORMATO DELLA CARTUCCIA PROPRIETARIO

    [​IMG]
    A sinistra una cartuccia DS, a destra una 3DS

    Le cartucce 3DS hanno una piccola linguetta di plastica su un angolo che non permette l'inserimento della stessa in un DS o DSi. Cosa succede se tagliamo la sporgenza riuscendo comunque ad inserire la cartuccia nel DS o nel DSi ? Esplode l'universo ? No, non viene semplicemente riconosciuta (ma continuerà comunque a funzionare se inserita in un 3DS) !
    [​IMG]

    Infine i chip utilizzati per memorizzare i dati nelle cartucce sono custom e parte del protocollo di comunicazione console-cartridge risulta criptato.
    [​IMG]


    PROCESSO DI BOOT - CHAIN OF TRUST

    Il processo di avvio della console è piuttosto intricato ma è stato riassunto molto bene qui ed in questa trattazione cercheremo di farla ancora più semplice anche se potrebbe purtroppo apparire un pochino pesante da leggere e me ne scuso.

    Una parte di questa catena è comune a tutte le varianti di 3DS esistenti e riguarda il controllo sull'integrità del sistema:
    [​IMG]
    Per garantire che tutto il codice in esecuzione sul sistema sia autorizzato, occorre avere una gerarchia di "fiducia". Il codice avviato in modalità utente si fida (trust) del codice del kernel, e il codice del kernel deve verificare crittograficamente il codice utente prima di eseguirlo; ma chi verifica il codice del kernel? Il loader del kernel... e così via salendo nella gerarchia dei controlli... questo processo garantisce che ogni componente del sistema sia stato controllato da un altro componente.

    Alla radice della gerarchia del 3DS abbiamo, come potete vedere nel grafico sopra, la bootROM, il cui codice non è riscrivibile. Il 3DS ha due bootROM (una per ogni CPU):
    - La bootROM "boot9", che contiene le istruzioni per CPU il processore ARM9 (il processore che si occupa della sicurezza della console)
    - La bootROM "boot11", che contiene le istruzioni per CPU ARM11 (il processore che esegue le applicazioni della console)
    Queste 2 bootROMs sono identiche in tutte le varianti hardware del 3DS.

    - La boot9 carica dalla NAND una delle partizioni esistenti in ordine predefinito e la prima è il firmware (partizione firm0 - NATIVE_FIRM). Il FIRM contiene i dati necessari ad avviare il kernel sia del ARM9 (nel NEW 3DS viene avviato prima un nuovo componente che è il Loader del kernel arm9) che del ARM11. Contemporaneamente la bootROM del ARM11 viene eseguita ed il kernel del ARM11, ora disponibile perchè caricato dal boot9, esegue il firmware comprensivo dei suoi moduli.
    - Da qui il modulo PM (ProcessManager) avvia il modulo NS (Nintendo User Interface Shell) il quale a sua volta avvia l'Home Menu
    - Infine l'Home Menu avvia altri moduli di sistema e dopo circa 10 secondi (circa 3 secondi nei NEW 3DS) dall'inizio di tutta la procedura siamo pronti per poter utilizzare la console !
    [​IMG]

    Se volete sapere di più sul kernel ARM11 ed i moduli aprite lo spoiler sottostante:
    Il kernel ha poche funzioni base specifiche, che sono disponibili ai suoi moduli, ed i moduli del kernel hanno privilegi di tipo "user land/user mode" (quindi non elevati) ma non tutti hanno gli stessi livelli di sicurezza. I moduli svolgono la maggior parte delle funzioni non di base nella console e sono in grado di comunicare tra loro. Esistono sostanzialmente 3 tipi di moduli a seconda del livello di sicurezza posseduto:
    - moduli di sistema (necessari per installare, comunicare con i servers Nintendo, ecc)
    - moduli applet (menu di sistema, notifiche, login, ecc)
    - applicazioni (impostazioni, fotocamera, giochi, ecc)
    Questa suddivisione di "competenze" rende l'hacking della console abbastanza complicato perchè, qualora si raggiungesse una esecuzione a livello del kernel, andrebbero comunque patchati i singoli moduli per ottenere le modifiche desiderate quindi serve una analisi approfondita di come/dove questi vengono caricati in memoria, ecc.
    Ma se guardiamo con attenzione come funziona il diagramma di flusso del kernel ci accorgiamo che c'è un "punto" in cui tutto converge:
    [​IMG]
    Il loader (anche lui rappresenta un modulo) ! Quindi possiamo modificare lui per riuscire ad applicare le patches a tutto ciò che è in grado di caricare.

    A seconda della versione di console o di firmware abbiamo 3 diverse implementazioni della catena dell'affidabilità.


    • [​IMG]
      L'ARM9 possiede un motore hardware per la crittografia AES che contiene fino a 64 "slot" di keys.
      Ogni key rimane salvata in questi slot finchè non viene sovrascritta da un processo che ha accesso a tali slot. Le key possono essere utilizzate così come sono (normal keys) oppure essere generate attraverso un altro motore che, a partire da 2 valori salvati negli slot (che chiameremo key-x e key-y) genera una nuova "normal key" ! Se anche avessimo accesso a questi 2 valory key-x e key-y non riusciremmo a ricavare la "normal key" perchè questa risiederebbe all'interno del motore AES e non verrebbe mai scritta negli slot !
      I giochi sono salvati in un formato contenitore chiamato NCCH e sono decriptati proprio con una key generata da una key-x (impostata dalla bootROM) e da una key-y (impostata dal modulo process9); process9 si trova all'interno del NATIVE_FIRM e tale FIRM è criptato (con un Initializing Vector [IV] univoco per singola console); la key per decriptare il NATIVE_FIRM è impostata dalla bootROM mentre l'IV viene ricavato a partire dall'ID della eMMC (NAND).

    • [​IMG]
      Nel 2013 gli hackers riuscirono ad ottenere un buffer overflow nel Process9 dei firmwares inferiori a 7.x andando a minare la chain of trust molto vicino alle basi e permettendo di intervenire all'interno della catena da quel punto in poi ! La key-x NCCH era ancora al sicuro perchè impostata dalla bootROM (boot9) ma era comunque possibile ottenere una decriptazione dei dati utilizzando il generatore di keys direttamente dalla console come se fosse un oracolo anche se tale key non poteva essere estratta.
      Cosa fece Nintendo per proteggere i futuri giochi in uscita ?
      Utilizzò i dati prodotti da un altro motore hardware crittografico della bootROM (boot9), quello RSA, per derivare una nuova NCCH key-y; siccome questi dati RSA iniziali vengono poi sovrascritti da altri dati generati dal kernel9, il quale li salva nello stesso slot, è impossibile risalire ai dati RSA iniziali quindi è impossibile usare la console come oracolo per decriptare i giochi.
      Impossibile finchè nel 2015 gli hackers non ottennero l'accesso alla catena prima dell'inizializzazione del kernel9 (arm9loaderhax) anche se pare esista un metodo non divulgato scoperto già nel 2014; con tale nuovo exploit fu di nuovo possibile decritpare direttamente da console.

    • [​IMG]
      Il SoC del 3DS (la "CPU") contiene al suo interno anche una OTP; tale one time programmable esiste già nei vecchi 3DS ma a partire dai NEW 3DS è stata integrata nella chain of trust come potete vedere nello schema soprastante !
      Inoltre i NEW 3DS contengono anche nuovi dai criptati con AES nella NAND chiamati key-store; i dati contenuti nel key-store, uguali per tutte le consoles, sono però criptati usando una key che è rappresentata dallo SHA256 della OTP rendendo il key-store (in forma criptata) univoco per ogni console !
      L'area della OTP è disabilitata molto presto nel processo di boot (ad opera del kernel9 nei vecchi 3DS mentre ad opera del ARM9 Loader [che non esisteva nei vecchi 3DS] nei NEW 3DS); questo nuovo "key-store" utilizzato sui nuovi 3DS per derivare la key per la decrittazione del NCCH funziona soltanto per i nuovi giochi NEW 3DS, i vecchi saranno sempre decrittati nello stesso modo per motivi di retrocompatibilità.
      Oltre ad aggiungere il Loader ARM9 Nintendo ha aggiunto anche un layer crittografico al codice ARM9 ed ARM11 contenuto nel NATIVE_FIRM ma... ha dimenticato di cancellare le keys dal motore SHA utilizzato per derivarle nonostante le abbia cancellate dal motore AES !
      Inoltre dalle versioni di firmware 3.0 ed inferiori la OTP non era protetta quindi è addirittura possibile downgradare a 3.0 i NEW 3DS (con alcuni stratagemmi) per dumpare anche la OTP ed estrarre dal key-store anche le key finora mai utilizzate !

      Questo dimostra che quando si tenta di inserire qualcosa in una chain of trust ci si deve ricordare di come tutto il sistema era stato concepito fin dall'inizio e non soltanto per "mettere una pezza" nel momento del bisogno e cioè per contrastare exploits.

      Inoltre Plutoo e yellow8 sono stati in grado di scoprire tramite criptoanalisi l'algoritmo alla base del motore di generazione grazie al fatto che alcune key-x e key-y note sono state trovate in forma elaborata (normale, già generata partendo dalle rispettive key-x e key-y) nella Wii U (perchè servivano alla comunicazione con il 3DS) mentre una key è stata inclusa "per sbaglio" come key "normale" in una specifica versione di firmware e poi modificata nei suoi "precursori" key-x e key-y nella successiva versione di fw; questo significa che, avendo a disposizione key-x e key-y è ora sempre possibile generare la key "normale" !



    WHITE LIST E FIRMA RSA

    Anche il 3DS, come il DSi, ha una sua white list e cioè un elenco di titoli autorizzati ad essere eseguiti. Vediamo come funziona:
    - Il 3DS si fa inviare le informazioni della cartuccia;
    - Verifica che le informazioni siano presenti nel file /title/0003000f/484e4841/content/00000001.app (come per il DSi);
    - Se non sono presenti, effettua la verifica della firma RSA;
    - Se anche la verifica della firma RSA non va a buon fine mostra l'errore "Premere un tasto per spegnere la console":
    [​IMG]


    CONTENITORE NCCH DELLA CARTUCCIA

    Le cartucce 3DS implementano un sistema di protezione che, come quello del DSi, si basa sulla lettura delle informazioni della cartuccia. Il contenitore NCCH è un formato di file che contiene altri files e presenta diverse caratteristiche:
    - l'intestazione (header) del contenitore NCCH è un insieme di dati che contiene le informazioni necessarie ad avviare la cartuccia, ma insieme a queste contiene anche una "firma speciale" che consente al 3DS di riconoscere l'originalità della cartuccia stessa. Insieme al header NCCH ci sono:
    - la "partizione" RomFS (che contiene i file usati dal gioco)
    - la "partizione" ExeFS (che contiene l'eseguibile che sarà avviato dalla console)
    entrambe criptate.


    LIVELLI DI SICUREZZA

    Se avete letto la chain of trust avrete capito come il 3DS abbia sostanzialmente 3 livelli di sicurezza:
    - ARM11 Userland: il livello in cui vengono eseguiti i giochi. Si può sfruttare l'hardware di base, come il processore, la GPU, la fotocamera, ecc.…
    - ARM11 Kernel Mode (o kARM11): In questa modalità si hanno gli stessi privilegi del kernel, ma i sistemi di sicurezza sono ancora attivi (quindi non si può modificare nulla)
    - ARM9: In questa modalità si ha il controllo completo sulla console e sui sistemi di sicurezza

    Sono stati sviluppati molti exploit per accedere alle modalità kARM11 e ARM9, anche se sono stati patchati tutti nei firmwares più recenti.


    UNITA DI SVILUPPO

    [​IMG]
    Il Nintendo 3DS ha una versione riservata agli sviluppatori (prende il nome di Panda per le vecchie versioni [equivalenti ad Old3DS] e di Snake per le nuove [New 3DS]). Hanno molte funzionalità che le versioni retail (normali) non hanno. Queste consoles hanno permesso i primi dumps di alcune applicazioni e quindi il loro reversing che ha poi portato i primi exploit.

    DevMenu
    Questo menù conteneva diverse voci:
    - Program: contiene la lista dei titoli installati;
    - Import (poi rinomata in SDMC): contiene un applicazione che permette di installare file .CIA (i file di installazione dei giochi);
    - HIO: permette di installare CIA da remoto;
    - ExtData e SExtData: permettevano di cancellare i dati relativi all'home menu e alle versioni dei giochi sulla memoria di sistema e sulla SD. Questo tipo di dati è criptato con AES.

    ConfigMenu
    Questo menù contiene voci relative al debug delle eccezioni, al debug del sistema e le voci classiche delle impostazioni di sistema (lingua, lista giochi, aggiornamenti del firmware)

    Altre applicazioni
    SaveDataFilter (che implementa la gestione dei salvataggi), oppure le varie riscritture delle funzionalità del 3DS (e anche del DSi) in linea di comando e facilitate per il debugging.


    EXPLOITS

    I coders/reversers più impegnati ed ai quali vengono attribuite le più significative scoperte sul versante 3DS della scena sono certamente quelli che potete vedere in foto:
    [​IMG]
    Video del trio in azione al 32C3:


    ARM11 Userland

    [​IMG]
    Ci sono diversi exploit ARM11 userland che avviano l'homebrew launcher, citiamo più noti:
    - Browserhax, che sfrutta vari bug del webkit (ce ne sono davvero tanti)
    - Cubic Ninja, che sfrutta un bug per permettere l'esecuzione di codice non firmato;
    - Menuhax, nell'ultima versione (per 11.2) sfrutta un bug dei banner (link);
    - RPwnG, che sfrutta un buffer overflow.
    - Molti altri (vedere anche qui)


    kARM11

    Anche in questa "modalità" abbiamo diversi exploits; ecco i principali:
    - memchunkhax (usato fino alla versione 11.0 e precedenti), che sfrutta un bug per l'esecuzione di codice arbitrario in grado di scalare i permessi fino al kernel11 (link);
    - fasthax, che sfrutta un bug del timer del kernel. Il funzionamento è molto semplice: il timer non fa eseguire nessun codice su un processore, ma l'altro processore può inviare un comando di chiusura del timer handler e fa rimanere in kernel mode il sistema (link);
    - slowhax, che lentamente (come dice il nome) sovrascrive l'interrupt handler della sincronizzazione e fa eseguire codice in kernel mode. Ci mette circa un'ora a fare tutto.
    - Molti altri


    ARM9

    Ci sono due principali exploit:
    - arm9loaderhax, che sovrascrive la parte dell'arm9loader e fa eseguire il suo codice (il file arm9loaderhax.bin nella SD). La scrittura del arm9loader è permessa grazie al dump delle chiavi OTP, fattibile da firmware 2.1. La vulnerabilità usata da arm9loaderhax (che in forma breve è anche chiamato "a9lh") è stata scoperta dai 3 dev precedentemente citati: Smealum, Plutoo e Derrek. Il primissimo abbozzo di arm9loaderhax venne creato da Yellows8 e Plutoo, mentre delebile ne ideò una versione migliore (che carica il file arm9loaderhax.bin dalla SD).
    - boot9strap (originariamente chiamato "sighax"), che grazie al dump di derrekr, invalida il check della RSA (infatti usa un hash che invalida i calcoli della RSA) e fa eseguire del codice non firmato. I payload di boot9strap svolgono le stesse operazioni di quelli per arm9loaderhax, cambia solamente il metodo con cui sono avviati.
    - Firmlaunch-hax è una vulnerabilità dei firmware fino a 9.2 che funziona così:
    • La CPU ARM11 modifica, in kernel mode, la FCRAM (che è un tipo di RAM molto veloce dove vengono memorizzate alcune istruzioni usate dalla CPU, una specie di cache). Su firmware maggiore di 9.3 non è più possibile modificarla
    • La CPU ARM9 esegue il codice del firmware custom nella FCRAM, quindi si è riusciti ad eseguire il CFW!


    DUMP bootROM

    Sia bootROM9 che bootROM11 sono state dumpate dal dev derrekr, il quale ha trovato una falla nel processore che permette di dumparle entrambe.


    NTRBootHax

    Qui non si parla propriamente di exploit, ma di "errore di logica". Questo sistema "nascosto" è stato scoperto grazie al dumping della boot9 ed al suo reversing. La boot9 del 3DS infatti, oltre al normale procedimento di avvio, ha una combinazione "meccanica" speciale che permette operazioni "speciali". Queste è la pressione in contemporanea dei tasti START, SELECT e X, che permette alla bootrom di avviare una cartuccia DS all'avvio. In particolare quando il 3DS è in modalità riposo (su 2DS vecchio si può fare spingendo la levetta in basso a destra, mentre sugli altri si mette un magnete sotto il tasto B) la bootROM si "dimentica" di inizializzare i vari sistemi di sicurezza e passare in userland, quindi abbiamo un ambiente con privilegi elevati che permette di installare boot9strap.

    Teoria: forse nei centri Nintendo usano questa configurazione per ripristinare le console brickate con una cartuccia NTR, quindi si è solo scoperta una funzionalità usata e voluta da Nintendo e voluta magari sperando non venisse mai scoperta dato che risiede nella ritenuta-erroneamente-non-dumpabile bootROM !


    CUSTOM FIRMWARES

    CFW e Luma 3DS
    Alcune persone hanno quindi modificato il file arm9loaderhax.bin per fare in modo che faccia operazioni aggiuntive.
    Ad esempio Aurora Wright ha creato Luma3DS (per gli amici luma), il più famoso (e semplice da usare) CFW per 3DS. Tra le operazioni aggiuntive che Luma è in grado di svolgere una è il caricamento dei payload (ovvero altri file che si possono usare per arm9loaderhax) situati nella SD (più precisamente in SD/luma/payloads/).
    In passato il caricamento dei payload avveniva con la pressione di tasti (infatti davanti al nome del payload c'era il codice corrispettivo per il tasto, ad esempio per un payload con il tasto SU il nome del file diventava: up_nomepayload.bin). Adesso invece, Luma utilizza un "Chainloader Menu" che permette la selezione del payload desiderato.
    [​IMG]
    Foto del menù chainloader

    Luma applica delle patch, le più note delle quali sono:
    • patch della whitelist, la quale permette di avviare le flashcard precedentemente bloccate.
      • Per alcune flashcard è necessario anche attivare la patch ARM9, che disattiva i controlli sugli accessi ARM9 e sulle chiamate inter-processore;
    • Disattiva la scrittura delle partizioni FIRM0 e FIRM1 della NAND una volta avviato il sistema (di conseguenza gli aggiornamenti non sovrascrivono la modifica);
    • Un elenco di altre patch applicabili dalle impostazioni di Luma:[​IMG]
    Luma all'avvio si presenta esteticamente come un normale console:
    [​IMG]
    Home Menu del 3DS con qualche app in più


    NTR CFW
    Questo è un CFW che si avvia da un applicazione nell'Home Menu (installata con FBI) e permette di usare i "plugin", ovvero delle estensioni nei giochi che permettono di usare cheat ed aggiungere funzionalità. Ecco il menù di ntr:
    [​IMG]


    GateWay e RXTools
    Gateway è (o meglio era) una cartuccia che permette di avviare un "sistema alternativo" usando l'exploit "firmlaunch-hax". Da gateway si potevano avviare giochi, fare dei backup e dei restore della sysNAND o emuNAND e formattare la SD o la sysNAND / emuNAND
    [​IMG]
    Come appariva il menù Gateway


    RXTools
    E'un custom-firmware che sfrutta la stessa falla usata da gateway. Invece di essere avviato da flash-card veniva avviato da menuhax (o da browser). Era un CFW che permetteva, oltre a fare le stesse cose delle gateway, a gestire l'home menu dell'emunand (e della sysNAND). Infatti si potevano fare tutte le cose che si fanno oggi con luma (installare CIA, ecc...) con un solo obbligo: bisognava avere una emuNAND, in modo da poter usare l'ultimo firmware in emuNAND e la 9.2 (ultimo firmware con cui rxtools è compatibile) in sysNAND.
    [​IMG]
    Menù di RXTools


    Altri CFW
    Oltre a luma ci sono anche altri CFW anche se la maggior parte sono stati abbandonati.
    Un esempio è Corbenik, un CFW creato da chaoskagami per "divertimento" (e abbandonato perché con boot9strap lo sviluppo diventava abbastanza difficile). La sua peculiarità è che ogni cosa è da configurare, ad esempio vanno selezionate tutte le patches che il sistema deve applicare e all'avvio al posto dell'Home Menu appare un'interfaccia testuale a sostituirlo:
    [​IMG]
    Un altro CFW che considero interessante è Salt, fork di luma e [credo] ancora in sviluppo. La sua particolarità? E' semplicissimo (zero configurazione, quindi è più semplice di Luma) ed è ancora compatibile con arm9loaderhax (Luma nelle ultime versioni è compatibile solo con boot9strap)


    HARDMOD

    [​IMG]
    La NAND del 3DS è equivalente a una memoria eMMC, quindi si può dumpare da un normale computer collegando i piedini CLK, DAT0, GND e CMD (i piedini usati per controllare le schede SD e eMMC) il 3DS va in errore (indica che la NAND non c'è perché è usata da computer):
    [​IMG]
    Effettuando un dump della NAND e decriptandolo con le chiavi AES usate (sono pubbliche) si può modificare la NAND. In precedenza si faceva un downgrade ma ora si riscrive solo la parte iniziale (del caricamento del sistema)


    CONCLUSIONI

    Con il 3DS Nintendo ha portato la complessità all'interno delle sue integrazioni hardware+software la quale ha reso più lunga la catena dell'affidabilità permettendo di trovare falle in più punti grazie anche al fatto che tale catena nel tempo è stata riadattata e la sua complessità ha reso difficile per gli sviluppatori di casa N l'identificare errori che ovviamente non sono sfuggiti ai devs/reversers più navigati !
    Inoltre notiamo per la prima volta parlare di "exploit nel browser internet", software già da tempo bersaglio di exploits di vario genere non solo nelle consoles ma anche nei PC e nei cellulari (non soltanto Android); prodotto che vedremo essere attaccato su tutti i fronti, magari riciclando anche exploits sviluppati per altre piattaforme, anche nelle consoles future !
    Insomma, riuscirà Nintendo ad imparare dai propri errori ?

    Lo vedremo nella prossima pUntata :smile:
     
    #1
    Ultima modifica: 12 Apr 2019
  2. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.617
    Adesso scrivete tutte le imprecisioni dell'ultima parte! Ah, student mi ha suggerito di non scusarmi senza fondamenti (era Excusatio non pentita, credo)

    EDIT: per chi non l'avesse letto l'articolo è stata creato da MODD3R, io (quindi iostream) e student. Quindi se vi piace lasciate un feedback anche a noi due!
    Invito anche @MODD3R a lasciare un messaggio così che possiate dargli un feedback
     
    #2
    Ultima modifica: 13 Set 2017
    A Maracaibo, zoomx, motherfan e 4 altri utenti piace questo elemento.
  3. IPorK

    IPorK Livello 3

    Iscritto:
    3 Feb 2016
    Messaggi:
    45
    Like ricevuti:
    22
    Allora complimenti come al solito a voi 3 :tonguewink:
    Wii U?
     
    #3
    A iostream e student piace questo messaggio.
  4. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.617
    Non lo so neanche io, dovresti chiedere a @student (se te lo vuole dire, c'è anche l'effetto suspense).
     
    #4
  5. IPorK

    IPorK Livello 3

    Iscritto:
    3 Feb 2016
    Messaggi:
    45
    Like ricevuti:
    22
    Preferisco l'effetto suspense:tearsofjoy:
     
    #5
  6. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    3.940
    Like ricevuti:
    3.941
    "… non petita" non "..non pentita" :wink:

    Il prossimo articolo é già pronto ma voglio vedere se c'è da integrare sul 3ds prima di pubblicarlo :wink:
     
    #6
    A iostream, Marty e IPorK piace questo elemento.
  7. zoomx

    zoomx Livello 19

    Iscritto:
    12 Set 2015
    Messaggi:
    892
    Like ricevuti:
    339
    No, Nintendo non sembra voler imparare dagli errori. Significa che si accontenta del tempo guadagnato con le sue protezioni imperfette.
     
    #7
  8. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.617
    Mi è venuto spontaneo premere sulla N...
     
    #8
  9. student

    student Staff Livello 41 Staff

    Iscritto:
    30 Ago 2015
    Messaggi:
    3.940
    Like ricevuti:
    3.941
    Aggiunto vecchio arm9 exploit ed aggiornata la parte sui custom firmwares (grazie ad iostream).
     
    #9
    A iostream piace questo elemento.
  10. iostream

    iostream Phoenix Wright

    Iscritto:
    13 Ago 2016
    Messaggi:
    4.895
    Like ricevuti:
    1.617
    @student Le immagini non sono più https, devi aggiornarle
     
    #10
Sto caricando...

Condividi questa Pagina