MobileRead Forums - View Single Post - [Progress] Jailbreaking Kindle 4.0 (Touch/No Keyboard)

yifanlu · 11-14-2011, 05:58 PM

As I've predicted, the days of unix filesystem/shell gliching is over. We must now find real exploits. I've spent the last few days exploring various binaries and system files and I've come up with a list of potential exploit vectors. I've listed them from most likely to least likely.

The thing we need to look for is for a part of the kindle that 1) accepts user input. Aka, reads files from the FAT32 partition. 2) Runs natively (no java involved, that's 95% of the Kindle OS). 3) preferably non-open source. Open source projects are usually very secure, as if an exploit exists, it would have been found long ago by smart people.

-PDF Reader. This seems like a great bet. The entire PDF library is a Java JNI library. /usr/java/lib/libAdobePDFReader.so and /usr/java/lib/libPDFReader.so. They are ~10MB total, so it would be easy to slip up somewhere. In addition, it is Amazon code (not open source). It also reads PDF files, a very complex file structure. There's bound to be a stack/heap/buffer overflow somewhere.
-libTopaz.so & libjniaudible.so. Found in the same dir as the pdf reader. These two are also amazon code, but there is less input to be read and the filesizes are small. However, there could be something there.
-/usr/bin/browserd. The Kindle webkit browser is actually a native code. The java frameworks "connects" to browserd through sockets and only feeds it urls and key input. I've spent most of my time analyzing this binary and I think it's a dead end. There are stack guards present and the only user input is URLs and a few files. None of the files have a complex structure and it reads them pretty straightforward. I did find 3 bugs in the binary, but none of them can lead to code execution. As someone mentioned, it uses an old version of webkit so we could use one of the many patched webkit exploits. I've tried a couple, but none of them worked. The kindle arch is very stripped down.
-Java framework - This is the GUI that you see. I'm sure there are tons of ways to crash the framework, but because of java's VM sandbox, most if not all are useless. I did stack overflow a couple of times but nothing useful came out of it.
-Linux filesystem - VERY unlikely. These files are pretty secure, but even worse, we don't really have access to any of them so if there is an exploit, we can't really feed data.

To have an idea of what to look for, here are some possible goals, from best bet to worse. Achieving any one of the following would make achieving the goals above it easier.

1) Running native code (duh)
2) Running a shell script/getting shell access
3) Writing to the root partition
4) Writing to the vars partition
5) Reading any partition other then the FAT32 one
6) Crashing native code
7) Crashing Java framework

Anyone else have any ideas?

11-14-2011, 05:58 PM	#63
yifanlu Kindle Dissector Posts: 662 Karma: 475607 Join Date: Jul 2010 Device: Amazon Kindle 3	As I've predicted, the days of unix filesystem/shell gliching is over. We must now find real exploits. I've spent the last few days exploring various binaries and system files and I've come up with a list of potential exploit vectors. I've listed them from most likely to least likely. The thing we need to look for is for a part of the kindle that 1) accepts user input. Aka, reads files from the FAT32 partition. 2) Runs natively (no java involved, that's 95% of the Kindle OS). 3) preferably non-open source. Open source projects are usually very secure, as if an exploit exists, it would have been found long ago by smart people. -PDF Reader. This seems like a great bet. The entire PDF library is a Java JNI library. /usr/java/lib/libAdobePDFReader.so and /usr/java/lib/libPDFReader.so. They are ~10MB total, so it would be easy to slip up somewhere. In addition, it is Amazon code (not open source). It also reads PDF files, a very complex file structure. There's bound to be a stack/heap/buffer overflow somewhere. -libTopaz.so & libjniaudible.so. Found in the same dir as the pdf reader. These two are also amazon code, but there is less input to be read and the filesizes are small. However, there could be something there. -/usr/bin/browserd. The Kindle webkit browser is actually a native code. The java frameworks "connects" to browserd through sockets and only feeds it urls and key input. I've spent most of my time analyzing this binary and I think it's a dead end. There are stack guards present and the only user input is URLs and a few files. None of the files have a complex structure and it reads them pretty straightforward. I did find 3 bugs in the binary, but none of them can lead to code execution. As someone mentioned, it uses an old version of webkit so we could use one of the many patched webkit exploits. I've tried a couple, but none of them worked. The kindle arch is very stripped down. -Java framework - This is the GUI that you see. I'm sure there are tons of ways to crash the framework, but because of java's VM sandbox, most if not all are useless. I did stack overflow a couple of times but nothing useful came out of it. -Linux filesystem - VERY unlikely. These files are pretty secure, but even worse, we don't really have access to any of them so if there is an exploit, we can't really feed data. To have an idea of what to look for, here are some possible goals, from best bet to worse. Achieving any one of the following would make achieving the goals above it easier. 1) Running native code (duh) 2) Running a shell script/getting shell access 3) Writing to the root partition 4) Writing to the vars partition 5) Reading any partition other then the FAT32 one 6) Crashing native code 7) Crashing Java framework Anyone else have any ideas?