Posts written by Carisma20

Benvenuto nel forum Stifler!!!

I LED ROSSI

La console di casa Microsoft notoriamente soffre di problemi di riscaldamento, talvolta molto gravi, dovuti probabilmente al fatto che la componentistica ad altissime prestazioni non è in grado di dissipare correttamente tutto il calore prodotto.
Se state leggendo questo tutorial è perché avete un problema con l’Xbox 360, che sia un problema relativo a microfratture sulle saldature della CPU o della GPU o relativo a temperature troppo elevate (feeeze continui o artefatti video), il risultato è lo stesso e tutto ciò col tempo porta alle fatidiche 3 luci rosse della morte (3rings of death).

Le operazioni qui descritte servono a ripristinare e/o evitare (se l’operazione viene fatta prima che la console dia le 3 luci rosse della morte) il distacco di una o più microsaldature, tra scheda madre, gpu e cpu, dovute all’eccessivo calore prodotto ed ad un sistema di raffreddamento, almeno per quanto riguarda la gpu, sottodimensionato.
Le microfratture che vanno a crearsi col tempo possono compromettere il corretto funzionamento della console presentando appunto i 3 led rossi della morte con relativo codice di errore 0102, 0110 o 0022 .

potete praticamente buttare la console ....... oppure no?

1 – DISASSEBLAGGIO

*Innanzitutto è necessario disassemblare la console seguendo questo tutorial .
Aperta la console, sono facilmente rimuovibili il lettore DVD-ROM ed il convogliatore d’aria davanti alle ventole.

*Successivamente si procede con lo smontaggio della piastra dalla gabbia metallica: per fare cio’ e’ sufficiente svitare tutte le viti, con giravite torx 8, sotto la lamiera metallica.



*Una volta svitate le viti, si procede con lo smontaggio del pannellino anteriore per l’avvio della console, il quale avviene svitando le tre viti di fissaggio, una delle quali e’ posizionata proprio sotto la mascherina di plastica bianca contenente il pulsante ON/OFF.

*Una volta estratto il pannellino, la scheda madre si rimuove con grande semplicita’ sollevando con cautela la parte anteriore.

2- RIMOZIONE DELLE X-CLAMPS E SOSTITUZIONE DEL CONDUTTIVO

*questo passaggio è il più complicato e ha bisogno di moltissima cautela e pazienza, perciò non abbiate fretta.

*Il sistema di dissipazione è ancorato alla piastra attraverso le staffe a X (le X-Clamps) posizionate proprio sotto la scheda madre.
Per rimuovere le staffe, ponete la scheda su un lato, e fate leva sull’estremità di una delle staffe con un cacciavite a taglio (della debita dimensione) come indicato in figura.



*Una volta rimossa un’estremita’, procedente con la successiva; rimosse due estremità, le ultime due si sganceranno con facilità.
A questo punto è possibile rimuovere il dissipatore.
Iterate lo stesso procedimento per il secondo dissipatore.
La situazione che si presenterà ai vostri occhi e’ la seguente:



* Per rimuovere la pasta originale sono possibili i seguenti metodi:

1. alcool e cotton-fioc e tantissima pazienza (l’alcool non e’ assolutamente il miglior solvente per questo composto)

2. arcticlean, che non si trova proprio dappertutto, ma grazie al quale l’operazione risulterà nettamente piu’ semplice
Basandomi sulla mia esperienza, vi dico che la pasta originale conduce calore ma non elettricità, ragion per cui anche qualora sporcasse i pin della componentistica prossima ai core non succederebbe nulla di grave: cio’ non toglie che bisogna comunque prestare la dovuta attenzione.

*Una volta rimossa COMPLETAMENTE la pasta originale (il lavoro deve essere impeccabile, altrimenti si annulla l’efficacia dell’operazione), si procede con l’applicazione della nuova (si consiglia l’Artic silver 5 , pasta a base di argento), magari con l’ausilio di una piccola spatola di plastica.
L’applicazione deve essere omogenea e deve formare un film sottilissimo, dal momento che lo scopo e’ solamente quello di colmare i microvuoti di contatto, non quello di formare un ulteriore strato di scambio termico



Vi ricordo che la pasta termoconduttiva va applicata solo sulla superficie dei core (la parte metallizzata del processore), non su tutto il processore!
Una volta terminata l’operazione di sostituzione della pasta termoconduttiva si può passare alla modifica del sistema di ancoraggio dei dissipatori.
Se potete e/o volete è consigliabile lappare (levigare) con della carta acqua finissima (utilizzate almeno una carta da 1000, più è alto il numero della carta abrasiva più essa risulterà fine) la superficie dei due dissipatori a contatto con i core ( non dovete lappare i core mi raccomando! ), essa deve diventare quasi uno specchio, questa operazione riduce al minimo i micro vuoti e migliora ancor più lo scambio termico tra core e dissipatore.

3-Modifica del sistema di ancoraggio dei dissipatori

*Occupiamoci ora dei dissipatori. Aiutandoci con un paio di pinze (o con una piccola chiave inglese) svitiamo gli agganci delle X-Clamps (ce ne sono 4 per ogni dissipatore).



*Ora dobbiamo procurarci 8 viti e 16/24 rondelline in acciaio o 24 gommini. Vi conviene portare dietro una delle viti originarie oppure direttamente un dissipatore in modo che il ferramenta con un calibro possa vedere subito la dimensione della vite e darvi quelle nuove con relativi bulloncini, rondelle o gommini adatti.

Le viti non devono essere più lunghe di 1 cm, nel caso siano più lunghe andranno poi tagliate a misura con un seghetto per ferro. La sezione della vite dovrebbe essere di circa 5 mm.

Per dare un’idea la sigla corretta della vite dovrebbe essere “M5-.80 x 10” mentre le rondelline sono da 5 mm (nel mio caso – ed è piuttosto importante – lo spessore delle rondelline in acciaio era di circa 1,5 mm ).

Potete anche procurarvi 16 “rondelline” (sottili come un foglio di carta per capirci) in nylon (per evitare possibili cortocircuiti al contatto delle rondelle in acciaio con la scheda madre).

Per il fissaggio dei dissipatori, viti e rondelle fatte riferimento allo schema che trovate poco sotto.



*Come potete vedere nei 3 test mostrati nello schema i dissipatori esercitando una pressione differente sul core, vi conviene incominciare con la soluzione della “flessione leggera” se cosi non risolvete il problema passate alla successiva. Sconsiglio di applicare sin da subito la soluzione estrema della “flessione grande” è sempre meglio procedere per gradi.
Riguardo al sistema di fissaggio rispetto a quanto avveniva col sistema originario la vite che fissa i dissipatori si avviterà direttamente dal retro della scheda madre e non più dalla scocca in acciaio, come avveniva in precedenza con le piccole viti torx nere.

*Ora rimettiamo all’interno della scocca in acciaio la scheda madre, riavvitiamo tutte le viti (ovviamente escluse le torx nere che andavano ad avvitarsi sulle X-Clamps), rimettiamo ventole, convogliatore d’aria e lettore dvd. Rimontiamo anche la placchetta anteriore sulla quale vi è l’interruttore di accensione ed i led.

4- GRAN FINALE

Siamo giunti alla parte più importante. Colleghiamo le ventole, il cavo video e l’alimentazione. Proviamo ad accendere.
Se la xbox360 si avvia senza problemi, testatale per un po, e se non dovessero presentarsi problemi, potete richiudere il tutto e tornare a giocare tranquillamente.

Se invece ricompaiono i 3 led rossi occorre ancora effettuare una rapida ma fondamentale operazione: facciamo surriscaldare la console, in questo modo le microsaldature incrinate dovrebbero ricomporsi.
Per fare ciò scolleghiamo le ventole e, con cavo video e di alimentazione attaccati, riaccendiamola.
Compariranno dapprima i 3 led rossi (mi raccomando è fondamentale aver attaccato la schedina con i led di stato per questa operazione se no non si può capire quando si surriscalda); a questo punto attendiamo che si surriscaldi a sufficienza: sapremo quando ciò accade perché al posto dei 3 led rossi ne compariranno solo due rossi (quelli di sinistra).
Da quando vi compaiono i 2 led rossi, lasciatela ancora accesa per 2 minuti (io ho fatto così ed è bastato). Poi spegnetela tramite l’interruttore principale e lasciatela completamente raffreddare.
Una volta fredda, riattaccate le ventole e riprovate ad accenderla.
Nel caso dovessero presentarsi sin da subito i 2 led rossi il problema è sicuramente dovuto al non corretto contatto tra dissipatore di cpu o gpu con il core, quindi spegnete e diminuite leggermente lo spessore creato dalle rondelle e/o stringete un po di più le viti.
Se invece dovessero presentarsi artefatti grafici il problema come sopra è dovuto al non corretto contatto tra il dissipatore della gpu ed il rispettivo core ( la gpu è quella col dissipatore basso) quindi anche in questo caso dovrete dimminuire leggermente la distanza tra scheda madre e dissipatore e/o stringere maggiormante le viti.

bene questo è tutto!! è un lavoraccio ma sempre meglio provare ke avere un xbox rotta giusto??


PS: Non mi assumo nessuna responsabilità riguardo a ulteriori danneggiamenti fatti alla vostra console..... la guida è a puro scopo informativo!!!!

Un ricercatore che si occupa di sicurezza informatica è riuscito a scoprire le chiavi di sicurezza del chip Infineon SLE 66 CL PC, utilizzato nel mondo dell'informatica per la gestione di chiavi digitali e la certificazione di software eseguibile all'interno di una macchina.

Christopher Tarnovsky, ricercatore presso Flylogic Engineering, ha infatti affermato di aver sbloccato le chiavi relative a questo chip utilizzato come Trusted Platform Module (TPM) anche dalla console Xbox 360 e che si occupa di impedire l'esecuzione di software non autorizzato. Tarnovsky ha approfittato della scoperta per sottolineare come i chip basati sulle specifiche TPM 1.2 "non sono così sicuri come i produttori vogliono farvi credere".

Un chip TPM, su un computer, dovrebbe impedire l'esecuzione di software malevolo garantendo l'esclusivo funzionamento di applicazioni "certificate". Fino a oggi questo tipo di funzionalità non è entrato a pieno regime, anche a causa dell'opposizione dei sostenitori del software open source "non certificabile", ma è utilzizato ad esempio da Microsoft all'interno della propria console Xbox 360 per impedire l'esecuzione di software non autorizzato o di videogiochi non certificati.

Fino a oggi, infatti, pur esistendo un sottobosco di pirateria legato alla console Xbox 360, gli hacker non sono riusciti a eseguire software non autorizzato sulla console. Nella precedente generazione, la Xbox 1 consentiva l'esecuzione di "dashboard" (l'interfaccia utente) alternative e di software non originale, comprensive applicazioni multimediali che estendevano le funzionalità della console. La scoperta di Tarnovsky, che comunque non ha reso note le caratteristiche del baco, consentirebbe la nascita di un universo del tutto inesplorato su Xbox 360, da giochi fatti in casa ad applicazioni in grado di eseguire funzionalità al momento non previste.

Infineon, produttrice del chip, ritiene impossibile questo tipo di "exploit", ma Tarnovsky conferma la riuscita dell'esperimento ed è pronto a dimostrarne l'efficacia che consentirebbe di sintonizzarsi sul databus della console e decifrare tutti i dati trasmessi, chiavi di sicurezza comprese.

Si tratta comunque di una procedura piuttosto complessa e che richiede alcune modifiche all'hardware della console, ma è comunque un primo passo dopo le recenti novità relative alla PlayStation 3 hackata dal noto smanettone GeoHot.


Tutto ciò comunque vuol dire che riusciremo a far partire materiale pirata anche su una console non modificata.

Benvenuto nel forum!!!

Bravo... se vuoi continuare a giocare con giochi sempre più nuovi comprane altri.... quelli che.hanno la large invece giocheranno scaricandoseli...

P2P is not a crime!!!

Niente chip... purtroppo è finira l'era in cui bastava mettere un chip per far partire tutto... adesso devi entrare e smatrare tutto il bios per capire come funziona il controllo sulla protezione.... da quel che ho capito bisogna dare un colpo di saldatura ad un collegamento sulla scheda madre, per quasi mezzo secondo, cioè possibilità molto alta di mandare a puttane la console e comprarne un'altra per ritentare di mandare a puttane anche quella... nel caso in cui non riusciate a mandarla a puttane, perchè avete azzeccato la procedura, vi ritroverete nel bios dove dovrete cambiare alcuni settaggi (quelli per il controllo del disco per intenderci....). Ovviamente questo può essere fatto solo su console che supportano linux, ed ecco il motivo per cui sulle slim linux non gira, evidentemente la sony aveva già capito qualcosa e scoperto questa falla nel sistema, e quindi ha deciso di produrre la slim.... e quelli che l'hanno comprata continueranno a comprare giochi a 70 euro l'uno...

Finalmente la ps3 sarà modificabile..... questo grazie al noto hacker George Hotz, già conosciuto per aver hackerato l'Iphone.... ecco il suo articolo con la relativa traduzione:

George Hotz, previously known as an iPhone hacker, announced that he hacked the Playstation 3 and then provided exploit details. Various articles have been written about this but none of them appear to have analyzed the actual code. Because of the various conflicting reports, here is some more analysis to help understand the exploit.

The PS3, like the Xbox360, depends on a hypervisor for security enforcement. Unlike the 360, the PS3 allows users to run ordinary Linux if they wish, but it still runs under management by the hypervisor. The hypervisor does not allow the Linux kernel to access various devices, such as the GPU. If a way was found to compromise the hypervisor, direct access to the hardware is possible, and other less privileged code could be monitored and controlled by the attacker.

Hacking the hypervisor is not the only step required to run pirated games. Each game has an encryption key stored in an area of the disc called ROM Mark. The drive firmware reads this key and supplies it to the hypervisor to use to decrypt the game during loading. The hypervisor would need to be subverted to reveal this key for each game. Another approach would be to compromise the Blu-ray drive firmware or skip extracting the keys and just slave the decryption code in order to decrypt each game. After this, any software protection measures in the game would need to be disabled. It is unknown what self-protection measures might be lurking beneath the encryption of a given game. Some authors might trust in the encryption alone, others might implement something like SecuROM.

The hypervisor code runs on both the main CPU (PPE) and one of its seven Cell coprocessors (SPE). The SPE thread seems to be launched in isolation mode, where access to its private code and data memory is blocked, even from the hypervisor. The root hardware keys used to decrypt the bootloader and then hypervisor are present only in the hardware, possibly through the use of eFUSEs. This could also mean that each Cell processor has some unique keys, and decryption does not depend on a single global root key (unlike some articles that claim there is a single, global root key).

George’s hack compromises the hypervisor after booting Linux via the “OtherOS” feature. He has used the exploit to add arbitrary read/write RAM access functions and dump the hypervisor. Access to lv1 is a necessary first step in order to mount other attacks against the drive firmware or games.

His approach is clever and is known as a “glitching attack“. This kind of hardware attack involves sending a carefully-timed voltage pulse in order to cause the hardware to misbehave in some useful way. It has long been used by smart card hackers to unlock cards. Typically, hackers would time the pulse to target a loop termination condition, causing a loop to continue forever and dump contents of the secret ROM to an accessible bus. The clock line is often glitched but some data lines are also a useful target. The pulse timing does not always have to be precise since hardware is designed to tolerate some out-of-spec conditions and the attack can usually be repeated many times until it succeeds.

George connected an FPGA to a single line on his PS3’s memory bus. He programmed the chip with very simple logic: send a 40 ns pulse via the output pin when triggered by a pushbutton. This can be done with a few lines of Verilog. While the length of the pulse is relatively short (but still about 100 memory clock cycles of the PS3), the triggering is extremely imprecise. However, he used software to setup the RAM to give a higher likelihood of success than it would first appear.

His goal was to compromise the hashed page table (HTAB) in order to get read/write access to the main segment, which maps all memory including the hypervisor. The exploit is a Linux kernel module that calls various system calls in the hypervisor dealing with memory management. It allocates, deallocates, and then tries to use the deallocated memory as the HTAB for a virtual segment. If the glitch successfully desynchronizes the hypervisor from the actual state of the RAM, it will allow the attacker to overwrite the active HTAB and thus control access to any memory region. Let’s break this down some more.

The first step is to allocate a buffer. The exploit then requests that the hypervisor create lots of duplicate HTAB mappings pointing to this buffer. Any one of these mappings can be used to read or write to the buffer, which is fine since the kernel owns it. In Unix terms, think of these as multiple file handles to a single temporary file. Any file handle can be closed, but as long as one open file handle remains, the file’s data can still be accessed.

The next step is to deallocate the buffer without first releasing all the mappings to it. This is ok since the hypervisor will go through and destroy each mapping before it returns. Immediately after calling lv1_release_memory(), the exploit prints a message for the user to press the glitching trigger button. Because there are so many HTAB mappings to this buffer, the user has a decent chance of triggering the glitch while the hypervisor is deallocating a mapping. The glitch probably prevents one or more of the hypervisor’s write cycles from hitting memory. These writes were intended to deallocate each mapping, but if they fail, the mapping remains intact.

At this point, the hypervisor has an HTAB with one or more read/write mappings pointing to a buffer it has deallocated. Thus, the kernel no longer owns that buffer and supposedly cannot write to it. However, the kernel still has one or more valid mappings pointing to the buffer and can actually modify its contents. But this is not yet useful since it’s just empty memory.

The exploit then creates a virtual segment and checks to see if the associated HTAB is located in a region spanning the freed buffer’s address. If not, it keeps creating virtual segments until one does. Now, the user has the ability to write directly to this HTAB instead of the hypervisor having exclusive control of it. The exploit writes some HTAB entries that will give it full access to the main segment, which maps all of memory. Once the hypervisor switches to this virtual segment, the attacker now controls all of memory and thus the hypervisor itself. The exploit installs two syscalls that give direct read/write access to any memory address, then returns back to the kernel.

It is quite possible someone will package this attack into a modchip since the glitch, while somewhat narrow, does not need to be very precisely timed. With a microcontroller and a little analog circuitry for the pulse, this could be quite reliable. However, it is more likely that a software bug will be found after reverse-engineering the dumped hypervisor and that is what will be deployed for use by the masses.

Sony appears to have done a great job with the security of the PS3. It all hangs together well, with no obvious weak points. However, the low level access given to guest OS kernels means that any bug in the hypervisor is likely to be accessible to attacker code due to the broad API it offers. One simple fix would be to read back the state of each mapping after changing it. If the write failed for some reason, the hypervisor would see this and halt.

It will be interesting to see how Sony responds with future updates to prevent this kind of attack.

Traduzione:


George Hotz, precedentemente conosciuto come un hacker di iPhone, ha annunciato di aver violato la Playstation 3 e poi sfruttare fornito dettagli. Vari articoli sono stati scritti su questo, ma nessuno di loro sembra aver analizzato il codice vero e proprio. A causa delle varie relazioni in conflitto, ecco alcune analisi di più per aiutare a capire l'exploit.

La PS3, come la Xbox360, dipende da un hypervisor per la tutela della sicurezza. A differenza del 360, la PS3 permette agli utenti di far girare Linux ordinaria, se lo desiderano, ma funziona ancora in fase di gestione da parte della hypervisor. L'hypervisor non permette al kernel Linux di accedere a vari dispositivi, come ad esempio la GPU. Se è stato trovato un modo per compromettere l'hypervisor, l'accesso diretto all'hardware è possibile, e altri codici meno privilegiati potevano essere monitorate e controllate da un aggressore.

Hacking l'hypervisor non è l'unico passo necessario per eseguire i giochi pirata. Ogni partita ha una chiave di cifratura memorizzata in un'area del disco chiamata ROM Mark. Il firmware del disco si legge questa chiave e le forniture per l'hypervisor da utilizzare per decifrare il gioco durante il caricamento. L'hypervisor avrebbe bisogno di essere sovvertito per rivelare questa chiave per ogni gioco. Un altro approccio sarebbe quello di compromettere il firmware del drive Blu-ray o saltare l'estrazione delle chiavi e proprio schiavo del codice di decrittazione, al fine di decifrare ogni partita. Dopo questo, tutte le misure di protezione del software nel gioco dovrebbe essere disabilitato. Non si sa cosa auto-misure di protezione potrebbe essere in agguato sotto la crittografia di un dato gioco. Alcuni autori potrebbero fiducia nella crittografia da soli, altri potrebbero implementare qualcosa di simile SecuROM.

Il codice viene eseguito su hypervisor, sia la CPU principale (PPE) e uno dei suoi sette coprocessori Cell (SPE). Il thread SPE sembra essere lanciato in modalità di isolamento, in cui l'accesso al suo codice privato e la memoria dei dati è bloccata, anche dal hypervisor. Le chiavi hardware radice utilizzata per decifrare l'hypervisor bootloader e quindi sono presenti solo in hardware, possibilmente mediante l'uso di eFUSEs. Ciò potrebbe anche significare che ogni processore Cell ha alcune chiavi univoche, e la decrittografia non dipende da una sola chiave principale a livello mondiale (a differenza di alcuni articoli di tale affermazione vi è un unico, fondamentale radice globale).

George's hack compromette l'hypervisor dopo l'avvio di Linux tramite il OTHEROS "funzionalità". Ha utilizzato l'exploit per aggiungere lettura arbitraria / scrivere le funzioni di accesso di RAM e il dump del hypervisor. L'accesso a lv1 è un primo passo necessario per montare altri attacchi contro il firmware del drive o giochi.

Il suo approccio è intelligente ed è conosciuto come un attacco "glitch". Questo tipo di attacco hardware comporta l'invio di un impulso di tensione con attenzione al momento giusto, al fine di provocare l'hardware a comportarsi male in qualche modo utile. È stato a lungo utilizzato dagli hacker smart card per sbloccare le carte. In genere, gli hacker avrebbero tempo l'impulso per raggiungere una condizione di terminazione del ciclo, causando un ciclo di continuare sempre e dump contenuto della ROM segreto per un bus accessibile. La linea di clock è spesso glitched, ma alcune linee dati sono anche un obiettivo di utile. I tempi di impulso non sempre per essere precisi visto che l'hardware è progettato per tollerare alcune out-of-condizioni specifiche e l'attacco di solito può essere ripetuto molte volte fino a quando non ci riesce.

George collegato un FPGA a una sola riga sulla sua PS3 bus di memoria. Ha programmato il chip con una logica molto semplice: invia un impulso di 40 ns tramite il pin di uscita, quando attivato da un pulsante. Questo può essere fatto con poche righe di Verilog. Mentre la lunghezza dell'impulso è relativamente breve (ma ancora circa 100 cicli di clock di memoria della PS3), l'avvio è molto imprecisa. Tuttavia, ha utilizzato il software per impostare la RAM a dare una maggiore probabilità di successo di quanto non sarebbe primo apparire.

Il suo obiettivo era quello di compromettere la tabella di hash pagina (HTAB) al fine di ottenere in lettura / scrittura di accesso al segmento principale, che tutte le mappe della memoria compresi l'hypervisor. L'exploit è un modulo del kernel Linux che chiama le chiamate di sistema in varie hypervisor si occupano di gestione della memoria. Si assegna, deallocazione, e poi tenta di utilizzare la memoria rilascia come HTAB per un segmento virtuale. Se il glitch desynchronizes con successo l'hypervisor dallo stato attuale della RAM, permetterà il malintenzionato di sovrascrivere il HTAB attiva e quindi controllare l'accesso a qualsiasi area di memoria. Let's scomposizione ancora un po '.

Il primo passo è quello di allocare un buffer. L'exploit poi chiede che l'hypervisor di creare un sacco di duplicati mappature HTAB che punta a questo buffer. Uno di questi mapping può essere utilizzato per leggere o scrivere al buffer, che va bene dato che il kernel possiede. In termini Unix, pensate di questi file come più maniglie per un singolo file temporanei. Qualsiasi file handle può essere chiusa, ma il tempo come un file handle aperto rimane, i dati del file sarà comunque possibile accedere.

Il passo successivo è quello di rilasciare il buffer senza prima rilasciare tutte le mappature ad esso. Questo è ok in quanto l'hypervisor passerà attraverso e distruggere ogni mappatura prima che ritorni. Immediatamente dopo aver chiamato lv1_release_memory (), l'exploit stampa un messaggio per l'utente di premere il pulsante glitch grilletto. Perché ci sono così tante mappature HTAB a questo buffer, l'utente ha una buona probabilità di scatenare il glitch mentre l'hypervisor è una mappatura deallocazione. Il glitch impedisce probabilmente uno o più degli hypervisor di cicli di scrittura da colpire memoria. Scrive queste erano destinati a rilasciare ogni mappatura, ma se dovesse fallire, la mappatura rimane intatto.

A questo punto, l'hypervisor è uno HTAB con uno o più di lettura / scrittura mapping che punta a un buffer che ha rilasciato. Così, il kernel non possiede più che tampone e presumibilmente non si può scrivere su di essa. Tuttavia, il kernel è ancora uno o più mapping valido che punta al buffer e può effettivamente modificare il suo contenuto. Ma questo non è ancora utile, perché non solo la memoria vuota.

L'exploit quindi crea un segmento virtuale e controlla per vedere se il HTAB associate è situata in una regione si estende l'indirizzo del buffer liberato's. In caso contrario, continua a creare segmenti virtuale fino a quando si fa. Ora, l'utente ha la possibilità di scrivere direttamente a questo HTAB l'hypervisor, invece di avere il controllo esclusivo di esso. L'exploit scrive alcune voci HTAB che darà pieno accesso al segmento principale, che tutte le mappe della memoria. Una volta che l'hypervisor passa a questo segmento virtuale, l'attaccante ora controlla tutta la memoria e quindi l'hypervisor stesso. L'exploit installa due chiamate di sistema che danno diretto lettura / scrittura di accesso a qualsiasi indirizzo di memoria, poi ritorna indietro al kernel.

È del tutto possibile che qualcuno pacchetto di questo tipo di attacco in un modchip in quanto il glitch, mentre un po 'stretto, non ha bisogno di essere molto preciso cronometrati. Con un microcontrollore e un po 'i circuiti analogici per il polso, questo potrebbe essere molto affidabile. Tuttavia, è più probabile che un bug del software sarà trovato dopo la reverse-engineering l'hypervisor di dumping e che è ciò che verrà distribuito per l'uso da parte delle masse.

Sony sembra aver fatto un ottimo lavoro con la sicurezza della PS3. Il cerchio si chiude bene, senza evidenti punti deboli. Tuttavia, l'accesso a basso livello al kernel determinato sistema operativo guest significa che qualsiasi errore nella hypervisor è probabile che sia accessibile al codice attacco a causa della vasta API che essa offre. Una soluzione semplice sarebbe quella di rileggere lo stato di ogni mappatura dopo le modifiche. Se la scrittura non riuscito per qualche motivo, l'hypervisor vedrebbe questo e arrestare.

Sarà interessante vedere come Sony risponde con aggiornamenti futuri per prevenire questo tipo di attacco.

Traduzione fatta da Google translate.......

Si, ma...... i link per il download dove sono??? A che pro aprire una discussione su un gioco se poi mancano i download???

Benvenuto nel forum!!!

Benvenuto nel forum!!

Benvenuto nel forum!!!

Benvenuto nel forum!!

Benvenuto nel forum!!!

Benvenuto nel forum!!!

Benvenuto nel forum!!!