Huawei E587 (T-Mobile 4G Sonic Hotspot): Information and rooting

Earlier this year, I got my hands on the T-Mobile 4G Sonic Hotspot and as always, had to tear it apart as soon as I got it. I never wrote about it because I didn’t find anything overly interesting, but now it’s the end of the year, and I need to clear some inventory from my brain. If anyone remembers my post on the (older) T-Mobile 4G Hotspot (sans “Sonic”), the main limitation of that device was that the processor is an obscure one that required some digging to get information on. Thankfully, the Sonic variety is much easier to break into.

Teardown

I don’t usually do this, but as I couldn’t find any good snapshots of the insides of this device, I took it upon myself to produce some amateur shots. One thing I want to say about the insides is that I loved how the main board is broken into three parts and they’re sandwiched together to make the device small (but thick).

Device with faceplate removed.

Device with faceplate removed.

MCIMX283CVM4B

FreeScale MCIMX283CVM4B

Qualcomm MDM8220 modem

Qualcomm MDM8220 modem

Middle layer, containing various chips

Middle layer, containing various chips

The important information is that the device is ARM based (it even uses the same system-on-chip as older Kindles), and having a well documented SoC is always a plus. There isn’t an obvious debug serial port, but I would bet that there is one knowing how the FreeScale SoCs work. However, we don’t need to explore hardware hacking yet as the software is unexplored.

Rooting

This was literally the easiest device I’ve ever rooted. I can honestly say that from opening the package (knowing nothing about the device) to getting a root shell took me about fifteen minutes. There was only one interface to the device and that’s the management webpage. My plan was to explore every location where I could pass input to the device (settings, HTTP POST requests, MicroSD file browser, etc) and basically just try things until I get a crash or something interesting. The first thing I’ve tried was the settings backup/restore feature. Creating a backup of the settings allows you to download a SQLite database containing the settings. A quick SQL dump of the settings showed me some interesting options that can’t be set directly from the web interface, including:

CREATE TABLE telnet
(
TelnetStatus int
);

Yep, setting TelnetStatus to 1 and restoring the backup database showed me that port 23 was now open from the hotspot’s IP. Well, that was extremely lucky, as always the best hacks are the one which doesn’t require hacking at all. Well that was only half the challenge, the next part is getting access to the root account. I’m thinking everything from brute forcing passwords to looking at privilege escalation exploits but all of that disappeared as soon as I typed “root” and enter because there was no password prompt. That’s right, “root” doesn’t require a password. I did a quick inventory of the filesystem and found the block devices, and using the magic of dd, nc, and the old Unix pipe, quickly dumped all the filesystems.

Software

Here’s the thing though, I spent all this time (almost 45 minutes at this point!) rooting the device and I don’t even have a clear goal. I don’t need to unlock the device because I was a T-Mobile customer at that point, and I didn’t really want to make a pocket ARM computer/server (which would be a thing one can do with this), so I just did a quick scan of how the device works (curiosity is the best excuse) and went my way. Here’s some of the things I’ve discovered, use this information how you will.

First of all, the device runs a stripped down build of Android running “Linux version 2.6.31 (e5@e587) (gcc version 4.4.0 (GCC) ) #1 Sun Aug 28 02:25:47 CST 2011.” On startup, most of the vanilla Android processes (including adbd) are not started, but instead the Qualcomm modem driver, some pppd/networking daemons, and a custom software they call “cms” are started. “cms” makes sure stuff like their custom httpd (which is hard coded to allow the HTML portal site to perform functions on the hotspot) and power management and the OLED display are running and in good status. The Huawi device stores all data on its flash MTD device. From a quick analysis (aka, might be errors), block 0 contains the u-boot bootloader (in what I believe is a format dictated by FreeScale), block 3 contains the kernel (gzipped with a custom header, possible also dictated by FreeScale), block 4 contains the rootfs (also gzipped with a custom header) loaded with boot scripts and busybox, block 5 is Android’s /system which also contains the main binaries (like cms, httpd) and the HTML pages, block 6 is Android’s /data which is empty, block 8 maps to /mnt/backup which I believe is, as the name says, just backups, block 12 maps to /mnt/flash which I believe is where ephemeral data like logs are and also where the settings are stored, and block 13 maps to /mnt/cdrom which has Huewai’s software and drivers for connecting to the computer with (and you see it when you plug the device into your computer).

That’s a quick summary of some of the things I’ve found while poking around this device. Nothing interesting (unless you’re a Huawei E587 fanatic I guess), but I’m sure there’s someone, someday, who got here from Google.

PlayStation Vita: the progress and the plan

Sorry that it’s been a while since I’ve said anything about the Vita. I was caught by surprise the last time of all the media attention from just a simple call for help. While I still don’t want to say too much right now, I do want to answer some common questions I’ve been getting and also go over what needs to be done.

If this is news to you, please read this interview I’ve done a while ago about it.

Did you hack the Vita? That’s a very vague question. What I have done, is run native code on the Vita with the same permissions as the game being exploited. This means I can load homebrews written and optimized for the Vita’s CPU and take full advantage of the CPU speed and RAM (unlike the PSP emulator or PSM, both impose artificial limits on resources and system functions). What has NOT been done (yet) is unlocking the system completely for tasks like USB interfacing, custom themes/system mods/plugins, and (fortunately) pirating games.

What’s UVLoader and how far along is it? The last I’ve spoken, I was beginning work on UVL and asked for any help I could get. Even though, I did not really get help, I did find people who were interested in what I was doing and we exchanged information. I also want to brag that I finished the main functionalities of UVL in a couple of weeks, and it has been “done” for about three months now. (Quotes around “done” because I decided to not worry about some features yet). That means, I can basically load most (most being the few that I manually built without an open sdk) compiled homebrews. You can run your standard hello worlds and spinning cubes and such, but in theory, it should load any homebrew built.

When’s the release? What’s taking so long? So as I’ve said, the loader was done three months ago. I have a couple of reasons for not releasing yet. The main reason is that currently, there is no open SDK for compiling and linking Vita homebrew like pspsdk did for the PSP. That means, even with the loader, it would be useless for users because there are no homebrew games, emulators, etc to run, and it would be useless for developers because they can’t build homebrews either. So what’s the progress on the open sdk? Zero, as I’m typing this right now. I have an idea of what it should look like and I spoke to a couple of people who are interested in helping, but so far, no code is written. Why is that? Because for me, I am very busy with lots of other unrelated things, and unfortunately, only me and a handful of other people know enough about the device and the executable format and etc to make the open sdk and none of us have the time currently.

The second reason is that having a Vita exploit at this stage (when it is really hard to find exploits) is very rare if not a once in a lifetime thing. Me and others I’ve talked to agree that right now it’s more important to use this exploit to gather more information about the system in order to find more exploits and such than it is to run homebrews right now. We have PSM for homebrew games and PSP emulator for homebrew emulators, so there really isn’t a huge demand for native PSVita homebrews yet. As I’ll expand on below, we’ve only scratched the surface of Vita hacking and there’s so much more to see.

Are you looking for testers/can I test UVLoader? There’s no need to “test” UVLoader right now because, as I’ve stated before, there isn’t any compiled homebrew and nothing to compile them anyways. Yes, UVL works with some of the custom still I’ve built manually, but it is unwise to write complex stuff without a working SDK.

Can help? Depends who you are. If you’re an established reverse engineer, you know how to contact me. If you just want to “beta test,” read above. If you know any other way of helping me, don’t ask, just do it™, since UVL is open source. Even though I don’t accept monetary donations before I release anything, if you have access to broken Vitas, memory cards, games, etc, or any unused hardware reversing tools like logic analyzers; anything you wouldn’t mind parting with, one of the things me and others involved don’t have access to is funds for materials to test some of the more… risky ideas and if you could help with that respect, just use the contact link at the top of the page to get in touch with me.

What needs to be done to “hack” the Vita? Again, that term is very vague, but I know what you mean. This is the perfect time to describe (as far as I know) the Vita’s security structure and what needs to be done at each level.

PSP emulator

I’ll start with the PSP emulator just because that is what’s “hacked” right now. How much control do you have of the Vita when you use vHBL? Almost none. On the PSP itself, games are “sandboxed” (meaning some other process tells it what functions of the PSP can be used by the current game, main thing being that one game can’t load another game). Because the Vita emulates the PSP, it also emulates this structure.

PSP kernel

One level up, we have “kernel exploits” on the PSP, which means that we are no longer limited to what functions of the PSP we can use. Any PSP function that is emulated by the Vita can be used, that’s why you see ISO loading as the main thing. However, all of this, the PSP emulator, sits in the Vita game sandbox. This sandbox is just like the PSP one, in that another Vita process tells the game (in this case, the PSP emulator running some PSP game) what Vita functions can be used in a similar fashion. For example, if a game doesn’t explicitly declare that it’s going to use the camera or bluetooth (and Sony approves), any code that tries to use these functions will crash.

Vita userland

This is where UVLoader works; we exploited some game to run code inside it’s sandbox, meaning that if that game doesn’t have camera functions, no UVLoader Vita homebrew can use the camera either. This also means, of course, we can’t load pirated Vita games and so on. A fun fact here is that, in theory, if someone finds an exploit in Kermit, the system inside the PSP emulator that talks to the Vita through a virtual serial port, they can run UVLoader in the process hosting the emulator (one level higher than a PSP kernel exploit), meaning they may be able to modify the emulator to have more RAM or faster CPU or etc. Another advantage of running UVLoader here is that because the PSP emulator has access to more Vita hardware than most games (bluetooth, camera, etc), homebrews could have more access too.

However, it’s easier said than done. It’s hard to appreciate  how hard it is to get a Vita userland exploit. Let’s work backwards: we want to somehow run native ARM code, how? Well, the classic route is some stack smash. But wait, modern ARM processors have XN (eXecute Never), which is a feature that only allow code in memory to run at specific locations (these locations are determined by the kernel and are read only). Ok, we have some other choices here: heap overflows, ROP (google if you don’t know), and so on (assuming you even know you got a working exploit, which in itself is hard to know without additional information; most “crashes” are useless), but all of these choices require that you know enough about the system to create a payload fitted for the system. That means, you need either a memory sniffer or somehow dump the memory. Well, let’s rule out hardware memory sniffing since the Vita has the RAM on the same system-on-a-chip as the CPU. How do we dump the memory then? Usually, you need to run some code to dump the memory or do some kind of oracle attack on crashes or error messages or something. Option one only works if we hacked the system before, and the second one, AFAIK, won’t work because the Vita doesn’t give any information when it crashes. So how did I get the first userland exploit? I’ll leave that as an exercise to the reader…

Vita kernel (lv2?)

Vita userland is the most we have access right now and PSP kernel mode is the most that is public. What comes after? Remember all information at this point could be wrong and is based off of the little evidence I have currently. We are in the Vita sandbox right now, which means we can run homebrew, but we can’t use functions that the game doesn’t use (camera, bluetooth, USB, etc). We also can’t modify the system (run Linux, change the theme, add plugins, etc). For those to work, we need to go one level up: the Vita kernel, which might be called lv2. Even with complete userland access, we can’t even poke at the kernel. The kernel acts like a black box, providing functions to the system through syscalls. You pass input into these syscalls and it returns some output, without revealing how the output is created. The kernel’s memory is separate from userland obviously, and even guessing what syscalls do (there’s no names in the memory, only numbers) is a challenge. In order to hack the kernel, we have a problem that is very much like the one I’ve stated above about getting Vita userland, except with even more limitations. Again, there’s the circular problem of needing a kernel RAM dump to inspect for exploits and requiring a kernel exploit to dump the RAM. Now, there’s even less “places” to inspect (visually and programmatically). In order of likelihood, one of the following needs to happen before there’s even a CHANCE of a kernel exploit: 1) Sony does something stupid like the PS3 keys leak, 2) we get REALLY lucky and basically stumble upon an exploit by just testing one of the several hundreds of syscalls with one of an infinite amount of different inputs, 3) some information leaks out from Sony HQ.

It’s still unknown how much control we would have if kernel mode is compromised, but me and some others think that we MAY at least be able to do something like a homebrew enabler (HEN) that patches signature checks temporarily until reboot, allowing for homebrews with no sandbox limitations (access to camera, BT, etc) and POSSIBILITY system plugins and themes. It is very unlikely at any keys will be found at this point or being able to create or run a CFW.

Hypervisor? (lv1?)

At this point, it is purely a thought experiment, as we literally have no information beyond what we THINK the kernel does. It is highly possible that there is a hypervisor that makes sure everything running is signed and the kernel isn’t acting up and such. Getting to this would be EVEN HARDER than getting kernel, which I already think is impossible. Even at kernel, it seems to be over my skill limit, but this would definitely be above me, and someone with real skills would have to attack this. I’m thinking at least, decaps will have to be attempted here. If somehow this gets hacked, we may be able to run CFWs, but like the PS3 before the lv0, newer firmwares would not be able to be CFW’d until…

Bootloader? (lv0?)

Again, only conjecture at this point, but this is the holy grail, the final boss. Once this is compromised, the Vita would be “hacked” in every sense of the word. We may never get here (and by never, I mean maybe 5-10 years, but I would most likely not be working on the Vita at this point). Here’s is where I think the keys are stored. With this compromised, CFW of any past, present, or future firmwares could be created, and anything would be possible.

Summary

I guess to summarize, the reason there’s no release in the foreseeable future isn’t just because I don’t have time to make an sdk so there won’t be homebrews to use even if UVL is released. Even if the SDK does get done, at this point, it would be more attractive to use the control we currently have, double down, and try to get more control. If the exploit is revealed prematurely, getting the game pulled, and the firmware patched, sure we may get a fast N64 emulator in a couple of months when somebody has the chance to write it (and at that point, most people might be enticed to upgrade anyways for new firmware features and PSN access), but we will have to start at square one (read above about finding userland exploits) before having another chance at exploring the full potential of the system. Deep down, I am a researcher, and would have more interest in reversing the system than I would at making a release for users just so I could be the “first”. Like all gambles, I may end up with nothing, but that’s a risk I’m willing to take.

[April Fools] Electronic Arts Inc. announces the closing of Yifan Lu

KATY, Texas, Apr 01, 2012 (BUSINESS WIRE) — Electronic Arts Inc. (NASDAQ: ERTS) today announced it will be permanently closing it’s doors at Yifan Lu. “The hardest part of my job is laying off employees. That and making games. Shit’s hard, we should start doing that soon.” commented EA CEO John Riccitiello in an earnings call following the announcement of the cuts. “It was tough having to get rid of such an awesome guy, but because of the drops of profits caused weak game sales (which was in correlation to the increase in the IQ of an average video game buyer), we had to make difficult decisions.” Yifan Lu has been responsible for hit titles such as TBA, Coming Spring 2013, and Project Canceled.

[April Fools] Yifan Lu has been acquired by Electronic Arts Inc.

KATY, Texas, Apr 01, 2012 (BUSINESS WIRE) — Electronic Arts Inc. (NASDAQ: ERTS) today announced it has acquired Yifan Lu, a leading innovator and badass for $4.95 USD and two chicken sandwiches. The acquisition accelerates EA’s position in popular appeal and strengthens its focus on the destruction of gaming. Yifan Lu will operate within EA Sports, a division of EA focused on changing logo text.

Unlocking T-Mobile 4G Hotspot (ZTE MF61): A case study

So, I have one of these MiFi clone from T-Mobile and want to unlock it to use on AT&T (I know that AT&T 4G/3G isn’t supported, but I thought maybe I could fix that later). The first thing I tried to do was contact T-Mobile, as they are usually very liberal concerning unlock codes. However, this time, T-Mobile (or, as they claim, the manufacture) isn’t so generous. So I’ve decided to take it upon myself to do it. I will write down the entire procedure here as a case study on how to “reverse engineer” a new device. However, in no way do I consider myself an expert, so feel free to bash me in the comments on what I did wrong. Also, I have decided against releasing any binaries or patches because phone unlocking is a grey area (although it is legal here), but if you read along you should be able to repeat what I did, even though I will also try to generalize.

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 0x3500000, 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 == 0x1801210. 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.

Playstation Vita’s USB MTP Connection Analyzed

This is the first of (hopefully) many posts on the PS Vita. Before I attempt anything drastic with the device, such as getting unsigned code to run, I hope I can try something easy (well, easier) to get used to the device. Ultimately, I want to make a content manager for the PS Vita for Linux. Unlike the PSP, the Vita does not export the memory card as a USB storage device, but instead relies on their custom application to copy content to and from the device. This post will give just a peek into how the communication between the Vita and the PC works.

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 0x2 is for input, while 0x81 is for data output, and 0x83 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
Also, I’ve compiled a list of MTP operation codes for the Vita that are referenced in CMA (and therefore implemented in the Vita). Note that some of the codes are not in the standards while others are. For events, the second number is for reference with regards to the jump-table inside CMA only.


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)

Commands:
0x1001: GetDeviceInfo
0x1002: OpenSession
0x1007: GetObjectHandles
0x1008: GetObjectInfo
0x1009: GetObject
0x100C: SendObjectInfo
0x100D: SendObject
0x101B: GetPartialObject
0x9511: GetVitaInfo
0x9513: SendNumOfObject
0x9514: GetBrowseInfo
0x9515: SendObjectMetadata
0x9516: SendObjectThumb
0x9518: ReportResult
0x951C: SendInitiatorInfo
0x951F: GetUrl
0x9520: SendHttpObjectFromURL
0x9523: SendNPAccountInfo
0x9524: GetSettingInfo
0x9528: SendObjectStatus
0x9529: SendHttpObjectPropFromUR
0x952A: SendHostStatus
0x952B: SendPartOfObject (?)
0x952C: SendPartOfObject (?)
0x952E: OperateObject
0x952F: GetPartOfObject
0x9533: SendStorageSize
0x9534: GetTreatObject
0x9535: SendCopyConfirmationInfo (?)
0x9536: SendObjectMetadataItems
0x9537: SendCopyConfirmationInfo (?)
0x9538: KeepAlive
0x9802: ?
0x9803: GetObjectPropValue
0x9805: GetObjectPropList

Response:
0x2001: OK
0x2002: GeneralError
0x2006: ParameterNotSupported
0x2007: IncompleteTransfer
0x200C: StoreFull
0x200D: ObjectWriteProtected
0x2013: StoreNotAvailable
0x201D: InvalidParameter
0xA002: ?
0xA003: ?
0xA004: ?
0xA00A: ?
0xA00D: ?
0xA008: ?
0xA010: ?
0xA012: ?
0xA017: ?
0xA018: ?
0xA01B: ?
0xA01C: ?
0xA01F: ?
0xA020: ?
0xA027: ?

Data Types:
0xDC01: StorageID
0xDC02: ObjectFormat
0xDC03: ProtectionStatus
0xDC04: ObjectSize
0xDC05: AssociationType
0xDC07: ObjectFileName
0xDC08: DateCreated
0xDC09: DateModified
0xDC0A: Keywords
0xDC0B: ParentObject
0xDC0C: AllowedFolderContents
0xDC0D: Hidden
0xDC0E: SystemObject
0xDC41: PersistentUniqueObjectIdentifier
0xDC42: SyncID
0xDC43: PropertyBag
0xDC44: Name
0xDC45: CreatedBy
0xDC46: Artist

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.

Welcome to the new yifan.lu!

It’s a new year, and I’m a bit tired of the old design. There were some main problems with it besides the looks though. The biggest one is I never wrote a backend for my “projects” list, so every time I add a new project, I’m doing it manually by uploading the files via FTP and adding the entry in phpmyadmin. In addition, I’m sure there were tons of PHP bugs and security holes that I had in the old script. The old theme was also badly coded with many HTML errors and many WordPress incompatibilities.

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.

Kindle Touch (5.0) Jailbreak/Root and SSH

Update Kindle 5.0.3 has fixed the hole to allow for jailbreak. Upgrading an already jailbroken Kindle Touch is fine as the update does not remove the custom key to allow custom packages. If you on 5.0.3 and have not already installed the key, there is a new jailbreak.

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

Reversing the Xperia Play emulator (part deux)

The last time we spoke, I managed to run any PSX game on the Xperia Play by redirecting some function calls. Well, since then Sony (you could say) fixed it (still don’t know how, I should look into it one day, I’m guessing they revoked the certificates for Crash Bandicoot) and people running Android 2.3.4 on the Xperia Play can’t use PSXPeria anymore. I’ve re-patched it a while ago, but never got the chance to modify the patching tool to use the new method (I really hate Java and don’t want to use it, so I held back.) until today. As customary to my releases, I will begin by telling more than what you want to know about how it works.

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

Analyzing Kindle 4.0

Well, Amazon might as well have stolen my wallet, because I am going to lose a couple hundreds of dollars. However, what fun is a Kindle if we can’t run our own code? (Answer: still pretty fun, but that’s besides the point.) Anyways, I haven’t gotten my hands on the new Kindles yet, but I got the next best thing: a software update from Amazon (http://www.amazon.com/gp/help/customer/display.html/?nodeId=200774090)

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 0x140 bytes) and change “FC04″ to “FC02″ (Bytes 0x0 to 0x4 after trimming the signature header). Now delete 4 bytes starting from 0x8 and 6 bytes starting from 0x10. (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).