After a month and a half of testing thanks to the community of MobileRead, I can finally release the first stable version of the Kindle 3.X software updater (help me come up with a better name, please). If you haven’t read my last few Kindle-related posts (read them if you want more technical details of this script), you should know that this allows you to use all the cool new features of the Kindle 3 on a K2 or DX device. Installation is easy and is only three steps: 1) Use “prepare-kindle” script on old Kindle to back up and flash recovery kernel, 2) Copy generated files to Kindle 3 along with “create-updater” script and run it, 3) Copy generated update package back to old Kindle and restart. If that sounds confusing, don’t worry, the readme contains very detailed directions and even how to recover in case anything goes wrong. Speaking of recovery, a “side effect” of using this is that the custom kernel that you flash in order to run the update package allows recovering without a serial cable and the installation of unsigned recovery packages.
Oh, and in case anyone is wondering why I’m not just distributing a full 3.X update package and making you generate it by yourself, it’s because the Kindle framework and OS are proprietary code. I believe that Amazon didn’t release 3.0 for the DX and K2 because they don’t want to lose business for the Kindle 3. So, by making you have a Kindle 3 in order to use this, I can keep Amazon happy.
I was bored one weekend and decided to jailbreak the new Kindle firmware. It was time consuming to find bugs, but not difficult. Unlike the iPhone, the Kindle doesn’t really have security. They have a verified FS and signed updates and that’s it, but I will still call my jailbreak an “exploit” just to piss you off. Previous Kindle 3 jailbreaks worked (AFAIK, I haven’t really looked into it) by tricking the Kindle into running a custom script by redirecting a signed script using a syslink. This worked because the updater scans only “files” that do not end with “.sig” (signature files to validate the file). They fixed this now by scanning all non-directorys that do no end with “.sig”. This is the first bug I’ve exploited. Part one is getting the files into the update, which I did by conventionally renaming them to “.sig” even though they’re not signature files. Part two is harder, getting the unsigned script to run.
How the Kindle updater works is that first it gets a list of all files (including files in subfolders, excluding signature files) in the update and checks it’s signature with Amazon’s public keys. If you modify any of the scripts from a previous update, the signature is broken and the Kindle won’t run it. If you add your own scripts, you can’t sign it because you don’t have Amazon’s keys, and finding them would take more then the lifespan of the universe. (SHA256 HMAC). They also use OpenSSL to check the signatures, so trying to buffer overflow or something is out of question (or is it? I haven’t looked into it). Afterwards, when all files are matched with their signatures and checked, the updater reads a “.dat” file which contains a list of all scripts, their MD5 hash and size (to verify, I don’t see the point since they were just signature checked. Maybe a sanity check?). It finds the “.dat” file using “find update*.dat | xargs” which means all the .dat file has to be is start with update and end with .dat. They don’t care what is in between. Next, they read the file using “cat” and with each entry, verify the hash and loads the script. Well, conventionally, “cat” can read multiple files if more then one filename is given in the input. This means if the update*.dat file contains spaces, then “cat” will read every “filename” separated by a space. I took a signed .dat from one of Amazon’s update. Renamed it “update loader.sig .dat” and placed my actual .dat (containing an entry to the script jailbreak.sig, a shell script renamed) in loader.sig. jailbreak.sig untars payload.sig, a renamed tgz file which contains the new keys we want to use to allow custom updates. Amazon’s updater only signature checks “update loader.sig .dat” which is valid. Then cat tries to read the files “update”, “loader.sig”, and “.dat”, one of which exists and the others silently fail. Loader.sig points to the script jailbreak.sig which the updater happily loads thinking it’s already signature checked. Jailbreak.sig, calls tar to extract payload.sig and copies the new keys to /etc/uks and installs a init.d script to allow reverting to Amazon’s keys for installing future updates. Now we own the system again!
A download to the jailbreak can be found here. Directions are provided in the readme file. Use it at your own risk (I’m not responsible if you somehow brick it) and note that it most likely will void your warranty. Make sure to uninstall all custom updates before you uninstall the jailbreak, as after uninstalling the jailbreak, you cannot run custom packages until you jailbreak again. Directions for switching between custom updates and Amazon updates can be found in the readme file.
Here’s another one of my famous 3-hour-projects. I finally decided to cleanup my email. It’s too hard to “clean”, so I decided to start from scratch by making a new email account. So, I made a Google Apps account. Google Apps is a great product, but one thing missing is registration for users. (You must make an account manually for your user) So, I decided to make one myself. This PHP script acts as a proxy between you and Google Apps. It allows your users to create their own account with you and your Google Apps. It is composed of a backend and a frontend. The backend does the work of taking your admin credentials and form data from a user and creating an account for the user. The frontend hosts the GUI. I made sure to well-comment the code, so it should be easy to create your own frontend to match the style and code of your site. I’m probity won’t work on this project again, but because it’s released under GNU v3 (as all my projects), you can take it and add on to it.