Getting information

The hardest part of any hack is the figuring-out-how-to-start phase. That’s always tricky. But… let the games begin.

-Wheatley, Portal 2

So before we can do anything, we need to know what to do. The best place to begin is to look at the updater. A quick look at the extracted files, we find that the files being flashed have names such as “amss.mbn”, “dsp1.mbn”, and such. A quick scan with a hex editor, we see that the files are unencrypted and unsigned. That’s good news because it means we have the ability to change the code. A quick Google search shows us that these files are firmware files for Qualcomm basebands. Now, we need to find more information on this Qualcomm chip. You may try some more Google-fu, but I took another path and took apart the device (not recommended if it’s any more complicated). In this case, I found that we are dealing with a Qualcomm MDM8200A device. Google that and you’ll find more information such as there are two DSP processors for the modem and on “apps” ARM processor (presumably for T-Mobile’s custom firmare, and is what you see as the web interface). We want to unlock the device, so I assume the work is done in the DSP processor. That’s the first problem. QDSP6 (I found this name through more Google skills) is not a supported processor in IDA Pro, my go-to tool, so we need another way to disassemble it.

Disassembly

Some more Googling (I’m sure you can see a pattern on how this works now) leads me to this. QDSP6 is actually called “Hexagon” by Qualcomm and they kindly provided an EBI and programmer’s guide. I guessed from the documents that there is a toolchain, but no more information is provided about it. More searching lead me to believe that the in-house toolchain is proprietary, but luckily, there is an open source implementation that is being worked on. Having the toolchain means that we can use “objdump”, the 2nd most popular disassembly tool [Citation Needed]. So, it’s just a matter of sending dsp1.mbn and dsp2.mbn into objdump -x? Nope. It seems that our friends at ZTE either purposely or automatically (as part of the linker) stripped the “section headers” of the ELF file. I did a quick read of the ELF specifications and found that the “section headers” are not required for the program to run, but provides information for linking and such. What we did have was the “program headers”, which is sort of a stripped down version of the section headers. (Program headers only tell: 1) where each “section” is located in file and where to load it in memory, 2) is it program or data?, 3) readable? writable?, while section headers give more information like the name of each section and more on what the program/data section’s purpose is). What I then did is wrote my own section headers using the program headers as a guide and made up the names and other information (because they are not used in the actual disassembling anyways) with a hex editor. Then I pasted my headers into the file, changed some offsets, and objdump -x surrendered the assembly code. 180MB worth of it.

Assembly

So we have 180MB worth of code written in a language that could very well be greek. Luckily, as I’ve mentioned earlier, Qualcomm released a document detailing the QDSP assembly language and how it’s used. Most likely, you would be dealing with a more “popular” processor like ARM or x86 and would have access to more resources. However, for QDSP6/Hexagon, we have two PDF documents and that is basically the Bible that we need to memorize. I then spend a couple of hours learning this new assembly language (assembly isn’t that hard once you embrace it) and figured out the basics needed to reverse engineer (that is: jumps, store/loads, and arithmetic). Now, another problem arises. We have literally 3 million lines of assembly code with no function names, no symbols, and no “sections”. How do we find where the goal (the function that checks the NCK key and unlocks the device accordantly) without spending the next two years decoding this mess? Here, we need to do some assumptions. First, we know   (through Google) that the AT modem command for inputting the NCK key is AT+ZNCK=”keyhere” for ZTE devices. So, let’s look for “ZNCK” in the hex editor of dsp1.mbn and dsp2.mbn. (If you are not as lucky and don’t know what the AT command is, I would put money that the command will contain the word NCK, so just search that). In dsp2.mbn, we find a couple of results. One of the results is in a group of other AT commands. Each command is next to a 4-byte hex value and a bunch of zero padding. I would guess that it is a jump table and the hex values are the memory locations of the functions to jump to. Doing a quick memory to file offset conversion (from our ELF program header), we locate the offset in our disassembly dump to find that it starts an “allocframe” instruction. That means we are at the beginning of a function so our assumptions must be right. Now, we can get to the crux of the problem, which is figuring out how the keycheck works.

Mapping out the functions

We now know where the function of interest starts, but we don’t know where it ends. It’s easy to find out though, look for a jump to lr (in this case for this processor, it’s a instruction to jump r31). We start at the beginning of the function and we copy all the instruction until we see a non-conditional jump. We paste the data into another text file (for easier reference). Then we go to the next location in the disassembly (where it would have jumped to) and copy the instruction until we see another non-conditional jump, and then paste them into the second text file. Keep doing this until you see a jump to r31. We now have most of the function. Notice I kept saying “non-conditional” jumps. That’s because first, we just need the code that ALWAYS runs, just to filter out stuff we don’t need. Now, we should get the other branches just so we have more information. To do this, just follow each jump or function call in the same way as we did for the main function. I would also recommend writing some labels like “branch1″ and “func1″ for each jump just so you can easily locate two jumps to the same location and such. I would also recommend only doing this up to three “levels” max (three function calls or three jumps) because it could get real messy real quick, and we will need more information so we can filter out un-needed code, as I will detail in the next section.

Finding data references

Right now, we are almost completely blind. All we know is what code is run. We don’t know the names of functions or what they do, and it would take forever to “map” every function and every function every function calls (and so on). So we need to obtain some information. The best would be to see what data the code is using. For this processor (and likely many others), a “global pointer” is used to refer to some constant data. So, look for references to “gp” in the disassembly. Searching from the very beginning of the program, we find that the global pointer is set to 0×3500000, and according to the ELF headers, that is a section of the dsp2.mbn file at some file offset. In the section we care about, look for references to “gp” and use the offsets you find to locate the data they refer to. I would recommend adding some comments about them in the code so we don’t forget about them. Now, the global pointer isn’t everything, we can have regular hard-coded pointers to constant areas of memory. Look for setting of registers to large numbers. These are likely parameters to function calls that are too big to be just numerical data and are more likely pointers. Use the ELF header to translate the memory locations to file offsets. In this case (for this processor), some values may be split into rS.h and rS.l, these are memory locations that are too “large” to be set in the register at once. Just convert rS.h into a 16 bit integer, rS.l into a 16 bit integer (both might require zero padding in front), then combine them into one 32 bit integer where rS.h’s value is in front of rS.l’s value. For example, we have: r1.h = #384; r1.l = #4624. That will make r1 == 0×1801210. You should also make some comments in the code about the data that is being used. Now, predict standard library calls. This may be the hardest step because it involves guessing and incorrect guessing may make other guess more wrong. You don’t have much information to go by, but you know 1) the values of some of the data being passed into function calls, and 2) library calls will usually be near the start of the program, or at least very far away from the current function. This will be harder if the function you are trying to map is already near the beginning of the program. The function I’m mapping is found at 0xf84c54, and most function calls are close to it. When I see a function call to 0xb02760, I know that it might be a library call. 3) Some of the more “common” functions and the types of parameters they accept. You don’t need to figure out all of the library calls, just enough to get an idea of what the code is doing so you don’t try to map out these functions (trying to map out strcpy, for example will get messy real quick). For example, one function call, I see is taking in a data pointer from a “gp” offset, a string that contains “%s: %d”, and some more data. I will assume it is calling fprintf(). I see another function is being called many times throughout the code, and it always accepts two pointers where the second one may be a constant and a number. I will assume it is calling memcpy().

Translating

This may be the most boring part. You should have enough information now to try to write a higher language code that does what the assembly code says. I would recommend doing this because it is much easier to see logic this way. I used C and started by doing a “literal” transcription using stuff like “r0-r31″ as variable names and using goto. Then go back and try to simplify each section. In my process, I found that how the unlock key is checked is though sort of a hash function. It takes the user input, passes it through a huge algorithm of and/or/add/sub of more than 1000 lines and takes the result and compares it to a hard coded value in the NV ram (storage area for the device). Here, I made a choice to not go through and re-code this algorithm for two reasons. First, it would be of little use, as the key check doesn’t use a known value like the IMEI and relies on a hard coded value in the NV ram that you need to extract (which a regular user might have trouble doing). Second, after decoding it, we would have to do the algorithm backwards to find the key from the “known value” in the NV ram (and it could be that it would be impossible to work backwards). So I took the easy way out and made a 4-byte patch in where I let the program compare the known value to itself instead of to the generated hash from the input and flashed it to the device. Then I inputted a random key, and the device was unlocked.

Now, remember at the beginning I said the code was unsigned? Because of that I could easily have reflashed the firmware with my “custom” code. However, if your device has some way of preventing modified code from running, you may have no choice but to decode the algorithm.

There are two ways of approaching this. One is to sniff the USB packets to figure out what data gets sent to and from the device, and second is to disassemble the content manager application to find out how it communicates with the device. I tried both methods.

Reverse engineering the Content Manager

The biggest problem here is that the PC version of Sony’s content manager has its symbols removed. This makes everything a hundred times harder as you would have a harder time guessing what each function does. Luckily, the OSX version of the content manager does have the symbols intact. The problem here is that IDA does not work perfectly with Objective-C (it works, but you get a C++ish interpretation of Objective-C). I have a good idea of how the application is laid out, but there isn’t much point giving all the details (not useful). I will give some important points:

• The Vita uses the Media Transfer Protocol, however I am not sure if it adheres completely to standards or if it uses a custom implementation
• USB endpoint 0×2 is for input, while 0×81 is for data output, and 0×83 is for MTP event output
• There is support for passing PSN account information to and from the Vita (password would be in plain text!), but it is unimplemented
• CMA uses a SQLite database to index media information and licenses


Events:
0xC104 0: RequestSendNumOfObject
0xC105 1: RequestSendObjectMetadata
0xC107 3: RequestSendObject
0xC108 4: RequestCancelTask
0xC10B 7: RequestSendHttpObjectFromURL
0xC10F 11: RequestSendObjectStatus
0xC110 12: RequestSendObjectThumb
0xC111 13: RequestDeleteObject
0xC112 14: RequestGetSettingInfo
0xC113 15: RequestSendHttpObjectPropFromURL
0xC115 17: RequestSendPartOfObject
0xC117 19: RequestOperateObject
0xC118 20: RequestGetPartOfObject
0xC119 21: RequestSendStorageSize
0xC120 28: RequestCheckExistance
0xC122 30: RequestGetTreatObject
0xC123 31: RequestSendCopyConfirmationInfo
0xC124 32: RequestSendObjectMetadataItems
0xC125 33: RequestSendNPAccountInfo
0xC801 1789: Unimplemented (seen when getting object from Vita)

Object Formats:
0x3000: Undefined
0x3001: Association
0x3008: WAV
0x3009: MP3
0x3801: EXIF/JPEG
0x3804: BMP
0x3806: UndefinedReserved
0x380A: PICT
0x380B: PNG
0xB007: PSPGame
0xB00A: PSPSave
0xB014: VitaGame
0xB400: ?
0xB411: MNV
0xB984: MNV2
0xB982: MP4/MGV/M4V/MNV3

USB packets

I’ve also captured the USB packets for initializing the device (from device plug-in to Vita displaying the content menu) and gave my best interpretation of it. First line is PC to Vita packet or Vita to PC packet

, followed by packets captured by VMWare running Windows 7, followed by the same action on OSX (dumped from memory using GDB on CMA, not from capturing USB packets), followed by my interpretation of what the packet does (question mark means not sure). EDIT: Some of my comments in the log I know are wrong now.

Next time

I’m hoping to decode these packets and implement them using libusb. I hope Sony is using the MTP standard so I can also make use of libmtp. I also need to be more familiar with how the USB protocol works so I can understand the packet layout better.

EDIT: I’ve begun work on a new project to create an open source content manager for the Vita. As of this post, it can init the device and tell it to show the main menu.

On this new version of the site, the first thing I did was integrate my projects list to WordPress. I wrote a custom plugin that allows me to manage and add my projects with ease and manage things like downloads, version/changlog, screenshots, etc. I may release this plugin as open source one day. I also got a new style thanks to CSSHeaven. They provided the free HTML template and I coded it into a WordPress style (and also made it more HTML5 compliant). If you have any complaints or suggestions regarding the new site, feel free to comment.

In addition, I added two new Kindle projects that I’ve been working on.

So long story short, we can run custom code on the Kindle Touch now but because the operating system has changed so much from Kindle 3, most Kindle modifications will not run without changes. I hope developers will jump to this device now that it’s unlocked. See the bottom of the post for download links. The directions for using are in the readme. Keep reading for technical details on how this came about.

Obtaining the root image
Before we can look for vulnerabilities in the system that would allow us to break in, we need to break into the system and obtain the files that might contain vulnerabilities. Yes, this is a chicken-and-egg problem, but fortunately Amazon is nice enough to help us with this. On every Kindle device is a TTL serial port. I found this port on the bottom of the device when the cover is opened. Fortunately, I did not even have to mess with it, as hondamarlboro and ramirami both managed to get the dump before me. Once we have the root image, it was only a matter of painstakingly looking through all the files to see possible injection vectors.

Looking for the needle

At first, I was digging deep into the system, disassembling and maping out various native libraries, looking for stack overflows (I found a couple but none could be accessed efficiently). I found the bootloader was unlocked but it would be a pain and danger for users (and even developers) to flash custom kernels and such. I also found that the Java code (the Kindle’s entire GUI is written in Java) is NOT obfuscated (which means it would be easier to reverse and later modify) and Amazon has left in many places to place plugins. For example, once someone has the time to figure things out, it would be very possible to write a EPUB extension to read EPUBs from the native reader. There are some other hidden secrets in the device too. The Kindle Touch has an accelerometer and proximity sensor (and a mic, but we know that) but they aren’t used in the software (yet). The more I looked into the system, I was aware that because it was such a huge rewrite, I had misjudged when I assumed that it would be harder to break as Amazon had years to fix the holes now. In fact, I would say that the Kindle 4 is more secure until I found out that Amazon left in SSH in diagnostics mode. Anyways, as I searched up the complexity chain from the bootloader to the kernel to the libraries to the Java interface, I found something very curious. Much of the operating system is no longer written in Java, but are now in HTML5 and Javascript. In fact, many of the interfaces on the Touch are actually web pages in disguise. For example: the password entry screen, the search bar, the browser (is just an HTML page with a frame), the Wifi selection screen, and even the music player. Obviously, these can’t all run natively in HTML and JS, or the device will be even slower (and it is pretty damn slow). What Amazon did is write a couple of Javascript hooks that are implemented by native libraries and events are read by these libraries and they perform actions accordantly. In short, Javascript will run native code. This is a goldmine, there could be many possible ways of using this to our advantage. There could be buffer overflows, heap overflows, string formatting bugs, etc. However, I didn’t have to look though much before I found a curious function: nativeBridge.dbgCmd();. It seems too good to be true. This function takes any shell command, and runs it (as root). Yup. The web browser will run as root, any command given to it. Don’t go looking for remote code execution yet (although it is highly possible), as the native bridge seems to be disabled when in web browser mode (it may be able to be bypassed, but I haven’t looked into it).

Calling the debug function

So the normal browser (as the one you can enter URLs into) can’t make use of this native bridge. However, as I’ve mentioned, a large part of the GUI in the Kindle Touch is HTML and JavaScript. All we need to do is inject some HTML into one of these and we would be all set. We need something that takes input and displays it to the user. The first thing I thought of was the media player. The Kindle displays the song title, artist, and album name in the music player, so what if we put some HTML into the ID3 tag? Yup, it works. How about some javascript? Running. Let’s try to call the debug function. It works. Well, that was a freebie.

Having some fun

That was a bit too easy and I was disappointed that I didn’t get to talk about how I whipped out IDA Pro and did some master debugging. So, let’s make things harder. We can use a MP3 with custom ID3 tags to execute any command, but how can we make this into a cool one-click solution? First of all, we should limit ourselves to one file to copy. Why make the user keep track of MP3s and shell scripts and where to put them? I took the shell script payload (which installs a developer key into the device so custom packages can be installed) and placed it into the comments section of the ID3 tag in the MP3. Then I used “dd” to extract the script, chmod it, and execute it. Now, another problem in terms of user friendliness is how to let the user know that the process was successful? I quickly whipped up an awesome looking “splash screen” and planned on displaying it while the magic is taking place. At first I tried to encode it into a variable in the shell script payload and extract it, but it was too slow and memory intensive. Instead, I took the image, raw, and appended it into the end of the MP3 (after all, the file was a bit too small). You can see the result in the video attached.

What’s next?

Just because the device is jailbroken does not mean it can now magically do anything you want. What needs to happen first is that developers need to take the device and write some code for it. This first jailbreak is really for these developers. For regular users, the only use is to preemptively unlock your device now in case the method is patched in an update or something. No mods for older Kindles will work as-is on the Touch. I’ve included a VERY basic usbnetwork package that will allow you to have SSH access to the device. I think that’s as good of a starting point as anything. From there, developers should be able to rip the root filesystem, test modifications, and write useful tweaks. (And in case of a brick, read my previous post on the bootloader access). Some things I would have to see or do is GUI plugins in the device’s operating system. The Java code is easy to decompile and read as the variable names have not been stripped out (like previous models). Hopefully people can write some reader plugins (like X-Ray) or even format plugins for other ebook formats. Being a touch screen device, one could also write games or useful apps (although the speed and eink are limiting). I need to finish writing the update creation tool so developers can package their modifications.

Download

Download the jailbreak here

Simple custom screensaver mod

Simple usbnet update (supports wifi ssh and resetting root password)

GUI menu launcher and screen rotation hack

Demonstration

Previously on “cracking the emulator”…

If you haven’t read the last posts I’ve made about how I reverse engineered the emulator data format and binary, you may want to, but I’ll summarize it in a few words. Basically, the emulator was separated into two binaries bin-one decrypts bin-two and bin-two asks bin-one to decrypt and load the game’s table-of-contents which is used to load the game. The TOC is important because anyone can replace the game data files, but it won’t load because the TOC contains addresses of the places to decompress in the game data. Well, after the hard part of reversing the formats and finding all this out, the actual patch was fairly easy. All we did was make a new library with the same function name as the one that is used by bin-two to query bin-one for the TOC, and use it to load the TOC for our custom game and make sure that library loads before Sony’s and the rest is almost magic. We don’t need to overwrite any function pointers or even touch the emulator because the linker looks for the first definition of a function and calls it.

How Sony made our lives harder

So version 1 is always easiest to break. This applies for almost everything. The PSP, the iPhone, the DS, etc. Version 2 is where it gets real. So what are the changes? First of all, no more bi-binary system. There is a single binary that does both the decrypting and emulating. Oh, and they removed the symbols so we can no longer search for “GetImageToc” and find where the function is. Also, they’ve started verifying that ISOs.

Finding the needle

Before we can begin to think about patching, we first need to find what to patch. As I’ve mentioned, Sony removed the symbols, so we no longer know what the function names are. We CAN try to map out the entire binary (10MB) and look for something that does what appears to be decrypting a TOC, but we don’t have months or a team of assembly experts. What we DO have is the older version of the binary that has the symbols. Assuming that they didn’t rewrite the emulator from scratch, the structure should be similar. We open up the old binary, find the function that calls the ones we want to patch, and look for identifying characteristics. What are they? Well, we look for mentions of unique strings and unique calls to standard functions (unique as in something like atoi, not malloc, which is called every other line). Luckily we have both. It seems like a few lines before the function we are interested in, the program does something with the string ”/data/image.ps” and sometimes afterwards, uncompress is called. Now we have the address of the functions we want to patch.

Patching the function

Well, here’s our second problem. What do we patch the function with? We are only limited to the length of what the function originally is, but I’m sure that’s not a problem for experts. I’m not an expert though, so how about we steal what Sony did in version 1? We use dlsym to call the function from a loaded binary in memory. After a quick trip to an assembly reference, I wrote the following code: https://github.com/yifanlu/PSXPeria-Wrapper/blob/master/jni/java-activity-patch.S, I would go into more details, but I believe my comments on the code explains it better than I could. The only other thing we need is to manually define the address for “dlsym” and the offset for the name of the function. ARM assembly uses relative address, so I haven’t come up with a quick way to do this yet. For now, I’m using a calculator and a piece of paper to find the address of dlsym relative to the patch in the program. Comment if you have a better way.

Phase 2

When the game didn’t boot and was frozen on screen, I knew it had to be another obstacle. Our code had to have worked because otherwise, it would have crashed. Debugging with GDB, it seems like the program is blocking forever, seemingly on purpose. To double check, I loaded Crash Bandicoot again, but with my patched emulator and it worked. So, I guess there was a check somewhere that only loads Crash Bandicoot. Yes, I could go back into IDA and look for where the check is and NOP it out, but I was tired by then and my short attention span wants me to work on something else, so I took the easy way out and patched the PSX image with the titleid for Crash Bandicoot. As far as I know, this shouldn’t affect anything in terms of compatibility, but farther tests are needed.

Next week on “cracking the emulator”…

Version 3 of the emulator is already out and is distributed in the PS-Suite games in the Japanese PSN store (on the Play). I already took a look at it, and the emulator did not seem to be updated, so I didn’t try hard to patch it. However, it seems that they implemented many new security mechanisms in the PS-Suite PSX games. For starters, there is a public-private key exchange to make sure all the files in the APK are untouched, and I’m pretty sure the PS-Image is now encrypted or the format has changed. Now, Sony did not do all this to prevent us from loading our own games (or maybe they did). I suspect it’s to prevent pirates from stealing the PSN games. Which means that if I crack the version 3 emulator, I may be helping piracy. This means, I will most likely not touch the PS-Suite emulators, and if I do, two things have to happen. 1) I need to be sure that the emulator has much better compatibility, and 2) I need a way to make sure that my tool isn’t going to be used for piracy. So I guess this may be the last release for a while.

Links

Project Page
Source
Downloads

If you want to follow me and others try to crack this thing, visit this thread on MobileRead.

I’ll post some of the more important stuff we find on this post, so check back regularly.

• The update format has changed! No more signatures for each file in the update, the update itself is signed and will refuse to extract unless the signature check passes. That means no more easy way out. To get “kindle_update_tool.py” to recognize and extract the new update, remove the signature (first 0×140 bytes) and change “FC04″ to “FC02″ (Bytes 0×0 to 0×4 after trimming the signature header). Now delete 4 bytes starting from 0×8 and 6 bytes starting from 0×10. (Offsets depend on the SP01 part removed). Now “kindle_update_tool.py” will recognize it.
• Kindle 4.0 is codenamed “Yoshi” following “Luigi” (3.0) and “Mario” (2.0) (I can’t remember 1.0). It is built for the iMX50 (800MHz ARM Cortex A8) platform. The Kindle 3 is iMX35 (532MHz ARM) and the Kindle 2/DX is iMX3 (400MHz ARM).

Requirements:

• Windows 8 Developer Preview burned to a DVD (unless you’re using virtual machine)
• Windows 8 M1 build 7850 burned to a DVD (unless you’re using virtual machine)
• 16GB flash drive or external hard drive (or larger)

(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.