KindleDrip — From Your Kindle’s Email Address to Using Your Credit Card

[fonix232]

Originally Posted by NiLuJe

Err, no, that is *entirely* out of my area of expertise (hello, I'm an English Lit major). e.g., the only thing that resonates with me is the tiny bit of dump-stack trickery at the end.

Well, that still makes your skillset much larger than mine! Nonetheless, I have a few acquaintances who might have some specific experience in this field, so I'll keep asking around. Hopefully it results in a nice little jailbreak for all Kindles under 5.13.4

[simonpacis]

Originally Posted by melksnor

Super interesting read. It does seem to me that older than the latest firmwares should all be vulnerable to the JPEG XR exploit. You wouldn't need the whole email to kindle path, just a special mobi file to side load and then once it has elevated privileges, install the certificate key of the jailbreak.

I am a mere javascript programmer, but posts like these always make me want to jump into other things. The creativity of the hacks like from the article and the hacks from the mobileread users are something I really admire.

Is someone reaching out to the author on getting access to the ̶s̶p̶e̶c̶i̶a̶l̶ ̶m̶o̶b̶i̶ ̶f̶i̶l̶e̶?̶ special JPEG?

Reached out to him, awaiting reply.

[fonix232]

Originally Posted by simonpacis

Reached out to him, awaiting reply.

I've also reached out to the guy who discovered the exploit. He won't be able to help, for a number of reasons, one of them being Amazon - they wouldn't be too happy if he started releasing jailbreaks left and right. So now I'm studying the JPEG-XR reference code, and will try to make a Python base implementation that can generate an image for us that will appropriately inject the certificate for further jailbreaking purposes.

[simonpacis]

Originally Posted by fonix232

I've also reached out to the guy who discovered the exploit. He won't be able to help, for a number of reasons, one of them being Amazon - they wouldn't be too happy if he started releasing jailbreaks left and right. So now I'm studying the JPEG-XR reference code, and will try to make a Python base implementation that can generate an image for us that will appropriately inject the certificate for further jailbreaking purposes.

Yeah, same response I got. Totally respect that. If you put it on GitHub, I'd like to contribute with what I can. Did a couple semesters of Computer Science before changing major.

[simonpacis]

Originally Posted by simonpacis

Yeah, same response I got. Totally respect that. If you put it on GitHub, I'd like to contribute with what I can. Did a couple semesters of Computer Science before changing major.

For anyone interested in seeing what we can do, I created a GitHub repo here: https://github.com/simonpacis/DripBreak

My current idea is looking at jxrlib's source code and patching the JPEG XR encode-part, so that it creates a JPEG XR-file with the necessary adjustments to exploit the Kindle.

[fonix232]

Originally Posted by simonpacis

For anyone interested in seeing what we can do, I created a GitHub repo here: https://github.com/simonpacis/DripBreak

My current idea is looking at jxrlib's source code and patching the JPEG XR encode-part, so that it creates a JPEG XR-file with the necessary adjustments to exploit the Kindle.

The reason why I wanted to implement it in Python is because the JPEG-XR codec is incredibly complex - at least for me. Writing a simplified solution that takes an input image, encodes it to JPEG-XR using the system-provided codec, then parses the output file and adds the appropriate exploit bytes in a properly parsed object sounds much more doable. All you need is the objectified structure of the file, and addressing the exploitable parts.

[tryol]

Originally Posted by fonix232

The reason why I wanted to implement it in Python is because the JPEG-XR codec is incredibly complex - at least for me. Writing a simplified solution that takes an input image, encodes it to JPEG-XR using the system-provided codec, then parses the output file and adds the appropriate exploit bytes in a properly parsed object sounds much more doable. All you need is the objectified structure of the file, and addressing the exploitable parts.

I think completely "reverse-engineering" the image file would take a considerably longer time than modifying the preexisting encode algorithm, which already has this done.

I don't have any experience with exploits, but I know a fair amount about c/c++ and have a basic grasp over how memory management works.
I tried doing it your way first and I managed to get an absolute-write primitive pretty quickly.
Unfortunately if I understand it correctly, this exploit requires at least 2 (1 for GOT spraying and 1 for the actual shell code).

Doing it once is easy because you only need understand how the header works, but in order to pull off this exploit and get your 2nd absolute-write primitive, you'd need to split the image into at least 2 tiles. (tiles_num controls the amount of times the buffer overflow happens.).
In order to get to the 2nd tile's header which gives you the 2nd write primitive, you'd need the header and body of the first tile encoded correctly. This is a considerably larger task than only getting the header encoded (with 1 tile).

After I realized this I was thinking about starting again from scratch with the method simonpacis suggested, but since I don't have a jailbroken kindle to debug the image, I decided to wait until somebody who has one (and is probably more experienced in stuff like this) can do it.

[fonix232]

Originally Posted by tryol

I think completely "reverse-engineering" the image file would take a considerably longer time than modifying the preexisting encode algorithm, which already has this done.

I'm not talking about complete reverse engineering here - the image structure is relatively cleanly written in the JPEG-XR implementation, and that's pretty much all we need.

Originally Posted by tryol

I don't have any experience with exploits, but I know a fair amount about c/c++ and have a basic grasp over how memory management works.
I tried doing it your way first and I managed to get an absolute-write primitive pretty quickly.
Unfortunately if I understand it correctly, this exploit requires at least 2 (1 for GOT spraying and 1 for the actual shell code).

Doing it once is easy because you only need understand how the header works, but in order to pull off this exploit and get your 2nd absolute-write primitive, you'd need to split the image into at least 2 tiles. (tiles_num controls the amount of times the buffer overflow happens.).
In order to get to the 2nd tile's header which gives you the 2nd write primitive, you'd need the header and body of the first tile encoded correctly. This is a considerably larger task than only getting the header encoded (with 1 tile).

Could this be why the exploit video shows two distinct images? At least that's what it looked like to me - two separate images loaded on the same HTML page in the browser.

Originally Posted by tryol

After I realized this I was thinking about starting again from scratch with the method simonpacis suggested, but since I don't have a jailbroken kindle to debug the image, I decided to wait until somebody who has one (and is probably more experienced in stuff like this) can do it.

As soon as I can get my PW3 back in working order, I can help out with that - I've done the serial port modification, but for some reason my Kindle won't boot into normal mode properly (screensaver stays on forever, and serial terminal stops receiving input after some time). I'll see if I can wipe the device somehow, maybe that would fix it. Or just flash a stock firmware image back through the recovery mode.

[tryol]

Originally Posted by fonix232

Could this be why the exploit video shows two distinct images? At least that's what it looked like to me - two separate images loaded on the same HTML page in the browser.

No, it's still 1 image but it's split into multiple tiles. I'm not sure how that works exactly, I didn't really look into how the JXR format works. I just threw this together "quickly".

I've been thinking and theorethically this exploit is doable with just 1 tile (that means 1 absolute-write primitive). Unfortunately that would only give us 15*16 (240) bytes for the shellcode... I wonder if that's enough.

If I did it with more than 1 tile, that would give us 240+(n-1)*256 bytes of space where n is the number of tiles. I don't have any experience with shellcode or kindle jailbreaking so it's hard to make a guess on how much space we need. I'd prefer if 240 bytes was enough because I'm not sure how hard it would be to make it work with multiple tiles. Does anybody have an idea?

[NiLuJe]

Assuming that's post privilege escalation, the shellcode basically only needs to call `sh /mnt/us/jb.sh` (or something similar, c.f., @BranchDelay's JB).

[cronot]

Originally Posted by tryol

No, it's still 1 image but it's split into multiple tiles. I'm not sure how that works exactly, I didn't really look into how the JXR format works. I just threw this together "quickly".

I've been thinking and theorethically this exploit is doable with just 1 tile (that means 1 absolute-write primitive). Unfortunately that would only give us 15*16 (240) bytes for the shellcode... I wonder if that's enough.

If I did it with more than 1 tile, that would give us 240+(n-1)*256 bytes of space where n is the number of tiles. I don't have any experience with shellcode or kindle jailbreaking so it's hard to make a guess on how much space we need. I'd prefer if 240 bytes was enough because I'm not sure how hard it would be to make it work with multiple tiles. Does anybody have an idea?

I'm not experienced with jailbraking either, but wouldn't having a single line of script that would source the full script from (e.g.) mass storage work?

[fonix232]

Originally Posted by tryol

No, it's still 1 image but it's split into multiple tiles. I'm not sure how that works exactly, I didn't really look into how the JXR format works. I just threw this together "quickly".

I've been thinking and theorethically this exploit is doable with just 1 tile (that means 1 absolute-write primitive). Unfortunately that would only give us 15*16 (240) bytes for the shellcode... I wonder if that's enough.

If I did it with more than 1 tile, that would give us 240+(n-1)*256 bytes of space where n is the number of tiles. I don't have any experience with shellcode or kindle jailbreaking so it's hard to make a guess on how much space we need. I'd prefer if 240 bytes was enough because I'm not sure how hard it would be to make it work with multiple tiles. Does anybody have an idea?

I think NiLuJe's solution would be the most straightforward. However I'd warn against publishing the source code (or the original image!) of the exploit - while we are using it for good (although, arguably, from Amazon's point of view!), people could employ it to create more malicious implementations, implementations that could snatch Amazon account details from unsuspecting Kindles stuck on older firmware versions (e.g. because there's no 5.13.4 update for that specific model). Which is why I didn't even start a repository. Having such a tool available publicly would just give black hat hackers an even easier way to exploit devices. However, if you can do the below suggestion (the call is much less than 240 bytes), that's practically a highway to jailbreakland in a brand new Model X.

Also, quite funny that the exploitable payload is exactly the size of a tweet!

Originally Posted by NiLuJe

Assuming that's post privilege escalation, the shellcode basically only needs to call `sh /mnt/us/jb.sh` (or something similar, c.f., @BranchDelay's JB).

That's actually a great idea. Originally I was thinking a more direct approach (injecting the developer certificate into the system partition, which in return would allow flashing the jailbreak), but this is actually more applicable via the existing jailbreak guides.

[melksnor]

I'll be monitoring this thread, I'd love for it to work out. I am a mere JS dev, but I started reading "Hacking: the art of exploitation". Maybe at some point I'll be able to help out.

[tryol]

First of all:
I'm pretty new here so I'm not sure how openly this stuff should be discussed. If I'm going too far, I'd like to ask one of the mods to delete this message!

I managed to pull off the external code exection part of the exploit, and with that, (hopefully) the hard part of it is over. I won't be able to progress any further without a cracked kindle though, so I hope fonix232 can help me out with that. (PM'd you!)

As for sharing the jailbreak - if I manage to make it work, no promises - I've thought about multiple ways that would make it hard for anybody to get access to the modified image. Unfortunately, this would require me hosting it on a website, meaning that people would have to risk getting an automatic update by turning on their wifi.

Alternatively I could publish the image file so people could host their own web server locally to access it, but that'd make it really easy for bad actors to use it for scary things.


I'm open to ideas. If anyone can think of a better way to share it, please let me know!

[yparitcher]

@tryol

Great

I have a jailbroken KT4 that I am willing to help develop a jailbreak on.

The kindle has gdbserver so i can debug stackdumpd to figure what need to be passed to it.

For distribution it might be a good idea to package it as a self contained webpage that the user can access from the browser via `file:///mnt/us/webpage.html`

this is not any worse than some of the other jailbreaks that are also RCE.