Replace specific ASINs, the book title, and the license voucher GUID with
generic placeholders ahead of making the repo public. No technical content
changes (the format census, vault structure, and analysis are unaffected).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Investigated decrypting the My Kindle Content library and automating Kindle
key extraction. Census: 14 KFX, 1 Topaz, 1 MOBI (crypto_type 2) — all 16
account-locked, none decryptable without the Kindle account key.
That key is only in the modern Store/UWP vault: .kinf2024 (char-encoded, no
"/" records) plus main_shared.blob/.salt/.sha256. The blob is NOT a DPAPI blob
and there is no registry entry, no .kinf2018, and no plaintext token file, so
the key cannot be recovered by static file inspection — it would need dynamic
analysis of the UWP app. The realistic workaround (use Kindle for PC <=1.39,
which writes .kinf2018) and the achievable port work it would unlock are
recorded in docs/kfx2024-decryption-effort.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Investigated decrypting a real Microsoft Store Kindle book (KFX). Found the
content is a loose DRMION container with a sibling .voucher, and the account
key material lives in .kinf2024 — a key store newer than and structurally
different from the .kinf2018 that DeDRM supports (zero "/" record separators;
not a version bump). No DeDRM/community support exists for .kinf2024.
The blocker is the key, not KFX itself: without the account DSN/secret the
voucher (and thus the book) cannot be decrypted or tested. Reverse-engineering
.kinf2024 is novel work outside the "port DeDRM" premise, so per decision the
findings, evidence, and a two-part follow-up plan (KFX engine port + .kinf2024
RE) are captured in docs/kfx2024-decryption-effort.md rather than implemented.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
JMR-devandClaude Opus 4.8