Some info about this error code as requested by a XBH member.

On HDMI consoles, the error code 0031 is set by the SMC during the hardware error checks (mostly voltages).

There is a regulator (U4V1 on falcon) that generates the 5V rail and the memory voltage rail (1.8V).  This regulator (ADP1823) has a "power good" signal at pins 10 and 24 which are tied together and connected to a pullup and send to the SMC port P3.1.  They are open drain, in that they pull down when regulator is not enabled and float up when the power is good.

Note on Xenon consoles, there was no power good signal for the 5V rail or GDDR rail.

If your console throws this code, one of those two rails is not coming up, and you most likely have a short on one of them.  

It is more often caused by GDDR then 5V.  Often replacing the GPU fixes the problem because the short was created by the GPU balls themselves.  However this does not guarantee this is the location of the problem, it could also be at the ram chips.

Lastly, you may have blown components in the ADP circuit itself (inductor or cap failure etc.).

A good console repair shop should be able to find the failure location and repair it for you.  With the price of consoles these days the labour may not justify repairing the console if it's not JTAGable.  A poor repair shop will just play guess and test on reflows until you run out of patience.

You can leave the JTAG wiring in place, it won't hurt anything.  Just make sure you have your efuses protected so you don't loose JTAG functionality.

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".

@ 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.

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 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*

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?

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?

Indeed.  In addition, the nonsense these (not just x360Glitchip) developers are spouting about their products improved boot times and such is ridiculous.  Most of them are just copycatting whatever the 'flavour-of-the-day' alternate cap/wire gauge/loop is on the forums, almost none bring any value-add to the table.

There are some big hints about what needs to be done to glitch a Corona on this board, but somehow I doubt these guys even understand the information available to them.  STBY_CLK is used because you need *some* clock at a reasonably fast frequency.  I create my own clock on my FPGA board simply because I can, but as Tiros pointed out, I still need to use either CPU_PLL_BYPASS or change the HANA clock in order to change the CPU's clock.

On the bright side, the useless oscillator is eating into their profits since people will quickly realize paying more for this is stupid.

The Webpack has everything you need, from compiling source code to programming the CPLD.  That link I provided even says


Trust me, you can do everything with the webpack, it's all free, no need for any warez.

ISE Webpack should have everything you need and it's free

http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm

It's possible the long wire lengths improve things for some people because they are adding delay, but we don't know for certain that is the dominant effecdt.  It's possible that it is acting more like a filter and that could be more significant, the point is we really don't know right now.  The fact that there are so many different empirical solutions out there (caps, wire lengths, loops, where to put the loops, shielding, etc.) means we don't really understand what's going on yet.  And make no mistake, the groups selling glitch chips have no idea either, they're just stumbling around in the dark until they hit something.


Both.

Monitoring the HANA clock is easy, you can use a scope to probe any of the diff pairs coming out of that chip, they're all at the same frequency as CPU clk.  Just probe aroung the STBY_CLK point and you'll quickly find a suitable testpoint, the diff pairs are very easy to see.

My setup uses a custom FPGA with some modules I wrote to perform several functions including full POST logging, runtime configurable glitching (via software, no reprogramming), and an I2C interface that lets me perform read/writes to the HANA and log the bus.

You don't need all of that to start investigating timing though, using the new version of Nandpro by Tiro's with POST monitoring and just playing with the values in gligli's VHDL files can go a long way.

Has anyone tried actually changing the slim reset value to +/- 1 and reported results?  Is the default the only value that works???

I've only dealt with a a falcon so far, and I tried changing my timing values to find out how big the valid timing window is.  For me, my falcon boots 100% on first try across four different timing values, so obviously I set mine to one of the middle values.  This means my reset window is about 83 ns wide.  It is important to note that the PLL_BYPASS slows the CPU down by a factor of 128.  This means at full speed, the glitch window would be about 0.648 ns.  With a 20 ns CPLD clock, no wonder we have to slow it down!

For slims (which I do not own), we are not using PLL_BYPASS, we are changing the clock frequency in the HANA.  Assuming the HANA on my falcon is similar to the slim, the values sent by the slim hack reduce the clock frequency from 100 MHz to about 31 MHz.  This only slows the CPU down by a factor of ~ 3!  For the sake of argument, let's say the trinity and falcon cpus have the same windows size at full speed.  This means with the current slim hack, we have expanded that window size to 3 * 0.648 = 1.944 ns.  IF SOMEONE CAN CONFIRM THE HANA CLOCK FREQUENCY WHEN SLOWED DOWN I'D APPRECIATE IT.

Using the 96 MHz CPLD rate in the slim hack, we have roughly a 10ns resolution and we're trying to hit a target less than 2 ns long.  So changing the timing on the slim even by 1 might break it and we're lucky it works at all.

This is probably why people are having success with longer reset wires.  You get an added delay of somewhere between 1.2 ns and 2.4 ns for every foot of wire, but introduce a host of other concerns because you've made a radio antenna.


I've been trying to port the hack to my falcon SMC, the SMC has a resolution of only 170 ns.  So the 83 ns window I mentioned above is not large enough.  I've been experimenting with combined the PLL_BYPASS and slowing the HANA as well.  Basically, set my falcon HANA to 31 MHZ and assert PLL_BYPASS to stretch the window hopefully by a an additional factor of 3, giving me 3*83 ~= 240 ns so I can hit it with the SMC.

Well, some really interesting things have happened by doing this.  For starters, the minimum glitch length has increased dramatically.  I need to keep reset low for a minimum of 625 ns in order to get the system to react at all, and yes I can glitch it in this state, but the success rate isn't good.  More investigation required.

This is very interesting, the glitch pulse width should not have changed if the reset is asynchronous.  The fact I NEED to make the glitch super long in order to get anything to happen suggests the reset is synchronized with the clock some how in a complex relationship that resets some, but not all CPU registers.  This relationship could mean further slowing down the clock doesn't automatically make glitching more reliable, we could be in a nasty scenario where some internal events have to line up just right like a planetary alignment!

Does it do this every time you power up?  If not, whenever it happens, unplug for 20 seconds and try again.  Check your I2C lines, too.  I've been playing with the HANA on my falcon and I've noticed that the I2C bus is susceptible to corruption.  

If you have a system that seems to run fine sometimes, but other times gets in a very short (or very long) reboot/crash cycle then you probably need to power cycle to clear it.

For those who want a little more technical detail here are some causes:

i) Cold solder joints on your I2C lines can result in corrupted I2C transfer.  As a result the HANA register controlling CPU clock speed is set to an unstable value and the clock loses lock.
ii) the CPU (via the SMC) polls the HANA status on fairly frequent basis.  If the CPLD attempts to change the clock speed while the I2C bus is busy, the transaction gets corrupted and same problem as above.
iii) In some instances changing the HANA frequency register repeatedly (like the CPLD does over many boots) can also cause the clock to become unstable (loss of lock).  If you reset the HANA PLLs themselves after a clock frequency change, it's always stable.  It's basically looks like a crapshoot each time you switch frequencies without a PLL reset, it may unlock occasionally.

I've experienced ii) and iii) many times while doing my research.  The HANA is reset by the SMC on reach reboot but the reset does not actually reset the HANA registers or the PLLs.  At first I had to power cycle whenever this happened, but eventually I found the individual resets for the PLL which I can use to recover the system on the fly, however the CPLD does not do this currently.

Error code 0031 is a new error code introduced for the HDMI consoles (the ones with a HANA, not ANA).  Speculation is that the debug pins on the Xenon were repurposed as HANA controls for these consoles.

The SMC will set this error when one of these previous debug pins is asserted.  I suspect this is some kind of status/error signal from the HANA.

If this signal has a pullup somewhere, a bad solder joint at either the SMC or the HANA could cause this error code.

R/B is a part of the standard Flash interface.  It is Ready/Busyb.  It is an output that signals the status of the memory command interface.  Keep in mind Flash memories have their own little state machines inside, you send them commands and they execute them.  The pin is used to indicate the state machine is ready for the next command.

I've already got an accurate POST monitor running on the SMC.  That might not sound like much but took a lot of work because you are taking complete control of the SMC for an extended period of time when it normally would be working with the CPU/HANA/ARGON for system config and init.  But you can't simply take over and start monitoring a POST bit.  If you don't reset the watchdog the SMC will halt, if you don't run certain service routines at the correct times (during early 2BL hardware init) you will halt the CPU.  I had to find the registers that control the SMC I/O direction.  I had to reverse engineer the I2C FSM and interrupt routine in order to control I2C from my own thread (it's not bit banged, it's a memory mapped peripheral).

None of the information above was available publicly (or to me privately) so it all had to be RE'd from scrach.

That said, my SMC post monitor can keep the system starting properly, and send I2C command to the HANA at the correct time, and I can see the clock frequency change.  That might be enough to get a Corona working if necessary assuming the I2C bus is not exposed on the PCB (and using a CPLD for glitching) if they still use an abstracted I2C to configure the co-packaged HANA in the same way, I've only got a falcon to work with at the moment.  Right now I'm just trying to get my head around the HANA PLL controls.

The problem at the moment is there is a limit to how slow you can set the CPU input clock  (HANA controls clock INTO the CPU PLL, PLL_BYPASS controls frequency AFTER the CPU PLL or bypasses it entirely.  On slims, we dont' bypass the PLL I believe, and PLLs have certain frequency bands they must be in after internal multiply but before divide).  If the CPU input frequency is too low, the CPUs internall PLL won't be able to lock to it.  

Also, it seems a single PLL controls four of the clocks coming out of the HANA, including CPU and PCIe.  This bad because I can't lower the CPU clock frequency without lowering PCIe.  I believe the PCIe bridge is configured and initalized in POST_2E, but if I drop the clock to low during POST_36 to slow the CPU, I think the PCIe links break and need their PLLs to be reset, not entirely sure.

So, lots of progress, lots of work still ahead.

During my research on my falcon, my RF board became damaged.  I don't have the fans attached (I used external bench fans that keep it at 30 C) or the DVD drive so during all my testing the power LED flashes green.

After a while, one day the led just stopped flashing.  The power button still works, but the light no longer flashes with the drive unattached.  I have no idea if it still syncs, etc.  

I assumed it got static shocked (though I'm usually quite careful with ESD) or someone else in my lab decided to look with their fingers.  The other point of interest for me is this board is still wired for JTAG hack, using AUD_CLAMP and TRAY_OPEN.  I thought maybe that had something to do with it, though I understand the circuits involved and there shouldn't be any way to cause damage in that regard.

That said, I don't see how the RGH could damage the the tray status tracks, the SMC pins they are connected to, or the argon board.

Only the BYPASS and the CPU RST should theoretically be at risk of electrical damage.

As far as powering the CPLD, my setup is very different than the common CPLD glitchers.  I have a custom FPGA board, a second interface board with various level translation for POST, then the 360 mobo.  The FPGA board and interface board are powered independent of the 360, only ground is common.

It takes 4-5 seconds for ONE attempt.  If it boots in about 5 seconds, it got it on the first try.  Everyone seems to have no trouble glitching a Falcon, but I haven't seen any report profiling their console them self for a Zephyr, Jasper or Slim.

I profiled my Falcon and found the console glitched successfully 100% of the time across FOUR sequential offset values, while keeping a constant temperature of about 30 C for consistency (big ass fan on it).  once you were +/- 3 from the central window, it dropped to about a 1 in 5 chance, one more tick away and it pretty much didn't glitch.  That is a VERY small window and that's on an 'easy-glitching-falcon'.

All you guys need to do is take the VHDL file, change the value as Cory suggested, rebuild with ISE and reprogram with impact.  It's worth taking the time learn this.  You will only have to try +/- a few ticks to find the optimal value for YOUR console, so it's not a lot of effort.  You might not find a better value than the one you are already starting with, but you won't know unless you try.

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.

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.