SpringBreak Jailbreak | Penguins184
Back<br>Donate
00:00
Article
SpringBreak Jailbreak
2026-06-22 12:46:09 +0100 +0100
Well… The fact I’m writing this still comes off as a bit of a shock to me; I never thought I’d be able to find an exploit in anything (I even asked a Magic 8-Ball and it said I wouldn’t!)
If said ‘omniscient’ 8-ball is reading, I want you to know you’re wrong and I did, in fact, get my jailbreak. So suck it.
But we’re getting off-topic. Here’s the inner workings of the exploit in detail. I’ll explain each factor chronologically.
TL;DR: SpringBreak achieves root code execution by combining store cache injection, an exposed dynconfig configuration interface, and arbitrary webpage loading via the Kindle API to trigger a window manager local privilege escalation. A bit of a mouthful.
The Vector
You might be aware that SpringBreak exclusively targets mass-storage based devices (KT5/PW5(SE), KT4/PW4). That is because the vector is the Kindle Store.
You might also know that with WinterBreak, Amazon patched the Kindle Stores’ HTML Cache Replacement - Upon every eject, the cache is deleted and therefore impossible to modify. On MTP, creation of the folder is blocked entirely. (For those who don’t know, WinterBreak injected custom code into the store, and with some elevation, obtained root access. This is what I’m referring to when I say ‘Kindle Store HTML Cache Replacement’.)
With SpringBreak, Hackerdude, the creator of WinterBreak, found a bypass for the cache deletion. It was discovered only shortly after his jailbreak was patched, but not much came of it until I thought it could be useful for my JB. It only worked on mass storage, too.
…It was the creation of 5,000 empty nested folders inside of the cache - because the Kindle cannot handle deleting that, which I found quite amusing ;). Theoretically, this bug is also present on MTP, but MTP blocks the creation of the cache folder entirely before the nested folders can even be transferred, making it a dead end.
Here’s an example of the cache replacement:
The TODO API
Okay, so let’s recap. We can successfully inject any arbitrary HTML into the store. But by itself, this is of no use… it’s just HTML!
Luckily, the HTML runs through Mesquite, a framework which wraps WebKit and injects the window.kindle API into each webapp. This API lets you interact with the system. WinterBreak used it to send lipc (lab126 inter-process-communication) messages to parts of the Kindle, but that part of the API has strict whitelists and is now hard to exploit. All of the other parts of the API are mostly boring, device values/static strings/Wi-Fi connectivity.
Well, all but one. The ToDo API!
window.kindle.todo is not extensively documented at all. When I joined the KindleModding Hacker’s team, h^9 (creator of AdBreak, Nosebleed) had already discovered you could use it for something interesting, though.
ToDo is a simple messaging service. You make XML; It parses it into JSON; it sends it off to lipc services. A full list of handlers (XML keys) to lipc services can be found in /etc/todo/handler_registry.conf.
Specifically, the one we’re interested in is legacy.SET.SCFG=com.lab126.dynconfig. Dynconfig (‘dynamic config’) is configuration stored in /var/local/appreg.db that can be accessed by numerous services. An example dynconfig key is url.store which resolves to https://www.amazon.co.uk/gp/digital/juno/index.html (If you’re in the UK of course. Otherwise the TLD would be different.)
Detour made use of this. It replaced url.store to a file:// URI to permanently make it display whatever HTML you like (the Cache still gets disregarded after a reboot - not deleted - regardless of us bypassing the ejection deletion stuff.) But that’s boring. What can we replace that isn’t url.store?
The AdBreak LPE
Admittedly, it took me embarrassingly long to connect the two. In AdBreak, h^9 had already discovered that you could set winmgr.vibrancyMode.pref.path in dynconfig to any SH, and calling lipc-set-prop -s com.lab126.winmgr vibrancyMode '[arbitrary value]' could trigger it. Scam.net made this obvious to me, for which I am thankful.
Although he knew this, he couldn’t do anything and was sitting on the ToDo exploit because;
Initially, he did not have store cache injection.
There was no way to call com.lab126.winmgr.
As I mentioned beforehand, you can use window.kindle to talk to lipc, but it has a whitelist. The store did not have com.lab126.winmgr on this whitelist, so we could not communicate to it.
This brings up the final trick up my sleeve…
The FTS App
Before this, I was already trying to find a jailbreak, but did not succeed. I did find something interesting though. I tell people who want to create jailbreaks, as someone new to this, that usually you’ll find an exploit in random unusual or...