Kao što već duži vremenski period kod nas je zastupljen RGH, hm RGH zar to nije JTAG???
Odgovor je NE, postoji velika razlika izmedju RGH i JTAG, krenućemo pojedinačno.
JTAG poznat ljubiteljima XBOX360 od prve generacije konzole, hm šta to beše, pa to je onaj čuveni film Kingkong koji je omogućio to software-sko iskorišćenje XBOX360. JTAG’ovan xbox omogućuje da pokrenete igre sa USB-a, HDD-a, Linux i jos što šta.
JTAG je moguće bilo poslednji put uraditi 2009 godine u januaru mesec, a već pre toga u mesecu avgustu 2008 ovakve konzole su bile nestale na tržištu.
_RGH Skraćenica koja potiče od reset glitch hack, hm šta je sada ovo??? RGH je hardwaresko-softwaresko rešenje za iskorišćavanje(exploit) XBOX360 vrlo bitna razlika od klasičnog JTAG-a je da je potreban MODCHIP da bi se uradio RGH.
Bilo kako bilo RGH je moguće uraditi na novijim generacijam XBOX360 na kojima **SMC JTAG **je odavno patchovan, popravljen da više nije moguće praviti JTAG XBOX360. Reset Glitch Hack se pojavio u septembru mesecu 2011 godine i od tada do danas je aktuelan i moguće je uraditi na svim konzolama i novim XBOX360 SLIM.
Daću malo detaljnije na engleskom jeziku.
_
What is the JTAG Modification?
A JTAG modification is done to the 360 motherboard, this modification allows you to play backup copies of games off a usb harddrive or even the 360’s own harddrive. When you play games off of a harddrive to you no longer need the original game disc, instead you can keep them safe and unused for re-sale . This modification cannot be taken online with getting banned.
How is this different from the normal Flash mods that have been out for years?
The Normal Flash Mod is a modification that is done only to the xbox 360 DVD or Optical Drive. This modification is when you flash the optical drive with new firmware so that it no longer knows the difference between a real game and a backup game. A JTAG can do this to but can also run exciting home brew applications like emulators (Nintendo, Super Nintendo, Sega, Etc, Etc) and it allows you to play the game off a harddive without ever needing the game disc at all.
Which consoles Can Be Jtaged?
JTag modification can only be done on consoles that are a little older and that have the 7371 dashboard. You have to look at your console settings to see if you meet this requirement for JTAGING your console. Most consoles cannot be jtaged because they have been played in the last year, which means they took a update that will not allow them to be modified in this manner.
You console had to meet 2 criteria to be able to JTAG it:
A: HAS to have a manufacture date before June 18 2009
B: Dashboard HAS to be 7371 or Lower
To determine the manufacture date is easy, simply look at the back of your console, it will have that date stamped on the back of it.
To Determine the dashboard version you hook it to a TV and select the following:
Turn on your Xbox and go to console settings.
Go to system info, the kernel version is on top right.
it will look something like 2.0.12416.0
The 12416 is the part you look at, if that number is higher than 7371 you cannot JTAG
What are the different Names people use for the Jtags like Xenon or Jasper?
There are 5 generations of Xbox 360, as Microsoft was trying to build a better console that would not give hte4 RROD they changed the design a total of 5 times for the Fat style console. The New consoles that have are being sold today in stores new are called the slim consoles and they of course cannot be Jtaged.
The Fat style consoles are names as such : Xenon, Opus, Zephyr, Falcon and Jasper.
The Xenon is the first gen console that Microsoft, it was launched November 2005, had no HDMI, it is popular with People running Modded lobbies online because it is the Easiest to change the Keyvault or KV on.
The Zephyr launched July 2007 it has a HDMI, can be a little tricky to Jtag, and not is easy for KV swaps
Falcon Launched September 2007, it has HDMI, can be tricky to swap KVs
Opus Launched June 2008, it has no HDMI and is tricky to swap KVs
Jasper, Launched September 2008, had HDMI and is tricky o swap KVs out on but is HIGHLY sought after because it is a console that rarely if ever Experiences the RROD. It is also very difficult to find one that meets the criteria to JTAG it. Excellent console to Jtag if you can find it.
Whats a KV or Keyvault?
That is a file that is embedded inside the Xbox 360 Firmware, it contains a few key pieces of information, but most importantly it contains the consoles identification. Each console has a unique identification contained inside the KV. So generally when a modder modifies a console they Take a copy of its KV and sell it. The purchase of this unique KV can then program up to 5 consoles with this file and get them online to offer up modded lobbies. As Microsoft is constantly trying to ban consoles that are JTAGED online the length of time you can be online with a a fresh KV greatly varies from 10 minutes to 5 hours.
To put a fresh KV into your Jtaged consoles check out tutorials section but know that the Xenon consoles are the EASIEST to do this to.
What are modded lobbies?
Jtag consoles let you run modified versions of games. So people modify games like Modern Warfare so that they can create games and then their friends/customers can join them and get all ranked up and unlock all weapons nad things like this in a matter of minutes. There were a lot people offering this service for money in 2010. The scene is constantly changing however as Microsoft is trying to stop this sort of thing.
So can I take my JTAG online?
If you have a fresh KV inside your console then yes, you can for a time from 2 minutes to 5 hours. Your times will vary. After that the console or the KV inside the console is banned forever. So until you program your JTAG with a fresh KV it cannot go online again.
We hope this little Q and A clears up what a JTAG is.
_
Reset glitch hack
_
The Xbox 360 reset glitch hack
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.
_
Nadam se da su neke pojedinosti sada jasnije i da više nećemo da mešamo RGH i **JTAG **
Ako nekoga zanima detaljno kako, šta i još neke pojedinosti o hackovima ispod text-a su linkovi:
_Free60
How to JTAG XBOX 360 - TIAO’s Wiki