About Sony Downgrade + Rebooter (Root)

"Although the information we release has been verified and shown to work to the best our knowledge, we cant be held accountable for bricked devices or roots gone wrong."

How this works

---

The first exploit we found was a great one which allowed full access inside recovery. This allowed us to mount everything RW, and replace just about everything at will. However after the Honeycomb (3.1) release it was patched by Sony. So, we started looking for another exploit. Long story short, we did not find a new exploit on par with the previous exploit, so we opted for a downgrade!

Downgrade

---

To start, you need a little bit of background on the system. The system is initialized and calls the bootloader from nand. This is Intel's "Secure Boot" with RSA signatures, encryption, and all that jazz. The bootloader then calls a signed and/or encrypted (depends) kernel. We can't attack that without a boatload of work. So, we looked into the current recovery version. This recovery, when you initialize a USB update will do the following:

Verify a "package_list_*.zip" exists on USB Memory

If so, it will then extract package_list_*.txt and system/build.prop

Then, it checks the:

• ro.product.device
• ro.build.date.utc
• ro.build.id

If, ro.build.date.utc is not equal to, or newer than the current version - the update errors out

If, ro.build.date.device is not for, the device - the update errors out

Assuming these checks are satisfied, the system will prompt if the user would like to continue the update, and if so the system will then copy the update to the internal partition and verify it, then continue on with the upgrade.

This, is what we used to get a downgrade. We use 3 USB sticks, labeled 1, 2, 3.

Stick 1 - A modified update file, containing a build.prop with "ro.build.date.utc" set to the future.

Stick 2 - A file system node, pointed to /dev/Glob_Spectraa2 (this is important later)

Stick 3 - A modified image of /dev/Glob_Spectraa3

We use stick 1 to satisfy the device/utc/id checks. Upon prompt, stick 2 is swapped in. This will copy our file system node to the system. It will then error. Next, we re-use stick 1, to re-satisfy the checks. Upon prompt, stick 3 is swapped in. Since they share the same file name, cp will copy our image into our file system node, which is /dev/Glob_Spectraa2. It will, after a few moments error. This means that cp copied our image over. Now, /dev/Glob_Spectraa2 holds the encrypted bootloader, along with recovery kernel and initrd (encrypted). By using the cp, we are able to replace it with the older, exploitable version.

Exploit

---

Upon power-on, you will be greeted with a new splash, and enter the old recovery. This is where the magic happens! This exploit was found somewhat oddly. Specifically, the command is issued as follows:

ls /tmp/mnt/diskb1/package_list_*.zip | head -1 | grep package_list_

The results of this command are then passed onto a shell script in-line. On this version there is no stripping of special characters etc. So...

./package-updater.sh -l 0 -p /tmp/mnt/diskb1/package_list_somefile.zip

Therefore, if we specially craft a file we will be able to alter that command specifically using this:

package_list_;cd /tmp;cd /mnt;cd /diskb1;sh t.sh;.zip

We do have some restrictions (like full paths, among other things) so we use that series of cd's to get to our usb drive, and execute "t.sh".

./package-updater.sh -l 0 -p /tmp/mnt/diskb1/package_list_;cd /tmp;cd /mnt;cd /diskb1;sh t.sh;.zip

Now, we could have it run a real program - but scripts are just so much more convenient in this case.

The Goodies

---

This, is all great - the exploit allows RW access to any spot on the system. However, the kernel is still limiting. Specifically - the normal kernel keeps system RO, as well as /. This is annoying of course. So we quested to get an unsigned kernel running too. Noting back to above, going after it via the bootloader would have been quite difficult, and taken too long so we opted for a reloader. For anyone who recalls, there are not too many out of the box solutions for reloading a kernel, at least not without having support in the kernel first.

After some thinking we decided to port kexec over to a module and then include it at boot. It took a little work, but it paid off. We ported over kexec. Once kexec was in we then compiled our own kernel based off of Sony's provided source code. I will commend Sony, because with a little work - it compiled, they did not forget anything (kernel wise). This was fabulous, we had our own kernel reloading and then re-initializing the hardware. We did run into some issues with timing though. Specifically, the new kernel needs to reload before the old one has a chance to do anything. We've also removed the OTACerts for the update process, so you won't be receiving any automatic updates from Sony. Also each install will have a modified flash plugin to allow users to bypass content provider restrictions (hulu, cbs, etc.)

Boot Process

---

Upon boot, once the init scripts are called we hijack the boot process, insert our kexec modules, mount our new partition "sda8" and load kexec. This all happens in about 1 second (not lying!). Kernel is rebooted, loads in our kernel, and boots off "sda8." This is a mirror of "sda1" (boot) but has some modifications:

• no initd hash
• no signed init.rc
• no signed init.(eagle/asura).rc
• does not load kexec (nasty boot loop that would be - it's happened)
• modified init.rc
• modified init.(eagle/asura).rc
• modified default.prop

Our modifications are few - but for default.prop:

• ro.secure=0
• ro.debuggable=1

Furthermore, init scripts are modified for RW to / , and to /system. Also, the kernel is modified for RW to /.

Final Thoughts / Wishlist

---

The Sony boxes have had our attention, on and off for the past 7 months or so, with most of the work happening in short bursts, over approximately one month of combined work time.

As I'd like to point out - this was no simple root and go, it took a lot of work. It saddens me when people (I'm looking at you, tech-blogs) get over-excited over a root for a device, when it's a simple adb push job. Then the more complex work - be it finding exploits in the kernel, the system itself, etc which gain higher privileges go unannounced. Just remember the next time you read about a "root", there is usually more that goes into it, much more. Commend the developers who spend their own time and money to get it done. It's more than just what the software can do, think of the initial hack. However, a few things we'd love to see, but did not have time to do - if you want to help out, let us know:

Ad block for chrome, should be totally possible - and would improve the system browsing speed considerably

GTVHacker