Font, ScreenSaver & USBNetwork Hacks for Kindle 2.x, 3.x & 4.x

[Zbigniev Hamson]

Hi,

Thanks for the replies. I think maybe I haven't been clear about what I wanted and what I have tried, so I'll try again.

Essentially I'm wanting to apply the font hack so that I have the ability to change fonts, but to not actually make any changes to the default system fonts in and of itself (I can then make my own changes to individual fonts). When I install the hack, there are already widespread font changes that I'd like to undo.

I dont' have the hack installed right now so I can't check the exact folder names, but from what I can see the hack creates a "fonts" folder where the fonts that are currently being used are placed. There is also a "backup" folder which I initially thought would be a backup of the original system fonts, so I was hoping I could just copy these over the equivalent fonts in the "fonts" folder, but it seems these are actually identical. So it seems the "backup" folder is actually a backup of the hack fonts, rather than the original system fonts, presumably for if you mess them up making changes.

So yes I'm essentially looking for the original system fonts, which may have been what mergen linked to and was removed is there no way of getting those from my own Kindle?

Originally Posted by Jacksaur

Tried that, now my lock screen is always pure white. Whoops :P

Did you restart your kindle after clearing the cache? I'm not sure if that's required but I'm pretty sure that's what I did. And of course you'll also have to go into at least one book before you put it to sleep to pick up a new cover.

[PoP]

Originally Posted by Zbigniev Hamson

...
So yes I'm essentially looking for the original system fonts, which may have been what mergen linked to and was removed is there no way of getting those from my own Kindle?
...

On my K3 3.4.2 the fonts are in /usr/java/lib/fonts/ With a Terminal or an SSH session, you can copy them to /mnt/us.

[NiLuJe]

They *are* backed up in the fonts folder by the hack!

EDIT: Oops, right folder name. Only *configs* are backed up to the backup folder on FW < 5.x. The fonts themselves are thrown into the fonts folder.

[Zbigniev Hamson]

Originally Posted by NiLuJe

They *are* backed up in the fonts folder by the hack!

EDIT: Oops, right folder name. Only *configs* are backed up to the backup folder on FW < 5.x. The fonts themselves are thrown into the fonts folder.

Okay, so I installed it again to check what I actually get.

It looks like there's a whole bunch of identical fonts in the fonts and backups folders (Caecilia, Helvetica, etc).

The fonts folder has the "Mono", "Sans" and "Serif" fonts in there, as well as "CJK", which aren't in backups.

The backups folder has some config files and things which aren't in the fonts folder.

So I'm not sure which if any of these are the original system fonts, and which other fonts need to be replaced by them to get everything back looking the way it did pre-hack.

[montalex]

Here's a weird one. I just read a book on my jailbroken Kindle 3 with font hack and Georgia2 font installed. Certain letters were missing from the text used for speech and notes. Usually, it would be a capital letter, like "ts" in place of "Its". The text looks fine on ADE and KforPC. I tried redownloading, converting, and reinstalling the book on my Kindle. Same problem. Could the Georgia font I have installed be unable to code certain letters? I've not seen this problem in over a hundred books I've read on the device. I guess that means I shouldn't freak out and should just move on! I'm a bit of a control freak, though. Who else installs a font hack, LOL?

[knc1]

I see where you tested the conversion source before conversion, but I don't see where you tested the result on anything other than the Kindle.

So a conversion error can not be ruled out.

[NiLuJe]

@montalex: Do you mean IPA glyphs? Because, yeah, it's highly possible that your setup may be missing those, and I don't recall if the fallback mechanism kicks in everywhere...

[montalex]

It was the Georgia font! I reapplied the font hack, and the problem is gone. Funny...

[montalex]

Originally Posted by knc1

I see where you tested the conversion source before conversion, but I don't see where you tested the result on anything other than the Kindle.

So a conversion error can not be ruled out.

I wasn't clear. I reconverted, tried to result on KforPC and Calibre reader -- no problem. The problem only appears on my Kindle with the Georgia fault. I've now reverted to the font hack font, and all is good. Thanks!

[JohnSmith6429]

Hi,

I own a Kindle DXI and started looking into "Kindle Hacks" today. However, there is a few things I am confused about: first, can someone explain to me what the "jailbreak" actually does? It is stated in this thread that

The JailBreak opens the door to pretty much everything you'll find on this forum

but I don't understand what exactly requires the device to be jailbroken. For example the wiki and the USBNetwork README_FIRST.txt provide conflicting statements on whether the device needs to be jailbroken.
I've looked into the extracted binary, and saw that it provides a public key. My guess is that this key is used for installing the Kindlets. Is that correct?

Also I've looked into the install.sh for the jailbreak and saw that it tries to extract a file update-patches.tar.gz, which doesn't seem to be present. Is this an issue with the way I "demunged" the binary (I'm kind of reluctant to execute untrusted code, so I wrote a small Python script, doing it the same way KindleTool does for OTAv1 firmware)?

Second I'm interested in the default private RSA key used by KindleTool for signing the packages. Whose key is that and how is it related (if there is any relation at all) to the public key installed by the jailbreak. My guess again is that this is a leaked Amazon key, but that seems kind of unlikely to me. However, if that is not the case I wonder how it is possible to install the jailbreak in the first place.

[NiLuJe]

@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 /) .

[JohnSmith6429]

I'm impressed by how quick you replied, thanks for that.
I didn't see anything that looked like an exploit to me while looking through the jailbreak contents, so I automatically assumed that it was a "legitimate update" (signed by a legitimate private key).

But that also means that the statement

(you don't need to jailbreak or launchpad to use usb networking)

on the wiki is incorrect, right?

By the way, the first time I saw the RSA key was in yifanlu's repo (nothing personal, just the first result in my search engine), which was before nettle. But since there was no public key in the code I didn't see how it was related to the pubhackkey (and apparently OpenSSL doesn't implement PGP, so I couldn't verify using gpg).

[NiLuJe]

@JohnSmith6429: It's *maybe* true in that context (< K5), as some devices did ship with USBNet enabled in diags.

In main, never, though.

EDIT: Or, hell, maybe in some antediluvian FW releases. Generally, no, though. Will update the wiki, as it's confusing, and easy to spot up there at the top ;p.

EDIT²: Technically, for those specific JB exploits, it is based on a legitimate update (parts of it, anyway), so some of it may be untouched and signed by Amazon . But that'd be nitpicking, as we did not re-sign anything ourselves .

[knc1]

Sometimes right, sometimes incomplete.
Refer to the update log of that page to see when that statement was added. Probably a long time ago (but would still be valid now for whatever it was valid then).


Yes, KindleTool contains both our public and our private keys.
And correct, you can't test a OpenSSL certificate file with GPG.
But you can test it with OpenSSL.


You probably want to read a few more of the "advanced" level of public key encryption/decryption/signing (and perhaps similar for GPG).
Apples and Oranges.


If not, then just take the fact that everything posted here for the last ten years works for everyone to mean we probably know what we are doing.

[NiLuJe]

Yep, dates back from 2012 .

To be fair, the KindleTool repo does not actually store a plaintext (i.e., PEM) copy of the key pair. That was left with the JB/MKK packages for probably historical reasons, or I just never noticed ;p.