fire hd 8 12th generation (raspite) fire hd 10 13th generation (tungsten) magisk twrp root bootloader unlock lineageos

gistfile1.txt

im praying bro 

########

Based on further targeted research, here is a device-specific evaluation of Routes 3, 4, and 5 for Raspite and Tungsten. The evidence sharpens the picture considerably: **Route 3 is a conditional maybe for Tungsten (and almost entirely unassessed for Raspite), Route 4 is almost certainly blocked by MediaTek's authentication stack, and Route 5 remains a speculative research branch with no evidence of support in either stock kernel.**

---

### 🪝 Route 3: `kaeru` / Patched-LK — Conditional on Architecture and Sec Policy

`kaeru` works by patching an LK (Little Kernel) bootloader image to inject a payload that provides arbitrary code execution during the boot process. Its applicability to either tablet hinges on two unresolved properties.

#### 🚧 The Architecture Gate (Tungsten: Promising Lead; Raspite: Unknown)

`kaeru` **only supports ARMv7 LK bootloaders**; it explicitly excludes AArch64 bootloaders.

*   **Tungsten (KFTUWI):** A recent XDA post provides a concrete reverse-engineering note. A researcher used a "lkpatcher dump, Ghidra, base `0x4C400000`, size `0x173A10`" and "built a `kaeru` against this map and linked a 9600-byte payload at `0x4C568000` with the `platform_init` BL redirected." Crucially, this work is explicitly described as **unflashed** — a theoretical build, not a booted modification. The mention of an `lkpatcher` and a 32-bit base address (`0x4C400000`) is a *lead* that Tungsten's LK may be ARMv7, but this has not been publicly confirmed by dumping the actual LK and checking its ELF header. The same XDA thread also warns: **"Do not dd a patched lk — preloader still signature-checks it."**
*   **Raspite (KFRAWI/KFRAPWI):** No public LK map, no `kaeru` build attempt, and no architecture analysis was found for Raspite. The SoC is reported as **MT8169A**. Whether its LK is ARMv7 or AArch64 is simply **unknown** from public sources. It could be ARMv7 (which would make Route 3 theoretically possible) or AArch64 (which would rule out `kaeru` entirely).

#### 🔐 The Sec Policy Gate (Both Devices: Unsolved and Potentially Fatal)

Even if the LK is ARMv7, the preloader's **security policy** determines whether a modified LK will boot at all. The `kaeru` wiki defines three modes:

*   **Type 1 (Never verify):** `kaeru` works, even on a locked bootloader. Rare, mostly on some Chinese-brand phones.
*   **Type 2 (Verify only when locked):** `kaeru` works *if* the bootloader is unlocked, or if the unlock state can be manipulated.
*   **Type 3 (Always verify, no matter what):** **`kaeru` is impossible.** The preloader will reject any modified LK regardless of lock state.

For both tablets, **the sec policy is unknown.** The Raspite XDA thread does not mention determining it; the Tungsten thread's explicit warning that "preloader still signature-checks it" strongly suggests a Type 2 or Type 3 policy is in play. If it is **Type 3**, Route 3 is a dead end for both devices without a separate preloader bypass.

#### 🧪 Evaluation for Route 3

| Device | LK Architecture | Sec Policy | Verdict |
| :--- | :--- | :--- | :--- |
| **Tungsten** | Likely **ARMv7** (based on an unflashed RE note), but unconfirmed | **Unknown**; "preloader still signature-checks" is a warning sign | **Conditional maybe.** A `kaeru` build exists in theory but has never been flashed. If the sec policy is Type 1 or 2, it could be testable—*only after* a recovery path is established. If Type 3, it is blocked. |
| **Raspite** | **Unknown** (MT8169A LK architecture not publicly established) | **Unknown** | **Unassessed.** No public work has even begun. If the LK is AArch64, `kaeru` is inapplicable. If ARMv7, the sec policy still needs to be determined. |

The `kaeru` wiki's own eligibility test—editing the LK to invalidate its signature and flashing it—is itself a brick-risk operation that the Tungsten thread explicitly warns against. Without a proven recovery path, this test cannot be safely performed.

---

### 💾 Route 4: `mtkclient` / BootROM — Blocked by Authentication and DA Compatibility

`mtkclient` can communicate with MediaTek BootROM (BROM) and potentially write partitions, but the security stack for modern MediaTek chips presents layered obstacles.

#### 🧱 The V6 Protocol and DA Requirement

The relevant chipsets (MT8169/MT8186 family) use **protocol V6**, and the BootROM is patched. This means `mtkclient` **requires a valid, compatible Download Agent (DA) file** supplied via `--loader`; a generic DA will be rejected.

No public evidence was found of a compatible DA for either the MT8169A (Raspite) or MT8186/MT8169 (Tungsten) Amazon tablets. This is a fundamental prerequisite that is currently unmet.

#### 🛡️ The Authentication Barrier (SBC, SLA, DAA)

Even with a DA, the device's security configuration (retrieved via `GET_TARGET_CONFIG`) determines whether `mtkclient` can proceed. The critical flags are:

*   **SBC (Secure Boot Control):** Requires signed DA images.
*   **SLA (Security Lifecycle Assurance):** Requires SLA authentication.
*   **DAA (Download Agent Authentication):** Requires DA signature verification.

The `mtkclient` documentation states plainly: **"For all devices with DAA, SLA and Remote-Auth activated no public solution currently exists."**

**The security flags for Raspite and Tungsten are not publicly reported.** They are unknown. If Amazon enabled DAA+SLA (which is plausible for a modern retail tablet), `mtkclient` is **blocked at the authentication stage**, regardless of DA compatibility. If the device is unfused and these flags are disabled, a path might exist—but this is unverified.

#### 🔌 The BROM Access Problem

`mtkclient` requires the device to enter BROM or preloader mode. This can sometimes be triggered by button combinations (e.g., volume keys + USB), but for a hard-bricked device, a **physical test point** is often required to force BROM mode.

*   **Raspite (2022 HD 8):** No test point documentation was found for the 12th-generation model. A test point procedure exists for the **7th-gen** Fire HD 8, but that is a different board and SoC; it cannot be assumed to apply.
*   **Tungsten (2023 HD 10):** No test point documentation was found for the 13th-generation model. A thread for the **9th-gen** Fire HD 10 discusses the concept of shorting test points for BROM mode, but again, different hardware generation.

Without a documented test point, a failed write that corrupts the preloader may render the device completely inaccessible, with no software-only recovery route.

#### 🧪 Evaluation for Route 4

| Criterion | Raspite (MT8169A) | Tungsten (MT8186/MT8169) |
| :--- | :--- | :--- |
| **Compatible DA** | **Unknown / not found** | **Unknown / not found** |
| **SBC/SLA/DAA flags** | **Unknown** | **Unknown** |
| **BROM test point** | **Not documented for this generation** | **Not documented for this generation** |
| **Verdict** | **Likely blocked.** Even if a DA exists, DAA/SLA authentication is a probable stopper. Recovery without a test point is not viable. | **Likely blocked.** Same authentication barrier. Recovery without a test point is not viable. |

Route 4 is the most *technically direct* route (it operates below the OS), but the authentication stack makes it the most likely to be **cryptographically blocked**. It cannot be recommended for any write operation without first proving, in read-only mode, that the device's security flags permit an unsigned DA and that a compatible DA exists.

---

### ⚙️ Route 5: `kexec` — Speculative, With No Evidence of Kernel Support

`kexec` allows a running Linux kernel to load and boot a second kernel into memory, bypassing the normal firmware boot process. For these tablets, it would be a mechanism to boot a custom kernel (e.g., a Linux kernel or a recovery kernel) from the **already-rooted stock Android kernel**, without modifying any boot-chain partition.

#### ❓ The Critical Unknown: Is `CONFIG_KEXEC` Enabled?

The entire route hinges on whether the stock Fire OS kernel was built with `CONFIG_KEXEC=y` or `CONFIG_KEXEC_FILE=y`. **No public evidence was found confirming that either device's 5.4.86 kernel has kexec support enabled.**

Android kernels frequently disable kexec for security or simplicity, or because vendor configurations omit it. The XDA discussion for a different Fire device (from 2016) notes that "kexec wasn't compiled in the stock kernel," requiring a custom kernel module. While this is not conclusive for Raspite/Tungsten, it illustrates that kexec is not a default assumption.

#### 🔬 What Would Need to Be True (and Is Currently Unverified)

Even if `CONFIG_KEXEC` is enabled, several barriers remain:

1.  **Kernel lockdown/LSM restrictions:** The running kernel's security policy (SELinux, lockdown) might restrict the `kexec_load` syscall, even from a root shell.
2.  **Hardware handoff:** The second kernel would need to reinitialize or inherit working state for storage (eMMC), display, USB, and memory. This is non-trivial on an Android device where the first kernel has already configured these devices in a vendor-specific way.
3.  **Device tree and command line:** The second kernel needs a valid DTB and kernel command line. Whether the rooted stock environment can supply these in a form the second kernel accepts is unknown.
4.  **No route to TWRP:** `kexec` could theoretically boot a **Linux kernel**, but it does **not** unlock the bootloader or provide a persistent recovery. It would not enable a standard TWRP installation.

#### 🧪 Evaluation for Route 5

| Criterion | Assessment |
| :--- | :--- |
| **Kernel support (`CONFIG_KEXEC`)** | **Unknown for both devices.** No public evidence confirms it is enabled. |
| **Security policy** | Unknown; SELinux/lockdown may block the syscall even from root. |
| **Hardware handoff** | Significant engineering challenge; unproven on these platforms. |
| **Goal alignment** | Useful for a **Linux PoC**, not for TWRP or a persistent Android ROM. |
| **Verdict** | **Speculative.** A time-boxed feasibility check (inspecting the kernel config) is worthwhile, but there is no basis to treat this as a viable route to custom recovery. |

---

### 💎 Summary: Feasibility Ranking for Both Devices

| Route | Raspite (2022 HD 8) | Tungsten (2023 HD 10) |
| :--- | :--- | :--- |
| **3. `kaeru`** | **Unassessed.** LK architecture and sec policy are entirely unknown. If ARMv7 + permissive policy, a path exists in theory; if AArch64 or Type 3, it is blocked. | **Conditional maybe.** An unflashed `kaeru` build exists against a mapped LK. Success depends on confirming ARMv7 and a non-Type-3 sec policy. Without a recovery path, testing is reckless. |
| **4. `mtkclient`** | **Likely blocked.** No known DA; authentication flags unknown but likely to include DAA/SLA. No BROM test point documented. | **Likely blocked.** Same authentication and DA unknowns. No BROM test point documented. |
| **5. `kexec`** | **Speculative.** Kernel support unconfirmed. Potential PoC route for Linux, not a path to recovery. | **Speculative.** Same; kernel support unconfirmed. |

**The only route with any concrete, device-specific engineering progress is Route 3 for Tungsten**—but that progress is a *build*, not a *boot*. It cannot be advanced without first answering the sec policy question, and answering that question safely requires a recovery path that does not currently exist. Route 4 is the most powerful if unblocked, but the authentication stack makes it the least likely to succeed. Route 5 is a parallel research branch with a different goal (Linux) and no evidence of kernel support.

The rational order of operations remains: **determine the sec policy from static analysis of the preloader and LK (read-only), confirm the LK architecture, and only then evaluate whether a write-based experiment is justifiable.** Until the recovery question is answered, none of these routes can be safely tested beyond read-only analysis.

########

Based on the research document and the latest public sources, here is the mapped-out route. The path is fundamentally different for each device: **Raspite has a relatively complete, community-documented workflow up to tethered Magisk, while Tungsten has a reproducible temporary root but remains stuck at the bootloader gate for anything beyond that.**

---

### Stage 0: Universal Prerequisites (Both Devices)

Before touching any exploit, you must establish an immutable baseline. The document is explicit that a matching kernel version is not enough; the full build fingerprint and hardware revision must be pinned.

**1. Disambiguate the Hardware (Critical for Raspite)**

Amazon reuses the model identifier `KFRAPWI` for both the 2022 HD 8 (12th Gen) and a 2024 refresh. Do **not** rely on the retail name or RAM size alone. Run the baseline capture commands from the document (Section 3.3) and record:

- `ro.product.model` (`KFRAWI` vs `KFRAPWI`)
- `ro.build.fingerprint`
- `ro.build.version.incremental`
- `uname -a` (must confirm the `5.4.86` kernel family)

For Tungsten, confirm `KFTUWI` and note the persistent SoC naming ambiguity: Amazon specs say **MT8186A**, while device reports and GhostLock issues often say **MT8169**. Do not resolve this by guessing; record both from `getprop` and kernel logs.

**2. Pin the Exploit Artifact**

For **Raspite**, the primary artifact is `seph3421/GhostLock-Raspite`. Its README explicitly states it was tested on **Fire OS 8.3.3.8** and provides both a Linux toolkit and a Shizuku-enabled Android app. Record the exact commit SHA and the hash of any bundled payload.

For **Tungsten**, the artifact is the **`sshell/GhostLock` `5.4-tungsten` branch**, often distributed as a “1-click root repack” ZIP. Public reports confirm it has achieved `uid=0` on **Fire OS 8.3.3.7** and, more recently, on **8.3.3.8** using compiled-in defaults.

**3. Accept the Hard Boundary**

Before starting, internalize the stop rule from the Tungsten thread: **“Will brick: flashing lk / tee / preloader / mcupm, Magisk onto boot, remount /system rw.”** The stock partitions remain protected by `dm-verity`. Temporary root does not change this.

---

### Stage 1: Tethered GhostLock Temporary Root

This stage proves you can obtain a root shell in the running OS. It does **not** unlock the bootloader or persist across a reboot.

#### Route A: Raspite (KFRAWI / KFRAPWI, Fire OS 8.3.3.8)

There are two supported methods. Both use the same underlying GhostLock payload (CVE-2026-43499).

**Method 1 — Linux Root Helper Toolkit (Recommended for reproducibility)**

1.  Clone `seph3421/GhostLock-Raspite` and extract the release ZIP. Do not run a launcher from inside the archive.
2.  Connect the tablet, enable USB debugging, and authorize the host.
3.  Run the Linux helper. The project provides a menu-driven workflow. Select the option to run GhostLock.
4.  The exploit will push a payload and attempt to escalate. If successful, you will land in a root shell. Verify with `id`; it must report `uid=0(root)`.
5.  **Immediate post-exploit step:** The script may disable OTA packages. This is intentional to prevent an unsupported firmware update from silently killing the exploit. Note this state, but do not attempt to modify system partitions.

**Method 2 — On-Device Android App (Shizuku-dependent)**

1.  Install the companion “GhostLock Raspite” APK from the same repository.
2.  Start Shizuku using ADB from a computer (this is a one-time setup per boot session unless Shizuku is configured to restart via wireless debugging).
3.  Open the app, grant it Shizuku access, and trigger the GhostLock workflow. The app provides a UI and integrity checks around the same payload.

**Acceptance criteria for Raspite:** Run this from a clean boot **at least five times**. Record the attempt count, time-to-root, and whether any kernel panic occurs. The document is clear: a binary existing at a path is not evidence; `id` output is.

#### Route B: Tungsten (KFTUWI, Fire OS 8.3.3.7 or 8.3.3.8)

1.  Obtain the **1-click root repack** (the `ghostlock-tungsten` ZIP). Version **v1.0.3** is referenced in recent success reports.
2.  Extract the complete ZIP to a local directory.
3.  **Linux/macOS:** `chmod +x root.sh && ./root.sh`.
    **Windows:** Double-click `root.bat`.
4.  The script will reboot the tablet before each attempt and retry up to **eight times**. It automatically disables Wi-Fi during USB attempts to improve reliability.
5.  On success, it opens an interactive root shell. Verify `id` and note SELinux status (reports consistently show `Permissive` for the rooted session).

**Crucial note on 8.3.3.8:** Public reports confirm that even when GhostLock says “no registry entry matched this build,” it can still drop root using **compiled-in defaults** on `RS8338.3339N`. Do not assume an 8.3.3.8-specific offset ZIP is mandatory; test the standard repack first.

**Acceptance criteria for Tungsten:** Same as Raspite—five clean-boot trials. Save all logs. If the kernel panics repeatedly with identical output, stop; a mismatched payload is likely.

---

### Stage 2: Tethered Bootless Magisk

This stage loads a Magisk runtime into the *current* root session. It is **not** a standard Magisk installation. The document warns that standard Magisk image-patching assumes an unlocked bootloader; attempting it here will fail or brick the device.

#### Raspite: A Complete, Supported Workflow Exists

The `seph3421/GhostLock-Raspite` project explicitly includes a **“bootless Magisk start workflow”** integrated with its GhostLock payload.

1.  Complete Stage 1 (GhostLock root) and remain in the root shell.
2.  Using the **Linux Root Helper**, select the option to start bootless Magisk (menu option **3** is referenced in the project description).
3.  The script will mount the Magisk runtime into the current session. It does **not** write to the `boot` partition.
4.  **Verification is mandatory.** Open the Magisk app. Do not trust the UI alone. The document specifies checking the runtime state, not just whether the app is installed. A reliable check is whether a known root-requesting app receives a grant, or whether `/sbin/` contains the Magisk daemon socket (e.g., `magiskd`).
5.  **Negative test:** Reboot. Magisk and root should be gone. Re-run Stage 1 and Stage 2. This proves tethered repeatability, not persistence.

#### Tungsten: No Public Port Exists — This is a Development Task

The research document is unambiguous: **“No device-verified Tungsten bootless Magisk script was located.”** The Raspite script cannot be copied because partition layouts, mount points, and SELinux policies differ. The Tungsten thread confirms the temporary root is “not Magisk” and that persistent root requires a bootloader unlock.

**If you choose to port it (high difficulty, optional):**

1.  **Behavioral inventory:** Document exactly what the Raspite script changes in the running session (mounts, `setprop`, services, kernel modules).
2.  **Tungsten mapping:** Dump the equivalent read-only values from your Tungsten (mount table, `/dev/block/by-name`, SELinux contexts, `init` services). Do not assume any path or partition name.
3.  **Minimal edit:** Change one known difference at a time. Keep the Raspite and Tungsten branches separate.
4.  **Static review:** Confirm the ported script does **not** write to `boot`, `vendor_boot`, or `vbmeta`. A “bootless” script that writes to a boot-chain partition is a bricking script.
5.  **Runtime validation:** Same as Raspite—verify the Magisk daemon, not just the UI.

Until this port is independently validated, **Tungsten’s tethered Magisk milestone should be considered blocked.**

---

### Stage 3: TWRP and Custom Recovery

This is where the path diverges completely from the root workflow. **Temporary root in the running OS does not grant the ability to execute a custom recovery image.** The device’s preloader and LK (secondary bootloader) still enforce Amazon’s signature chain on boot images.

#### The Brutal Status (Both Devices)

- **No official TWRP** exists for either Raspite or Tungsten in Team Win’s device list.
- **No public, bootable TWRP image** was found for either device.
- **No bootloader unlock** has been publicly demonstrated for either device.

For Tungsten, the XDA brainstorming thread states plainly: **“There is no public tungsten unlock zip.”** The bootloader unlock exploit must be reverse-engineered, and a mistake “could potentially lead to brick”. For Raspite, the only public TWRP-related reference is a vague Gitea page, with no image or success report.

#### What Would Have to Be True to Proceed

The document’s Stage C (Section 6) lays out the research path. You cannot shortcut this by flashing an image. The prerequisite is **a verified, recoverable way to execute an unsigned or custom-signed image on the exact device/build.**

**Immediate research tasks (read-only, non-destructive):**

1.  **Dump the boot chain.** With temporary root, use `dd` to read (not write) the `preloader`, `lk`/`lk2`, `tee1`/`tee2`, `boot`, `vendor_boot`, `dtbo`, and `vbmeta` partitions to a host. The Tungsten thread provides a command template for this exact dump. Hash every image.
2.  **Analyze LK/Preloader policy.** Open the dumped LK in a disassembler (Ghidra). Determine the architecture (ARMv7 vs. AArch64) and whether the preloader performs signature verification on LK. The `kaeru` documentation explicitly warns that its patched-LK approach depends on the preloader’s verification policy being permissive.
3.  **Evaluate the Amazon signed-unlock gate.** The Tungsten thread references `amzn_verify_unlock` in LK and an IDME `unlock_code` slot. Determine whether this gate can be satisfied without Amazon’s private key. If it cannot, this route is permanently blocked.
4.  **Check BootROM/Download mode.** Does `mtkclient` detect the device in BootROM or preloader mode? Record the security flags (SBC/SLA/DAA). A successful **read** does not imply a successful **write** or DA acceptance.

**Only after a verified custom-image execution route is found can you consider building TWRP.** Even then, the document requires temporary boots (not permanent flashes) first, with separate acceptance gates for display, touch, ADB, storage, and return-to-stock.

---

### Summary: The Realistic Route Map

| Milestone | **Raspite (KFRAWI/KFRAPWI)** | **Tungsten (KFTUWI)** |
| :--- | :--- | :--- |
| **Stock Baseline** | Capture full fingerprint; confirm 2022 vs. 2024. | Capture full fingerprint; note MT8169/MT8186 ambiguity. |
| **Tethered Root** | **Documented & repeatable.** Use `GhostLock-Raspite` (Linux toolkit or Shizuku app) on 8.3.3.8. | **Documented & repeatable.** Use `ghostlock-tungsten` repack (v1.0.3) on 8.3.3.7/8.3.3.8. |
| **Tethered Magisk** | **Documented workflow.** Linux toolkit menu option 3. Verify daemon, not just UI. | **Blocked.** No public port. Porting is a separate reverse-engineering project. |
| **Bootloader Unlock** | **Not established.** No public route. | **Not established.** No public route. High brick risk. |
| **TWRP / Custom Recovery** | **Blocked.** Cannot execute custom image without unlock/execution primitive. | **Blocked.** Same constraint. |
| **LineageOS / Linux** | **Blocked.** Depends entirely on solving TWRP/execution. | **Blocked.** Same dependency. |

The shortest path to a *useful* rooted tablet today is **Raspite up to tethered Magisk**. For Tungsten, the ceiling is temporary root. For TWRP on either device, the project is not a flashing exercise; it is a **boot-chain reverse-engineering effort** that must first answer: *how can this specific device be made to execute an unsigned image, and how can it be recovered when that experiment fails?*

########

# Raspite and Tungsten: Stock → Tethered Magisk → TWRP Boot

**Research report | 23 October 2026**  
**Scope:** Amazon Fire HD 8 (12th generation, 2022; community codename *Raspite*) and Fire HD 10 (13th generation, 2023; *Tungsten*).

> **Executive finding:** A tethered temporary-root workflow is supported by community evidence for Raspite and has device-tested evidence for Tungsten on Fire OS 8.3.3.7. Bootless Magisk is reported working on one Raspite variant/build. A verified bootless Magisk workflow for Tungsten, a verified TWRP image for either device, and a verified way to boot an unsigned recovery image on either locked bootloader were not established by the sources reviewed. Therefore, the realistic plan is **stock → tethered temporary root → (Raspite only, under matching conditions) bootless Magisk → research/build the missing TWRP boot path**. It is not yet a validated end-to-end path to TWRP.

## 1. What “tethered Magisk” means here

These terms must not be conflated:

- **Temporary root:** GhostLock obtains a root shell in the running kernel. A normal reboot removes that root.
- **Tethered Magisk:** after each reboot, a PC is used to run the compatible root exploit and then the device-specific bootless Magisk loader. Root and Magisk are gone again after the next reboot.
- **Bootless Magisk:** a community script loads Magisk into the current running OS without permanently patching/flashing `boot`, `init_boot`, or `recovery`. This is not Magisk’s standard installation path; the official Magisk guide assumes an unlocked bootloader for the usual image-patching workflow. [13]
- **TWRP boot:** executing a custom recovery image. A working root shell alone does not provide a way to boot a custom kernel/ramdisk. The bootloader must accept the image, or a separate early-boot exploit/chain must transfer control to it.

This report treats **booting TWRP temporarily, without flashing it to a partition**, as the target. That is safer than installing recovery permanently, but it still requires a way around the locked boot chain.

## 2. Evidence snapshot

| Device | Identifiers and firmware evidence | Tethered temporary root | Bootless Magisk | TWRP boot |
|---|---|---|---|---|
| **Raspite — Fire HD 8 (2022, 12th gen.)** | Amazon lists `KFRAWI` (2 GB) and `KFRAPWI` (3 GB) for the 2022 model. Do not identify the device by generation alone. [7] | GhostLock kit/payload is reported for Fire OS 8.3.3.6–8.3.3.8; exact model and build matching still matter. [1][2] | Reported working on `KFRAPWI` / Fire OS 8.3.3.8. This does **not** prove every Raspite SKU/build combination works. [1][2] | No verified image or boot path found. No official Raspite entry in Team Win’s Amazon device list. [10] |
| **Tungsten — Fire HD 10 (2023, 13th gen.)** | Amazon lists model `KFTUWI` and SoC `MT8186A`. Community exploit notes identify the kernel/platform as `5.4.86` / `MT8169` (also described as MT8186 in the device tree). Treat this as a platform-naming mismatch; match the exact kernel/build fingerprint, not the label alone. [4][7] | Physical-device success is documented for Fire OS 8.3.3.7, build `RS8337.3186N`, incremental `0029461607044`, kernel `5.4.86-g3397a7c4f706`. The branch also mentions 8.3.3.8 offsets, but the cited successful physical test is for 8.3.3.7. [4][5] | No device-verified Tungsten bootless Magisk script was found. Porting one is separate engineering work. [1][3][4] | No verified image or boot path found. No official Tungsten entry in Team Win’s Amazon device list. [10] |

**Confidence labels used:** “reported” means a community report exists, not independent reproduction; “device-tested” means the linked developer report names a physical-device test; “not established” means the available evidence does not support presenting the step as a working procedure.

## 3. Before touching either tablet

### 3.1 Identify the exact target

Install Android Platform Tools (`adb`; `fastboot` is only useful if the tablet exposes a usable fastboot interface). Enable Developer Options and USB debugging, connect by USB, and authorize the computer. Run these read-only checks:

```sh
adb devices
adb shell getprop ro.product.model
adb shell getprop ro.product.device
adb shell getprop ro.build.fingerprint
adb shell getprop ro.build.version.incremental
adb shell uname -r
adb shell getprop ro.boot.flash.locked
adb shell getprop ro.boot.vbmeta.device_state
adb shell getprop ro.oem_unlock_supported
```

Save the output with the date and the exact package/source revision you intend to use. If the model, build fingerprint, incremental version, or kernel differs from the target listed by the exploit project, **stop**. Kernel exploits use build-specific offsets; “same generation,” “same chipset,” or “same Android version” is not enough.

### 3.2 Recovery and data safeguards

1. Back up personal files. Assume bootloader unlocking, if it ever becomes available, may wipe user data.
2. Preserve the stock OTA/firmware package for the exact model and build, plus the project’s documented backups. Verify backup file sizes and hashes on the PC.
3. Keep device-identity data such as NVRAM, `proinfo`, and Amazon IDME backups private and offline; do not publish them.
4. Do **not** write to `preloader`, `lk`, `tee`, `vbmeta`, `boot`, `recovery`, GPT, or other boot-chain partitions at this stage. A normal factory reset cannot repair a corrupted bootloader or preloader.
5. Do not rely on an untested key combination or random test points to enter MediaTek BootROM. A device-specific, demonstrated recovery route is a prerequisite for any future write experiment.
6. Prevent automatic firmware updates during the experiment using a method documented for your exact device. Do not run an unknown “OTA blocker” script with root just because it appears in a forum post.

**Gate 0:** proceed only when the tablet’s exact model/build is recorded, the right exploit package is identified, personal data is backed up, and no partition-write step is needed.

## 4. Stage A — Raspite: stock to tethered root, then bootless Magisk

### A1. Obtain the matching root package

Start from the Raspite root thread and its currently linked project assets. Read the current instructions and comments before running anything; community repositories and payloads change. [2] The gist reports a payload covering Fire OS 8.3.3.6–8.3.3.8, but the scripts distinguish `KFRAWI` from `KFRAPWI`. [1] Do not substitute a Tungsten, Sunstone, Karat, or other Fire-tablet package.

### A2. Run the documented temporary-root process

1. Confirm `adb devices` lists the intended tablet as authorized.
2. Run the project’s documented root script/tool for the exact model and firmware. Do not run a generic GhostLock binary or copy exploit offsets from another device.
3. Follow the project’s documented wait/retry behavior. The gist notes that the exploit may take time and that a live exploit stage can panic the kernel if left running; use the cleanup instructions for the exact tool version after root succeeds. Do not kill arbitrary processes or improvise process names. [1][2]
4. Verify root with the project’s supplied root helper. The gist gives `adb shell /data/local/tmp/su -c id` as an example **only if that tool placed its helper at that exact path**; success should show `uid=0(root)`.
5. Repeat the root test after a normal reboot before proceeding. This validates the tethered-root stage independently from Magisk.

### A3. Load bootless Magisk

The gist points to xda_kh’s firmware-matched `start-bootless-magisk-raspite-8.3.3.X` scripts and reports a successful `KFRAPWI` / 8.3.3.8 run. [1][2]

1. Use only the script matching the exact Fire OS build and model. Read the script itself before running it as root.
2. Run it from the root environment exactly as its own instructions specify. The gist does not provide enough stable, versioned detail to safely reproduce a universal invocation here.
3. Open the Magisk app and verify that the expected runtime is visible. Test only essential functions first; do not install modules until the setup is stable.
4. Reboot. Confirm that root and Magisk disappear, then reconnect the PC, rerun GhostLock, and rerun the bootless Magisk loader.

**Do not use Magisk’s normal “Direct Install,” patch a stock boot image and flash it, or flash an `empty`/patched `vbmeta` image while the bootloader remains locked.** Those are not part of this bootless workflow. The standard Magisk installation instructions assume an unlocked bootloader for the usual image-patching method. [13]

**Raspite stage exit criteria:** the exact device/build gets root reliably; bootless Magisk starts successfully; the PC-tethered root→Magisk sequence works after at least three fresh reboots; no partition was written.

**Important limitation:** the cited report is specifically for `KFRAPWI` / 8.3.3.8. If the tablet is `KFRAWI`, or runs another build, require a matching success report or conduct isolated testing without partition writes. Do not assume the Plus/base-SKU scripts are interchangeable.

## 5. Stage B — Tungsten: stock to tethered root; Magisk is a separate port

### B1. Select the correct GhostLock source

Use the Tungsten-specific `5.4-tungsten` branch maintained by the port author, not the upstream GhostLock branches for Fire Max 11 (`sunstone`) or Fire TV Stick 4K Max 2nd Gen (`karat`). Upstream’s README lists those devices as its supported targets; that list is not a general compatibility promise for every Fire tablet. [4][5][6]

The public device-tested baseline in the cited Tungsten report is:

- Fire OS `8.3.3.7`
- Build `RS8337.3186N`
- Incremental `0029461607044`
- Kernel `5.4.86-g3397a7c4f706`

The report says an 8.3.3.8 offset set was added, but the explicit physical-device success record is for 8.3.3.7. [4] For 8.3.3.8, check whether the current branch now documents an exact fingerprint plus successful physical testing. Offsets alone are not validation.

### B2. Run and verify temporary root

1. Record the exact build details from Section 3.1.
2. Obtain source from the Tungsten-specific branch and follow its current build/run documentation. The issue reports Android NDK r29 builds for the named projects, but this is not proof that every binary or later commit works on every firmware. [4][5]
3. Run only a payload explicitly matched to the target kernel/build. Do not reuse a `sunstone`/`karat` binary, offset table, or unlock package.
4. Verify `id` reports `uid=0(root)`. Record success rate, elapsed time, SELinux mode, and any reboot/panic. Repeat from a fresh boot.

**Tungsten stage exit criteria:** repeatable tethered root on the exact firmware, including explicit validation of 8.3.3.8 if that is the installed version. Do not downgrade by writing individual partitions merely to reach a better-documented version; that is a separate, high-risk firmware operation.

### B3. Magisk status

The research found no device-verified Tungsten bootless Magisk script. The Raspite script is a reference, not a ready-to-run port: partition naming, boot/init configuration, mount points, SELinux behavior, and the device-specific runtime must be checked. [1][3][4]

The correct next deliverable is a **Tungsten-specific bootless Magisk port and validation report**, not a guessed adaptation of the Raspite commands. Until that exists and is tested on the exact firmware, the documented end state for Tungsten is **tethered temporary root, not tethered Magisk**.

## 6. Stage C — What must happen before TWRP can boot

### 6.1 Two independent requirements

TWRP needs both:

1. **A recovery image that actually works on the device.** That requires a device-specific recovery build configuration/tree and a compatible kernel/ramdisk, partition map and `fstab`, display/touch, storage, USB/ADB, reboot behavior, and data-encryption handling. Team Win’s maintainer guidance lists basic bring-up checks such as screen/touch, backup/restore, ADB, and reboot tests. [11]
2. **A way to execute that image.** Normally this is an unlocked bootloader with a usable temporary-boot command, or a device-specific early-boot exploit that bypasses the normal image-verification gate. A root shell inside Fire OS does not itself bypass the preloader/LK/verified-boot chain. [8][9]

Team Win’s official Amazon device index lists older Kindle Fire models but not Raspite or Tungsten. This does not exclude an unindexed private experiment, but no public, verified image was located in this review. [10]

### 6.2 Practical TWRP research plan

**C1 — Document the boot path, read-only.** If the tablet exposes a bootloader/fastboot interface, collect its advertised variables and commands without issuing write commands. Confirm whether it supports unlocking or temporary boot, and whether it reports itself locked. The Tungsten research cited by the gist reports no usable `oem unlock`, `flashing unlock`, or `flash:unlock` command; that is a blocker, not an invitation to try random commands. [1]

**C2 — Map the verified boot chain.** From the temporary root shell, collect partition metadata and read-only copies using a device-aware procedure. Document which stage verifies the next: preloader → LK/secondary bootloader → boot/recovery and AVB metadata. Hash every dump on the PC. Keep IDME/NVRAM/`proinfo` backups private. Do not write anything back during this phase.

**C3 — Establish an actual image-boot method.** These are research alternatives, not known working procedures:

- an officially supported bootloader unlock followed by the bootloader’s documented temporary-boot feature;
- a reproducible, device-specific exploit that makes the bootloader execute a custom recovery image without a permanent partition write;
- a signed/otherwise accepted recovery image, if such an image and process exist.

No verified route in this list was found for either tablet. `mtkclient` is a generic MediaTek flashing/research tool; its existence and generic `seccfg` commands do not prove that a suitable Download Agent, security bypass, or recovery route exists for these models. [9]

**C4 — Build recovery only against known device data.** Start a device-specific TWRP tree/config from the stock images and source where available. Validate the recovery image’s header, kernel compatibility, DTB/DTBO arrangement, partition map and userspace. Do not borrow a recovery image from a neighboring Fire model. Team Win explicitly warns that images for different devices usually do not work. [10][11]

**C5 — First test must be temporary.** Once—and only once—a documented boot path is proven, attempt to boot the candidate recovery without flashing it to `recovery`, `boot`, or another partition. Validate display, touch, ADB, storage detection, backup/restore, and a clean reboot to Fire OS. Only a successful repeatable temporary boot should lead to a separate discussion of persistent recovery installation.

### 6.3 Why the tempting shortcuts are not a plan

- **`fastboot boot twrp.img`:** useful only if the device exposes a compatible bootloader fastboot implementation and permits that image to execute. Neither prerequisite is currently established here.
- **`python mtk da seccfg unlock`:** a generic command is not proof of a device-compatible DA or an authorized/unlocked state on these Amazon models. Do not run it from this report.
- **Writing an empty `vbmeta`:** not a universal bypass; verification behavior is device- and chain-specific. Do not flash one as an experiment.
- **Patching/flashing LK or preloader:** the gist’s research itself says the preloader signature check is a major blocker and warns that these writes can hard-brick the tablet. A root shell is not a restore strategy.
- **Using another device’s unlock ZIP/image:** partition layouts and trust chains differ. Do not reuse `sunstone`, `karat`, `trona`, or older Fire-tablet artifacts as if they were interchangeable.

## 7. Decision gates and stop/go checklist

| Gate | Required evidence | Decision |
|---|---|---|
| **G0 — Identification** | Exact model, build fingerprint, incremental version, kernel, and matching package | Stop on any mismatch. |
| **G1 — Tethered root** | Root shell confirmed; repeatable after reboot; logs saved | Continue only after stable root. |
| **G2 — Magisk** | Bootless Magisk is device/build-specific and works across at least three fresh boots | Raspite: reported for KFRAPWI/8.3.3.8; independently validate. Tungsten: blocked until a port is tested. |
| **G3 — Recovery build** | TWRP image builds and boots in a suitable test environment; essential hardware works | Build readiness is not proof it can execute on the locked tablet. |
| **G4 — Temporary execution path** | Documented, tested way to execute the candidate image without writing a boot-chain partition | Until this gate passes, do not attempt TWRP boot. |
| **G5 — TWRP smoke test** | Recovery boots temporarily, ADB/touch/display/storage work, Fire OS reboot succeeds repeatedly | Only then plan any persistent recovery installation. |

## 8. Recommended order of work

1. **Raspite first:** establish the exact SKU/build; reproduce GhostLock; validate bootless Magisk on the matching script; save logs and repeat after fresh reboots.
2. **Tungsten second:** reproduce temporary root on the explicitly tested build, or independently validate the exact 8.3.3.8 payload before trusting it; keep Magisk as a separate porting task.
3. **Research TWRP in parallel, without writes:** document bootloader/fastboot capabilities, dump/map the boot chain read-only, identify a supported recovery build base, and resolve the early-boot execution problem.
4. **Do not treat TWRP as the next shell command after Magisk.** It is a distinct project milestone. Until both a recovery image and a proven temporary boot path exist, the safe end point is tethered root (and, for the matching Raspite target, bootless Magisk).

## Sources

1. **Original research gist** — *Fire HD 8 12th Gen (Raspite) / Fire HD 10 13th Gen (Tungsten): Magisk, TWRP, bootloader unlock, LineageOS* (23 Oct 2026). [Open gist](https://gist.github.com/estyseesghosts/546a4539761fa29152f288a8f04eef01)
2. **XDA — Fire HD 8 (2022, 12th Gen) root thread.** [Open thread](https://xdaforums.com/t/root-amazon-fire-hd-8-2022-12th-gen.4801332/)
3. **XDA — Fire HD 10 (13th Gen / Tungsten) temporary-root thread.** [Open thread](https://xdaforums.com/t/root-fire-hd-10-13th-generation-2023-tungsten-kftuwi-temporary-root.4686124/)
4. **R0rt1z2 GhostLock issue #3 — Tungsten 5.4 port and device-test report.** [Open issue](https://github.com/R0rt1z2/GhostLock/issues/3)
5. **sshell — Tungsten-specific GhostLock branch (`5.4-tungsten`).** [Open branch](https://github.com/sshell/GhostLock/tree/5.4-tungsten)
6. **Upstream GhostLock README.** Distinguishes the upstream `sunstone`/`karat` targets from the separate Tungsten port. [Open README](https://github.com/R0rt1z2/GhostLock)
7. **Amazon — official Fire HD model specifications.** Establishes `KFRAWI`/`KFRAPWI` for the 2022 HD 8 and `KFTUWI` / MT8186A for the 2023 HD 10. [Open specifications](https://developer.amazon.com/docs/device-specs/ft-device-specifications-firehd-models.html)
8. **Android Open Source Project — bootloader overview and verified boot chain.** [Open documentation](https://source.android.com/docs/security/features/verifiedboot)
9. **bkerler/mtkclient README.** Generic tool capability; does not establish target-specific support for these tablets. [Open README](https://github.com/bkerler/mtkclient)
10. **Team Win — official Amazon device index.** [Open device list](https://twrp.me/Devices/Amazon/)
11. **Team Win — becoming a TWRP maintainer / device tree and testing checklist.** [Open guide](https://twrp.me/faq/OfficialMaintainer.html)
12. **AOSP — lock and unlock the bootloader.** [Open documentation](https://source.android.com/docs/core/architecture/bootloader/locking_unlocking)
13. **Magisk — official installation guide.** Documents the ordinary image-patching path and its unlocked-bootloader assumption. [Open guide](https://topjohnwu.github.io/Magisk/install.html)
---

**Scope limitation:** This report is a research roadmap, not a tested flashing tutorial. Public sources were checked on 23 October 2026. Firmware, exploit offsets, and community repositories can change; re-check the exact source revision and build immediately before any test. No experimental partition-write procedure is endorsed here.

########

old botslop below this line

########

Start with the Preloader and LK (little kernel) bootloader, because untethering needs one of two things: a bootloader unlock or a way to make a boot-time change persist. In the thread, xda_kh points to R0rt1z2’s kaeru wiki, “Can I use kaeru on my device?”, which says the first job is working out the Preloader’s security policy for the LK. That tells you whether the LK image can be patched or replaced, and whether the Preloader will accept it. Next, with temp root, dump the boot-chain partitions (preloader, lk, boot, vbmeta, and the A/B slots), then check vbmeta and dm-verity state and how the Preloader verifies LK. Chrizzly92’s patch mentions dm-verity, and xda_kh says he downgraded 8.3.3.7 to 8.3.3.6 by flashing partitions from inside the OS. That means a root shell can already write partitions, which is both your best lead and your biggest brick risk. For comparison, look at how the Fire Max 11 and Fire TV Cube 3 unlocks were built. The Cube 3 chain pairs GhostLock with a separate bootloader flaw, and I don’t know whether raspite’s Preloader has the same weakness. Also keep an eye on Rortiz2, who said in the thread he ordered this tablet and expects to work on an unlock, so you may want to wait rather than duplicate that work. Before writing anything to flash, back up every partition and the nvram/proinfo data, stay on a firmware build that GhostLock supports (8.3.3.6–8.3.3.8), and block OTA updates. This is hardware-level work, and a bad preloader or LK write can hard-brick the tablet.

########

Start with the part that carries over to both. Learn what code runs at each boot stage and what verifies it: dump preloader, lk, boot, vbmeta, tee and the A/B slots with temp root, then work out the Preloader’s security policy toward LK (the kaeru wiki checklist), the AVB/dm-verity chain, and how Amazon’s unlock gate works. Reports on the 11th-gen HD 10 point to an IDME flash:unlock flag plus an Amazon-signed unlock code, and Rortiz2 says the same for tungsten, so check whether raspite uses that scheme. Study the Fire Max 11 and Fire TV Cube 3 unlocks the same way, since those are the working precedents. Both tablets share kernel 5.4.86 and GhostLock, so the second shared task is the persistence design. Run the exploit at boot (a BOOT_COMPLETED app or service). First find out which uid and SELinux context GhostLock needs, since lmNewAtThis needed Shizuku (adb-level shell) to launch it. Then handle the ~100 s trigger time and the kernel-panic risk after root is gained. That gets you “semi-untethered” without a bootloader unlock. I’d estimate roughly 60-70% of the methodology is shared, but every artifact is device-specific: LK/preloader binaries, partition layout, offsets and keys. Raspite-only work: its payload is already confirmed on 8.3.3.6-8.3.3.8, bootless Magisk scripts exist, and it can write partitions from root, so it is the easier place to prototype. Rortiz2 also says he is working on an unlock for it. Tungsten-only work: confirm sshell_’s port on 8.3.3.8, since only 8.3.3.7 is documented. Port the Magisk script (no tungsten version exists), and handle its different SoC (the listing says MT8186A, though its init.rc references mt8169) and different partition layout. Also test the unlock gate, which is the known blocker. For both, don’t flash lk, tee, preloader or boot until you have full dumps and a recovery route.

########

# Raspite + Tungsten: Userland to Persistent Magisk

Oct 23, 2026 · @Julie

## Scope and current state

Goal: Magisk that is active after every reboot with no PC attached. Both tablets currently have temporary root only, so root and Magisk must be re-applied after each boot.

| Device | Model | Kernel / SoC | Firmware | Current state |
| --- | --- | --- | --- | --- |
| Raspite (Fire HD 8, 12th gen) | KFRAWI, KFRAPWI | 5.4.86, MT8169 | 8.3.3.6 to 8.3.3.8 | GhostLock temp root works; bootless Magisk scripts exist; no unlock |
| Tungsten (Fire HD 10, 13th gen) | KFTUWI | 5.4.86; SoC listed as MT8186A, init.rc references mt8169 (unresolved) | 8.3.3.7 documented; yours is 8.3.3.8 (unverified) | GhostLock temp root only; no Magisk script; no unlock |

Three levels of "persistent" are used in this document:

1. Tethered: a PC re-runs the exploit after each boot (today).
2. Semi-untethered: the tablet re-roots itself after boot, no PC.
3. Untethered: root and Magisk are part of the boot chain, which needs a bootloader unlock or a boot-chain bypass.

## Ground rules

Nothing is written to a boot-chain partition until full dumps exist and a recovery route is confirmed.

- Treat these as brick-class writes: lk, tee, preloader, mcupm, boot, and any /system remount read-write. The tungsten thread lists all of these as bricking.
- Do not reuse unlock zips from other devices (sunstone, karat). Partition layouts differ; the tungsten thread lists these as bricking.
- Block OTA updates first. A patched kernel would stop GhostLock.
- Kill the exploit stages right after root: `pkill -9 -f ghostlock.stage; pkill -9 -f ghostlock-raspite`. Otherwise a stage can panic the kernel within about a minute.
- Prototype on raspite first. It supports partition writes from root (xda\_kh downgraded 8.3.3.7 to 8.3.3.6 this way) and has more tooling.
- Keep a dated log of every command, build ID and result, and note the build fingerprint with each test.

## Phase 0: Baseline and safeguards

Exit criterion: you can restore every partition you plan to touch from files on a PC.

1. Record the exact build on each tablet: `getprop ro.build.fingerprint`, model, codename, Fire OS version. The raspite scripts check these and reject mismatches (KFRAWI vs KFRAPWI).
2. Disable OTA before connecting to Wi-Fi if possible, or with the exploit's own OTA block.
3. Get temp root (Phase 1), then dump all block devices to the PC: preloader, lk, boot, vbmeta, tee1, tee2, and both A/B slots where present.
4. Back up device identity data (nvram, proinfo, and Amazon's IDME) separately and check the hashes on the PC.
5. Confirm a recovery route: factory reset alone does not restore a damaged lk or preloader, so identify how the SoC enters BootROM download mode on each tablet (test point or key combo). Do this before any Phase 3 write.

## Phase 1: Userland to temporary root

Exit criterion: a repeatable root shell on 8.3.3.8 on both tablets, with the success rate and time-to-root measured.

- **Raspite:** use the kit that matches your model (KFRAWI or KFRAPWI). The same payload (sha256 starting 94046e6f) covers 8.3.3.6 to 8.3.3.8. Verify with `adb shell /data/local/tmp/su -c id` and expect uid=0.
- **Tungsten:** use sshell\_'s `5.4-tungsten` GhostLock branch (ghostlock-tungsten v1.0.3 or newer). It is documented only for 8.3.3.7, so test on 8.3.3.8 and record whether the offsets still match.
- Record the trigger time (raspite waited about 100 s in one report), the retry count, and any kernel panic. Check `/sys/fs/pstore` after a panic.
- Check which SELinux mode you end up in on each device (the tungsten thread expects Permissive).
- The raspite scripts are Windows PowerShell and had a stderr bug that Chrizzly92 patched, so pull the patched version. A Linux toolkit and an Android app (via Shizuku) also exist from lmNewAtThis, which matters for Phase 3 path A.

## Phase 2: Boot-chain and unlock-gate research

Exit criterion: a written answer for each tablet to "what verifies lk, and what gates the unlock flag."

- Work through R0rt1z2's kaeru checklist ("Can I use kaeru on my device?") against each dumped preloader to find its security policy toward LK.
- Map the AVB/vbmeta and dm-verity chain from the dumps: which partitions are hash-protected, and what happens on a mismatch (refuse to boot vs. warn).
- Identify the unlock mechanism. Two conflicting claims exist and need resolving per device: an IDME `flash:unlock` flag checked by the bootloader (11th-gen HD 10 reports), versus an Amazon-signed unlock\_code that can't be forged without Amazon's private key (stated for tungsten and for Fire TV Cube by Rortiz2). Raspite's own mechanism is undocumented in the thread.
- Read the Fire TV Cube 3 (gazelle) and Fire Max 11 (sunstone) unlock writeups as precedent, but note Cube 3 uses a separate bootloader flaw alongside GhostLock, and sunstone's partition layout differs from both trona and raspite/tungsten, so offsets don't transfer directly.
- Watch Rortiz2's own raspite unlock effort (he stated he ordered the device) before duplicating this work.

## Phase 3: Choose a persistence path

Decide per device once Phase 2 gives you an answer on the unlock gate.

| Path | What it needs | Reboot behavior | Risk |
| --- | --- | --- | --- |
| A. Boot-time re-root | A launcher/app (Shizuku-based, per lmNewAtThis) that triggers GhostLock on BOOT\_COMPLETED | No PC needed; root re-acquired every boot (semi-untethered) | Low: userland only |
| B. Bootloader unlock | A valid unlock flag/code per Phase 2 findings | True persistence once unlocked | High: wrong write bricks the device; may be infeasible if an Amazon-signed key is required |
| C. Patched boot chain | A modified lk/boot that still passes the Preloader's checks | True persistence without a formal unlock | High: this is what bricked the trona bootloader-patch attempt |

Path A is the only one confirmed working today (raspite, via lmNewAtThis's app) and is the realistic near-term target for both tablets. Treat B and C as research tracks pending Phase 2, not committed work.

## Phase 4: Magisk integration

Exit criterion: Magisk is active and modules load after a normal reboot cycle (no PC) on both tablets.

- **Raspite:** use xda\_kh's bootless Magisk scripts, matched to firmware (`start-bootless-magisk-raspite-8.3.3.X`). Push the script, open a root shell, run it, and confirm Magisk Manager detects root. Confirmed by bartek81005 on 8.3.3.8 (Plus/KFRAPWI).
- **Tungsten:** no Magisk script exists yet. Port xda\_kh's raspite script using the same shared kernel (5.4.86) as a starting point, then adjust for tungsten's partition layout and SoC differences once Phase 2 is resolved.
- Wire the chosen Phase 3 path (most likely A) to auto-run this Magisk step after each re-root, so the sequence is: boot, re-acquire root, start Magisk, no PC.

## Phase 5: Validation and recovery

- Reboot 3 to 5 times in a row and confirm root/Magisk comes back each time without manual intervention (if on path A).
- Confirm OTA is still blocked after each test.
- Re-test after any firmware change (do not let a tablet auto-update mid-project).
- Keep the Phase 0 dumps and the BootROM recovery route ready for every session that touches partitions, not just the first one.

## Device matrix: shared vs. exclusive

| Item | Shared | Raspite-only | Tungsten-only |
| --- | --- | --- | --- |
| Exploit | GhostLock, same kernel (5.4.86) | Payload confirmed 8.3.3.6 to 8.3.3.8 | Payload (sshell\_'s port) confirmed only on 8.3.3.7; needs verification on 8.3.3.8 |
| Temp root | Methodology (dump, kill stages, check uid) | KFRAWI/KFRAPWI model split handled in scripts | No published Windows/Linux kit beyond the GhostLock branch itself |
| Partition writes from root | Risk rules (never flash lk/tee/preloader) | Demonstrated safe downgrade via partition flash (8.3.3.7 to 8.3.3.6) | Not attempted; thread explicitly flags this as brick-risk, untested |
| Magisk | Bootless install concept | Working scripts, confirmed on 8.3.3.8 | No script exists; needs porting |
| Boot-time re-root (path A) | App/launcher concept (Shizuku) | Implemented by lmNewAtThis | Not built |
| Bootloader unlock | Unlock-gate research approach (kaeru checklist, AVB/dm-verity mapping) | Rortiz2 stated he is starting this; mechanism unconfirmed | Reported to need an Amazon-signed unlock\_code; unconfirmed, likely harder |
| SoC/partition layout | None — these differ by device | MT8169, raspite partition layout | Listed as MT8186A; init.rc references mt8169 (unresolved); partition layout undocumented in thread excerpts seen so far |

## Open questions and sources

Open questions:

- Does tungsten's unlock gate match the IDME flag scheme or the signed-key scheme, or something else entirely?
- Is tungsten's SoC MT8186A or MT8169 (the istyles.com spec and the init.rc reference conflict)?
- Does GhostLock's tungsten payload work unmodified on 8.3.3.8, or does it need new offsets?

Sources:

- [XDA: \[ROOT\] Amazon Fire HD 8 (2022, 12th Gen)](https://xdaforums.com/t/root-amazon-fire-hd-8-2022-12th-gen.4801332/)
- [XDA: \[ROOT\] Fire HD 10 13th Gen "Tungsten" Temporary Root](https://xdaforums.com/t/root-fire-hd-10-13th-generation-2023-tungsten-kftuwi-temporary-root.4686124/page-2)
- [XDA: Fire HD 10 13th Gen Bootloader Unlock + Root Brainstorming](https://xdaforums.com/t/fire-hd-10-13th-generation-2023-tungsten-kftuwi-bootloader-unlock-root-brainstorming.4686124/)
- [GitHub: kz363/fire-hd10-2021-root](https://github.com/kz363/fire-hd10-2021-root)
- [GitHub: wjdob/firehd11g-unlock-public](https://github.com/wjdob/firehd11g-unlock-public)
- [XDA: Fire HD 10 11th Gen Bootloader Unlock + Root Brainstorming](https://xdaforums.com/t/fire-hd-10-11th-generation-2021-bootloader-unlock-root-brainstorming.4509197/page-2)
- [GitHub: R0rt1z2/kaeru wiki](https://github.com/R0rt1z2/kaeru/wiki/Can-I-use-kaeru-on-my-device?)
- [Fire TV Cube 3 hacked, root up to PS7717](https://pasqualepillitteri.it/en/news/23078/fire-tv-cube-3-hacked-root-ps7717)
- [Fire Max 11 root shell and bootloader unlock update (Liliputing)](https://liliputing.com/amazon-fire-max-11-hack-use-a-root-shell-to-disable-the-home-screen/)
- istyles.com Fire HD 10 13th gen spec page (SoC listed as MT8186A, unverified against thread)

########

Here’s the English version of the same answer.

## Bottom line

You **cannot** currently go from “nothing” to “booting LineageOS” on Raspite or Tungsten using this guide. The guide can get you to **semi-untethered root + Magisk** on both tablets. LineageOS requires three things that do **not** exist yet for these devices:

1. **An unlocked bootloader** — not available on Tungsten without an Amazon-signed `unlock_code` or a preloader/BootROM route; Raspite’s unlock mechanism is undocumented.
2. **A LineageOS device tree + kernel** — Raspite has only an old vendor-source repo, not a LineageOS device tree; Tungsten has no public device tree.
3. **A recovery** — no verified TWRP/Lineage Recovery for either device.

So the realistic roadmap is: **nothing → Path A semi-untethered root + Magisk → research unlocks/porting → LineageOS only if the community gap closes.**

---

## What you can actually do now: Path A

This is the only path the guide confirms as working today.

### Phase 0 — Baseline and safety
- On Raspite, confirm **KFRAWI vs KFRAPWI**. Scripts reject mismatches.
- On Tungsten, record `ro.build.fingerprint` and Fire OS version. Yours is **8.3.3.8**, while GhostLock tungsten is documented only for **8.3.3.7**.
- Get temp root, then dump to PC: `preloader`, `lk`, `boot`, `vbmeta`, `tee1`, `tee2`, both A/B slots where present.
- Verify hashes on the PC. Factory reset will **not** restore a damaged `lk` or `preloader`.
- Confirm the BootROM/download-mode entry method for each tablet **before** any partition write.

### Phase 1 — Repeatable temp root
- **Raspite:** use the GhostLock kit matching your model. The same payload (`sha256 94046e6f...`) covers **8.3.3.6–8.3.3.8**. After root, immediately run:
  ```sh
  pkill -9 -f ghostlock.stage
  pkill -9 -f ghostlock-raspite
  ```
  Otherwise a stage can panic the kernel within about a minute.
- **Tungsten:** use sshell’s `5.4-tungsten` GhostLock branch. It is documented for **8.3.3.7** only. Test on **8.3.3.8** and record whether offsets still match. Tungsten offsets are **build-specific** — do not reuse 8.3.3.7 payloads blindly.

### Phase 2 — Only the parts needed for Path A
Do **not** try `kaeru`, LK patching, or boot-chain writes yet.
- Tungsten’s LK reportedly lacks usable `oem unlock` / `flashing unlock` / `flash:unlock`; the unlock slot is empty, and garbage won’t pass verification.
- A patched `lk` will be rejected by preloader signature checks.
- For Path A, you only need to confirm your temp root is stable and OTA is blocked.

### Phase 3 — Path A: boot-time re-root
- Raspite has lmNewAtThis’s Shizuku-based app/launcher concept that triggers GhostLock on `BOOT_COMPLETED`.
- Port that concept to Tungsten: wrap sshell’s GhostLock payload in a userland trigger that runs after boot.
- Kill exploit stages immediately after root succeeds.

### Phase 4 — Magisk
- **Raspite:** use xda_kh’s bootless Magisk scripts matched to firmware. Confirmed on **KFRAPWI / 8.3.3.8**. Push script, get root shell, run it, confirm Magisk Manager detects root.
- **Tungsten:** **no Magisk script exists yet.** Port Raspite’s script using shared kernel **5.4.86** as a starting point, then adjust for Tungsten’s partition layout and SoC differences. The SoC conflict (`MT8186A` vs `mt8169` in `init.rc`) is still unresolved, so reliability is unproven.

### Phase 5 — Validation
- Reboot **3–5 times** and confirm root + Magisk return with no PC.
- Confirm OTA remains blocked after each reboot.
- Keep Phase 0 dumps and BootROM recovery route ready for every session.

**End state of this path:** both tablets boot into a rooted, Magisk-enabled system with no PC attached. That is **semi-untethered**, not LineageOS.

---

## Why LineageOS is not currently executable

| Requirement | Raspite | Tungsten |
|---|---|---|
| Unlocked bootloader | Mechanism undocumented | Needs Amazon-signed `unlock_code` or preloader/BootROM route |
| LineageOS device tree | No public LineageOS tree; only old vendor source | No public device tree |
| Recovery | No verified TWRP/Lineage Recovery | No TWRP |
| Kernel/SoC clarity | MT8169 | `MT8186A` vs `mt8169` conflict unresolved |

Without an unlocked bootloader, you cannot flash a custom `boot`/`system`. Without a device tree and recovery, there is nothing to build or flash. So “booting LineageOS” is currently a **research project**, not a local step-by-step procedure.

---

## What to do if you still want to pave the way

1. Complete **Path A** first. A stable semi-untethered root is your base camp.
2. Finish Phase 0 dumps and Phase 2 mapping: `preloader`, `lk`, AVB/vbmeta, dm-verity, and the unlock gate.
3. Watch Rortiz2’s Raspite unlock effort before duplicating it.
4. On Tungsten, treat Magisk script porting as a separate engineering task — it has a real deliverable even without LineageOS.
5. Do **not** write `lk`, `tee`, `preloader`, or remount `/system` RW without full dumps and a confirmed recovery route.

**Summary:** the guide gets you to **root + Magisk after every reboot**. It does **not** get you to LineageOS, because bootloader unlock, device trees, and recovery do not exist for these devices yet.

#######

Alright, let’s map out the exact technical chasm between “GhostLock temp root” and “booting LineageOS,” stage by stage. You know the bridge isn’t built yet, so this is a map of what the bridge would have to look like, and where the construction currently stops.

---

### 🗺️ Stage 1: From GhostLock to a Persistent, Unlocked Bootloader (The Hard Wall)

GhostLock gives you `uid=0` in userspace. LineageOS needs to write to `boot` and `system` partitions. To do that, the bootloader must be unlocked. This is the primary blocker, and the research is most advanced on Tungsten.

#### 🔓 Tungsten (Fire HD 10 2023): The LK Map Exists, But the Door Is Locked

Recent XDA research has mapped exactly what’s missing. From a root shell, the IDME partition shows:

*   `unlock_code = 256 bytes of 00` (empty)
*   `ro.boot.flash.locked=1` and `ro.boot.vbmeta.device_state=locked`
*   Fastboot has **no** `oem unlock`, `flashing unlock`, or `flash:unlock` commands

Amazon’s `amzn_verify_unlock` path exists in LK (the secondary bootloader), but the unlock slots are empty. Filling them with junk will not pass verification. Critically, **do not `dd` a patched `lk`**—the preloader still signature-checks it, so that is a brick-class write.

The research has gone as far as building a **kaeru payload** against the LK map (base `0x4C400000`, inject hole at `0x4C568000`) and linking a 9600-byte payload with `platform_init` redirected. **It has not been flashed.** The researcher explicitly says: “Don’t flash it”.

**What would need to happen next for Tungsten:**
1.  **A Preloader/BootROM Path:** Since the LK signature check cannot be bypassed from a `dd` write, the persistent unlock likely needs a preloader exploit or a BootROM download-mode path to modify the preloader or `seccfg` directly. `mtkclient` can interact with preloader mode, but the exact DA file and protocol for the MT8169/MT8186 need to be validated for this device.
2.  **A Valid `unlock_code`:** The alternative is obtaining an Amazon-signed `unlock_code`, which is the explicitly stated requirement in the thread. Without either the signing key or a preloader hole, there is no persistent unlock.

#### 📱 Raspite (Fire HD 8 2022): The Path Is Less Mapped

The Raspite thread shows the community is asking the same question: “Will there be a sort of bootloader unlock/a port of kaeru and TWRP? If so we’d have to figure out the Preloader’s sec policy for the LK”. The tooling exists (`kaeru`, `lkpatcher`, `mtkclient`), but there is **no public dump analysis or kaeru payload** for Raspite’s MT8169 yet. The same preloader signature-check wall applies: a patched LK will be rejected unless the preloader is bypassed or its policy is compatible with kaeru.

**Stage 1 Verdict:** **Blocked.** Neither device has a verified, non-bricking path to a persistent unlocked bootloader. Tungsten has a partial LK map and an unflashed payload; Raspite has even less public research. This is the wall.

---

### 🧱 Stage 2: Recovery and Device Tree (The Missing Infrastructure)

Even if the bootloader were unlocked tomorrow, you cannot boot LineageOS without two other things.

#### 🔧 Recovery (TWRP/Lineage Recovery)
There is **no verified TWRP** for either Raspite or Tungsten. A search for Raspite TWRP turns up a bare Gitea mention with no downloadable, tested image. Without a custom recovery, you have no reliable way to flash a ROM ZIP or back up partitions before flashing.

**What would need to happen:** A developer would need to build TWRP from the LK/kernel dumps, which requires a working device tree and a bootable kernel image for recovery. This is a multi-week project even with an unlocked bootloader.

#### 🌳 Device Tree
A LineageOS device tree (`device/amazon/raspite` or `device/amazon/tungsten`) defines partition layouts, kernel `defconfig`, HALs, and SELinux policy.

*   **Raspite:** Only an old vendor-source repo exists (`vendor-mtk-sources/Amazon-Fire_HD8_12th_Gen`), last synced over two years ago and not a LineageOS device tree.
*   **Tungsten:** No public device tree at all. A search for a Fire HD 10 13th-gen device tree returns only Amazon’s source-code notice and forum threads, not a usable tree.

The **trona (Fire HD 10 11th gen) LineageOS 18.1** port is the closest reference. It shows the required workflow: unlock bootloader, flash TWRP, format data, flash ROM. But trona’s partition layout and SoC (MT8183) differ from Raspite/Tungsten (MT8169/MT8186), so its device tree cannot be reused directly; it must be adapted from scratch using the dumps.

**Stage 2 Verdict:** **Missing.** There is no recovery and no device tree for either device. Both are prerequisites that do not exist.

---

### 🛠️ Stage 3: Building and Flashing LineageOS (The Final Step, Once 1 & 2 Exist)

If, hypothetically, a bootloader unlock and a device tree + recovery existed, the final sequence would be:

1.  **Unlock the bootloader** (via the preloader/kaeru path or signed code).
2.  **Flash TWRP** to the recovery partition.
3.  **Boot to TWRP**, format data, and wipe system/cache.
4.  **Flash the LineageOS ZIP** built from the device tree.
5.  **Flash GApps** (optional, ARM64 package for Android 11).

This is the “easy” part. The reason it cannot happen today is not the flashing step; it is that Stages 1 and 2 are incomplete.

---

### 💎 Summary: The Exact Research Gaps to Close

| Stage | Raspite | Tungsten | What’s Missing |
| :--- | :--- | :--- | :--- |
| **Bootloader Unlock** | Preloader sec policy unmapped; no kaeru payload | LK mapped, kaeru payload built but unflashed; needs preloader/BootROM path or signed code | A non-bricking unlock write path |
| **Recovery** | No verified TWRP | No TWRP | A built and tested recovery image |
| **Device Tree** | Old vendor source only | None public | A LineageOS-compatible device tree + kernel |
| **LineageOS Build** | None | None | A maintainer to build and test |

**The realistic first move** is not to attempt a LineageOS flash. It is to **complete the Tungsten preloader/LK research**: validate whether a preloader exploit (via `mtkclient` or a BootROM hole) can disable the LK signature check, because that is the only path that avoids needing Amazon’s private key. For Raspite, the first step is to **dump and map its preloader and LK** with the same rigor the Tungsten researcher applied, to see if kaeru is even viable. Until one of those research tracks produces a **verified, non-bricking unlock**, “booting LineageOS” remains a project plan, not a procedure.

########

Using `mtkclient` is the correct approach to try to bypass the locked bootloader on these MediaTek-based Fire tablets. However, it's important to be clear about what it can and cannot do: **`mtkclient` can likely get you an unlocked bootloader, but it cannot conjure a LineageOS port into existence.** It solves the "lock" problem, not the "missing device tree and recovery" problem.

Here is the technical roadmap for how `mtkclient` would be used, and where the process currently stands for Raspite and Tungsten.

### 🛠️ The `mtkclient` Technical Pathway

`mtkclient` exploits the MediaTek BootROM (BROM) or Preloader mode to interact with the device's storage at a low level, bypassing Android's normal security layer. The general workflow to prepare a device for a custom ROM is as follows:

**1. Establish BROM/Preloader Mode Connection**
You must first force the tablet into BROM mode. This is usually done by holding specific buttons while plugging in USB (e.g., Volume Up + Power) or by using a test point to short specific pins on the motherboard. Once connected, you can verify communication by running `python mtk gettargetconfig`.

**2. Unlock the Bootloader via `seccfg`**
This is the core step to bypass the lock. The `seccfg` (Security Configuration) partition holds the lock state. `mtkclient` can patch this partition directly in memory or on disk.
*   **The Standard Command:** The most common command is `python mtk da seccfg unlock`. This modifies the `seccfg` data to set the `lock_state` to unlocked (`3`) and `critical_lock_state` to `1`.
*   **The Complication (DA Files):** Many modern MediaTek chips require a specific **Download Agent (DA)** file to authorize the unlock. The command often needs to be `python mtk da seccfg unlock --loader DA_FILE_NAME.bin`. The correct DA file for the MT8169/MT8186 chips in your Fire tablets is the critical missing piece.
*   **The Security Patch:** On some devices, even with the right DA, a hash check will fail during the unlock process. Advanced `mtkclient` builds can patch the DA in memory to disable this check, allowing the `seccfg unlock` to succeed.

**3. Disable Verification (AVB/dm-verity)**
An unlocked bootloader is not enough; the bootloader will still verify the integrity of the `boot` and `system` partitions. You must disable Android Verified Boot (AVB) and dm-verity.
*   This is done by flashing a **patched or empty `vbmeta` partition**. The `vbmeta` partition contains the cryptographic signatures for the boot chain.
*   `mtkclient` can write a pre-patched `vbmeta.img` directly: `python mtk w vbmeta vbmeta-empty.img`.
*   Alternatively, once fastboot is accessible, you can use: `fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img`.

**4. Flash Custom Partitions (Recovery, Boot, System)**
With the bootloader unlocked and verification disabled, you can now use `mtkclient` to flash images directly to partitions, bypassing the need for a custom recovery entirely if you wish.
*   The command is `python mtk w <partition_name> <image_file>`.
*   You would use this to flash a custom recovery (like TWRP) to the `recovery` partition, or to directly flash a LineageOS `boot.img` and `system.img` (if one existed).

### 🚧 The Reality for Raspite & Tungsten

While the `mtkclient` pathway is theoretically sound, applying it to your specific devices hits the research gaps identified previously.

*   **The Preloader Signature Check:** A simpler method to unlock involves patching the `preloader` partition itself to change the lock flag and then writing it back with `mtkclient w preloader <patched_preloader.bin>`. However, the guide you provided explicitly states that writing a patched `lk` or `preloader` is a **brick-class operation** because the previous boot stage verifies its signature. `mtkclient`'s `seccfg` method is preferred because it modifies a data partition that is designed to be writable, rather than modifying the verified boot code itself.

*   **The Missing DA File:** The single biggest hurdle is that **no one has publicly documented a working DA file and the exact `mtkclient` command sequence for the MT8169 (Raspite) or the MT8186/MT8169 (Tungsten)**. The research on Tungsten has mapped the LK and built a `kaeru` payload, but it has **not** been flashed because the preloader/LK signature wall is still in place.

*   **The Unsolved "LineageOS" Problem:** Even if you successfully unlock the bootloader tomorrow using `mtkclient`, **you still cannot boot LineageOS**. The fundamental blockers remain:
    *   **No Device Tree:** There is no LineageOS-compatible device tree for Raspite or Tungsten.
    *   **No Recovery:** There is no verified TWRP or Lineage Recovery image for either device.
    *   **No ROM Build:** Consequently, no LineageOS build exists to flash.

### 💎 Summary

`mtkclient` is the tool you would use to break the bootloader lock, and it is the most promising avenue. The research path is to find or create a working DA file for the MT8169/MT8186, use it to run `da seccfg unlock`, and then flash an empty `vbmeta` to disable verification.

However, **unlocking the bootloader is only the first step of a much longer project.** The "LineageOS" part of your goal requires a community developer to build a device tree and recovery from scratch using the dumps you would take. `mtkclient` gets you past the wall, but the bridge to LineageOS still needs to be built.

########

Rolling your own DA (Download Agent) file is a deep reverse-engineering task, and it's important to set expectations: **it is a research project, not a step-by-step procedure, and it will not, by itself, get LineageOS booting.** The DA gets you past the bootloader wall; it does not build the missing device tree or recovery.

Here is how the process works conceptually, the specific obstacles for the MT8169/MT8186 chips in your Fire tablets, and the practical paths you can explore.

### 🧬 What a DA File Is and What It Does

A DA is a small ARM executable that `mtkclient` (or SP Flash Tool) uploads into the device's **SRAM** during **BROM (BootROM) mode**. Once loaded, it becomes a mini-operating system that initializes hardware (RAM, storage controllers), handles the security handshake with the BootROM, and performs the actual read/write operations to eMMC/UFS partitions.

The critical point: on modern MediaTek chips, the BootROM is **patched** and uses a newer protocol (V6 or XML-based). This means **you cannot simply use a generic DA**; you must provide a **valid, chip-specific DA file** via the `--loader` option for `mtkclient` to communicate at all.

### 🛡️ The Security Wall: What Your DA Must Bypass

Before a DA will even run, the BootROM checks the device's security configuration via `GET_TARGET_CONFIG`. Your Fire tablets likely have several of these flags enabled:

| Flag | Bit | Description | Impact |
| :--- | :--- | :--- | :--- |
| **SBC** | 0x1 | Secure Boot Control | Requires a **signed DA** |
| **SLA** | 0x2 | Security Lifecycle Assurance | Requires SLA authentication |
| **DAA** | 0x4 | Download Agent Authentication | Requires DA **signature verification** |
| **CERT** | 0x10 | Root Certificate | Requires sending a root certificate |

If `DAA` is enabled, the BootROM will verify the DA's signature. A hand-built DA with no valid Amazon/MediaTek signature will be rejected. This is why the search results repeatedly stress that for chips with **DAA, SLA, and Remote-Auth activated, "no public solution currently exists."**

**For Fire HD 8/10 (2022/2023), the DA must either be a leaked, signed DA for MT8169/MT8186, or you must use an exploit to bypass the signature check in memory.**

### 🛠️ The Two Realistic Paths to a "Custom" DA

You are not starting from a blank text file; a DA is a compiled ARM binary. "Rolling your own" means either **patching an existing DA** or **building one from leaked/obtained sources**.

#### Path A: Patch an Existing DA (The Practical Route)

`mtkclient` has a built-in framework for patching DA binaries **in memory** to bypass security checks. This is how tools like **Carbonara** work: they modify the DA binary after it is uploaded but before it executes, disabling signature verification or redirecting commands.

1.  **Obtain a Base DA:** You need a DA binary that is at least *recognized* by the BootROM, even if it fails the signature check. Look for DA files bundled with **official Fire OS firmware** for your specific model (often named `DA_SWSEC.bin`, `DA_PL.bin`, etc.). The `mtkclient` repository also contains a `Loader/` directory with pre-compiled DA binaries for many chipsets.
2.  **Use `mtkclient`'s Extension System:** The tool has classes like `LegacyExt`, `XFlashExt`, and `XmlFlashExt` that patch DA2 (the second-stage DA) to inject custom read/write commands or bypass checks. The `XmlFlashExt.patch_da2()` method is specifically used for XML-protocol DAs (which newer chips use).
3.  **Apply Security Bypasses:** When `mtkclient` uploads the DA, it can activate exploits like **Carbonara** (patches the DA in memory) or **Heapbait** (a heap overflow exploit in DA2 to gain code execution). These are already integrated into the `mtkclient` exploit framework; you would be enabling them via command-line flags or by modifying the `mtkclient` source to target your specific firmware version.

**The core challenge:** You need the **exact memory addresses and byte patterns** for your firmware version to make these patches work. For MT8169/MT8186, these offsets are **not publicly documented** for the Fire tablets. You would need to dump the DA from a device (or obtain it from firmware) and reverse-engineer it with **Ghidra** or **IDA Pro** to find the signature check routines and patch them manually.

#### Path B: Build a DA from Scratch (The Research Route)

This is essentially rebuilding a proprietary MediaTek tool. You would need:
*   The **DA source code** (leaked or reverse-engineered).
*   The **ARM toolchain** to compile it.
*   The **exact hardware initialization sequences** for MT8169/MT8186 (RAM timings, storage controller registers, etc.).

This is far beyond a typical modding project and is not something the community has achieved for these specific Fire tablets.

### 🚧 The Specific MT8169/MT8186 Obstacle

A critical detail from your research: the **Fire HD 10 13th Gen (Tungsten)** may use an **MT8186** SoC, but `init.rc` references **mt8169**, and the Fire HD 8 12th Gen (Raspite) uses **MT8169**. A **CVE from 2026** (CVE-2026-20435) specifically lists **MT8169 and MT8186 as affected** by a preloader logic error that allows reading device unique identifiers—this confirms both chips share a vulnerable preloader lineage.

However, **no public DA file or exploit specifically targets these Fire tablet models**. The closest community work is the **Amonet** exploit chain for the **Fire HD 8 (2018, karnak)**, which used a MediaTek BootROM exploit + LK exploit. That was an older chip generation and a different Fire OS version; its DA/exploit will **not** transfer directly to MT8169/MT8186.

### 💎 A Realistic Workflow to Attempt

If you want to pursue this, here is the sequence to try, knowing that each step may hit a dead end:

1.  **Extract a Base DA:** From a **Fire OS firmware update** for your exact model (KFRAWI/KFRAPWI or KFTUWI), extract the DA file. Use `da_parser.py` (a developer tool in `mtkclient`) to analyze its metadata and supported chipsets.
2.  **Attempt `mtkclient` with the Extracted DA:** Run `python mtk.py printgpt --loader YOUR_DA.bin`. Observe the `Target config` output. If `DAA` or `SLA` is `True` and the command fails, you know the signature wall is active.
3.  **Enable In-Memory Patching:** Look at `mtkclient`'s `--patch` options or the `Carbonara`/`Heapbait` exploit flags. These are not always automatic; you may need to modify the `mtkclient` Python code to force the patching logic for your specific DA version.
4.  **Reverse-Engineer the DA:** If patching fails, disassemble the extracted DA in **Ghidra**. Look for the functions that check a signature or certificate. The goal is to find the conditional jump that rejects the DA and patch it to always accept. This requires deep ARM assembly knowledge.
5.  **If a Patched DA Runs:** You could then attempt `da seccfg unlock` to write the unlock flag to the `seccfg` partition. **This is a brick-class operation**; ensure you have a full dump and a confirmed BootROM entry method (test point) before attempting it.

**The hard truth:** Even if you succeed in creating a working DA and unlocking the bootloader, **you still cannot boot LineageOS**. You would then need a **device tree** and a **custom recovery (TWRP)**, neither of which exists for Raspite or Tungsten. The DA is the key to the first door, but there are two more locked doors behind it that the community has not yet opened.

########