From c15b3131a5d89fc74cff85a6caf73c72627f998b Mon Sep 17 00:00:00 2001 From: Jason Ross Date: Wed, 24 Jun 2026 19:12:57 -0500 Subject: [PATCH] Document Store-Kindle key vault + book census (account-locked, .kinf2024) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- docs/kfx2024-decryption-effort.md | 68 +++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/docs/kfx2024-decryption-effort.md b/docs/kfx2024-decryption-effort.md index 3c85a5c..e06c516 100644 --- a/docs/kfx2024-decryption-effort.md +++ b/docs/kfx2024-decryption-effort.md @@ -182,6 +182,74 @@ decrypt account-locked classic `.azw` files. - Output of Part A is decrypted **KFX**, not EPUB — readability needs a separate KFX→EPUB step (out of scope here). +--- + +## Update — Store/UWP Kindle key vault + book census (same investigation) + +Follow-up attempt to decrypt the user's `My Kindle Content` library and automate +Kindle key extraction. Result: **same blocker, now confirmed harder.** + +### Every book is account-locked + +Census of `~\My Drive\Documents\My Kindle Content\*_EBOK\*.azw` (16 books): + +| Format | Count | Notes | +|---|---|---| +| KFX (DRMION) | 14 | needs voucher key (account DSN/secret) | +| Topaz (`TPZ0`) | 1 | `B000WDSEMG`; different cipher, out of v0.1 scope | +| MOBI | 1 | `B076DKH9BC` — **crypto_type 2** (HUFF/CDIC), needs a PID | + +So **none** are decryptable without the Kindle account key — even the single +MOBI is PID-locked (not the fixed-key type-1 we hoped for). + +### The Store/UWP key vault (`…\Classic\Data\storage\`) + +| File | Size | Observation | +|---|---|---| +| `.kinf2024` | 86,477 | char-map-encoded; **no `/` records** (unlike `.kinf2018`) | +| `main_shared.blob` | 256 | **not** a DPAPI blob (starts `a8 90 2d 20…`, not `01 00 00 00 d0 8c 9d df`) | +| `main_shared.salt` | 32 | salt for deriving the blob's key | +| `main_shared.blob.sha256` | 32 | integrity hash | + +`main_shared.salt` + a custom-encrypted `main_shared.blob` is a **new master-key +vault**: the blob's encryption key is derived inside the UWP Kindle app (not via +DPAPI), so it can't be recovered by reading files. `.kinf2024`'s per-value +protection presumably chains off this master key. + +### Accessible-credential paths — all exhausted +- `HKCU\Software\Amazon`: **absent** (UWP app doesn't use it). +- `main_shared.blob`: **not DPAPI** → `CryptUnprotectData` doesn't apply. +- No `.kinf2018`/`.kinf2011` anywhere (no older desktop K4PC install). +- No plaintext `kindle.info`/token files. + +**Conclusion:** extracting the account key from this machine's Store Kindle is +not feasible by static file inspection. It would require **dynamic analysis** of +the running UWP app (hooking the DataProtection/key-derivation calls or dumping +the decrypted master key from memory) — specialized RE, uncertain, and outside +what the available tooling can do. + +### Realistic ways to actually decrypt these books +1. **Use a Kindle version DeDRM supports.** Kindle for PC **≤ 1.39** (the desktop + `.exe`, not the Store app) stores keys in `.kinf2018` and downloads + MOBI/older-KFX. De-register the Store app, install the older client, + re-download, and the key is then extractable. This is the standard community + workaround for the Store-app/`.kinf2024` problem. +2. **A registered eInk Kindle's serial number** lets `getKindlePids` (already + ported, `kindle/pid.rs`) derive PIDs for books delivered to that device — + though app/account downloads usually won't match. +3. Wait for / import community RE of the `.kinf2024` + `main_shared` vault. + +### What DRMLibre can do to support path (1) — a port, achievable +- Port `kindlekey.py` **`.kinf2018`** extractor (DPAPI header unprotect, the + `testMap1/testMap8/charMap5` decoders, `GetIDString` = volume serial [we + already have `volume_serial()`], PBKDF2, AES-CTR). → produces the kindle key DB. +- Port `kgenpids.py` **`getK4Pids`** (primitives `encode`/`encode_hash`/ + `generate_device_pid` already ported + tested in `kindle/pid.rs`). +- Wire the kindle DB → PIDs → existing MOBI decryptor; add Topaz + KFX engines. + +This would NOT decrypt the books currently on this machine (they're `.kinf2024`), +but would make the tool "just work" against a supported Kindle install. + ## References - DeDRM_tools: `DeDRM_plugin/kfxdedrm.py`, `ion.py` (`DrmIonVoucher`, `obfuscate*`/`process_V*`), `kfxtables.py` (symbol table), `kindlekey.py`