Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
You are one funny sunovabitch hahahaha
Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
- Thread starter Xecuter
- Start date
Ubergeek
Xecuter Groupie
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
I heard that
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Is it hard to do this? do we need nand x for this?
Is it hard to do this? do we need nand x for this?
TilVl
VIP Member
- May 11, 2011
- 1,383
- 0
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
I'm sure once xecuter release there add-on for nand x it'll be easy.
As of now if you bought all the pieces i'm sure it be more difficult then just buying a nand-x then the add on when it is released. The time you save will be worth the investment. Doing it over LPT sucks and becomes a headache at times.
I'm sure once xecuter release there add-on for nand x it'll be easy.
As of now if you bought all the pieces i'm sure it be more difficult then just buying a nand-x then the add on when it is released. The time you save will be worth the investment. Doing it over LPT sucks and becomes a headache at times.
mcornbill
VIP Member
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Hi Guys
Well just been looking round for the XC2C64A CoolRunner-II CPLD in UK stores but to no avail. Noticed these boys who deliver very reasonably to the UK but the board doesn't look the same as the one shown in The Reset Glitch Hack.pdf. Has the right model number?
http://www.seeedstudio.com/depot/pr...d-p-800:7a53928fa4dd31e82c6ef826f341daec.html
Hi Guys
Well just been looking round for the XC2C64A CoolRunner-II CPLD in UK stores but to no avail. Noticed these boys who deliver very reasonably to the UK but the board doesn't look the same as the one shown in The Reset Glitch Hack.pdf. Has the right model number?
http://www.seeedstudio.com/depot/pr...d-p-800:7a53928fa4dd31e82c6ef826f341daec.html
sick360mods
BANNED
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
thats not shipping till october
thats not shipping till october
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
All of this info sounds exciting. Only thing is that I know nothing about j-tag. Will this mean that the first xbox 360 i ever "tried to mod" will come back to life since the key was lost before and can get it back now with the glitch??
Also from my understanding I would only need the nand x and Xecuter Coolrunner?
Sorry for sounding like a noob since all i know is how to do the basic mods and also have a lot of patience and will wait as much time as the team needs for the release.
All of this info sounds exciting. Only thing is that I know nothing about j-tag. Will this mean that the first xbox 360 i ever "tried to mod" will come back to life since the key was lost before and can get it back now with the glitch??
Also from my understanding I would only need the nand x and Xecuter Coolrunner?
Sorry for sounding like a noob since all i know is how to do the basic mods and also have a lot of patience and will wait as much time as the team needs for the release.
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
READ THIS:
**********************************
* The Xbox 360 reset glitch hack *
**********************************
Introduction / some important facts
===================================
tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.
The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).
CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
- A hash of the entire fuseset.
- The timebase counter value.
- A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.
Basically, CD will load a base kernel from NAND, patch it and run it.
That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code.
In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code.
On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them.
The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.
On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".
Glitching here is basically the process of triggering processor bugs by electronical means.
This is the way we used to be able to run unsigned code.
The reset glitch in a few words
===============================
We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.
Details for the fat hack
========================
On fats, the bootloader we glitch is CB, so we can run the CD we want.
cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.
So it goes like that:
- We assert CPU_PLL_BYPASS around POST code 36 (hex).
- We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
- We wait some time and then we deassert CPU_PLL_BYPASS.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.
The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly.
In most cases, the glitch succeeds in less than 30 seconds from power on that way.
Details for the slim hack
=========================
The bootloader we glitch is CB_A, so we can run the CB_B we want.
On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).
So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus
So it goes like that:
- We send an i2c command to the HANA to slow down the CPU at POST code D8 .
- We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
- We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
- Always activate zero-paired mode, so that we can use a modified SMC image.
- Don't decrypt CD, instead expect a plaintext CD in NAND.
- Don't stop the boot process if CD hash isn't good.
CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically:
crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
guessed-pseudo-random-keystream = crypted xor plaintext
new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place?
Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!
The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.
Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !
Caveats
=======
Nothing is ever perfect, so there are a few caveats to that hack:
- Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
- 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).
- It requires precise and fast hardware to be able to send the reset pulse.
Our current implementation
==========================
We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time.
We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock)
The cpld code is written in VHDL.
We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.
Conclusion
==========
We tried not to include any MS copyrighted code in the released hack tools.
The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.
Credits
=======
GliGli, Tiros: Reverse engineering and hack development.
cOz: Reverse engineering, beta testing.
Razkar, tuxuser: beta testing.
cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360.
No, this particular hack won't work on XENON - It uses the HANA chip, only HDMI consoles have it, on XENON is ANA chip
READ THIS:
**********************************
* The Xbox 360 reset glitch hack *
**********************************
Introduction / some important facts
===================================
tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.
The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).
CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
- A hash of the entire fuseset.
- The timebase counter value.
- A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.
Basically, CD will load a base kernel from NAND, patch it and run it.
That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code.
In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code.
On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them.
The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.
On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".
Glitching here is basically the process of triggering processor bugs by electronical means.
This is the way we used to be able to run unsigned code.
The reset glitch in a few words
===============================
We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.
Details for the fat hack
========================
On fats, the bootloader we glitch is CB, so we can run the CD we want.
cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.
So it goes like that:
- We assert CPU_PLL_BYPASS around POST code 36 (hex).
- We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
- We wait some time and then we deassert CPU_PLL_BYPASS.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.
The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly.
In most cases, the glitch succeeds in less than 30 seconds from power on that way.
Details for the slim hack
=========================
The bootloader we glitch is CB_A, so we can run the CB_B we want.
On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).
So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus
So it goes like that:
- We send an i2c command to the HANA to slow down the CPU at POST code D8 .
- We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
- We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
- Always activate zero-paired mode, so that we can use a modified SMC image.
- Don't decrypt CD, instead expect a plaintext CD in NAND.
- Don't stop the boot process if CD hash isn't good.
CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically:
crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
guessed-pseudo-random-keystream = crypted xor plaintext
new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place?
Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!
The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.
Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !
Caveats
=======
Nothing is ever perfect, so there are a few caveats to that hack:
- Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
- 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).
- It requires precise and fast hardware to be able to send the reset pulse.
Our current implementation
==========================
We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time.
We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock)
The cpld code is written in VHDL.
We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.
Conclusion
==========
We tried not to include any MS copyrighted code in the released hack tools.
The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.
Credits
=======
GliGli, Tiros: Reverse engineering and hack development.
cOz: Reverse engineering, beta testing.
Razkar, tuxuser: beta testing.
cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360.
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Q: Is it hard to do this?
A: Depends on your definition of hard; It has been mentioned that you just need to solder 6 or 7 wires to the motherboard.
Q: Do we need NAND-X to do this?
A: Yes + NAND-X addon (unless you want to buy inferior sh*t at twice the price)
and next time......
I would take cover if I were you, you're gonna get a little flamed over this question after 50+ pages. Since I have started typing I will answer though.
Q: Is it hard to do this?
A: Depends on your definition of hard; It has been mentioned that you just need to solder 6 or 7 wires to the motherboard.
Q: Do we need NAND-X to do this?
A: Yes + NAND-X addon (unless you want to buy inferior sh*t at twice the price)
and next time......
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Hi guys, felt compelled to join just to say I find it funny all these guys slating the noobs for not reading - which is fair enough, cos there's no excuse for not reading and askig the same question over and over, etc
But, it's hilarious when some answer to say the reason this "glitch" isn't working on the xenon is because it doesn't have a HANA chip. IF they'd read properly, the HANA is only used on the slim, as a way of slowing the CPU down - it's not used in this process on any phat machines
Great work so far guys, will be continuing to purchase and use quality TX products
Hi guys, felt compelled to join just to say I find it funny all these guys slating the noobs for not reading - which is fair enough, cos there's no excuse for not reading and askig the same question over and over, etc
But, it's hilarious when some answer to say the reason this "glitch" isn't working on the xenon is because it doesn't have a HANA chip. IF they'd read properly, the HANA is only used on the slim, as a way of slowing the CPU down - it's not used in this process on any phat machines
Great work so far guys, will be continuing to purchase and use quality TX products
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Wow 60 pages - and pretty much the only two posts that contain the important info are post #1 and also post #469 on page 47 lol
Wow 60 pages - and pretty much the only two posts that contain the important info are post #1 and also post #469 on page 47 lol
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
true that. lol
incidentally, how comes even though i know and identify my hardware, it still shows as "unknown" - I'd already guessed from others that they were probably slims. But thought it was maybe cos when they joined slims weren't an option
true that. lol
incidentally, how comes even though i know and identify my hardware, it still shows as "unknown" - I'd already guessed from others that they were probably slims. But thought it was maybe cos when they joined slims weren't an option
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
yes
i remarked that
no slim profile details
wish a solution to it
thanks and sorry
yes
i remarked that
no slim profile details
wish a solution to it
thanks and sorry
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
LOL, my guess is that it was Uber who added the little extra "and next time...BITCH SLAP" to the end of my post? It is a funny pic tho
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
:facepalm: myself
examples as to why this thread is 60 pages long lol....of course....I realise the irony of posting this, as it indeed increases the length of this thread lol
:facepalm: myself
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
Quick question...
Would it be to much hassle for a Mod to delete all the stupid questions (most likely this one too) and just keep the ones with usefull info? 60 pages with hardly any new info, no wonder there's so many stupid questions.
Quick question...
Would it be to much hassle for a Mod to delete all the stupid questions (most likely this one too) and just keep the ones with usefull info? 60 pages with hardly any new info, no wonder there's so many stupid questions.
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
plus 2-3 informative posts in 60 pages. i guess i'm not helping either by posting this :rolleyes2:
Maybe we should have a "like" and "dislike" for posts, that way n00b posts that are disliked by enough members are "minimized", meaning the full post is hidden, kind of like on youtube. though that won't really help keep the page numbers down :facepalm:
seriously. half the posts are n00bs repeating the same sh*t over and over again.. and the other half are :facepalm::facepalm::facepalm:..
plus 2-3 informative posts in 60 pages. i guess i'm not helping either by posting this :rolleyes2:
Maybe we should have a "like" and "dislike" for posts, that way n00b posts that are disliked by enough members are "minimized", meaning the full post is hidden, kind of like on youtube. though that won't really help keep the page numbers down :facepalm:
Re: Reset Glitch Hack - "JTAG" Type Exploit Zephyr/Jasper/Trinity(Slims) !!!
http://pictures.xbox-scene.com/xbox360/hdmi-360/xbox360-set2-hdmi-03.jpg
Correct me if i'm wrong.
There are more noobs than you know. Not only slim has the HANA chip. All HDMI versions have it. This is from a Zephyr:Hi guys, felt compelled to join just to say I find it funny all these guys slating the noobs for not reading - which is fair enough, cos there's no excuse for not reading and askig the same question over and over, etc
But, it's hilarious when some answer to say the reason this "glitch" isn't working on the xenon is because it doesn't have a HANA chip. IF they'd read properly, the HANA is only used on the slim, as a way of slowing the CPU down - it's not used in this process on any phat machines
Great work so far guys, will be continuing to purchase and use quality TX products
http://pictures.xbox-scene.com/xbox360/hdmi-360/xbox360-set2-hdmi-03.jpg
Correct me if i'm wrong.