EurAsia News

Xbox 360 Reset Glitch Hack Explained

[source: Blackaddr @ xboxhacker.org] 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.

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?

Jailbreaking Is Not A Crime

[source: bunnie @ jailbreakingisnotacrime.org] You bought it. You own it. Tell the Copyright Office: let me install whatever software I want on my phone, tablet, or video game system. bunnie Huang, author of Hacking the Xbox, is standing with the Electronic Frontier Foundation to defend users' right to jailbreak. Will you sign on to bunnie's letter to show the Copyright Office that users everywhere are demanding the right to jailbreak?

Dear Ms. Pallante,

Whether it's patching a security vulnerability or homebrewing video games and apps, people who own smart phones, tablets, and video game systems are finding inventive ways to use and improve their devices. Often users need to gain full administrative access, through a process known as "jailbreaking," to innovate and take advantage of the device's full potential.

But right now, jailbreaking a device can lead to legal threats. That's a vulnerability in the law: we need you to create a "patch" so users who jailbreak devices won't be at legal risk.

Three years ago, the Copyright Office agreed to create an exemption to the Digital Millennium Copyright Act so that folks could jailbreak their smartphones. But that exemption is about to expire. We need you to renew that exemption and expand it to cover jailbreaking gadgets with similar computation potential. These are all siblings to the PC, yet unlocking their potential as versatile and powerful computers is burdened with legal murkiness.

We need these exemptions to conduct security research on devices to help safeguard everyday users from security threats. Furthermore, users of these products benefit from the flexibility to choose their own operating systems and run independently developed software. We need the law to catch up with how people are using technology.

Jailbreaking is helping to make technology better, more secure, and more flexible. Please defend the rights of users.

Thanks for enabling us to keep technology innovative, secure, and focused on the users.

bunnie Huang
@bunniestudios

Easily Swap PS3 Firmwares Without USB

[source: Shaitan @ psx-scene.com] Hi guys, I'm always looking for ways to make my PS3 experience easier so this was awesome. It's nothing special but I'm constantly needing to change firmwares like many of you so I thought I'd share it.

To do this it's best to use QA Flag Extra since most firmwares can not enable "System Update Debug".

1. Enable QA Flag Extra and go to the debug settings and enable "System Update Debug"
2. Use Multiman's file manager(or other) and create a folder in /dev_hdd0 called "updater", so it's /dev_hdd0/updater/
3. Create folders in that directory for the firmwares called 01, 02, 03, ect.(Dont miss a number or it will error).
4. Copy whichever PS3UPDAT.PUP into one of those folders and........
5. Rename it to whatever you want, you dont even need the .PUP at the end.
6. Go to System Update then Update via Hard Disk and it should look something like the image shown above.

P.S. Updates take only 3 minutes with this!

Untethered Jailbreak for iPhone 4S & iPad 2 released

modrobert writes: "The Chronic Dev Team has released Untethered Jailbreak for iPhone 4S & iPad 2 (Apple A5 / iOS 5.0.1). Quote: 'Greetings, friends & jailbreakers! We are well-aware of how very many of you, our faithful fans, have been waiting for months for this announcement, so - with no further ado, we are excited to unveil the newest addition to our GreenPois0n toolkit. This release should come as no surprise to those of you who have been following pod2g�s iOS blog for the past few months. Earlier this week, you might have even wet your pants a little when you watched the video demonstration of today�s release (named Absinthe A5) and first witnessed our jailbreak working its magic to liberate both the iPhone 4S & iPad 2.'"

PS VITA Firmware 1.52 Status

[source: streetskaterfu.blogspot.com] Ok guys we tested the possibilities on firmware 1.52 for a few days now. What I can confirm is the following: Tech4's exploit still works. Wololo's HBL still works. Everything I research atm didn't change from 1.50 to 1.52. If that is fine for you, there's no reason not to update.

Anyways, I have to mention that this can change without a firmware upgrade!

If you are online with your PS VITA, it can download and install silent updates for any application which runs in usermode and has nothing to do with system critical modules.

The good is, those updates are removed once the system is restored to the current firmware, so it would not be a major problem to remove a fix.

- SKFU

Status update on the PS3 4.0 HEN

[source: kakaroto.homelinux.net] Here's a "quick" status update on the 4.00 HEN (Homebrew ENabler) for PS3. Following my clarifications from almost 2 months ago here, there has been a lot of progress. We have not been slacking off, we�re a group of about 10 developers working together for the last 2 months, for sometimes 15 hours everyday in order to bring back homebrew support to the latest version of the PS3. There are three major parts to the HEN, first, getting the packages to install on the PS3, that part is done, completed, tested, debugged, etc.. the second part is to get the apps to run, that one still has major issues� the last part is something I will not discuss for now (it�s a surprise) but it�s about 60% to 70% done (and it has nothing to do with peek&poke and has nothing to do with backup managers or anything like that. This is and will stay a piracy-free solution for the PS3).

Now, running apps is the biggest challenge that we�ve been working on for the past 2 months. As some of you know, if you�ve been following me on Twitter, we originally had hoped for Mathieulh to give us the �npdrm hash algorithm� that was necessary to run the apps, but he was reluctant, he kept doing his usual whore so people would kiss his feet (or something else) so he�d feel good about himself. But in the end, he said that he refuses to give us the needed �npdrm hash algorithm� to make it work� So what I initially thought would be �this will be released next week� ended up taking a lot more time than expected, and we�re still nowhere near ready to make it work.

Mathieulh kept tossing his usual �riddles� which he thinks are �very helpful for those who have a brain�, and which pisses off anyone who actually does� so he told us that the solution to all our problems was to look in appldr of the 3.56 firmware.. and that it was something lv1 was sending appldr which made the �hash check� verified or not� so we spent one month and a lot of sweat and after killing a few of our brain cells out of exhaustion, we finally concluded that it was all bullshit. After one month of reading assembly code and checking and double-checking our results, we finally were able to confirm that that hash algorithm was NOT in the 3.56 firmware like he told us (at all).

He said that it was an AES OMAC hash, but after tracking all the uses of the OMAC functions in appldr, we found that it was not used for the �hash�� he then said �oh, I meant HMAC�, so we do that again and again come up with the same conclusion, then we�re sure it�s not in appldr, and then he says �ah no, it�s in lv1�.. have a look for yourself to what he decided to write : http://www.ps3devwiki.com/index.php?title=Talk:KaKaRoTo_Kind_of_%C2%B4Jailbreak%C2%B4

That happened after the huge twitter fight I had with him for being his usual arrogant ass and claiming that he �shared� something (For your information, the code that he shared was not his own, I have proof of that too (can�t show you the proof because even if I don�t respect him, I gave him my word to not share what he gave me, and I respect my word) since he forgot to remove the name of the original developer from one of the files� also it was completely useless and was not used at all, just made me waste a day reading the crappy undocumented code. So why is he still trying to force his �advice� through these riddles even after we had that fight? Well to sabotage us and make us lose all those months of hard work!

So anyways, we had all accepted that Mathieulh was full of shit (we knew before, but we gave him the benefit of the doubt) and decided to continue working without considering any of his useless riddles. So we then tried to exploit/decrypt the 3.60+ firmware in order to get the algorithm from there.

Now, a few more weeks later, we finally have succeeded in fully understanding that missing piece from the �npdrm hash algorithm�, and here it is for everyone�s pleasure with some prerequisite explanation :

A game on the PS3 is an executable file in a format called a "SELF" file (kind of like .exe on windows), those �self� files are cryptographically signed and encrypted.. For PSN games (games that do not run from a bluray disc), they need to have an additional security layer called �NPDRM�. So a �npdrm self� is basically an executable that is encrypted and signed, then re-encrypetd again with some additional information. On 3.55 and lower, we were able to encrypt and sign our own self files so they would look like original (made by sony) �npdrm self� files, and the PS3 would run them without problem. However, it wasn�t really like an original file.. a real NPDRM self file had some additional information that the PS3 simply ignored, it did not check for that information, so we could put anything in it, and it worked. Since the 3.60 version, the PS3 now also validates this additional information, so it can now differentiate between NPDRM self files created by sony and the ones that we create ourselves for homebrew. That�s the �npdrm hash algorithm� that we have been trying to figure out, because once we can duplicate that information in the proper manner, then the PS3 will again think that those files are authentic and will let us play them.

Another important point to explain, I said a few times that the files are �signed�.. this means that there is an �ECDSA signature� in the file which the PS3 can verify. The ECDSA signature is something that allows the PS3 to verify if the file has been modified or not.. it is easy to validate the signature, but impossible to create one without having access to the �private keys� (think of it like a real signature, you can see your dad�s signature and recognize it, but you can�t sign it exactly like him, and you can recognize if your brother tried to forge his signature). So how were we able to sign the self files that were properly authenticated on 3.55? That�s because this �ECDSA signature� is just a very complicated mathematical equation (my head still hurts trying to fully understand it, but I might blog about it in the future and try to explain it in simple terms if people are interested), and one very important part of this mathematical equation is that you need to use a random number to generate the signature, but Sony had failed and used the same number every time.. by doing that, it was easy to just find the private key (which allows us to forge perfectly the signature) by doing some mathematical equation on it. So to summarize, a �signed file� is a file which is digitally signed with an �ECDSA signature� that cannot be forged, unless you have the �private key� for it, which is impossible to obtain usually, but we were able to obtain it because Sony failed in implementing it properly.

Now, back on topic.. so what is this missing �npdrm hash algorithm� that we need? well it turns out that the �npdrm self� has a second signature, so it�s a �encrypted and signed self file� with an additional layer of security (the NPDRM layer) which re-encrypts it and re-signs it again. That second signature was not verified in 3.55 and is now verified since the 3.60 version of the PS3 firmware.

One important thing to note is that Sony did NOT make the same mistake with this signature, they always used a random number, so it it technically impossible to figure out the private key for it. To be more exact, this is the exact same case as the .pkg packages you install on the PS3, you need to patch the firmware (making it cfw) so that those .pkg files can be installed, and that�s because the .pkg files are signed with an ECDSA signature for which no one was able to get the private key. That�s why we call them �pseudo-retail packages� or �unsigned packages�.

The signature on the NPDRM self file uses the exact same ECDSA curve and the same key as the one used in PS3 .pkg files, so no one has (or could have) the private key for it. What this means is that, even though we finally figured out the missing piece and we now know how the NPDRM self is built, we simply cannot duplicate it.

The reason we wasted 2 months on this is because Mathieulh lied by saying that he can do it.. remember when the 4.0 was out and I said �I can confirm that my method still works� then he also confirmed that his �npdrm hash algorithm� still works too? well he didn�t do anything to confirm, he just lied about it because there is no way that he could have verified it because he doesn�t have the private key.

I said I will provide proof of the lies that Mathieulh gave us, so here they are : he said it�s in 3.56, that was a lie, he said it�s an AES OMAC, that was a lie, he said it�s an HMAC, that was a lie, he said it�s in appldr, that was a lie, he said it�s in lv1, that was a lie, he said that he can do it, that was a lie, he said that �it takes one hour to figure it out if you have a brain�, that was a lie, he said that he verified it to work on 4.0, that was a lie, he said that he had the algorithm/keys, that was a lie, he said that once we know the algorithm used, we can reproduce it, that was a lie, he kept referring to it as �the hash�, that was wrong. The proof ? It�s an ECDSA signature, it�s not a hash (two very different terms for different things), it was verified by vsh.self, it was not in lv2, or lv1, or appldr, and the private key is unaccessible, so there is no way he could build his own npdrm self files. Now you know the real reason why he refused to �share� what he had.. it�s because he didn�t have it�

So why do all this? was it because his arrogance didn�t allow him to admit not knowing something? or was it because he wanted to make us lose all this time? To me, it looks like pure sabotage, it was misleading information to steer us away from the real part of the code that holds the solution�. That is of course, if we are kind enough to assume that he knew what/where it was in the first place. In the end, he wasn�t smart enough to only lie about things that we could not verify.. now we know (we always knew, but now we have proof to back it) that he�s a liar, and I do not think that anyone will believe his lies anymore.

Enough talking about liars and drama queens, back to the 4.0 HEN solution� so what next? well, we now know that we can�t sign the file, so we can�t run our apps on 3.60+ (it can work on 3.56 though). What we will do is look for a different way, a completely new exploit that would allow the files we install to actual run on the PS3. We will also be looking for possible �signature collisions� and for that we will need the help of the community, hopefully there is a collision (same random number used twice) which will allow us to calculate the private key, and if that happens, then we can move forward with a release.

When will the �jailbreak� be released? If I knew, I�d tell you, but I don�t know.. I would have said in last november, then december, then before christmas, then before new year, etc� but as you can see, it�s impossible to predict what we will find.. we might get lucky and have it ready in a couple of days, or we may not and it will not be ready for another couple of months.. so all you need to do is : BE PATIENT (and please stop asking me about an estimated release date)!

I would like to thank the team who helped on this task for all this time and who never got discouraged, and I�d like to thank an anonymous contributor who recently joined us and who was instrumental in figuring it all out. We all believe that freedom starts with knowledge, and that knowledge should be open and available to all, that is why we are sharing this information with the world. We got the confirmation (by finding the public key used and verifying the signatures) yesterday and since sharing this information will not help Sony in any way to block our efforts in a future release, we have decided to share it with you. We believe in transparency, we believe in openness, we believe in a free world, and we want you to be part of it.

If you want to know more about this ECDSA signature algorithm, read this interesting paper that explains it in detail, and you can also watch Team Fail0verflow�s CCC presentation that first explained Sony�s mistake in their implementation, which made custom firmwares possible.

Thanks for reading,

KaKaRoTo

iXtreme LT+ v3.0 for Slim Lite-On released

[source: C4E @ LTPlus3.0_slim.nfo] Official release of the iXtreme LT+ v3.0 for 0272/0225/0401/1071 slim Liteons. Support for topology data on AP25 enabled titles. Will correctly answer any ap25 challenge eliminating need for dae.bin to create a backup. No need to make new backups everytime dae.bin is updated on console. Extra support for rare firmwares.

Topology Data
-------------

When ap25 was first introduced I devised a way of calculating any challenge which I called the silver bullet which I made reference to along time ago.
This was withheld until it was absolutely necessary. It was easier to replay the fixed challenges.

With unique per console ap25 challenges it has become necessary to use the silver bullet.

A series of measurements are taken across the disk. This topology data is then used to calculate a response to any ap25 challenge.

It is very important that the drive used to create the topology data is reliable at reading discs as bad topology data equals bad ap25 responses.

Liteon drives using 0800 v3 seem to be more accurate for this purpose. Only ap25 enabled titles require topology data. Activation of ap25 on older non-ap25 games although technically possible is highly unlikely.

Currently topology data for xgd3 titles are similar and topology data from one xgd3 title will pass on another xgd3 title although this is not advisable.

Per title title topology data is best as there are slight differences between titles and newer titles could have different topology than existing ones.

One liteon to go and four Hitachis. Have a great year everyone.

Thanks go to Team Jungle and all testers for their hard work and efforts in the development process.
Thanks also go to Team Xecuter for their support to this project.

xk3y back in stock!

We now have the xk3y (aka x360key and xkey) for Xbox 360 back in stock at USD $99. For more products and shipping check the complete price list.

Matrix Glitcher 2 tutorial and software released

[source: infinitymod.com] The tutorial, the fine tuning software and the first reviews for the Matrix Glitcher 2 are now available in the Download section of our website. Feel free to deep test the software and forward us any comment and suggestion to improve it. We have some more cool news coming next week so, stay tuned! :)

NOTE: You need separate programmer hardware to run the fine tuning software. For those who want to test it now, use the programmer included with Matrix Freedom PCB.

multiMAN author removes official download thread

modrobert writes: "Deank, author of the multiMAN project for PS3, has edited out the official forum thread with multiMAN releases over at ps3hax.net and replaced it with this brief message; 'mutliMAN is a ... lot of things'. This happened shortly after Team Cobra released mmCM v04.00.00 (MultiMan Cobra Manager) which can now be used without the Cobra USB dongle for the first time. I don't really know if the events are related, but it seems that way. The official release thread has been at multiMAN v02.09.02 since October 2011. If you want to download the latest official release or older ones, check EurAsia download section with this search. The source code is available there as well. Please post comment if you have more info regarding this."