[Progress] Jailbreaking Kindle 4.0 (Touch/No Keyboard)

[yifanlu]

Good news everyone, I found a usable crash. I was able to crash cvm and smash the stack. However, gdb fails to behave on the Kindle, so I'm still trying to find the exact data of the stack (so I can write a payload). It also sucks because cvm does not dump the registers and stack on crash, so I have to manually dump the memory.

[Qxr]

Just would like to congratulate you with this achievement and express my respect to your skills. Thanks for all your efforts and goodwill in sharing your knowledge!

[ryran]

Rock ON!

[yifanlu]

Ok, here's another setback. The Kindle has "randomize_va_space" enabled, meaning that the stack is at a random memory location. This means we either have to find a way around this or brute force it, meaning keep restarting the kindle until it works.

[nealsharmon]

Looking forward to hearing of your results yifanlu!

[yifanlu]

Hmm, in order to defeat thr ASLR protection, we need to find a loaded instruction that jumps to SP. knowing that's impossible, we need to find an instruction that does that indirectly. Any ideas? But I'm getting ahead of myself. I still need a working shell code.

[dsmid]

Originally Posted by yifanlu

I'm going to throw some ideas around about a kindle packaging system.
...
Can developers give some feedback about this?

Some time ago I was thinking about the same thing.
My conclusion was almost the same as yours, with few differences.
I'd like to have two more hooks: install.sh and uninstall.sh .
Many hacks need to write to the root partition when installed (besides installing SysV service script), install.sh would offer install-time executed shell script,
uninstall.sh would be copied to a secure place when package is installed (renamed to /opt/packages/<package name>) and run when /mnt/us/packages/<package name>/ deletion is detected.
On each start the packaging system service would compare /opt/packages/ contents with /mnt/us/packages/ and run install (a new kid on the block) or renamed uninstall script (package deleted on US).

Copying to /opt/packages/ may appear as an unnecessary abuse of the root partition but it makes sense.
The users often try to solve their problems with hacks by making a factory reset, hoping it will rollback all changes made to their Kindle. That makes the situation even worse, leaving the hacks in an inconsistent state (true support nightmare).

If the package registry is protected from factory reset, the packaging system would be able to finish the uninstallation procedure of all hacks and make the Kindle clean of all hacks as desired (with the exception of the packaging system/jailbreak)

[Lorphos]

randomize_va_space picks one of only 8192 locations. Perhaps it can still be defeated? A format-string bug would be the ticket.

[yifanlu]

Originally Posted by dsmid

Some time ago I was thinking about the same thing.
My conclusion was almost the same as yours, with few differences.
I'd like to have two more hooks: install.sh and uninstall.sh .
Many hacks need to write to the root partition when installed (besides installing SysV service script), install.sh would offer install-time executed shell script,
uninstall.sh would be copied to a secure place when package is installed (renamed to /opt/packages/<package name>) and run when /mnt/us/packages/<package name>/ deletion is detected.
On each start the packaging system service would compare /opt/packages/ contents with /mnt/us/packages/ and run install (a new kid on the block) or renamed uninstall script (package deleted on US).

Copying to /opt/packages/ may appear as an unnecessary abuse of the root partition but it makes sense.
The users often try to solve their problems with hacks by making a factory reset, hoping it will rollback all changes made to their Kindle. That makes the situation even worse, leaving the hacks in an inconsistent state (true support nightmare).

If the package registry is protected from factory reset, the packaging system would be able to finish the uninstallation procedure of all hacks and make the Kindle clean of all hacks as desired (with the exception of the packaging system/jailbreak)

Could you give an example of rootfs usage other than copying an init script? I would rather manually implement anything that requires access to rootfs than let all scripts modify it. That's one of the main problems I have, after a while, I don't know what files on thr FS are modified. Especially since I lost the uninstaller scripts.

Originally Posted by Lorphos

randomize_va_space picks one of only 8192 locations. Perhaps it can still be defeated? A format-string bug would be the ticket.

I was thinking something along the lines of 1) push location of an instruction that copes SP pointer to another register, and pops stack into pc and 2) push location of instruction that jumps to said register. Then when the overflow runs it does two jumps.

[Ceuse]

Originally Posted by yifanlu

Good news everyone, I found a usable crash.

Did i tell you that i love you


keep on rocking. sadly i cant halp you with my crapy vbscript knolage

[yifanlu]

Ok, here's my idea. I'm writing it down so I don't forget. Basically we can control exactly where in the memory to jump to. The shellcode is in the stack, but the location of the stack is randomized. Therefore, we need to find where the stack is before we can jump to it. My idea is that after we overflow and overwrite the first LR pointer, we use that pointer to point to some code in the memory that does MOV R0, SP. (It would be very easy if we find BLX SP, but nobody with the right mind would ever put that in their code). Then we have the stack pointer in R0. Now, since we already control the stack, we just keep overwriting it so the next LR pointer that gets poped points to an instruction that calls BLX R0. This will jump to the stack and switch to thumb mode (shorter shell code in thumb mode).

[yifanlu]

Bad news everyone. I finally got my Kindle Touch in the mail, and so far, it looks like that exploit I found on the K3 and K4 does NOT work on the Touch. It may need some modifications or it may be fixed, but so far, I don't know as I can't get a log dump or anything. If anyone can dump the Kindle Touch rootfs, I would love to take a look.

[James D]

If it is offtopic then please sorry

Originally Posted by geekmaster

Regarding claim #1: You must agree to Amazon Terms of Service when you register an account with them. You cannot get 3G access on an unregistered kindle.
Regarding claim #2: Do you have any proof to backup your claims?
My 3G in the USA still lets me web browse anywhere. I just tried it. Perhaps 3G has been restricted in other countries OR some users have had their Amazon accounts restricted due to excessive bandwidth consumption. Can anybody here verify whether or not a renamed kindle "keyboard" has restricted 3G?

I repeat I did not agreed on any terms. I have not bought it yet. And I will not buy 3G version for Wikipedia only.
Proofs for what I claimed? I claimed about Touch version. About Kindle Keyboard I wrote that I think that it is also restricted.
Anyway I may tell you why do I have a feeling* that new Kindle Keyboard, not the previously called Kindle 3 3G.
"Use of Wireless Connectivity. Your Kindle uses wireless connectivity to allow you to shop for and download Digital Content from the Kindle Store. In general, we do not charge you for this use of wireless connectivity. Your Kindle may use wireless connectivity to make other services available to you for which we may charge you a fee, such as personal file download and subscriptions when you are located in another country.
Your Conduct. You may use the wireless connectivity provided by us only in connection with the Service. You may not use the wireless connectivity for any other purpose. "
I have no idea whether same terms and conditions were for buying Kindle 3 3G but this is what I read for Kindle Keyboard. So basically buying this Kindle you agree with this terms and conditions (Hmmm. I guess I already heard these 2 words somewhere... Didn't you tell me smth about this?)

*Hint: Think but not sure.

[geekmaster]

The TOS look the same as for the 3G.

I did not mean to step on any toes. Sorry...

[dsmid]

Originally Posted by yifanlu

Could you give an example of rootfs usage other than copying an init script? I would rather manually implement anything that requires access to rootfs than let all scripts modify it. That's one of the main problems I have, after a while, I don't know what files on thr FS are modified. Especially since I lost the uninstaller scripts.

For example the freedownload hack needs to modify /opt/amazon/ebook/config/wrs.ini, the localization hacks need to inject translation strings into /opt/amazon/ebook/ JARs, the webpatch hack needs to replace libwebkit.so .
I admit everything can be done with mount-binds instead of root fs modification and many hacks do it like that. Couldn't even the jailbreak just mount-bind the keys instead of overwriting them ?

Nevertheless, the package system should provide an API (shell functions) to make the root fs modification/mount-bind-overlay easy, safe and traceable.
Actually you can't stop anybody from modifying the root fs but at least you can offer hackers a convenient API that allows them to do it properly.
All changes to the root fs would then be registered in one place and there would be a generic restore-all procedure.
That's way more important than the install.sh and uninstall.sh hooks.