RGH Explained

[miki4]

Think about it, MS updates CB to Dual somehow, if possible or not but lets say they can.

user glitch their system before new cb update, gets cpu key. Updates to new dual cb, well they can glitch the same as before.

as they can decrypt it with the cpu key before hand.

As far as I know, phat CB has LDV checks, so it would not be possible to downgrade to a glitchable CB.

[Grandmaster56]

So they burn the efuses and increase the LDV on the CB..so what?? doesn't mean the CPU isnt glitchable afterwards.Also having your cpu key has nothing to do with glitching.

[Xumpy]

There is no problem in glitching a dual CB the trinity boards all have dual CB.

The problem is that nobody has found (posted) the correct timings + a hacked CB that would load a custom CD for dual CB phats (you following)

But let's keep this on toppic.

What I can make up of all this.

There are 2 ways of interacting with the nand:

- SMC trough flash controller (software based)
- SPI port trough the flash controller (hardware based)

Is it possible that they somehow locked the nand, as they have done with the dvd boards flash???

* EDIT * This is stuppid, you wouldn't be able to accept updates if the nand was locked. But maybe only the SMC has read/write capabilities.

Maybe they just cut a line or something so the spi only can be used on manufacturing...

Would be interesting if someone could investigate cause I don't own a corona.

[Tony_Amigozs]

hopefully you are right because the lastest dashboard updates all fat consoles cb to dual cb confirmed on xecuter forums.

[SSkillZ]

Who said its a dual CB? Its a different CB but it doesn't mean its two staged. Even if it is composed of two parts
it doesn't mean its exactly the same code as slims, I doubt it is. Anyway they need to find a weakness, and glitch it.

BTW, @Blackaddr , Do you know if work is being done on any of the two staged CBs of phats? Those are important as
correct me if I'm wrong, but if m$ mistakenly moved the LDV check to CB_B glitching it will unlock the entire board reversion (faclon, jasper...).
For example if CB 5772 (falcon), which I read is two staged, has LDV check in the second stage glitching the first stage
will unlock all falcons. Since you can then use the same CB_A on any falcon (same HW) with any LDV value - possibly unpatchable.

[peshkohacka]

Haven't checked myself, but i've already heard it from a few people that POST output  have been changed, also the Phat CB_A have pairing data (unlike slim) and apparently differs from the Trinity CB. Let the fun begin.

[ddxcb]

Haven't checked myself, but i've already heard it from a few people that POST output  have been changed, also the Phat CB_A have pairing data (unlike slim) and apparently differs from the Trinity CB. Let the fun begin.

not aiming at you but, dang ms keep up on the security. But stop attacking the RGH/unsigned coded system. Get the people using backups online, not the unsigned code systems.

[peshkohacka]

Haven't checked myself, but i've already heard it from a few people that POST output  have been changed, also the Phat CB_A have pairing data (unlike slim) and apparently differs from the Trinity CB. Let the fun begin.

not aiming at you but, dang ms keep up on the security. But stop attacking the RGH/unsigned coded system. Get the people using backups online, not the unsigned code systems.

I'm not pro-backups/cheaters/LIVE, i don't judge the people who use their systems in the best way they see fit. I'm mostly interested in my xbox as a security device to poke with, because its simple - almost everything is reversed and public and yet it retains its security. That's why i'm interested in this update. Nothing more.

[edsondario]

Thank you Blackaddr ! Increased my understanding of RGH. I will not lose much time with the Slims.

[peshkohacka]

Has anyone else noticed something odd - when you put a resistor in parallel to the capacitor - you boot within half a minute. I put 15kOhm  and it boots fairly quickly but  removing the resistor hangs the CPU (pretty much like Xenon when de-asserting), 10kOhm is much better and doesn't always cause a hang (doesn't cause a hang if you wait the boot anim to finish). I've also tried 100Ohm but the CPU goes into constant reset.

[Xumpy]

Blackaddr if the nand really is the problem why can't we just use a dual nand for now.

If the dual nand has an internal spi and is directly connected with the mainboard then the only problem would be that you have no original nand dump.

I guess that can be resolved with donors not?

Regards

Xump

So I guess to answer to your question. If the HANA is still there I would say that the only difference is the Onboard XTAL which runs a 25 MHz crystal instead of 27.

Yup, that's the only relevant clock change so far as we know at the moment.  

This means that if you just reuse the Trinity PLL values you'll get a slower CPU Ref clock, and thus slower CPU core clock.  Obviously you would need to retime the glitch trigger, and either change the PLL value to get 31.4 Mhz, or find an entirely new frequency 'sweet-spot' for Corona.  Probably a fair bit of trial and error, but no technical barriers in this regard.

Based on the Corona SMC, the PLL registers are accessed via I2C at the same register address as before.  However, that's just my speculation until someone hooks to the I2C pins on the board and confirms it.  There are a few groups researching privately who have asked me a few questions in this area.

As for what I've *found*, I don't have a Corona at the moment.  I'm still researching the effects of different PLL frequencies on the behavior of the reset on my Falcon.  I've posted more than enough information for any curious folk to start experimenting with HANA via I2C on their Corona.

Now, why is the Corona NAND a concern right now?

[Tieri]

Please enlighten me. Why don't we just multiply the input clock for CPLD to get better reset singnal resolution? Would this make the glitching easyer? You won't propably need any new HW either.

[Blackaddr]

Please enlighten me. Why don't we just multiply the input clock for CPLD to get better reset singnal resolution? Would this make the glitching easyer? You won't propably need any new HW either.

In general, yes.  From my experiments, as soon as I change the HANA clock speed, the system becomes far more random, far less reliable.

If you ran the glitch hardware fast enough that you can target the correct CPU instruction with the necessary precision, and without resorting to changing the HANA speed, or using PLL_BYPASS (not available on Trinity+) then it would make glitching easier from that perspective.

I do think you would need new, faster hardware.  How fast would the glitch hardware need to run?  Well, I'd say a good starting point is that on Trinity glitch, you slow the CPU down by a factor of 99.6/31.4 = 3.17.  Given that the slim hack runs the CPLD at an effective rate of 96 Mhz, you should not need to run faster than 3.17x this, which is about 304 MHz or, 3.29 ns glitch resolution.  Keep in mind that Gligli/Tiros were trying to get the HANA as slow as they could to make glitching easier, so it's quite possible glitching can be achieved with less than a factor of 3.17, which means your glitch hardware still needs to be much faster than 96 Mhz, but perhaps not as high as 300 Mhz.

Whatever the required frequency is, it will probably be much faster than what the Coolrunner CPLD can handle.  You could get a faster CPLD or small FPGA, but a fast microcontroller would probably be a better solution.

It's quite possible the glitch-chip manufacturers have already accomplished this, but are trying to find a method somehow that works on existing hardware, especially since some claimed to be "Corona ready".

[peshkohacka]

Blackaddr is correct TX are preparing a new glitch hardware (FPGA/CPLD based). Too bad for almost an year no one else have actually produce anything short of an endless CPLD clones.

[rz2k]

Too bad for almost an year no one else have actually produce anything short of an endless CPLD clones.

agreed.
cheapest spartan6 costs only 8euro and has LVCMOS15 resolution of 1.23/2.07ns (p. 26, table 28).
it will need 4layer+ pcb though.

[Tieri]

Please enlighten me. Why don't we just multiply the input clock for CPLD to get better reset singnal resolution? Would this make the glitching easyer? You won't propably need any new HW either.

In general, yes.  From my experiments, as soon as I change the HANA clock speed, the system becomes far more random, far less reliable.

If you ran the glitch hardware fast enough that you can target the correct CPU instruction with the necessary precision, and without resorting to changing the HANA speed, or using PLL_BYPASS (not available on Trinity+) then it would make glitching easier from that perspective.

I do think you would need new, faster hardware.  How fast would the glitch hardware need to run?  Well, I'd say a good starting point is that on Trinity glitch, you slow the CPU down by a factor of 99.6/31.4 = 3.17.  Given that the slim hack runs the CPLD at an effective rate of 96 Mhz, you should not need to run faster than 3.17x this, which is about 304 MHz or, 3.29 ns glitch resolution.  Keep in mind that Gligli/Tiros were trying to get the HANA as slow as they could to make glitching easier, so it's quite possible glitching can be achieved with less than a factor of 3.17, which means your glitch hardware still needs to be much faster than 96 Mhz, but perhaps not as high as 300 Mhz.

Whatever the required frequency is, it will probably be much faster than what the Coolrunner CPLD can handle.  You could get a faster CPLD or small FPGA, but a fast microcontroller would probably be a better solution.

It's quite possible the glitch-chip manufacturers have already accomplished this, but are trying to find a method somehow that works on existing hardware, especially since some claimed to be "Corona ready".

Well with my limited knowlage about VHDL and CPLD/FPGA's I can't undestand why we are still running the XC2C64A with only 96Mhz? The chips is capable for mutch faster operation. This should give us better reset singnal resolution -> more reliable glitch -> faster boot times? Am I right? So if the box is "inaf stable" whit the HANA clock down why not multiply the CPLD reference clock to get better resolution? Also faster CPLD's aren't even that expencive. Found some 600Mhz CPLD dev boards for ~20$. Af course this all is for us diy guys. The non capable and greedy are for they self. I am with this just for the fun of it. I Know I can get some TX boards/chips for ~10$, but I rather do things my self. I have fun and I enjoy myself same time as I learn something new and interesting, so why not?

P.S. Got my self new trinity. If anyone wats me to do some experiments with it to get some new info, let me know.

[RnRdude]

What is the reason that Xell always glitch faster then Dashboard ? If there was a way to load dashboard from Xell this would benefit all RGH xboxes.

[peshkohacka]

What is the reason that Xell always glitch faster then Dashboard ? If there was a way to load dashboard from Xell this would benefit all RGH xboxes.

The 4BL have a different hash, i.e. takes different (more/less) time to compute it, so the "sweet" spot is hit more often. In general its better to alter the 4BL hash in a way that the time it takes to compute the hash would be closer to the vhdl values Gli posted and load the patches/modules from the NAND on later stage. Sadly i think xeBuild always produce different hashes, so some dashboards may boot faster/slower than previous versions. Until we get a glitching device that can easily go beyond 200-300Mhz the hashes would matter.

[cory1492]

False, the hash check is done on decrypted data against a static hash contained in a signed area of the already loaded BL. For example, a static hash in CB_A is compared with a hash of the decrypted CB_B, if this check fails there is a panic and if this value is changed CB_A will fail the signature check done by 1BL, the nonce has nothing to do with the checks and is only used for decryption. If we could change the hash in question, we wouldn't need a glitch hack. What can affect it is...

1 - changing the patches in the bl that the glitched bl is loading changes the calculated hash, I won't get into it but I did try mitigating the effect of this by profiling rotsumsha calculation times as well as changing the tick counters in the CPLD and neither proved truly effective in producing any sort of answer; barring generating a hash collision with the original unchanged code which is extremely unlikely and again would remove the reason for glitching in the first place, the best that can really be done is "this works ok for most people" - making the timing more precise may help, but would have to be redone for any change to the bl.

2 - glitching is essentially random as the xbox hardware was not designed to do this... and there does seem to be some kind of 'moving target' which crashes hardware other than the CPU some of the time which results in a failed boot attempt. For example on one day my trinity boots every time within 1-3 resets, yet on another it consistently takes 5-7 resets. That it is even remotely stable at all is a miracle (or a nightmare, depending on which side of the console purchase you are on.)

3 - perception. I find when I'm working on something that requires the console to reboot alot, that even when it's glitching fast it seems... to... take... forever (think kids in a car saying: are we there yet?)

[peshkohacka]

Yeah my mistake i was actually referring to what Gli said in the initial release:

That success rate seems to depend on something like the hash of the modified bootloader we want to run (CD for fats and CB_B for slims).