Pagina 1 di 3 123 UltimaUltima
Risultati da 1 a 10 di 28

Discussione: [NEWS] Dump BOOTLDR

  1. #1
    Senior Member L'avatar di sid01993
    Data Registrazione
    03-01-12
    Località
    Terra
    Messaggi
    341

    Dump BOOTLDR

    Sembra che un utente di qualche forum ha rilasciato un tutorial per dumpare il BOOTLDR.


    Messaggio da parte dell'utente sul forum PS3hax
     
    Wow... such hostility against me just cause I said that one my future projects was trying to adapt the btldr exploit to hardware so we can hack (ie run unsigned code) on all consoles. I think I deserve the opportunity to explain myself before you start doubting me.

    That means releasing the btldr exploit (which it patchable) before the others devs can even check if its remotely possible but it is the only way to get redemption so let's start...


    DUMPING THE BOOTLDR

    As you know the bootldr is one of the two loaders that are signed per console and it was the only part of the system that haven't been hacked.

    Once you load it the same way as metldr (via SigNotify) it would start requesting different addresses that we don't control. You can take a look on my user page to the dma sequence that it produces.

    As you see it access a lot of different addresses and we don't have control of any of them so the first objective was to control the input/output.

    The sandbox:

    The objective was to redirect the flows of data to our controlled buffers so we know what is written or read. To achieve that a driver was created.

    This driver performs two functions:
    - the first is creating lv1 peek/poke using the patched lv114 that comes with OtherOs++ and other CFW.
    - the second is reserve a block of consecutive memory that would be used as an HTAB.

    The SPU is told to use our HTAB which in turns redirects to our user buffers. To get the physical address... the user pages are locked on memory and then using an old trick found by geohot their real address is retrieved.

    At this point we have control of what the SPU reads BUT if consecutive small accesses are done we have no control if we want to change something in between.

    The first exploit:

    I'm calling this an exploit but actually is a bad implementation of a feature cause it should be disabled on isolation. The feature is called the MFCLSACMP. Basically is a register on the spu that is checked before doing a dma op.
    If the source/target address on the SPU is inside the mask defined by this register then dma is stopped and an interruption is reported. Until this interrupt is cleared the dma is not started.

    Great, so we control what it reads and when it is read... the first objective was achieved total control of the I/O. That is what you can see on my user page on wiki.

    However this all so allowed me to find the biggest problem on using the booldr as an oracle.... the config ring.

    The config ring is a series of bits that syscon sends to the cell before during the power up.... On this cell implementation the config ring is accessible from inside the spu as a read once channel.
    So unless I could find a way to refill the channel the bootldr couldn't be used as oracle. Even worse at this point I didn't know how the config ring was read (although an undocumented channel was on top of the list).

    I spent a couple weeks trying to figure the problem. Finally I posted the log on the wiki looking for help. Obviously some approach. We exchanged info. I gave then the tools and they gave me means of validating my hypothesis (those on the log)

    We worked a lot of time on this. Remember that I was trying to get an oracle not an exploit so filling the config was a must... several thing were tried but none worked.

    After a month or so I started checking other projects while thinking of what to do. Then after several months I decided to try to exploit it instead of using it.... given the log the entry point was clear...

    The bootldr exploit:

    If you see the log you'll see a lot of data exchanging between the spu and the syscon. graf had described it on his bible so it was known... but the log also said that the data was read twice once to read the header and once to read header + data.

    On the header was a variable length. So I decided to change the len between both reads.... didn't work until i corrected also the chksum... and then BINGO! unexpected behavior... a possible exploit was found.

    The advantage of this exploit is that it gave us a lot of points to test. The info was shared and two of us friendly raced one against the other to find the correct possibility.

    I won the race of finding the execution point although I lost the one for dumping. The winner was command 0x20 which is an info message... casually the config error message... so their own protection had given us the bootldr.

    That's the story of the exploit... it was then decided that I got the ultimate decision of releasing the exploit and any of us could leak the keys... however they asked me too hold it until SONY has reacted to the dex conversion and I told them that I would not release them until I got the appldr keys by myself.

    I suppose they passed the keys to others and them at some point the keys probably arrived to EXETrimAll and N0DRM (I don't think they exploited trublue...). Meanwhile i was in the middle of my holidays and when I come back they were releasing non-stop so I didn't see that it was necessary to leak them.

    Unfortunately they also leaked to a scoundrel that sell the key to discblu.

    That forced some one that have the key to make it public.

    You said that I'm angry cause someone leak the key... nope. I was angry with discblu... and with some hacker that reappeared just to say that he already knew how to do it. As you can see the method is completely software and does not use the signature bug (except for installing the cfw... but then all the apps need to credit them). If you persist I'll tell you that this can also be done on a 3.15 with geohot pulse exploit.

    The code:

    Download bootldrexploit.rar from Sendspace.com - send big files the easy way

    I have attached the code of a working version for latest exploitable slim. I know that also works on other version but I don't know which ones. It is only valid for NOR consoles cause it expects a full NOR flash as one of the parameters.
    It has two programs. One is a kernel module so it must be load with insmod.
    The second its a user program that takes as parameter the speID (i recommend using 0 that is normally enabled), the flash file and the output file.
    The dump is shifted by as a side effect of the bug. For me it was 0x800 bytes... but others got different result. The start function must be at 0x400 once shift is corrected

    BTW the code is ugly and there is a lot of data that is not used so if someone has questions please ask me (on this or other ps3 related things)... I'll be available until sunday... then I'll definitely leave.

    Now I'll explain my idea for the hardware solution.

    Improving the exploit

    THE FOLLOWING IS ALL THEORETICAL AND IT WILL PROBABLY NOT WORK (I'M NOT A HARDWARE EXPERT AND THAT'S THE MOST DIFFICULT PART)

    In this case the objective is not dumping the bootldr but get code execution. Using an small payload a program will be copied to spu. That program will just copy a patched unencrypted lv0 to the memory and tell the PPU that code was loaded successfully.

    By achieving that we would have full control of the system. Our patched lv0, will load an original lv1ldr (required to get the ATA keys) which will load an original lv1 but before giving control to level1 our level0 will patch it so we still have control. Same with lv2 and vsh.

    As I said basically the bug consist of changing the response len between the first read and the second. That is easily done if you control the buffer where the data is located (exploitable consoles). But we want to do this before anything is loaded

    So we need to change the comm between syscon and cell before any software outside the cell is loaded... the only option is a hardware interceptor. This hardware will intercept the communications and change it so the exploit is triggered (This is called a man in the middle attack). The payload will be sent as part of the 0x20 command reply... if the bug is trigger properly we know that our payload will start around 0x3E010.

    In addition to this I recommend adding a second flash chip that will contain the patched firmware. That will allow the user to go from patched to official with a switch

    As you see the device I propose is not a drm device... it actually triggers an exploit similar to the ODE device that whats announced (BTW that is perfectly done with the info that glevand posted).

    The questions is: Is all of this possible?... well from the software part I'm pretty sure but I don't know if the hardware can be build or if the cost will be too much.

    In any case if it is possible, there is enough info on this post to make it...

    Unfortunately there is also a enough info to patch the bug (if they didn't already). However it would only be patchable on factory...

    Traduzione con traduttore google
     
    Wow ... tale ostilità contro di me solo perché ho detto che uno dei miei progetti futuri stava cercando di adattare l'exploit btldr di hardware in modo siamo in grado di incidere (ad esempio l'esecuzione di codice non firmato) su tutte le console. Penso di meritare l'opportunità di spiegare me stesso prima di iniziare a dubitare di me.

    Ciò significa che il rilascio del btldr exploit (che patchable) prima degli altri sviluppatori possono anche controllare se la sua distanza possibile, ma è l'unico modo per ottenere il rimborso in modo cominciamo ...


    IL DUMPING BOOTLDR

    Come sapete il bootldr è uno dei due caricatori firmati per console ed era l'unica parte del sistema che non sono stati attaccati.

    Una volta che si carica allo stesso modo metldr (via SigNotify) sarebbe comincia a chiedere indirizzi diversi che noi non controlliamo. Potete dare un'occhiata alla mia pagina utente alla sequenza dma che lo produce.

    Come potete vedere, accedere a un sacco di indirizzi diversi e non abbiamo il controllo di una di esse in modo che il primo obiettivo è stato quello di controllare l'input / output.

    La sandbox:

    L'obiettivo era quello di reindirizzare i flussi di dati per i nostri buffer controllati in modo da sapere ciò che è scritto o letto. Per ottenere che un driver è stato creato.

    Questo driver svolge due funzioni:
    - La prima è la creazione di lv1 peek / Poke utilizzando il lv114 patch che viene fornito con OtherOS + + e altri CFW.
    - La seconda riserva è un blocco di memoria consecutive che potrebbe essere utilizzato come HTAB.

    La SPU viene detto di utilizzare il nostro HTAB che si trasforma in reindirizzamenti ai nostri Tamponi. Per ottenere l'indirizzo fisico ... le pagine degli utenti sono bloccati sulla memoria e quindi utilizzando un vecchio trucco trovato da geohot il loro vero indirizzo viene recuperato.

    A questo punto abbiamo il controllo di ciò che la legge SPU MA se consecutivi accessi piccoli sono fatto non abbiamo alcun controllo se vogliamo cambiare qualcosa in mezzo.

    Il primo exploit:

    Chiamo questo un exploit, ma è in realtà una cattiva attuazione di una causa funzionalità dovrebbe essere disabilitata su isolamento. La funzione si chiama MFCLSACMP. In pratica è un registro sul spu che viene controllato prima di fare un op dma.
    Se la sorgente / indirizzo di destinazione sul SPU è all'interno della maschera definita da questo registro dma poi viene arrestato e viene segnalato un'interruzione. Fino a quando questo allarme viene cancellato il dma non è stato avviato.

    Grande, quindi controllare ciò che si legge e quando viene letto ... il primo obiettivo è stato raggiunto il controllo totale di I / O. Questo è ciò che si può vedere nella mia pagina utente su wiki.

    Tuttavia questo tutto così mi ha permesso di trovare il più grande problema sull'utilizzo del booldr come un oracolo .... l'anello di configurazione.

    L'anello config è una serie di bit che SYSCON invia alla cella durante la prima accensione .... In questa implementazione cella l'anello di configurazione è accessibile dall'interno della spu come una lettura, una volta canale.
    Quindi, a meno che non riuscivo a trovare un modo per riempire il canale del bootldr non poteva essere utilizzato come oracolo. Come se non bastasse, a questo punto non sapevo come l'anello di configurazione è stato letto (anche se un canale non documentato era in cima alla lista).

    Ho trascorso un paio di settimane cercando di capire il problema. Infine ho postato il log nel wiki in cerca di aiuto. Ovviamente qualche approccio. Ci siamo scambiati informazioni. Ho dato poi gli strumenti e mi hanno dato i mezzi di convalidare la mia ipotesi (quelle del registro)

    Abbiamo lavorato un sacco di tempo su questo. Ricorda che stavo cercando di ottenere un oracolo non è un exploit così riempire il config era un must ... cosa che molti sono stati processati, ma nessuno ha funzionato.

    Dopo un mese o giù di lì ho cominciato a controllare altri progetti pensando a cosa fare. Poi, dopo qualche mese ho deciso di cercare di sfruttare invece di usarlo .... dato il registro il punto di ingresso è stato chiaro ...

    Il bootldr sfruttare:

    Se viene visualizzato il registro vedrete un sacco di scambio di dati tra la spu e SYSCON. graf aveva descritto la sua bibbia così era conosciuto ... ma il registro ha anche detto che i dati sono stati letti due volte, una volta a leggere l'intestazione e una volta per leggere i dati + header.

    Sulla testata era una lunghezza variabile. Così ho deciso di cambiare la len tra le due letture .... non ha funzionato fino a quando ho corretto anche il chksum ... e poi BINGO! comportamento imprevisto ... possibile un exploit è stato trovato.

    Il vantaggio di questo exploit è che ci ha dato un sacco di punti da verificare. Informazioni è stata condivisa e noi due amichevole corso uno contro l'altro a trovare la possibilità corretta.

    Ho vinto la gara di trovare il punto di esecuzione, anche se ho perso quella per lo scarico. Il vincitore è stato 0x20 comando che è un messaggio di info ... casualmente il messaggio di errore di configurazione ... così la loro stessa protezione ci aveva dato il bootldr.

    Questa è la storia di exploit ... si è poi deciso che ho avuto l'ultima decisione di rilasciare l'exploit e ognuno di noi potrebbe perdere le chiavi ... tuttavia mi hanno chiesto anche tenerla fino a quando Sony ha reagito alla conversione dex e ho detto loro che non li rilascia finché non ho avuto le chiavi appldr da me.

    Suppongo che passavano le chiavi agli altri e loro a un certo punto le chiavi, probabilmente arrivati ​​a EXETrimAll e N0DRM (non credo che sfruttavano trublue ...). Nel frattempo ero nel bel mezzo delle mie vacanze e quando torno stavano rilasciando non-stop quindi non ho visto che era necessario a perdere loro.

    Purtroppo anche trapelare un mascalzone che vendono la chiave per discblu.

    Che ha costretto qualcuno che ha la chiave di renderlo pubblico.

    Lei ha detto che io sono una persona arrabbiata causa perdite la chiave ... Nope. Ero arrabbiato con discblu ... e con qualche hacker che riapparve solo per dire che sapeva già come fare. Come si può vedere il metodo è completamente software e non usa il bug della firma (tranne che per l'installazione del CFW ... ma poi tutte le applicazioni devono accreditare loro). Se insisti ti dico che questo può essere fatto anche su un 3,15 con exploit geohot impulsi.

    Il codice:

    [Url = http://www.sendspace.com/file/wvknol] Download bootldrexploit.rar da Sendspace.com - inviare file di grandi dimensioni in modo rapido [/ url]

    Ho allegato il codice di una versione funzionante per gli ultimi sottile sfruttabili. So che funziona anche su altre versioni, ma non so quali. E 'valido solo per le console NOR causa, si attende una piena NOR flash come uno dei parametri.
    Ha due programmi. Uno è un modulo del kernel, quindi deve essere carico con insmod.
    Il secondo è un programma utente che prende come parametro il speID (mi consiglia di utilizzare 0 che è in genere abilitata), il file flash e il file di output.
    Il dump viene spostata di come un effetto collaterale del bug. Per me è stato 0x800 byte ... ma altri ottenuto risultati diversi. La funzione di avvio deve essere 0x400 una volta spostamento viene corretto

    BTW il codice è brutto e c'è un sacco di dati che non viene utilizzata, quindi se qualcuno ha domande non esitate a chiedere a me (su questo o altre cose ps3 correlate) ... Sarò a disposizione fino a domenica ... allora io sicuramente lasciare.

    Ora ti spiego la mia idea per la soluzione hardware.

    Migliorare l'exploit

    Di seguito è riportato TUTTI teorica e probabilmente non funzionerà (non sono un esperto di hardware e che è la parte più difficile)

    In questo caso l'obiettivo non è il dump del bootldr ma ottenere l'esecuzione di codice. L'utilizzo di un piccolo carico utile di un programma verrà copiato spu. Tale programma sarà solo copiare una patch in chiaro lv0 alla memoria e raccontare la PPU che il codice è stato caricato con successo.

    Con il raggiungimento di che avremmo avuto il pieno controllo del sistema. Il nostro lv0 patch, verrà caricato un lv1ldr originale (necessario per ottenere le chiavi ATA) che caricare un originale lv1, ma prima di dare il controllo al nostro level1 level0 lo patchare quindi abbiamo ancora il controllo. Stessa cosa con LV2 e VSH.

    Come ho detto sostanzialmente bug consistono nell'inversione len risposta tra la prima lettura e il secondo. Questo è fatto facilmente se controlli il buffer in cui si trovano i dati (console sfruttabili). Ma noi vogliamo fare questo prima di tutto viene caricato

    Quindi abbiamo bisogno di cambiare il comm tra SYSCON e cellula prima di qualsiasi software al di fuori della cellula viene caricato ... l'unica opzione è un intercettore hardware. Questo hardware intercettare le comunicazioni e modificarlo in modo che l'exploit viene attivato (Questo è chiamato un uomo in the middle). Il carico sarà inviato come parte della risposta di comando 0x20 ... se il bug è grilletto correttamente sappiamo che il nostro carico avrà inizio intorno 0x3E010.

    Oltre a questo vi consiglio di aggiungere un secondo chip flash che conterrà il firmware modificato. Ciò consentirà all'utente di passare da patch a ufficiale con un interruttore

    Come potete vedere il dispositivo che propongo non è un dispositivo drm ... si innesca in realtà un exploit simile al dispositivo di ODE che cosa è che ha annunciato (a proposito, che sono fatti alla perfezione con le informazioni che glevand pubblicato).

    Le domande è: E 'possibile tutto questo ...? bene da parte del software sono abbastanza sicuro, ma non so se l'hardware può essere costruire o se il costo sarà troppo.

    In ogni caso, se è possibile, c'è abbastanza informazioni su questo post per farlo ...

    Purtroppo c'è anche una abbastanza informazioni per patchare il bug (se non lo facessero già). Tuttavia sarebbe solo patchable in fabbrica ...

  2. #2
    Member L'avatar di lerrel
    Data Registrazione
    27-12-11
    Messaggi
    51
    dicono che chi l'ha postato ha sempre dato molto aiuto alla scena ps3, si chiama juan nadie, inoltre nei commenti tutti lo ringraziano e lo venerano quasi come un dio.. xD quindi direi che siamo al punto decisivo

  3. #3
    in attesa che esca un cfw L'avatar di gallo_88
    Data Registrazione
    29-12-11
    Messaggi
    71
    e a cosa porterebbe?
    [SIGPIC][/SIGPIC]Il mondo è imperfetto. È per questo che è così bello...

  4. #4
    Rubare=Accedere al PSN
    Data Registrazione
    29-12-11
    Messaggi
    476
    Raga non date false informazioni porca miseria. Non ci sarà nessun Cfw installabile da fw superiori al 3.55 l'unica svolta che ci sarà è che se vogliono rilasceranno tutti i fix se non vogliono si è costretti a mettere un ibrido.

  5. #5
    Senior Member L'avatar di sid01993
    Data Registrazione
    03-01-12
    Località
    Terra
    Messaggi
    341
    io ho scritto solo una notizia che sembra essere vera!!

  6. #6
    Member L'avatar di lerrel
    Data Registrazione
    27-12-11
    Messaggi
    51
    infatti è vera, andate su ps3hax

  7. #7

    Data Registrazione
    18-12-11
    Messaggi
    3,611
    La ps3 non avebbe più segreti.Ecco uno schema che chiarirà la sua reale applicazione.



    immagine postata da jiro nella discussione del fw 4.20.

    Ricevere un grazie dopo aver aiutato qualcuno fa sempre piacere.

  8. #8
    Rubare=Accedere al PSN
    Data Registrazione
    29-12-11
    Messaggi
    476
    Si big ma non quella che si aspettano tutti.

  9. #9
    L'avatar di Prometheus_91
    Data Registrazione
    20-12-11
    Località
    Dove tutto ebbe inizio...
    Messaggi
    4,207
    Non per qualcosa ma è una news postata cosi? mha! le news vanno tradotte... altrimenti chi legge e non sa l'inglese che fa?
    L'universo è cambiamento; la nostra vita è il risultato dei nostri pensieri.

  10. #10
    Senior Member L'avatar di sid01993
    Data Registrazione
    03-01-12
    Località
    Terra
    Messaggi
    341
    Scusami capo!! provvedo subito!!

Discussioni Simili

  1. Modifica Ps3 Slim 320 gb
    Di Luigi9ove nel forum Hacking PS3
    Risposte: 4
    Ultimo Messaggio: 02-01-2016, 08:58
  2. Ecco i primi ban permanenti su ps3
    Di xasal nel forum Hacking PS3
    Risposte: 71
    Ultimo Messaggio: 31-12-2012, 19:40
  3. Saluti di benvenuto
    Di murdock78 nel forum Community
    Risposte: 6
    Ultimo Messaggio: 05-08-2012, 18:16
  4. FAQ MODIFICA PS3
    Di John Locke nel forum Hacking Helper Zone
    Risposte: 0
    Ultimo Messaggio: 05-12-2010, 12:50

Permessi di Scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •