RGH Explained

[Blackaddr]

There seems to be a lot of confusion about exactly how the RGH works, and what clocks are involved, etc.  Here is a brief technical summary that elaborates on the information provided already by Gligli and Tiros.  This will focus on the hardware side, not the bootloader modifications.  This information is already on XBH scattered in several threads, so I'm posting it in the General section because this is not new information, its been out there for some time.

First, let's get the clocks straight since this seems to be the root of much confusion.

Onboard XTAL: All consoles from Xenon to Trinity have a 27 MHz crystal on the board (Corona has 25 Mhz).  Every other clock on the board is generated from this xtal reference clock using one or more PLLs.  The Xenon generates fixed frequency clocks using a Cypress chip.  All other consoles have programmable PLLs in their HANA which is what we're concerned with for this document.

STBY_CLK: The 'standby' clock, so named because it is the main clock for the SMC processor.  The SMC processor runs whenver the console is plugged in, even in standby mode.  It runs at 48 MHz, it is generated by a PLL in the HANA.  It is used by the RGH CPLD because the CPLD needs some kind of clock, and it's convienient.  The actual frequency is not very relevant.  It just needs to be a 'Goldilocks' frequency, not too fast that the CPLD can't keep up, not too slow that the glitch resolution isn't sufficient.  Using an external clock instead of STBY_CLK accomplishes nothing with regards to Corona.  The STBY_CLK is on Corona, and it has already been found by private researchers.

CPU Reference Clock: this is a 100 MHz clock that comes from the HANA and connects to the CPU.  The CPU will use this clock and it's own internal PLL(s) to generate any other internal clocks it needs (excluding PCIe, etc.), such as the CPU core clock, or perhaps a reset circuit clock.  If you change this clock frequency by reprogramming the HANA (via I2C) you will also change the CPU Core Clock as a consequence.

CPU Core Clock: this is the clock that runs the CPU instruction core.  It is generated in the CPU from the CPU Reference clock, and will run much faster then the ref clock (think Gigahertz).

Now onto the Reset Glitch Hack itself.

THE EXPLOIT:
Gligli was able to get the CPU to get past the CD authentication by pulsing the reset at just the right time, for just the right length.  The idea is the successful authentication eventually boils down to a 'branch-if-register-equals-zero' instruction on a certain CPU register.  If this register has been reset, it will think the check passed.  The problem is other CPU registers have likely been reset by the glitch.  If any of these registers contain values that are needed for continued booting, the system will crash.  If no 'critical' registers got reset, the system will successfully continue loading the CD.

HOW ITS DONE:
Cjack's research discovered some methods of slowing down the CPU, including asserting CPU_PLL_BYPASS.  Asserting this signal slows CPU execution down by a factor of 128.  Gligli used this to his advantage to slow the CPU execution down enough that he could successfully exploit the system, originally using an external microcontroller.  In order to make it more user-friendly, the exploit was ported to a CPLD, that ran off the 48 MHz SMC standby clock.  This clock was chosen simply because it was convienient.  The clock is fast enough that it provides sufficient temporal resolution to pulse the reset appropriately for the exploit.

HOW ITS DONE (SLIMS):
Unfortunately, Gligli and Tiros were unable to locate CPU_PLL_BYPASS on the Trinity system, and decided to take a different approach.  Instead of using the CPU_PLL_BYPASS to slow down the core directly, they changed the frequency of the CPU reference clock (from the HANA) going into the CPU PLL which generates the core clock.  So, if you slow down the CPU reference clock from 100 MHz to 100/128 ~= 781 Khz, then you've accomplished the same thing, the core will run the same speed as if you had used CPU_PLL_BYPASS.  Unfortunately this doesn't work.  Tiros found the HANA PLL wasn't stable at arbitrarily slow frequencies.  It would wander and drift randomly around the target frequency.  This meant the CPU execution speed was constantly changing, and when you tried to time the reset pulse, the CPU was rarely at the correct instruction anymore.

BLACKADDR'S NARATIVE:
*** this portion is based on my own experiments with RGH.  I informed Tiros of my observations, he confirmed that he found the same behaviors when originally developing the Slim RGH ***

...continued from 'HOW IT'S DONE'

Luckily, you'll find that you can still reduce the HANA PLL frequency, just not by as much as you probalby would like.  The question becomes can you slow it enough to time the reset glitch properly, while keeping the HANA PLL stable.  The answer is yes!  But, something unexpected occurs. The CPU does not respond to the reset pulse in a consistent, predictable way like when you use CPU_PLL_BYPASS.  Some HANA clock frequencies are more sucessful than others, the system seems to react differently with slightly different frequencies.  The task is to find a clock slow enough to time the reset glitch, with a reset glitch length that results in the desired exploit behavior, with a reasonably high success rate.  After much trial and error, it was found that a clock frequency of roughly 1/3rd the original was suitable.

WHY SLIMS ARE HARDER:
So, the CPU reset is not purely asynchronous and this is important.  If it was, the effect of the length of the pulse would be the same regardless of what the CPU core runs at, but we know this is not the case.  I tried combining both CPU_PLL_BYPASS with slowing the HANA clock to 1/3rd on a Falcon and compared to just using CPU_PLL_BYPASS.  As expected, the CPU runs 3x slower with this extra slowdown from the HANA vs the conventional Falcon RGH.  Also as expected, the correct wait time to trigger the reset pulse is 3x longer as well.  What was not expected, is the length of the reset pulse needed to be approximately 8x as long to have any effect at all!  This means instead of a 100ns reset pulse (convential Falcon RGH) you need a minimum of about 800 ns otherwise the system completely ignores it.

What does this mean?  It means the CPU reset appears pseudo-synchronous.  THe effect of a reset pulse varies with the CPU reference clock.  It is likely there is a reset-relationship with the CPU reference clock, as well as the CPU core clock.  So why are slims harder?

There are several factors that make glitching slims more challenging. The CPU is only slowed down by a factor of about 3, instead of 128 like on phat consoles.  This means the CPLDs ability to trigger the reset at just the right moment is far less accurate, but still possible.  The slowdown is instead achieved by reducing the CPU reference frequency from the HANA.  This results in a complex reset behavior that is more random and thus less reliable.  Some people will have slims glitch quickly and consistently.  Others will struggle, trying every trick in the book and still have difficulty.  That's simply the random nature in effect.

WHAT ABOUT XENON:
Gligli and Tiros found that the Xenon CPU could be slowed down and glitched just fine using CPU_PLL_BYPASS, the problem was when de-asserting it to bring the CPU back up to full speed after passing CD authentication.  The CPU would reportedly crash.  You can't alternatively use the slim method to slow down the CPU because Xenon's do not generate the CPU reference frequency inside the ANA, they have a fixed frequency clock generator chip.  There is no technial reason why at the moment why RGH wont' work on Xenon.  Gligli and Tiros chose to focus on HDMI phats and slims rather than fight with the Xenon.  Big Hint:  Try to find a time to de-assert CPU_PLL_BYPASS such that the chip doesn't crash.

WHAT ABOUT CORONA:
I'm gonna let you think about this one.  What's different between Trinity and Corona with regard to all the clocks discussed?  Hint: the HANA is still there.  Why are the changes to the NAND important?

[dantheman]

Now that was a very interesting read and mean truthfully. I've always followed the scene but only working by tutorials and never really understood what exactly is going on. Hats off to the people who make all this possible and dedicate time to explore and share. Brilliant.

[Gazcoigne]

Great read thank you for taking the time to compile all the info into a very easy to read and understand format for us less technically minded geeks who are keen to learn

You are one of the few experts who doesn't sit on his laurels feeling important and contributes to the scene rather than having the usual f*** you attitude to anyone who isn't also in the elite club

I always enjoy reading your posts please keep them up I for one greatly appreciate them!!

[Luke69]

Thanks for the detailed explanation 

[Xumpy]

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.

And to keep in mind that all other clocks are generated from this crystal this could be quit interesting...

Did you find something Blackaddr that your trying to say???

Regards

[Blackaddr]

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?

[guerrierodipace]

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

from other posts here we know there are 2 Corona board, one have eMMC nand.
Reading and write problems?
I know that similar kind of eMMC is on maemo Nokia device N900,so eventually many people already worked around them.
Just my stupid speculation,I'm not so skilled

[utar]

Well Nandpro certainly can't read Corona Nands, but I'm not sure why.

Doesn't Nandpro just use SMC commands to read the Nand.  I don't know if this is over an i2c bus or by another method but whether the Nand is eMMC or not shouldn't make a difference.  So have the commands used changed in some way?  I know there was speculation that the SMC in Corona wasn't based on the 8051 but I don't know if this was correct or not.

[Blackaddr]

The only device that physically connects to the NAND is the Southbridge through a flash controller.  Note that the flash controller is NOT the SMC, they just live together on the SB chip.  However, the SMC can access the NAND *through* the flash controller. There is also a SPI port on the SB that can talk to the NAND *through* the flash controller.

Nandpro accesses the NAND through SPI commands.  Nandpro can't access the Corona NAND properly because something has changed.   Could be the commands themselves, could be the SB architecture has changed (it is a brand new SB design after all).  Whatever has changed, that is the biggest problem with Corona right now.  If you can't modify the NAND, there's not a lot you can do!

I know there was speculation that the SMC in Corona wasn't based on the 8051 but I don't know if this was correct or not.

I have disassembled the Corona SMC it is 100% an 8052 core, same as always.  The most noticeable difference is the size of the code space has doubled. *EDIT* This is poorly worded.  I meant the free code space available to write our own code has doubled in the Corona vs Falcon. *EDIT*

[guerrierodipace]

I know that there's just to invert 2 pin for reading the normal nand on Corona board,for eMMC I don't know if it's the same.

[peshkohacka]

I know that there's just to invert 2 pin for reading the normal nand on Corona board,for eMMC I don't know if it's the same.

You communicate with a controller through the SPI, it doesn't matter what type of media is used for storage (could be a xD card) as long as the controller talks to you. In this case it doesn't.

[cory1492]

I've seen dumps from the 16M corona (and apparently SPI is fine on those for NAND access.) The Arcade units on the other hand have only that phison chip (emmc controller as stated earlier, in the place where 16M is usually found) and a 4G NAND on the backside. For what it's worth, the emmc controller seems accessible via SPI and the NAND status reg seems to be emmc status reply.

Blackaddr, they made the corona smc 14k instead of 12k... 0x800 bytes isn't really doubling anything? Have you had a look to see the changes to how smc loads smc config data in the case of units that don't have a 16M NAND?

[Blackaddr]

@ Cory1492.  Sorry, you are correct, I was actually thinking about the free code space when I wrote that, not the total code space.  I've written an awful lot of custom SMC routines (mostly for my POST Monitor) and have actually run out of space in my Falcon SMC

Corona has roughly 1500 bytes of free space at the end of the SMC, my Falcon has roughly 750 bytes.

[Oggy]

Nice read Blackaddr, thanks.

[Intruder]

Good read kudos to you Blackaddr.....

Int

[RnRdude]

nice read indeed what I don't understand is why is ms not updating all fats to unglitchable cb versions are they afraid that gligli (or someone else)will answer with the (silver bullet) an ported cb_a from slim ? do they prefer to not risk this humilation ?  

[ddxcb]

nice read indeed what I don't understand is why is ms not updating all fats to unglitchable cb versions are they afraid that gligli (or someone else)will answer with the (silver bullet) an ported cb_a from slim ? do they prefer to not risk this humilation ?  

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.

[rz2k]

nice read indeed what I don't understand is why is ms not updating all fats to unglitchable cb versions are they afraid that gligli (or someone else)will answer with the (silver bullet) an ported cb_a from slim ? do they prefer to not risk this humilation ?  

theres no reason to port slim cb_a to phat, due to that dual cb is possible on phat and actually used in refurb. consoles and rumors saying that guys from rgloader already working on it.

[Mistawes]

This is like porn.. Thanks for the great read and for the amazing work you put in over the years!

[Gazcoigne]

This is like porn..

what?