@JohnSmith6429:
You're free to compile KindleTool yourself, you don't have to reinvent the wheel
.
Or, if you want a (much) smaller code-base to audit, the
legacy Python packager, which, for a DX, should mostly do the job (but will not understand newer packaging formats, such as those used in the snapshots).
That said, in order:
* Everything distributed as an update package requires the JB. Everything not distributed as an update package probably requires something else requiring the JB. If you get my drift
.
* At its core, it's just a public key installed in the right place, so we can get our own packages to pass the signing checks.
Both sides of that key are distributed with every JailBreak package, and are inherited from either igorsk or jyavenard. See the legacy packager, as it also embeds those
.
It's slightly less readable in KindleTool, as nettle doesn't natively handles PEM files, so the embedded copy is re-encoded, and then stored in a C array. But the CLI does support supplying your own key, via a bit of repurposed demo code doing the import process.
(On the flip side, nettle's API is designed by and for actual humans, unlike OpenSSL's ;p).
Depending on the target device/FW, the attack vector can vary wildly, and the amount of glue code needed to make it behave/stick/pass any and all other kinds of checks will vary (wildly).
Older does not necessarily means slimmer, on that front.
* Kindlets have nothing to do with it, as that's a whole other thing, with a whole other set of keys (see MKK).
* The update-patches thing is an artefact of the specific exploit being used for the JB version you checked
. Might be more details in the build script about it, might not be. In any case, it's all related to having at least enough/all things passing the safety checks without custom keys being installed.
* If we had access to any of the two pair of keys being used by Amazon, we wouldn't be in this mess (c.f., Kobo, where update packages are unsigned tarballs unpacked to /)
.