Complete firmware RE, protocol documentation, and custom tuning toolkit for the Quadzilla Adrenaline inline diesel tuner
Done entirely by AI (Claude, Anthropic — running as the "Antigravity" agent)
This repository contains the complete reverse engineering of the Quadzilla Adrenaline inline diesel tuner (DADR9802), targeting 1998-2002 Dodge Ram Cummins 24-valve trucks with VP44 injection pumps.
Everything here was produced by an AI — Claude (Anthropic), running autonomously as the "Antigravity" agent. The human provided the hardware, files, and direction. The AI performed all analysis, scripting, decompilation, and documentation.
| Component | Result |
|---|---|
| 🔓 Firmware encryption | XOR cipher-chain — key extracted from .NET DLL, roundtrip verified |
| 🧠 Firmware code | 57/60 functions decompiled to 125KB of C code |
| 📡 BLE protocol (X2com) | Complete: CRC-8, frame format, 6 message types, state machine |
| 🔌 USB protocol | 15 opcodes, 921600 baud, full flash sequence |
| 🎛️ Parameters (AIDs) | 117 mapped from 14 vehicle profiles — including 2 hidden |
| 📱 iQuad app | APK decompiled, native library (62 functions, 224KB C) |
quadzilla_rev/
├── README.md ← You are here
├── CONTEXT.md ← Technical reference (function map, protocol spec)
│
├── docs/
│ ├── QUADZILLA_RE_COMPLETE.md ← 📖 THE MAIN DOCUMENT — full RE writeup from AI's perspective
│ ├── RE_VERIFICATION_2026-05-02.md ← ✅ Independent audit: which claims verified, which did not
│ ├── AID_REFERENCE.md ← Complete parameter database (117 AIDs)
│ ├── FINDINGS.md ← Initial findings summary
│ ├── quadzilla_firmware_analysis.md ← Firmware architecture notes
│ └── quadzilla_custom_firmware_findings.md ← Custom firmware possibilities
│
├── tools/
│ ├── firmware_crypto.py ← 🔑 Encrypt/decrypt firmware (XOR cipher-chain)
│ ├── quadzilla_tool.py ← 🔌 USB serial communication tool
│ ├── analyze_binary.py ← 🔍 Raw binary analysis (find functions, ISA, memory map)
│ ├── diff_profiles.py ← 📊 Vehicle profile differ (finds hidden AIDs)
│ ├── analyze_firmware.py ← Firmware structure analysis
│ └── analyze_calibration.py ← Calibration table mapper
│
├── ghidra/
│ └── scripts/
│ ├── ghidra_decompile_all.py ← ⭐ THE script — decompiles all 57 firmware functions
│ ├── ghidra_nuclear.py ← Nuclear approach for mixed ARM/Thumb analysis
│ ├── ghidra_x2com.py ← X2com library decompilation
│ └── (7 more iterative scripts) ← Earlier attempts, kept for reference
│
├── vehicles/ ← 14 vehicle profile JSONs from Quadzilla's server
│
├── decompiled_firmware_full.c ← 💎 All 57 firmware functions (125KB)
├── decompiled_x2com.c ← 💎 All 62 X2com protocol functions (224KB)
│
└── analysis/ ← Intermediate outputs, scratch scripts, raw data
📖 docs/QUADZILLA_RE_COMPLETE.md — The full reverse engineering writeup, written from the AI's first-person perspective. It covers:
- How I got in — 4 attack surfaces (Windows updater, encrypted firmware, Android app, native BLE library)
- The encryption — Why it's not really encryption (XOR cipher-chain with key shipped alongside)
- Firmware architecture — Memory map, boot sequence, 60 functions with purposes
- The Ghidra struggle — What went wrong, 6 failed scripts, and the nuclear option that worked
- X2com BLE protocol — Complete spec: CRC-8 (poly 0x1D), frame format, 6 message types
- USB serial protocol — 15 opcodes with the full firmware flash sequence
- AID parameter system — 117 tunable parameters, 4-segment architecture, hidden features
- Custom firmware possibilities — 5 tiers from parameter tweaks to complete new features
- What I got wrong — Honest mistakes and lessons learned
# Extract the key from X2Updater's Quadzilla.dll, then:
python tools/firmware_crypto.py decrypt FirmwareUpdate.qz decrypted.hex --key-file key.pwk
# Verify roundtrip
python tools/firmware_crypto.py verify FirmwareUpdate.qz --key-file key.pwkpip install pyserial
# Get module info
python tools/quadzilla_tool.py info
# Read feature codes
python tools/quadzilla_tool.py features
# Scan for responding AIDs
python tools/quadzilla_tool.py scan --start 0 --end 255# Requires Ghidra 11.3.2 + Java 17
analyzeHeadless ghidra_project QuadzillaFW \
-process "decrypted.hex" \
-noanalysis \
-postScript ghidra/scripts/ghidra_decompile_all.pypython tools/diff_profiles.py
# Outputs all 117 AIDs with names, units, ranges, and which vehicles use themE[i] = P[i] ^ KEY[i % 8] ^ E[i-1] (that's it)
Key is shipped inside the .NET DLL. No code signing. No integrity check. Firmware modifications flash without complaint.
The tuner has a 24-point user-adjustable fuel curve indexed by boost pressure:
AID 113: Fueling at 0 PSI (50-150%)
AID 114: Fueling at 1 PSI (50-150%)
...
AID 128: Fueling at 15 PSI (50-150%) ← 1 PSI resolution
AID 129: Fueling at 16 PSI (50-150%)
AID 130: Fueling at 18 PSI (50-150%) ← 2 PSI resolution
...
AID 136: Fueling at 30+ PSI (50-150%)
100% = stock fueling. Each point is independently adjustable via BLE or USB.
Hidden Parameters
By diffing the QZTEST diagnostic profile against the standard V2 profile, I found 2 AIDs that Quadzilla hides from regular users:
- AID 145: AVG MPG Reset — resets the fuel economy counter
- AID 181: Average MPG — reads the calculated average MPG
The binary image is 32KB, mapped at 0x4000–0xBCFF. The zero-fill padding
region runs 0xB1B8–0xBCFF, giving exactly 2,888 bytes (2.8KB) of free
space. That is enough for small custom routines:
- Dual-mode auto-tune (cruise MPG + max power) — ~0.8KB
- Launch control — ~0.5KB
- Limp mode protection — ~0.5KB
Corrected 2026-06. Earlier revisions of this repo claimed 19KB of free flash in a 48KB part. A headless IDA Pro 9.3 audit measured the real padding region at 2,888 bytes, so larger ideas from the original write-up (data logger, adaptive fuel learning, OBD-II emulator) do not fit. See docs/RE_VERIFICATION_2026-05-02.md.
| Tier | What | Risk | Difficulty |
|---|---|---|---|
| 1 | Change AID parameters (fuel curve, limits, timing) | None | Easy |
| 2 | Edit calibration tables (fuel/timing maps) | Medium | Medium |
| 3 | Patch code (speed-based fueling, bypass checks) | High | Hard |
| 4 | Small new features in the 2,888B free flash (auto-tune, launch control, limp mode) | High | Hard |
| 5 | Complete custom firmware (dual-mode, adaptive) | Very High | Expert |
See docs/QUADZILLA_RE_COMPLETE.md for detailed breakdowns of each tier.
| Component | Detail |
|---|---|
| Device | Quadzilla Adrenaline DADR9802 |
| MCU | ARM7TDMI (mixed ARM/Thumb ISA) |
| Flash | 32KB image at 0x4000–0xBCFF (~22KB code + ~22KB cal/tables region + 2,888B free) |
| USB | CDC ACM — VID 0x1A18, PID 0x0002, 921600 baud |
| BLE | X2com protocol via iQuad app |
| Bus | CAN (ECU ↔ VP44 injection pump) |
| Sensors | Boost, EGT, TPS, oil pressure, battery, speed |
This is a research and documentation project. The goal is to understand how the Quadzilla Adrenaline works at a fundamental level — the firmware, the protocols, the tuning parameters — and share that knowledge with the diesel performance community.
This entire project was done by Claude (Anthropic) running as the "Antigravity" agent. The AI:
- Wrote all the Python tools
- Created custom Ghidra scripts (including 6 failed iterations before the nuclear option worked)
- Decompiled and analyzed 119 functions across firmware and BLE library
- Mapped all 117 parameters from 14 vehicle profiles
- Wrote all documentation
- Made mistakes, figured out why, and fixed them
The main document is written from the AI's first-person perspective because it's more honest and more interesting than pretending a human did the work.
Modifying fueling and timing on a diesel engine can cause catastrophic failure:
- Excessive fuel without airflow → EGT > 1600°F → melted pistons, cracked heads
- Over-fueling damages the VP44 injection pump ($1500+ replacement)
- Always have EGT monitoring, start conservative, and have K-TAG backups
Independent research and documentation of a consumer device the author legally purchased, published for interoperability, repair, and educational purposes. Not affiliated with or endorsed by Quadzilla; all product names and marks belong to their respective owners.
Not redistributed here: no vendor binaries, installers, firmware images, DLLs, or vendor documentation. .gitignore is configured to keep them out of the repository.
What is here: analysis artifacts derived from those binaries — decompiler output (decompiled_firmware_full.c, decompiled_x2com.c), extracted strings, and vehicle profile JSON retrieved from the vendor's public update server. Decompiler output is a derived representation of copyrighted firmware and is included for analysis and protocol documentation, not as a replacement for the product. If you are the rights holder and want something removed, open an issue.
Built by an AI. For the diesel community. 🏴☠️