Why hacking the Vita is hard (or: a history of first hacks)

It’s been about a year since I revealed the first userland Vita exploit and I still occasionally get messages asking “what happened” (not much) or “when can I play my downloaded games” (hopefully never) or “I want homebrew” (me too). While I don’t have anything new exploitwise (same problems as before: no open SDK, lack of interest in the development community, lack of time on my part), I do want to take the time and go over why it’s taking so long.

Where are the hackers?

A common (and valid) complaint I hear is that there is a lack of hackers (a word I hate) working on the Vita. The fail0verflow team has a great post about console hacking that applies just as well to the Vita. In short, there isn’t as much value to hacking a console now than before. Not too long ago, the PSP and DS were the only portable device people owned that plays games and, for many people, the only portable device they owned period. I had a DS Lite that I carried everywhere long before I had a smartphone. But then I got a smartphone (and so did everyone else). iPhones and Androids (and don’t forget Windows Phone) are the perfect platform for what we used to call homebrew. Indie developers who wanted to write a portable game no longer has to use a hacked PSP and an open SDK. Writing apps is much easier and much more profitable. Meanwhile users can play all the emulators they want on their Android phone or their jailbroken iPhone. The demand for hacked consoles shrunk dramatically with those two audiences gone. Plus with smartphones gaining a larger audience while the Vita barely sells (which by the way is a tragedy since it’s a pretty awesome console), a hacker can get a lot more attention (for for those who seek “donations”, a lot more money) spending time rooting phones that are coming out every month.

But [insert device here] was hacked very quickly, we just need more people working, right?

To some extent, that is true, but even with a large group of talented reverse engineers, I would not bet that the Vita would be hacked any time soon. To be clear here, when I say “hacked,” I refer to completely owning the device to the point that decryption keys are found and unsigned code can be run in kernel mode (or beyond). The problem is that even talented reverse engineers (who can read assembly code and find exploits) are out of luck when they don’t have the code to work with. I mentioned this circular problem before, but to restate it: you need to have access to the code before you can exploit it, and to get access to the code, you need to exploit it. But, if that’s the case, you ask, how would any device ever be hacked? That is why I believe that the first (real) hack of any device is the most important. Let’s look at some examples of “first hacks” and see why it doesn’t work with the Vita.

Insecure First Version

This is the most common situation. Let’s look at the PSP. The 1.00 firmware ran unsigned code out of the box. Someone found a way to access the filesystem, and saw that the kernel modules were unencrypted. They analyzed the kernel modules and found an exploit and owned the system. All it takes is to have an unreleased kernel exploit from one firmware version; then update to the next one; exploit it and dump the new kernel to find more exploits. Rinse and repeat.

Same with the iPhone. The first version(s) allowed you to read from the filesystem through iBoot. It was a matter of dumping the filesystem, analyzing the (unencrypted) binaries, and creating exploits. Plus, the kernel is from the same codebase as OSX, so analyzing it was not as difficult as looking at a new codebase.

The Vita however, has a fairly secure original firmware. No filesystem access (even to the memory card), proper encryption of things that do come out of the device, and very little areas of interaction in general (you have CMA and that’s pretty much it).

Similarities to other Devices

Most Android phones fall into this category. One Android root will most likely work across multiple manufactures. Plus, Android is open source, so it’s a matter of searching for an exploit. Once the device is rooted, someone has to find a way to dump the bootloader (which for many phones is just a matter of reading from a /dev/ endpoint), and analyze the bootloader for a way to root it.

The Kindle Touch (which I was the first to jailbreak), ran essentially the same software as the Kindle 3 and had a debugging console port.

The Vita has similarities to the PSP, but most of the system is different. With multitasking support, the Vita memory model is completely different from PSP and has proper abstraction of virtual memory. The Vita has NetBSD code, but the kernel is completely proprietary. No PSP exploit will work on the Vita.

Hardware Methods

This is usually the “last resort” because it takes the most skill and money to perform. This usually involves physically dumping the RAM with hardware to analyze the code. The most recently hacked console, 3DS had this done. I believe the first Wii hack was developed with a hardware RAM dumper. Many consoles had some kind of hardware analyzing done before the first hack is developed.

It would be very hard to do a hardware hack on the Vita. The system memory is on the same chip as the CPU, so you cannot try to piggyback the RAM. Plus anyone doing a hardware hack would have to have expert electrical engineering skills and access to expensive tools.

 

The story always starts with getting access to the code, then finding an exploit, and then using that exploit to get more code to find more exploits in the future. Most of the jailbreaks, roots, and hacks you see are developed with information gathered from a previous hack. I believe that Sony knows this and really made sure that their device does not suffer any of the flaws I listed. Lots of people make fun of Sony for not handing security well, but after spending countless hours on the Vita, I could honestly say that the Vita is one of the most secure devices I’ve ever seen. So far, they seem to have done everything well; using all the security features in modern computers and not trusting any code. But, as we learned countless times, nothing is completely secure.

EDIT: I’m seeing a lot of comments speculating that Vita slim or Vita TV may help hacking it. In my opinion, this is grasping at straws. There are no evidence that a minor revision of the console will magically create software or hardware holes.

Kindle 3.2.1 Jailbreak (Update)

When I first released the Kindle 3.2.1 jailbreak, I called it “temporary.” Although confusing to use and set up, it has gotten thousands of hits and reports of success. However, it was “temporary” because the method used depended on some precise timing and I had a better method that I was saving for Kindle 3.3. Now, I realize that 3.3 will never come, but will instead be 4.0 that will come with Kindle 4, and with a new hardware, everything doesn’t matter. Serge A. Levin has independently discovered a similar bug for what I was going to use on the 3.3 jailbreak, and I’ve asked him to release it because he deserves the credit for the work. If we’re lucky, Amazon will fix the bug in a way that my similar plan for 3.3/4.0 will still work.

(If you are already jailbroken, regardless of what version you’re running, you don’t need to download this. The actual jailbreak hasn’t been updated, just the injection method.)

Also, if you think that the jailbreak didn’t work, try installing a custom package anyways. I have fixed many people’s “I can’t get it working” by telling them that it’s already jailbroken.

Link to jailbreak for all devices on all versions.

EDIT: It seems like there is some confusion so I’ll clear this up. Jailbreaking does NOT remove ads.

Kindle 3.2.1 Jailbreak

UPDATE: Serge A. Levin has kindly modified my “temporary” jailbreak into a more permanent solution. The information below is now considered old and should be disregarded. Link to jailbreak for all devices on all versions.

 

So I never intended to release a jailbreak for Kindle 3.2.1 because 1) people who got a discount for their Kindles should stick by their commitment and keep the ads and 2) this was an update made purely to disable jailbreaks, so there are no new features. However, from what I heard, more and more people are receiving 3.2.1 as stock firmware (not just ad-supported Kindles) and that people who exchanged their broken Kindles also have 3.2.1. I don’t want to reveal the exploit I found yet (I’m saving it for the next big update), but thankfully, after half an hour of digging, I’ve found another glitch that I can use. The bad news is that this isn’t an “easy one click” jailbreak, it will actually take some effort as some precise timing needs to be correct in order to work.

Technical Details

What is this new glitch you ask? It’s pretty simple and pretty stupid and I feel almost embarrassed to use it (that’s why I’m not even using the word exploit). First of all, the last bug I found was fixed by a regex name check that prevent spaces in names. Now, whenever the Kindle gets an update, before doing anything, it looks for the signature of every file in the update (minus the signature files themselves). They do this by using the “find” command to get a file list and piping the output to “read” where “read” feeds each data (separated by a whitespace) into the signature check function where the function proceeds to use OpenSSL to check the signature. Simple enough. Well, what I want to do is make the signature check ignore a file, and to do it, I make a blank file called “\” (literally a backslash). Now it’s hard to explain what happens, so I’ll show you.

Here’s the output of the find command usually:

$ find /tmp/update

/tmp/update/file.ext

/tmp/update/file2.ext

Now, when I insert my slash-file:

$ find /tmp/update

/tmp/update/file.ext

/tmp/update//tmp/update/file2.ext

What happened? The backslash is used in Linux as an escape character. Basically it says to treat the next character as not-special. Remember that “read” splits the data to be read using whitespace (in this case a new line character), so by escaping the whitespace, I can get the system to ignore /tmp/update/file2.ext, and instead get it to read /tmp/update/tmp/update/file2.ext. In that file, I will include an already signed file from an old Amazon update, and when the updater runs, it ignores the extra files and reads the unsigned file. But we’re not done yet. Amazon doesn’t extract the update to a set folder, it extracts it to /tmp/.update-tmp.$$ where $$ means the process id of the script running. This can be any number from 1 to 32768. So what’s the elegant solution to this problem? I don’t know yet. Until someone can come up with a better idea, I’m going to include PIDs 5000-7000. From my tests, if you run it immediately after a reboot, it will be 64xx, so it’s a test of how bad you want to jailbreak ;)

Installation

Since this jailbreak is time and luck based, I’ve included very detailed directions on the exact timing for doing things in the readme. I suggest reading over the directions before starting, because timing is everything. It works only in a certain window of time after startup, so if it doesn’t work you need to restart and try again. If it doesn’t work after three or more tries, it’s mostly my fault as I only tested it with a Kindle 2 so the timing might be different on the Kindle 3. If you have serial port access on your Kindle 3, send me the otaup log and I’ll change the pid set.

Download

Since this is a temporary fix, I’m not going to add this to my projects list.

Download source and binaries here

EDIT: I’ve heard from some users that you have more chance of succeeding if you don’t have any books to load. So, before doing anything, rename the documents folder to documents.bak and the system folder to system.bak, install the jailbreak, and rename everything back. This should allow more chance of succeeding.

EDIT 2: Some people report turning the wireless off before starting also increases success rates.

Kindle 3.1 Jailbreak

I was bored one weekend and decided to jailbreak the new Kindle firmware. It was time consuming to find bugs, but not difficult. Unlike the iPhone, the Kindle doesn’t really have security. They have a verified FS and signed updates and that’s it, but I will still call my jailbreak an “exploit” just to piss you off. Previous Kindle 3 jailbreaks worked (AFAIK, I haven’t really looked into it) by tricking the Kindle into running a custom script by redirecting a signed script using a syslink. This worked because the updater scans only “files” that do not end with “.sig” (signature files to validate the file). They fixed this now by scanning all non-directorys that do no end with “.sig”. This is the first bug I’ve exploited. Part one is getting the files into the update, which I did by conventionally renaming them to “.sig” even though they’re not signature files. Part two is harder, getting the unsigned script to run.

How the Kindle updater works is that first it gets a list of all files (including files in subfolders, excluding signature files) in the update and checks it’s signature with Amazon’s public keys. If you modify any of the scripts from a previous update, the signature is broken and the Kindle won’t run it. If you add your own scripts, you can’t sign it because you don’t have Amazon’s keys, and finding them would take more then the lifespan of the universe. (SHA256 HMAC). They also use OpenSSL to check the signatures, so trying to buffer overflow or something is out of question (or is it? I haven’t looked into it). Afterwards, when all files are matched with their signatures and checked, the updater reads a “.dat” file which contains a list of all scripts, their MD5 hash and size (to verify, I don’t see the point since they were just signature checked. Maybe a sanity check?). It finds the “.dat” file using “find update*.dat | xargs” which means all the .dat file has to be is start with update and end with .dat. They don’t care what is in between. Next, they read the file using “cat” and with each entry, verify the hash and loads the script. Well, conventionally, “cat” can read multiple files if more then one filename is given in the input. This means if the update*.dat file contains spaces, then “cat” will read every “filename” separated by a space. I took a signed .dat from one of Amazon’s update. Renamed it “update loader.sig .dat” and placed my actual .dat (containing an entry to the script jailbreak.sig, a shell script renamed) in loader.sig. jailbreak.sig untars payload.sig, a renamed tgz file which contains the new keys we want to use to allow custom updates. Amazon’s updater only signature checks “update loader.sig .dat” which is valid. Then cat tries to read the files “update”, “loader.sig”, and “.dat”, one of which exists and the others silently fail. Loader.sig points to the script jailbreak.sig which the updater happily loads thinking it’s already signature checked. Jailbreak.sig, calls tar to extract payload.sig and copies the new keys to /etc/uks and installs a init.d script to allow reverting to Amazon’s keys for installing future updates. Now we own the system again!

tl;dr:

A download to the jailbreak can be found here. Directions are provided in the readme file. Use it at your own risk (I’m not responsible if you somehow brick it) and note that it most likely will void your warranty. Make sure to uninstall all custom updates before you uninstall the jailbreak, as after uninstalling the jailbreak, you cannot run custom packages until you jailbreak again. Directions for switching between custom updates and Amazon updates can be found in the readme file.