MobileRead Forums - View Single Post

bulltricks · 08-29-2023, 02:12 PM

Jailbreaking, or even attempting to jailbreak embedded devices is a fun challenge, and you can learn quite a bit even if you are not successful.

From my standpoint, you end up needing three pieces:
1. The exploit - this is what gets you in the door to execute arbitrary code on the device
2. The persistence - so that after reboot, your code runs ... this takes caution because if you mess this up, the device can be toast without hardware intervention (which either isn't implemented, or isn't documented) on modern Kindles. KUAL will do this piece for you, which is why you can find people with jailbroken newer versions
3. The ecosystem - Fortunately, this is largely done for you, by using the existing KUAL - but there are necessary changes as some things change (for example, the location of the signing keys)

In general, and somewhat paradoxically, the best way to jailbreak a Kindle is to start with a jailbroken kindle. Amazon's position as market leader has led to a software ecosystem that has barely budged, so you are likely to be able to get an older device at say, a thirft store, that has the old version of the firmware; or be amenable to a hardware jailbreak -- then, with proper persistence can result in having a shell on a Kindle with the newest firmware, and 'gdb'

You can also use KindleTool to rip apart the firmware files, and extract the root file system - this is a Linux system. If you look around, you can even find instructions to run this with qemu or similar

Then, it's a matter of exploit hunting, which is both fun and frustrating. A good 'start' is looking at previous jaibreak write-ups to see where people have looked, and what they found.

From a rough high level breakdown ..
1. There are the bash scripts on startup - these have been picked over fairly well, but you can still find some unexpected behavior . The days of 'simple' jailbreak here seem to be gone

2. Linux binaries - here is where you look for 'system' or 'popen' in the many many binaries - this is where Ghidra comes in, to see whether something (eg, contents of a file in the user file system) can lead to a parameter to system

3. As a special case of Linux binaries, Webkit has had many vulnerabilities, and the Kindle version tends to be out-of-date. You may be able to use an old vulnerability -- but then you need to get out of the sandbox.. LIPC (Amazon specific IPC) can be a good way to escape the sandbox (see Kindledrip)

4. Then, there are Java binaries - Java can still shell out, and many of the Java applications use files in the user accessible storage I haven't dug into this much though

5. At an even higher level, there's Javascript -- if you can get execution control (eg, Mesquito), you have access to LIPC .. There's multiple javascript wrappers on the Kindle - the wap framework (mesquite) which restricts access to the LIPC API, and then there's the Pillow framework, which can do any LIPC accesses). Then you can look through the list of LIPC calls (which you can get if you already have a shell, but people have documented many of these) to see how to get execution..

08-29-2023, 02:12 PM	#4
bulltricks Enthusiast Posts: 29 Karma: 100000 Join Date: May 2023 Device: Kindle family	Jailbreaking, or even attempting to jailbreak embedded devices is a fun challenge, and you can learn quite a bit even if you are not successful. From my standpoint, you end up needing three pieces: 1. The exploit - this is what gets you in the door to execute arbitrary code on the device 2. The persistence - so that after reboot, your code runs ... this takes caution because if you mess this up, the device can be toast without hardware intervention (which either isn't implemented, or isn't documented) on modern Kindles. KUAL will do this piece for you, which is why you can find people with jailbroken newer versions 3. The ecosystem - Fortunately, this is largely done for you, by using the existing KUAL - but there are necessary changes as some things change (for example, the location of the signing keys) In general, and somewhat paradoxically, the best way to jailbreak a Kindle is to start with a jailbroken kindle. Amazon's position as market leader has led to a software ecosystem that has barely budged, so you are likely to be able to get an older device at say, a thirft store, that has the old version of the firmware; or be amenable to a hardware jailbreak -- then, with proper persistence can result in having a shell on a Kindle with the newest firmware, and 'gdb' You can also use KindleTool to rip apart the firmware files, and extract the root file system - this is a Linux system. If you look around, you can even find instructions to run this with qemu or similar Then, it's a matter of exploit hunting, which is both fun and frustrating. A good 'start' is looking at previous jaibreak write-ups to see where people have looked, and what they found. From a rough high level breakdown .. 1. There are the bash scripts on startup - these have been picked over fairly well, but you can still find some unexpected behavior . The days of 'simple' jailbreak here seem to be gone 2. Linux binaries - here is where you look for 'system' or 'popen' in the many many binaries - this is where Ghidra comes in, to see whether something (eg, contents of a file in the user file system) can lead to a parameter to system 3. As a special case of Linux binaries, Webkit has had many vulnerabilities, and the Kindle version tends to be out-of-date. You may be able to use an old vulnerability -- but then you need to get out of the sandbox.. LIPC (Amazon specific IPC) can be a good way to escape the sandbox (see Kindledrip) 4. Then, there are Java binaries - Java can still shell out, and many of the Java applications use files in the user accessible storage I haven't dug into this much though 5. At an even higher level, there's Javascript -- if you can get execution control (eg, Mesquito), you have access to LIPC .. There's multiple javascript wrappers on the Kindle - the wap framework (mesquite) which restricts access to the LIPC API, and then there's the Pillow framework, which can do any LIPC accesses). Then you can look through the list of LIPC calls (which you can get if you already have a shell, but people have documented many of these) to see how to get execution..