Latest Posts

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 the jailbreak here

Simple custom screensaver mod

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

GUI menu launcher and screen rotation hack


kindle-touch-jailbreakKindle 4/Touch Jailbreak


What does the jailbreak do? All it does is open the door to unsigned modifications by installing a developer key into the device. It does not modify any existing files and it only writes one new file.
It does NOT do anything useful or noticeable other than this. You must find and install modifications that extend the device (the jailbreak only allows that to be possible.)

This jailbreak works on the Kindle 4 and Kindle Touch. If you have a Kindle 3, Kindle 2, or Kindle DX, check out my jailbreak for these older devices.

Thanks to ixtab for finding out this method of jailbreaking.

After installing the jailbreak, there is NO side effects at all (battery life, stability, etc). However, because you are no longer limited to Amazon’s sandbox, you could potently damage your device by installing modifications that are improperly coded or by incorrectly using the modifications. Just a warning.


This jailbreak is designed for usage on both the Kindle 4 and Kindle 5 (Touch) and packs in three different methods of jailbreaking into one package. Please follow the methods in order if one doesn’t work.

Method 1:

  1. Plug in the Kindle and copy “data.tar.gz” to the Kindle’s USB drive’s root
  2. Safely remove the USB cable and restart the Kindle (Menu -> Settings -> Menu -> Restart)
  3. After the Kindle restarts, you should see a new book titled “You are Jailbroken”, if you see this, the jailbreak has been successful. If you DON’T see this, continue.

Method 2:

  1. Restart the Kindle again (Menu -> Settings -> Menu -> Restart)
  2. After the Kindle restarts, you should see a new book titled “You are Jailbroken”, if you see this, the jailbreak has been successful. If you DON’T see this, continue.

Method 3:

  1. Plug in the Kindle and copy “data.tar.gz” to the Kindle’s USB drive’s root
  2. Create a blank text file named “ENABLE_DIAGS” and save it on the Kindle’s USB drive’s root
  3. Remove the USB cable and restart the Kindle (Menu -> Settings -> Menu -> Restart)
  4. Once the device restarts into diagnostics mode, select “D) Exit, Reboot or Disable Diags” (using the touchscreen or 5-way keypad)
  5. Select “R) Reboot System” and “Q) To continue”
  6. You should restart back into diagnostics mode, select “D) Exit, Reboot or Disable Diags”
  7. Select “R) Reboot System” and “Q) To continue”
  8. You should restart back into diagnostics mode, select “D) Exit, Reboot or Disable Diags”
  9. Select “D) Disable Diagnostics” and “Q) To continue”

If you wish to run a shell script after the jailbreak process, create a file named “” on the root of the Kindle’s USB partition. Use this like a regular shell script. Make sure to remount root as read-write if you plan to modify the file system. It is safe to run the jailbreak multiple times.

Important Notices

  • Packages on the Kindle Touch cannot work on the Kindle 4 as is and vice versa!
  • Again, the jailbreak itself does NOTHING except open the door for other packages.
  • Do not expect the jailbreak to remove ads, I don’t know why so many people ask me that.
  • If you have a Kindle Touch, you should try some of my Kindle mods: SSH (see usbnetwork in downloads below), custom screensavers, and GUI launcher (including screen rotation).

Installing Packages

You should NOT copy any packages until AFTER the jailbreak is successful. To install a package that you obtained as a .bin file, copy it to the Kindle’s USB drive’s root. Then go to Menu -> Settings -> Menu -> Update Your Kindle to install.


If you wish to uninstall the jailbreak, it is recommended that you first uninstall all packages first because you cannot run any other uninstallers after removing the jailbreak.

  1. Plug in the Kindle and copy the uninstaller .bin for your device to the Kindle’s USB drive’s root (update_jailbreak_X.Y_k4_uninstall.bin = Kindle 4, update_jailbreak_X.Y_k5_uninstall.bin = Kindle Touch)
  2. Safely remove the USB cable
  3. On the device, go to Menu -> Settings -> Menu -> Update Your Kindle


Development for the Kindle is usually done in one of two ways.

Java Kindlets

Kindlet is the “official” way of writing Kindle applications. These are known as “Kindle Active Content” and are written in Java either using the official SDK or unofficially imported JARs.

More information on writing unofficial Kindlet

After creating your Kindlet, you must sign it with the jailbreak Kindlet key to run it on any Kindle that installed this jailbreak.

With the official SDK, to use the jailbreak Kindlet key:

  1. Open up Eclipse
  2. Open up “Workspace Preferences” in Eclipse
  3. Select the “Kindle Active Content” item
  4. Set the “Keystore Path:” to the “developer.keystore” file found in the “keys” directory of this package
  5. Set the “Keypass:” to “password” (without the quotes)

To manually sign your Kindlet JAR, use the following commands:

jarsigner -keystore /path/to/developer.keystore -storepass password JAR_FILE Kindlet
jarsigner -keystore /path/to/developer.keystore -storepass password JAR_FILE KindletInteractionSupport
jarsigner -keystore /path/to/developer.keystore -storepass password JAR_FILE KindletNetworkSupport

where /path/to/developer.keystore is the actual path to the “developer.keystore” file found in the “keys” directory of this package and JAR_FILE is the name of your Kindlet JAR.

Other Apps

Any other ARM Linux application (Linux ELFs, Shell Scripts, etc) can be installed to the device using a signed update package. This is more advanced, and the developer should take care of startup scripts, framebuffers, GUI, etc. All Kindles run the Linux 2.6 kernel and contains all standard GNU libraries.
To cross compile ARM Linux code, you must use a toolchain. Below are two examples of ARM toolchains that you could use: (There is evidence that Amazon uses this) (I personally use this)

After creating your native application, you can install it on any jailbroken device by creating an update package. It is recommended that you use a packager such as my Kindle Tool (see the project link for more information) to generate these packages. To make an installer package, create a shell script named anything (.sh) in a directory containing all the files in your update. This script will run as root on the Kindle when your update package is installed, so use it to add, remove, or modify files. The working directory for the script is the same directory that the script is in, so everything in the input directory passed to Kindle Tool will be in the update.
If you wish to manually sign update packages (no information is provided, check the Kindle Tool source if you’re curious), the RSA private key for signing jailbreak update packages is provided in the “keys” directory of this archive under “updater_key.pem”.

Also, here is the original Kindle Touch MP3 jailbreak for archival purposes.


  • 2012-01-28: Update for Kindle Touch 5.0.3 support and Kindle 4 support.
  • 2011-12-09: First release.

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/” 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:, 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.


Project Page

facetime_surveillanceFaceTime Surveillance

This script will listen for FaceTime calls every minute. If it finds one, it will auto-accept the call and mute the system. Once the call ends, it will kill FaceTime (so the camera doesn’t stay on) and turn the volume back on. This is great for allowing you to always check your Mac’s camera when you are away with a simple FaceTime call.

IMPORTANT: Make sure your OSX’s FaceTime email is secret, or random people can call you.

If you want to run this in the background and on startup, download iBackground Scripts, save the script as an application, and run iBackground Scripts on it. Then you can set the application as startup.


  • 2010-10-22

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 (

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 “” 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 “” 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).

Installing Windows 8 Developer Preview (8102) on a USB Drive (Windows To Go/Portable Workspace)

This really isn’t some technical or hard to do thing, but it’s a cool little trick I found that I haven’t seen mentioned before. If you don’t know what “Windows To Go” (previously “Portable Workspace”), watch this video from the Build 2011 conference. Basically, it allows you to install a full copy of Windows 8 onto a USB drive/external hard drive and use it on any computer that supports USB booting. Your settings, files, programs, etc go where-ever you go. The feature is in Windows 8 (and the developer preview), but the program to make the drive is not. Luckily, an old leaked build has the program, but you can’t just copy and paste it, it won’t run. Instead, follow the directions below to get Windows 8 installed to a USB drive. (I used a virtual machine to do the following, therefore I did not need to burn any DVDs. I will give the directions assuming you’re using a real computer though).


  • 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)
  1. Install Windows 8 M1 build 7850. (I tried just copying pwcreator.exe and running it on a later build, but it didn’t work.)
  2. Open the start menu and type in “pwcreator.exe” and press enter. Alternatively, find and open C:\Windows\System32\pwcreator.exe
  3. Choose your USB drive and continue.
  4. Insert the Windows 8 M1 build 7850 DVD again and continue.
  5. Before starting the build process, take out the Windows 8 M1 build 7850 DVD and insert your Windows 8 Developer Preview build 8102 DVD.
  6. Continue and allow the process to finish.
I tested it with the x86 version of the Developer Preview, so I don’t know how well or if it will work with the x64 build. When you are asked to activate Windows, you can skip it or enter one of the keys found in the Developer Preview DVD under D:\Sources\product.ini (assuming D: is your DVD). I haven’t figured out which key to use yet.
Also, the requirements in pwcreator.exe states that you need a 16GB USB drive. However Windows only really need 12GB to install. I have a 16GB flash drive that shows up as 15GB and it wouldn’t work. I used GParted in Ubuntu to copy the partitions from a larger USB drive over after creating the image and it works fine. Just a tip.

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.

PSXperia: Converts any PSX game to work on Xperia Play

After two hard weeks of decompiling, reverse engineering, graphing, and coding, I’m proud to announce PSXperia, a set of tools to extract, patch, and repack the Crash Bandicoot game that comes with all Xperia Play phones to use any PSX game (that you legally own). In addition to allowing you to play any property ripped PSX game, you can also set a custom icon and the game will show up in the phone’s Playstation Pocket app, so you can quickly access it when you flip the gamepad out. I’ve converted and tested 8 games with this tool and they all run flawlessly, but if things don’t work out so smoothly for you, submit your issues to GitHub.

Download the program here and the source here
Setup and usage guide here
Support here
Bug reports here


This tool will take a PSX image that you legally own and convert it to be playable on the Xperia Play with the emulator extracted from the packaged game “Crash Bandicoot.”

To build, you need to copy the following to the “lib” directory
* apktool.jar from
* commons-io-2.0.1.jar from
* sdklib.jar from Android SDK (under tools/lib)
* swing-layout-1.0.4.jar from Netbeans (under platform/modules/ext)

You also need a copy of “aapt” from Android SDK (under platform-tools)
* OSX version named aapt-osx
* Windows version named aapt-windows.exe
* Linux version named aapt-linux
Put these in the “resources” directory

Finally, you need my PSXperia wrapper library (compiled) in the “resources” directory

To run the GUI, use “java -jar PSXperiaTool.jar”
To run the command line tool, use “java -cp PSXperiaTool.jar com.yifanlu.PSXperiaTool.Interface.CommandLine” to see usage directions, which is also listed below for your convenience.

Extract and patch data files
psxperia e[x]tract [-v|–verbose] input.apk input-data.zpak output
[-v|–verbose] Verbose output
input.apk Either or
input-data.zpak Either NCUA94900_1_1.zpak or NCEA00344_1_1.zpak (must match region of APK)
output Directory to extract the files

Convert ISO to Xperia Play APK and ZPAK
psxperia [c]onvert [OPTIONS] titleId image.iso output
titleId An unique ID, usually from the game in the format NCXAXXXXX_1
image.iso Input PSX image. You must rip it on your own!
output Directory to output files
Options (unset options will be set to defaults):
-v|–verbose Verbose output, including image creation progress
-D directory Custom location for extracted data files, default is “./data”
–load-xml Load options from Java properties XML
–game-name Name of the game
–description Description of the game
–publisher Publisher of the game
–developer Developer of the game
–icon-file Path to image for icon
–store-type Where to find this title (any string will do)
–analog-mode true|false, Turn on/off analog controls (game must support it).

Convert to ISO
psxperia [d]ecompress [-v|–verbose] output.iso
[-v|–verbose] Verbose output from ZPAK
output.iso ISO file to generate


  • 2011-08-11


Page 4 of 11« First...23456...10...Last »