5.19.5 RE: how Google Drive / OneDrive integration is gated on the 2022 Scribe (nativ

[faithprice]

Hi all — long-time reader, first post.

I did some reverse engineering on my 2022 Scribe (deviceType A12KI9K1KHHBVF; from my reading of /etc/deviceTypes.conf this code is shared with the 2024 model) on firmware 5.19.5, trying to understand why the third-party cloud drive integration (Google Drive / OneDrive / OneNote) — which ships fully built into this firmware — is hidden on pre-2025 devices. Sharing what I found, and where I stopped.

How the settings UI is built. The UI is KPPMainAppV2 (~47 MB native ELF) hosting an embedded Hermes bundle (main.hbc, ~9.4 MB). It decompiles cleanly with P1sec/hermes-dec on GitHub (~54 MB of readable pseudo-JS), which is how everything below was found.

Gate 1 — native device whitelist (local). The JS side is only a shim:


text
isCloudDriveIntegrationEnabled()
→ NativeModules.DeviceFeatureDataProvider.is3PCloudD riveIntegrationEnabledOnDevice()
(related siblings in the same module: isKindlePlannerEnabledOnDevice, and CloudDriveDataProvider.isShadowDriveEnabled). The real logic is native: a hardcoded deviceType list (six newer model codes, not including A12KI9K1KHHBVF), then a numbered feature check — flag #17.

Experiment: in a copy of the binary I flipped the conditional branch that consumes the check result — file offset 0x1BDFF50, original halfword 0xB138 (CBZ r0, +18) changed to 0xE007 (B +18: same target, condition removed) — then bind-mounted the copy over /app/bin/KPPMainAppV2 and restarted the UI. Result: the patched app crashed immediately on launch (stock binary untouched; umount + restart restored everything). I did not iterate further, because:

the watchdog binary kppMainAppCrashRecovery contains a CrashLoopDetector plus a deviceServices.factoryReset path, and its recovery dialogs lead to reset/deregister. On current firmware, losing a jailbreak to a forced reset may be permanent.
Gate 2 — feature flag infrastructure (mixed local/server). The binary carries Amazon's full feature stack: DKINDLE_FEATURE_* ids, dozens of is*WeblabEnabled bindings (server-side treatment assignments), and the mesquite per-device config sync (/var/local/reg/ServerConfig_mesquite.db; on my unit last written at registration — note this particular db turned out to be a mimetype/handler registry, so I could not confirm flag #17's actual backing store). Blind devcap-get-feature -a probes with plausible DKINDLE names all returned "not found". Where flag #17 reads from is, in my opinion, the key open question.

Gate 3 — the linking flow is cloud-brokered. GraphQL strings in the binary (UpdateIntegration, integrationId, getCloudImportStatuses, getDeviceImportStatuses) indicate that binding a Google/Microsoft account goes through Amazon's integration service rather than device-direct OAuth. This is consistent with what people observed in the 5.19.2 thread: the feature reaches new Scribes region by region — same firmware, different regions — so the server side is authoritative at least for rollout, and possibly per-device.

Safety notes for anyone going further:

Bind-mount substitution only; a reboot then always restores stock. Never write to /app/bin directly.
Don't touch /var/local/deviceType.txt to spoof the model — everything model-keyed gets fooled, including OTA.
Create /mnt/us/DISABLE_CORE_DUMP to keep crash-dump tgz files out of your library (tip seen on r/koreader).
If crash-recovery dialogs appear, do not tap reset/deregister.
Questions for the hive mind:

Has anyone pinned down where DeviceFeatureDataProvider's feature check reads from — a static firmware table, mesquite/KVP, or weblab?
Has anyone gotten the Settings → Cloud Drive entry to render on a pre-2025 device?
If yes: does account linking succeed end-to-end, i.e., does Amazon's integration service accept the device?
Happy to share decompiled excerpts or more offsets if useful.