Summary
The kindles have a "Magic Bullet" that will ALWAYS allow custom code to be installed on them, including anything from just adding a jailbreak key, custom screensaver or custom fonts, all the way up to installing a completely different operating system on them, like Android OS. These tools already exist and we know how to use them. Simple step-by-step instructions will be provided, along with custom partition images that already contain the custom changes that we want.
Why Not Fastboot Mode?
Up until now, I was thinking that because fastboot is TOO powerful (and therefore too dangerous for beginners) that we should avoid it and use the tools that amazon provided us as much as possible, as close to their default configuration as possible. That means using as simple a method as possible to install custom code onto the kindle.
Jailbreak
Because all kindle models are able to install signed update packages, the normal jailbreak procedure adds a custom key so that developer-signed update packages can be installed using the "Update your kindle" menu item, just as though they were amazon-signed update packages. These developer-signed updates contain installation scripts that run during the installation, and can make any changes to your kindle including adding new screensavers, new fonts, or even USB networking so you can use SSH to get a root shell.
Rooting
The real problem when a kindle model comes out, or a new firmware update for existing kindles, is how to get that custom key installed onto the main system root partition in the first place. That requires a lot of research to locate a method of gaining root access (usually calling "rooting" the device) so that custom code can be run. For kindles, the first thing that rooting it does is to install the custom key, so that user-selected custom apps can be installed using developer-signed updates.
On the new k4 (kindle mini), it turned out that root access was provided directly in the USBnet menu item in diags. Just add ENABLE_DIAGS to the USB drive and reboot, then enable USBnet from the diags menu and use SSH to get a root shell. With a root shell, you can make any changes you want and install any programs you want. One of the first things you want is to copy the dropbear files from diags to main so you can use SSH to get a root shell when booted from main. Another thing you want is to install the custom key so that developer-signed updates can be installed from the "Update your kindle" menu, just like all the other kindles.
For the Touch, things are a little different than the K4, because diags is missing files needed to allow SSH when you enable USBnet from the diags menu. In that case it was necessary to find a bug to exploit. The first one found was the "MP3 bug" that allowed a specially designed MP3 file to execute code that it contained. This was used to create the MP3 Jailbreak, that installed the custom key so that developer-signed updates can be installed from the "Update your kindle" menu.
Firmware Updates
Then firmware version 5.0.3 came out, which fixed the MP3 bug, so a new method was needed to jailbreak new kindles that come with 5.0.3 firmware. The replacement jailbreak uses the current "tar root path bug", which uses data.tar.gz to install custom code to writable locations but does NOT execute this custom code. It was necessary to study the startup scripts to locate locations where custom code could be written by data.tar.gz AND to find a method to trigger execution of that code. Multiple places were found in /var/local that can contain custom script code that gets executed during startup. The first location used was /var/local/system/locale, but this only worked on the touch, and only when booting from main.
The search continued for other locations and trigger methods, in case new firmware disables the existing method. Multiple locations and trigger methods were discovered, some of which only work in main, and some only in diags, and some only on the Touch, and others on the K4. The one we will use in this thread is the "/var/local/system/mntus.params" payload script. This one is particularly powerful because it runs on the Touch in both main and in diags, and it runs on the K4 in both main and in diags, and it runs on the K3, and DX and DXG. Besides this particular payload destination being powerful, it is also dangerous. If you use a mntus.params designed for a different kindle model, it can make the startup scripts erase your USB Drive. If you make even a small mistake when using it to run custom code, it can brick your kindle severely so that you cannot boot to main or diags, and you cannot access the USB drive. In this case, only "USB Downloader" mode can access it. It can be deployed on the K4 and Touch in a data.tar.gz file.
USB Downloader Mode and the Magic Key
We can get to USB Downloader mode by plugging in the USB cable so the power LED is on, then holding the power button until the LED turns off, then before releasing the power button we need to hold the "Magic Key" while releasing the power button. Each kindle model has a different "Magic Key" (what it is actually called in the source code). The Touch uses the Home button (its only button) as the Magic Key. The K4 uses the Five-way Down button as the Magic Key. The K3 uses the Volume Down button (Vol-) as the Magic Key, but it also uses a different VID/PID and needs a different tool to communicate with it.
As we learned more about USB Downloader mode, what we called it kept changing. In these forums it can be called "USB HID" mode (because that is how it appears in Windows Device Manager), and it can be called "USB Recovery" mode (because that is what we want to use it for), but in the manufacturer documentation they call it "USB Downloader" mode (which is the official name for it). When in USB Downloader mode, the K4 and Touch appear to be a USB HID device with VID/PID 0x15a2/0x0052. Special software that can be downloaded from the manufacturer website (freescale.com) can communicate with a kindle using that VID/PID. The software that we use in this thread is called "MfgTool". It allows many things, including writing new firmware to the mmc storage device. But we use it to load and execute custom code in the kindle RAM memory. In this thread, we use custom u-boot bootloader code to select which bootmode we want and to boot to that mode. The bootmodes provided here are main, diags, and fastboot. For a kindle bricked so badly that it can only boot to fastboot mode, we need to repair it either using MfgTool (which works in USB Downloader mode) or we can repair it in fastboot mode using the kindle fastboot tool.
Fastboot Mode -- Why Use It?
It is a lot faster and easier to use the fastboot tool which does everything with command line parameters, than to use MfgTool, which can do many of the same things as fastboot, but requires custom XML files to configure each and every thing you want to do. Fastboot is easier, so we will use that. We only use MfgTool to boot to main, diags, or fastboot mode.
Fastboot is very powerful, and can easily erase or reprogram anything or everything in your kindle mmc storage device (including the USB drive, and the main firmware, and the diags firmware). Where the danger lies is that it can even destroy the part of the firmware that the fastboot tool talks to, making even fastboot no longer work. In that case you can fall back to MfgTool, which will ALWAYS work, because it ONLY relies on features built into the CPU chip (iMX50 SoC). That makes fastboot somewhat less dangerous, because even if you disable fastboot support by using fastboot incorrectly, you can ALWAYS recover your kindle with MfgTool. With MfgTool as a backup method, we can feel less fear using fastboot.
So, the reason for using fastboot in the first place is when a kindle is bricked so it cannot boot to main or diags, but can still boot to fastboot, we can use fastboot to repair our kindles. And even if we damage it so fastboot no longer works, then we can EVENTUALLY develop custom XML files so that we can use MfgTool to repair fastboot mode, so that we can again use fastboot mode to repair our kindles.
The Power of Fastboot
Fastboot can write an image file to the main partition, and to the diags partition, and to the data partition. It can also write new bootloader code, which if done incorrectly can disable fastboot as mentioned above. But, (and this is the breakthrough realization that just occurred to me this evening) the data partition contains the USB drive that is the normal way of getting content onto the kindle.
The real breakthrough idea here is that when you need to get a special data.tar.gz and RUNME.sh onto your kindle when you cannot access the USB drive, you CAN put those files on the USB drive using fastboot! How? Create an image file in vfat format that contains those files, then flash it to the data partition using fastboot. It is that easy!
And we can even use fastboot to flash custom main or diags partition images, which are backup images of official partitions to which extra files have been added, such as the custom jailbreak key, and missing SSH files, and anything else you want like custom screensavers and custom fonts. There is no need to install anything, and it does not matter if the preinstalled factory firmware has ALL bugs fixed so that it cannot have custom code added by any other method. This way will always work as long as fastboot is not disabled by amazon, and even then, MfgTool can still be used to install custom code onto the kindle, just like the fastboot tool but a little more complicated to configure. Of course, after MfgTool XML config files are created, they can be used many times.
A Permanent Solution
The only way that amazon can prevent us from installing custom firmware is if they disable "unlocked" USB Downloader mode on new kindles, so that only firmware signed with their official (secret) key can be flashed to the mmc storage device. According to the manufacturer documentation, it appears that the CPU SoC comes from the factory in the "encrypted firmware" mode, and an internal fuse must be permanently burned when it is first configured, to allow unencrypted (open) firmware to be flashed like the kindles now support.
That means that any kindle that can now run custom code will ALWAYS be able to run custom code. Only NEW kindles can be locked to prevent this by NOT burning the fuse that allows custom code. The K5 u-boot source code includes support for multiple kindle models, including a future model that uses signed firmware packages, so some future kindle model may prevent flashing firmware images. In that case, we will have to return to our current method of exploiting bugs to gain root access.
What's in it for Me?
My kindle is now in "fastboot only" mode (it cannot boot main or diags, and has no USB drive access). It is this way because mmcblk0p3 contains a damaged mntus.params file, and I do not know how to fix this using fastboot. I know that the bricking happens because mntus.params does not exit back to the script that sourced it AFTER the RUNME.sh script is called. I can use a DIFFERENT RUNME.sh script to repair the damaged mntus.params file (by replacing or deleting it, or by destroying mmcblk0p3). But I cannot add those files to my USB drive by ordinary methods. If the problem had been to the main partition, it could have been repaired by booting to diags. But it is on mmcblk0p3, and I do not know how (or if) I can use fastboot to reflash that partition.
So I will use what I do know how to do. I will create a USB drive image file that contains the RUNME.sh file I need to repair it, and the data.tar.gz file I need to launch that RUNME.sh file. I will use fastboot to write that image file to the data partition. Then I will reboot to diags mode. At this point, I believe that this will do the job.
What's in it for You?
Even if mmcblk0p3 AND main and diags were ALL damaged, we can use fastboot to write repaired (original) images to main (system) and diags partitions, and a custom USB drive image to the data partition, that contains a RUNME.sh and data.tar.gz to repair mmcblk0p3. This worked for me to repair my K4 when it was bricked, but there are reports of problems flashing firmware images to a Touch using fastboot. This can be overcome by using a bist (built-in self-test) build of u-boot for the MfgTool Profiles, that includes "fixed" fastboot code (if it has any bugs to fix).
The Grand Conclusion
So, good news all around. Not just for me, but for everybody. Yes? Let's hear some feedback! At a bare minimum, the kindles recharge their batteries a lot faster in fastboot mode, so it is at least useful for that.
EDIT: Since this was written, we discovered a size limitation that prevents fastboot from writing large image files such as the main system partition (mmcblk0p1). I debricked my kindle touch, and many others have successfully debricked their kindles as well, by using fastboot to write the smaller diagnostics partition (mmcblk0p2) from an image containing SSH preinstalled, then boot to diagnostics mode and write the larger main system partition from a backup image using the linux "dd" command. This method of restoring a bricked kindle back to health has been greatly simplified from previous methods, and is documented in the "simple kindle touch (and k4nt) debricking method" thread:
https://www.mobileread.com/forums/sho...d.php?t=170929
UPDATE: There is now a fastboot for windows:
https://www.mobileread.com/forums/sho....php?p=2001690