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`