cn0xroot / Tesla_OS_On_QEMU

# Tesla_OS_On_QEMU
中文说明见 README.zh-CN.md。
Tooling to unpack a Tesla infotainment ECU ("ICE") firmware/eMMC dump,
optionally patch its root filesystem for research, and boot it under QEMU
for offline analysis — built from a full reverse-engineering pass over a
real Model 3 Intel Elkhart Lake ("ICE-MRB") firmware image.
Repository: https://github.com/cn0xroot/Tesla_OS_On_QEMU
> **This repository ships tooling and documentation only.** No firmware
> image, extracted filesystem, key material, packet capture, or log file
> is included or downloaded by anything here — see What's *not* in this
> repo below. You must supply your own firmware
> dump.
## What this is
Tesla's Intel-based infotainment ECU stores its root filesystem as a
squashfs image protected by dm-verity, spread across GPT partitions using
a private `dm-linear` layout that the stock `verity-init` reconstructs at
boot time. Getting a working, inspectable copy of that filesystem — and
being able to boot it in an emulator instead of on real hardware — takes
several non-obvious steps (documented in full, including the debugging
dead-ends, in `docs/firmware_unpacking_reproduction.md` if you keep a
local copy of that analysis).
`scripts/tesla_fw.py` is a single CLI that wraps the whole pipeline:
| Stage | What it does |
|---|---|
| `unpack` | Partition table → extract kernel from the `iasImage` container → reconstruct the `dm-linear`-spliced rootfs → `unsquashfs` it |
| `patch` | Build a minimal dm-verity-bypass `init` + initrd, and repack an edited rootfs directory back into squashfs |
| `run` | Boot the (optionally patched) firmware in QEMU — headless, interactive GUI, GDB-attached, or a full accelerated graphics stack |
| `ssh` / `focus` / `capture` | Day-to-day helpers for a running QEMU guest: SSH in, fix host input focus, capture traffic |
## Requirements
- Linux host, Python 3.8+
- `qemu-system-x86_64`, `qemu-img` (with KVM available for reasonable boot speed)
- `squashfs-tools` (`unsquashfs`, `mksquashfs`)
- `gcc` (to statically build the bypass `init`), `cpio`, `gzip`
- `fdisk`/`sfdisk` (partition inspection/extraction)
- `openssh-client` (for the `ssh`/`capture` helpers)
## Quickstart
 [code] 
Every subcommand has its own `--help` with the full option list.
### `unpack` in detail
 [code] 
The reconstruction step matters: on this firmware family, a single GPT
partition is *too small* to hold the full squashfs + dm-verity metadata.
The real root device is a `dm-linear` splice of that partition plus a
1GiB slice borrowed from the tail of the LVM data partition — the exact
offsets are derived from the vendor's own `verity-init` binary. Getting a
truncation/rounding detail in that formula wrong produces a rootfs that
*looks* corrupt (squashfs table pointers point past EOF) when it's really
just misaligned by a few thousand bytes; `tesla_fw.py unpack` reproduces
the corrected formula.
### `patch` in detail
 [code] 
The stock rootfs is dm-verity protected: touch a single byte and the
vendor'