prima contromossa al Reset Glitch Hack?

[guerrierodipace]

segnalo la scoperta da parte di un utente "stephane76700" del sito logic-sunrise di una revisione hardware che potrebbe bloccare il nuovo RGH

la xbox360 era contenuta nel pack "Forza 4 250 Go"

data di produzione 17-08-2011

monta un liteon 1071

segni particolari: manca il chip HANA....

UPDATE: il nome in codice della revisione è "Corona" e l'alimentazione non è più 10.83A ma 9.86A

la NAND è stata spostata sul lato inferiore e al suo posto c'è un componente che sembra non commerciale,si sta cercando di identificarlo


foto a seguire:
[URL=http://imageshack.us/photo/my-images/708/slimnewmobo4.png/][/URL][URL=http://imageshack.us/photo/my-images/845/slimnewmobo3.png/][/URL][URL=http://imageshack.us/photo/my-images/810/slimnewmobo2.png/][/URL][URL=http://imageshack.us/photo/my-images/207/slimnewmobo1.png/][/URL]
sopra:

sotto:

[rf1911]

Questo confermerebbe anche il nuovo 1BL...

[thematrix999]

il filo dell'RGH che andava saldato vicino al chip HANA serviva per prendere il clock per il microcontrlollore? o per modificare il clock della console?

[DS-1]

Domanda stupidissima: la data di produzione della console non è antecedente alla scoperta dell'hack?

[spyro82]

se notate la terza foto manca il chip hana!!!

[guerrierodipace]

se notate la terza foto manca il chip hana!!!

nella news in homepage è già scritto
qui non l'ho ripetuta ora aggiungo

[spyro82]

scusa errore mio non avevo letto tutta la home perdonami ancora

[guerrierodipace]

scusa errore mio non avevo letto tutta la home perdonami ancora

tranquillo

[xboxbs]

scusate ma il reset glitch hack è del 28 agosto...forse la mfr date è 17-09-2011?
[url=http://forums.xbox-scene.com/index.php?showtopic=735015]The Xbox 360 reset glitch hack - New Homebrew Hack! - Scenyx Entertainment Community[/url]

[Mauroz]

Scusa lite-on 1071 come già trovati o un altro nuovo 1701 come scritto a inizio post

[guerrierodipace]

Scusa lite-on 1071 come già trovati o un altro nuovo 1701 come scritto a inizio post

bravo
fa piacere che qualcuno legga con attenzione, ho corretto (my fault)

[Mauroz]

ormai si poteva pensare davvero anche ad un nuovo lettore......
Ma è confermato che questa nuova revisione hadware blocca il glitch reset?
Credo purtroppo di si..

[guerrierodipace]

ormai si poteva pensare davvero anche ad un nuovo lettore......
Ma è confermato che questa nuova revisione hadware blocca il glitch reset?
Credo purtroppo di si..

è presto per dirlo...

[Vola]

Forse più che una versione apposita per bloccare il RGH è una nuova versione su cui RGH non è mai stato testato...

[rf1911]

Questo è un altro indizio che MS sapeva qualcosa... prima CB splittato su fats refurbished, poi E81 e check del secdata/crl per evitare downgrade, poi revisione motherboard... non voglio fare dietrologia, ma 3 indizi fanno una prova...

[rf1911]

In ogni caso, il punto della resistenza R4B24 che proviene dall'Hana è solo il clock di STBY. Siccome comuni comunica con il sb e la nand ci deve essere un punto alternativo!
Se l'indirizzo dell'i2c non cambia dovrebbero bastare solo alcune modifiche del software che gestisce il glitch...

[guerrierodipace]

buona notizia

[Pa0l0ne]

Allego un paio di interventi chiarificatori in merito alla questione di uno dei veri Guru della scena (Blackaddr):

The manufacturing date of the new console is August 17th, before the glitch became public. Glaze83 is probably correct that the HANA and SB have been consolidated. Less likely is the HANA and GPU have been consolidated.

Just because the two previously separate devices might now sit on the same die (or atleast the same package) does not mean they dont' still communicate over an abstracted version of the I2C bus. This would prevent the designers having to rewrite all their existing software code.

If that bus is still exposed on the PCB, then nothing really changes.

If the bus is no longer exposed (since everything it connected to is now contained on the unified SB/HANA), then you still can glitch it, but you have to tell the SMC to handle the CPU clock speed adjustments.

I've already made a fair bit of progress towards porting the glitch to the SMC. To create an SMC based glitch hack for the slim, I was eventually going to have to use the SMC's I2C software routines to change the speed anyway.


The SMC itself is not fast enough, per say. A NOP instruction takes 170 ns. You still need an external circuit to precision delay the reset, but the circuit is not that complicated. I've noticed the pulse width is not that important on my Falcon, the moment where the pulse begins is.

Regarding security, and how MS might fix the glitch vulnerability, here are my thoughts:

The IBM processor as provided by IBM is not really a secure processor itself, nor should it be. The security layers are provided by microsoft.

The mistake MS made was in not doing anything to prevent hardware attacks, as Tmbinc noted back in 2007. That includes glitches on power, clock and reset. You don't have to worry about voltage glitching on a big processor because of capacitance.

Clock glitching is tough to protect against. Reset glitching is not. Regardless of whether your system needs security or not, even if your system uses asynchronous resets inside, you always buffer and extend the reset to ensure clean resets going to the asynchronously reset flops. Ultimately this was Microsofts responsiblity, not IBM. You never just pass an external reset signal directly into your logic where security is a concern. MS had ample opportunity to heed Tmbinc's advice and correct this each time they spun the CPU, they did not.

We might still see a properly buffered reset on future CPUs and it wouldn't be that hard or expensive for MS. If they are like most ASIC designers, you sprinkle unused logic gates around your custom logic. This is done so that if you need to fix anything, you use the existing (though unused) logic already there, and you only change the metal layers (the wiring) not the silicon (the logic).

Where as changing the logic (silicon) mask can cost a million dollars and take 6 months to spin, changing the metal interconnect often costs tens of thousands, and could be spun in a month. Not to mention you don't waste leftover bare dies that haven't had metal layers added.

Even cheaper of course is to just change the PCB. If MS thinks they can reliabliy fix the problem with a new PCB, we'll see yet another one after Corona, rather than a new CPU. But, that's still avoiding the original problem with the reset.

Now of course MS engineers should KNOW ALL OF THIS, they're not stupid, and I'm sure someone is saying to their managers, "I told you so!". I suspect any future hacking depends on what MS managers decide, not what MS engineers know or don't know.

All Credits to Blackaddr & xboxhacker forum