Tonverk ...what I found out some time ago about it

[petedorky]

Code:

# Tonverk OS - Reverse Engineering Notes ## Device Info - **Product**: Elektron Tonverk (Eimur) - **Manufacturer**: Elektron Music Machines - **Serial**: A0xxxxxxxx-42 - **USB VID/PID**: 6453 / 4138 - **SoC**: NXP i.MX8M Plus QuadLite (MIMX8ML4DVNLZAB) — ARM Cortex-A53, no GPU/NPU - **RAM**: Micron 8GB LPDDR4 (MT53E2G32D4DE-046, D8CJN) - **eMMC**: SanDisk 8GB (SDINBDG4-8G, 44B2DPDGE0LH) - **WiFi/BT**: AzureWave AW-CM276NF (WiFi 5 + BT 5.0) — shares UART with `bt_or_console` - **Audio Codec**: Cirrus Logic CS42526 (2-ch ADC + 6-ch DAC) - **PCB**: PCBH2053, © 2024 Elektron, board ref `X-18ASA00230D002` - **Firmware Version**: 1.2.1 - **bcdDevice**: 1554 (fw revision 0612) ## Firmware Structure The firmware is distributed as a `.swu` file (SWUpdate CPIO archive, 109 MB). ### Extracted Contents (`Tonverk-OS-1.2.1.swu`) | File | Size | Description | |------|------|-------------| | `sw-description` | 5.8 KB | SWUpdate metadata (encrypted/binary) | | `sw-description.sig` | 384 bytes | Cryptographic signature (RSA-3072 or ECDSA-P384) | | `mb-image-release-esp5-mb.rootfs-rootfs.squashfs` | 48 MB | Main root filesystem (encrypted) | | `mb-image-release-esp5-mb.rootfs-apps.squashfs` | 13 MB | Apps partition (encrypted) | | `mb-image-release-esp5-mb.rootfs-rescue.fit` | 26 MB | Rescue/recovery image (encrypted) | | `mb-image-release-esp5-mb.rootfs.fit` | 22 MB | Main boot FIT image (encrypted) | | `flash.bin-esp5-mb-mb0.signed` | 938 KB | Signed U-Boot bootloader (slot 0) | | `flash.bin-esp5-mb-mb1.signed` | 938 KB | Signed U-Boot bootloader (slot 1) | | `bootscript-release.fit` | 3.8 KB | U-Boot boot script (FIT wrapped, readable) | | `DEMO.tar.gz` | 87 KB | Demo project (LevelDB database with kits/presets) | | `esp5-update.sh` | 483 bytes | Post-install script for SWUpdate | ### Encryption Status - All `.squashfs` and `.fit` images are **fully encrypted** (AES or similar) - Entropy analysis confirms flat maximum entropy across entire files - no structure visible - `sasquatch` and standard `unsquashfs` cannot read them (non-standard magic bytes, not just vendor-modified SquashFS) - `binwalk v3.1.0` finds zero signatures inside the encrypted images - The bootloader (`flash.bin`) is **not encrypted** but is **signed** (HAB - High Assurance Boot) ### SWUpdate Signing The `.swu` package uses cryptographic signing: 1. `sw-description` contains image metadata + SHA256 hashes 2. `sw-description.sig` signs the description with a 384-byte signature 3. Reflashing modified firmware requires Elektron's private signing key - **not feasible** ## SoC Details (NXP i.MX8MP) Extracted from bootloader strings: ### Peripherals found in device tree - **2x Ethernet**: `ethernet@30be0000`, `ethernet@30bf0000` (FEC, i.MX8MP-FEC) - **4x UART/Serial**:   - `serial@30860000` (SPBA bus)   - `serial@30880000` (SPBA bus)   - `serial@30890000` (SPBA bus)   - `serial@30a60000` - **2x USB**: `usb@32e40000`, `usb@32e50000` (DWC3 controller, `dr_mode` present) - **GPIO**: 5 banks (`gpio@30200000` through `gpio@30240000`) - **I2C, SPI (ECSPI), CAN (FlexCAN), DSP, MIPI-DSI, LCDIF** - **USB-C connector** referenced in device tree ### Console Configuration (Release Firmware) ``` stdin  = nulldev      # Serial input DISABLED in release builds stdout = serial      # Serial output goes to UART (read-only) stderr = serial      # Errors go to UART ``` **Important**: There is a `bt_or_console` variable in the bootloader, suggesting one UART is **shared between Bluetooth and debug console**. In debug/development builds, this UART likely serves as a full interactive console. ### Boot Storage - **eMMC** (mmc device 2):   - Partition 1: rescue image   - Partition 2: bootscript (`bootscript.fit`)   - Partition 3: root filesystems (`rootA` / `rootB` for A/B updates) - **`/data` partition**: writable, stores factory projects, demo content, user data ## Boot Flow & Rescue Mode Extracted from `bootscript-release.fit`: ### Normal Boot Sequence 1. U-Boot loads `bootscript.fit` from eMMC partition 2 2. Sets `dtb_conf=esp5`, constructs board revision from `hw_bom` 3. Checks for rescue/recovery conditions (see below) 4. Loads `fitImage` from `activeroot` (rootA or rootB) on partition 3 5. Boots with `bootm` 6. Falls back to rescue if boot fails ### Rescue Mode Triggers ``` # USER-REQUESTED RESCUE (button combo) if test "${ui-alive}" = "true" && test "${ui-int}" = "true"; then     setenv request_rescue "user-requested" # INTERRUPTED UPDATE if test -n "${recovery_status}"; then     setenv update_failed "interrupted" # ROLLBACK (boot failed after update) if test -n "${upgraderoot}" && test "${bootcount}" != "1"; then     setenv update_failed "rollback" ``` **`ui-alive`** and **`ui-int`** are U-Boot env vars set by the front panel MCU. When both are `true`, the device enters **user-requested rescue mode**. This is the most promising entry point. ### How to Trigger Rescue Mode Based on Elektron's standard patterns and the bootscript variables: 1. **Power off the Tonverk completely** 2. **Hold the main encoder pressed** (this likely sets `ui-int=true` via the UI MCU) 3. **Power on while holding the encoder** 4. Watch USB for a different device profile (may switch to ECM/RNDIS network gadget or serial) Other combos to try: - Hold **FUNC** + power on (standard Elektron recovery pattern) - Hold **multiple encoders** or specific button combinations - Hold **encoder + FUNC** simultaneously while powering on ### HAB (High Assurance Boot) The bootloader contains: `authenticate image via HAB. Switch to USB BootROM mode on failure` If HAB authentication fails, the i.MX8MP falls back to **USB Serial Download Protocol (SDP)**. NXP's `uuu` (Universal Update Utility) tool can communicate with this mode. However, HAB is fuse-programmed and won't be easily triggered on a production device. ## USB Interface (Current Behavior) When connected via USB in normal operation: - **USB Class**: 239 (Miscellaneous / IAD - Interface Association Descriptor) - **USB SubClass**: 2, **Protocol**: 1 - **Interfaces exposed**:   - **MIDI** (claimed by macOS MIDIServer)   - **Mass Storage** (USB class 8, subclass 6 = SCSI transparent)     - SCSI Vendor: `Linux`     - SCSI Product: `File-Stor Gadget`     - Revision: `0612`     - Uses Linux USB gadget framework (`g_mass_storage` or `configfs`)     - **Does NOT mount** as a volume on macOS - likely exposes an empty LUN or requires a specific device mode ## Post-Install Script (`esp5-update.sh`) The SWUpdate postinst script writes to the **writable `/data` partition**: ```sh DEMO_FILE="/data/demo.tar.gz" PROJECT_PATH="/data/factory/projects" # Extracts demo project to /data/factory/projects/DEMO ``` This `/data` partition is the most promising target for modifications since it: - Survives firmware updates - Is writable (ext4 or ubifs) - Is likely **not integrity-checked** at boot (unlike the signed rootfs) ## DEMO Project Structure The `DEMO.tar.gz` contains a LevelDB database with: - `ProjectV2` tag - Kits with presets (`KitV2`) - Preset parameters (`PresetParameterValueV1`) - Backend port rules ## Attack Vectors (Ranked by Feasibility) ### 1. Rescue Mode via Button Combo (Most Promising) - Trigger `ui-int=true` via front panel button hold at boot - Rescue mode may enable full UART console, SSH, or USB network gadget - No hardware modification required ### 2. UART Serial Console - i.MX8MP has 4 UART ports; at least one outputs boot logs (`stdout=serial`) - Need to open the case and find UART pads/header on PCB - Look for 4-pin header near SoC: GND, TX, RX, VCC (3.3V) - Connect with USB-UART adapter at **115200 baud** (standard for i.MX8) - In release firmware `stdin=nulldev` blocks input, but:   - Rescue mode likely enables full console   - U-Boot may have a brief window to interrupt boot (press any key)   - The `bt_or_console` UART mux might be switchable ### 3. Ethernet - i.MX8MP has **two FEC Ethernet controllers** - If RJ45 jack exists (or test pads on PCB), connecting Ethernet may provide:   - DHCP client (check router for new device)   - SSH/Dropbear (if enabled in rescue mode)   - mDNS/Avahi advertisement ### 4. USB Gadget Mode Switching - The DWC3 USB controller supports `dr_mode` (dual-role: host/peripheral/otg) - In rescue mode, the device might expose different USB gadgets:   - `g_ether` / USB ECM/RNDIS (network over USB)   - `g_serial` (serial console over USB)   - `g_multi` (mass storage + serial + network) ### 5. NXP UUU (Universal Update Utility) - If you can get into USB SDP mode (Serial Download Protocol):   - Install `uuu` (`brew install uuu`)   - Can write directly to eMMC, load custom kernels to RAM   - Trigger: some i.MX8 boards have a "boot mode" DIP switch or test pad   - Alternative: short the eMMC data lines during boot to force SDP fallback ### 6. Writable `/data` Partition - If mass storage or rescue mode exposes `/data`:   - Drop scripts/binaries that get executed by the main app   - Modify project files to include payloads   - Add SSH keys or enable services ## PCB Analysis (Teardown Photos) ### Key Components (by reference designator) | Ref | Component | Notes | |-----|-----------|-------| | U1 | NXP i.MX8MP QuadLite SoC | Under heatsink | | U2 | (near SoC) | Support IC | | U3 | SanDisk eMMC 8GB | Under heatsink | | U8 | (near SoC area) | | | U21 | (near J3) | | | J3 | **2-pin header/jumper** | Likely `bt_or_console` UART mux — **most promising debug access point** | ### J3 — Suspected BT/Console UART Mux Located near U21, this 2-pin header likely controls the GPIO that switches a UART between the AzureWave BT module and a debug console: - **Open** (default) = UART connected to Bluetooth HCI - **Shorted/jumpered** = UART connected to debug console ### Test Points - **USNUS_1V8** — labeled test point near U8/U2, 1.8V SNVS power rail - Multiple gold test pads/vias visible around the SoC area ### Board Layout - **Left side**: Audio section (electrolytic caps, Cirrus Logic CS42526 area) - **Center**: AzureWave WiFi/BT module (gold-shielded) - **Right side**: Heatsink covering SoC/RAM/eMMC - **Top right**: Red/black ribbon cable to display/UI board - **Bottom left**: Coin cell battery (RTC) ## USB Disk Mode The Tonverk has a **USB disk mode** (separate from rescue mode) that exposes the `/data` partition: - **Volume name**: `Tonverk` - **Size**: 62.3 GB (wait — device has 8GB eMMC, so this may be reporting wrong or there's additional storage) - **Mount point on device**: `/mnt/sdcard` - **Filesystem**: FAT32 or ext4 (macOS readable) ### Contents of `/data` partition ``` /Elektron/Tonverk Factory Library/  — Factory presets and samples /User/                              — User samples, presets, projects /.system/active_project/            — LevelDB/RocksDB database (RocksDB 8.1.1, aarch64) /Diagnostics/                        — Encrypted system diagnostic logs ``` ### Diagnostics (encrypted) The "Save Diagnostics" option in rescue mode writes gzipped tar archives to `/Diagnostics/`: - Contains `journal.log.enc` (encrypted system journal) and `journal.log.enc.key` (384-byte RSA-encrypted AES key) - Only Elektron support can decrypt these ## Rescue Mode Accessed by holding the main encoder while powering on. ### Menu Options 1. **Reset active project** — clears current project 2. **OS upgrade** — looks for `.swu` file on **SD card** (NOT USB!) 3. **Save diagnostics** — writes encrypted logs to `/data/Diagnostics/` 4. **Exit reboot** — normal reboot **Note**: Rescue mode does NOT expose any USB interface. No network, no serial, no mass storage over USB in rescue mode. ## NXP UUU (Serial Download Protocol) ### SDP Mode Details - **USB VID:PID in SDP**: `1fc9:0146` (NXP SE Blank 865) - **UUU installed**: v1.5.243 (`brew install uuu`) - **BOOT_MODE[1:0] = `01`** → Serial Download Protocol mode - **HAB**: RSA-4096 keys fused (SRK1_sha256_4096_65537_v3_ca), `hab_auth_img_or_fail` — authentication is mandatory ### How to Enter SDP Mode 1. **BOOT_MODE pins** — find test pads on PCB, set BOOT_MODE[1:0] to `01` during power-on 2. **Corrupt eMMC boot area** — via U-Boot or UART: `mmc dev 2 && mmc erase 0 8000` 3. **Short eMMC DAT0 to GND** — prevents ROM from reading eMMC, forces SDP fallback (risky) ### UUU Commands (once in SDP) ```bash uuu -lsusb                    # Check if device shows up as 1fc9:0146 uuu -b spl flash.bin          # Boot custom SPL into RAM ``` If HAB is **Open** (unlikely but possible on dev units), we can boot a custom Linux with SSH directly into RAM without touching the device's eMMC. ## Goal Get full shell access to run custom apps and hook into the audio pipeline (likely PipeWire/ALSA on the i.MX8MP) to add custom audio effects. ## Tools Used - **binwalk v3.1.0**: Firmware extraction and entropy analysis - **sasquatch**: SquashFS extraction (vendor-modified formats) - could not extract due to encryption - **unsquashfs**: Standard SquashFS extraction - **uuu v1.5.243**: NXP Universal Update Utility for SDP mode - **Elektron Transfer**: Official Elektron file management tool ## Files Location - Project root: `~/AI/Tonverk_OS/` - Firmware + extractions: `~/AI/Tonverk_OS/tmp/` - PCB teardown photos: `~/AI/Tonverk_OS/*.webp`

[CyberDuck79]

OK, thanks for sharing. It's coherent with what I found.
So I guess you haven't tried yet to investigate the UART port (I guess J1)? Me neither, as I've been mostly busy working on OP1-Field custom firmware. Since Tonverk is still in active development, I prioritize OP1.

[petedorky]

I haven't. If you're bored you can look up the tech spec PDFs from the manufacturer ... they write "military grad security" (so like a Secure Enclave etc.) so I thought it might be a little bit too much work...

[heavymorphine187]

What's the progress? I've tried got so far as to identify 3/5 are gnd ports on j7

[misterairplane]

OK, thanks for sharing. It's coherent with what I found.
So I guess you haven't tried yet to investigate the UART port (I guess J1)? Me neither, as I've been mostly busy working on OP1-Field custom firmware. Since Tonverk is still in active development, I prioritize OP1.

working on op-1f?? keep me posted!! are you in the discord “custom operator”?

[heavymorphine187]

Code:

# Tonverk OS - Reverse Engineering Notes ## Device Info - **Product**: Elektron Tonverk (Eimur) - **Manufacturer**: Elektron Music Machines - **Serial**: A0xxxxxxxx-42 - **USB VID/PID**: 6453 / 4138 - **SoC**: NXP i.MX8M Plus QuadLite (MIMX8ML4DVNLZAB) — ARM Cortex-A53, no GPU/NPU - **RAM**: Micron 8GB LPDDR4 (MT53E2G32D4DE-046, D8CJN) - **eMMC**: SanDisk 8GB (SDINBDG4-8G, 44B2DPDGE0LH) - **WiFi/BT**: AzureWave AW-CM276NF (WiFi 5 + BT 5.0) — shares UART with `bt_or_console` - **Audio Codec**: Cirrus Logic CS42526 (2-ch ADC + 6-ch DAC) - **PCB**: PCBH2053, © 2024 Elektron, board ref `X-18ASA00230D002` - **Firmware Version**: 1.2.1 - **bcdDevice**: 1554 (fw revision 0612) ## Firmware Structure The firmware is distributed as a `.swu` file (SWUpdate CPIO archive, 109 MB). ### Extracted Contents (`Tonverk-OS-1.2.1.swu`) | File | Size | Description | |------|------|-------------| | `sw-description` | 5.8 KB | SWUpdate metadata (encrypted/binary) | | `sw-description.sig` | 384 bytes | Cryptographic signature (RSA-3072 or ECDSA-P384) | | `mb-image-release-esp5-mb.rootfs-rootfs.squashfs` | 48 MB | Main root filesystem (encrypted) | | `mb-image-release-esp5-mb.rootfs-apps.squashfs` | 13 MB | Apps partition (encrypted) | | `mb-image-release-esp5-mb.rootfs-rescue.fit` | 26 MB | Rescue/recovery image (encrypted) | | `mb-image-release-esp5-mb.rootfs.fit` | 22 MB | Main boot FIT image (encrypted) | | `flash.bin-esp5-mb-mb0.signed` | 938 KB | Signed U-Boot bootloader (slot 0) | | `flash.bin-esp5-mb-mb1.signed` | 938 KB | Signed U-Boot bootloader (slot 1) | | `bootscript-release.fit` | 3.8 KB | U-Boot boot script (FIT wrapped, readable) | | `DEMO.tar.gz` | 87 KB | Demo project (LevelDB database with kits/presets) | | `esp5-update.sh` | 483 bytes | Post-install script for SWUpdate | ### Encryption Status - All `.squashfs` and `.fit` images are **fully encrypted** (AES or similar) - Entropy analysis confirms flat maximum entropy across entire files - no structure visible - `sasquatch` and standard `unsquashfs` cannot read them (non-standard magic bytes, not just vendor-modified SquashFS) - `binwalk v3.1.0` finds zero signatures inside the encrypted images - The bootloader (`flash.bin`) is **not encrypted** but is **signed** (HAB - High Assurance Boot) ### SWUpdate Signing The `.swu` package uses cryptographic signing: 1. `sw-description` contains image metadata + SHA256 hashes 2. `sw-description.sig` signs the description with a 384-byte signature 3. Reflashing modified firmware requires Elektron's private signing key - **not feasible** ## SoC Details (NXP i.MX8MP) Extracted from bootloader strings: ### Peripherals found in device tree - **2x Ethernet**: `ethernet@30be0000`, `ethernet@30bf0000` (FEC, i.MX8MP-FEC) - **4x UART/Serial**:   - `serial@30860000` (SPBA bus)   - `serial@30880000` (SPBA bus)   - `serial@30890000` (SPBA bus)   - `serial@30a60000` - **2x USB**: `usb@32e40000`, `usb@32e50000` (DWC3 controller, `dr_mode` present) - **GPIO**: 5 banks (`gpio@30200000` through `gpio@30240000`) - **I2C, SPI (ECSPI), CAN (FlexCAN), DSP, MIPI-DSI, LCDIF** - **USB-C connector** referenced in device tree ### Console Configuration (Release Firmware) ``` stdin  = nulldev      # Serial input DISABLED in release builds stdout = serial       # Serial output goes to UART (read-only) stderr = serial       # Errors go to UART ``` **Important**: There is a `bt_or_console` variable in the bootloader, suggesting one UART is **shared between Bluetooth and debug console**. In debug/development builds, this UART likely serves as a full interactive console. ### Boot Storage - **eMMC** (mmc device 2):   - Partition 1: rescue image   - Partition 2: bootscript (`bootscript.fit`)   - Partition 3: root filesystems (`rootA` / `rootB` for A/B updates) - **`/data` partition**: writable, stores factory projects, demo content, user data ## Boot Flow & Rescue Mode Extracted from `bootscript-release.fit`: ### Normal Boot Sequence 1. U-Boot loads `bootscript.fit` from eMMC partition 2 2. Sets `dtb_conf=esp5`, constructs board revision from `hw_bom` 3. Checks for rescue/recovery conditions (see below) 4. Loads `fitImage` from `activeroot` (rootA or rootB) on partition 3 5. Boots with `bootm` 6. Falls back to rescue if boot fails ### Rescue Mode Triggers ``` # USER-REQUESTED RESCUE (button combo) if test "${ui-alive}" = "true" && test "${ui-int}" = "true"; then     setenv request_rescue "user-requested" # INTERRUPTED UPDATE if test -n "${recovery_status}"; then     setenv update_failed "interrupted" # ROLLBACK (boot failed after update) if test -n "${upgraderoot}" && test "${bootcount}" != "1"; then     setenv update_failed "rollback" ``` **`ui-alive`** and **`ui-int`** are U-Boot env vars set by the front panel MCU. When both are `true`, the device enters **user-requested rescue mode**. This is the most promising entry point. ### How to Trigger Rescue Mode Based on Elektron's standard patterns and the bootscript variables: 1. **Power off the Tonverk completely** 2. **Hold the main encoder pressed** (this likely sets `ui-int=true` via the UI MCU) 3. **Power on while holding the encoder** 4. Watch USB for a different device profile (may switch to ECM/RNDIS network gadget or serial) Other combos to try: - Hold **FUNC** + power on (standard Elektron recovery pattern) - Hold **multiple encoders** or specific button combinations - Hold **encoder + FUNC** simultaneously while powering on ### HAB (High Assurance Boot) The bootloader contains: `authenticate image via HAB. Switch to USB BootROM mode on failure` If HAB authentication fails, the i.MX8MP falls back to **USB Serial Download Protocol (SDP)**. NXP's `uuu` (Universal Update Utility) tool can communicate with this mode. However, HAB is fuse-programmed and won't be easily triggered on a production device. ## USB Interface (Current Behavior) When connected via USB in normal operation: - **USB Class**: 239 (Miscellaneous / IAD - Interface Association Descriptor) - **USB SubClass**: 2, **Protocol**: 1 - **Interfaces exposed**:   - **MIDI** (claimed by macOS MIDIServer)   - **Mass Storage** (USB class 8, subclass 6 = SCSI transparent)     - SCSI Vendor: `Linux`     - SCSI Product: `File-Stor Gadget`     - Revision: `0612`     - Uses Linux USB gadget framework (`g_mass_storage` or `configfs`)     - **Does NOT mount** as a volume on macOS - likely exposes an empty LUN or requires a specific device mode ## Post-Install Script (`esp5-update.sh`) The SWUpdate postinst script writes to the **writable `/data` partition**: ```sh DEMO_FILE="/data/demo.tar.gz" PROJECT_PATH="/data/factory/projects" # Extracts demo project to /data/factory/projects/DEMO ``` This `/data` partition is the most promising target for modifications since it: - Survives firmware updates - Is writable (ext4 or ubifs) - Is likely **not integrity-checked** at boot (unlike the signed rootfs) ## DEMO Project Structure The `DEMO.tar.gz` contains a LevelDB database with: - `ProjectV2` tag - Kits with presets (`KitV2`) - Preset parameters (`PresetParameterValueV1`) - Backend port rules ## Attack Vectors (Ranked by Feasibility) ### 1. Rescue Mode via Button Combo (Most Promising) - Trigger `ui-int=true` via front panel button hold at boot - Rescue mode may enable full UART console, SSH, or USB network gadget - No hardware modification required ### 2. UART Serial Console - i.MX8MP has 4 UART ports; at least one outputs boot logs (`stdout=serial`) - Need to open the case and find UART pads/header on PCB - Look for 4-pin header near SoC: GND, TX, RX, VCC (3.3V) - Connect with USB-UART adapter at **115200 baud** (standard for i.MX8) - In release firmware `stdin=nulldev` blocks input, but:   - Rescue mode likely enables full console   - U-Boot may have a brief window to interrupt boot (press any key)   - The `bt_or_console` UART mux might be switchable ### 3. Ethernet - i.MX8MP has **two FEC Ethernet controllers** - If RJ45 jack exists (or test pads on PCB), connecting Ethernet may provide:   - DHCP client (check router for new device)   - SSH/Dropbear (if enabled in rescue mode)   - mDNS/Avahi advertisement ### 4. USB Gadget Mode Switching - The DWC3 USB controller supports `dr_mode` (dual-role: host/peripheral/otg) - In rescue mode, the device might expose different USB gadgets:   - `g_ether` / USB ECM/RNDIS (network over USB)   - `g_serial` (serial console over USB)   - `g_multi` (mass storage + serial + network) ### 5. NXP UUU (Universal Update Utility) - If you can get into USB SDP mode (Serial Download Protocol):   - Install `uuu` (`brew install uuu`)   - Can write directly to eMMC, load custom kernels to RAM   - Trigger: some i.MX8 boards have a "boot mode" DIP switch or test pad   - Alternative: short the eMMC data lines during boot to force SDP fallback ### 6. Writable `/data` Partition - If mass storage or rescue mode exposes `/data`:   - Drop scripts/binaries that get executed by the main app   - Modify project files to include payloads   - Add SSH keys or enable services ## PCB Analysis (Teardown Photos) ### Key Components (by reference designator) | Ref | Component | Notes | |-----|-----------|-------| | U1 | NXP i.MX8MP QuadLite SoC | Under heatsink | | U2 | (near SoC) | Support IC | | U3 | SanDisk eMMC 8GB | Under heatsink | | U8 | (near SoC area) | | | U21 | (near J3) | | | J3 | **2-pin header/jumper** | Likely `bt_or_console` UART mux — **most promising debug access point** | ### J3 — Suspected BT/Console UART Mux Located near U21, this 2-pin header likely controls the GPIO that switches a UART between the AzureWave BT module and a debug console: - **Open** (default) = UART connected to Bluetooth HCI - **Shorted/jumpered** = UART connected to debug console ### Test Points - **USNUS_1V8** — labeled test point near U8/U2, 1.8V SNVS power rail - Multiple gold test pads/vias visible around the SoC area ### Board Layout - **Left side**: Audio section (electrolytic caps, Cirrus Logic CS42526 area) - **Center**: AzureWave WiFi/BT module (gold-shielded) - **Right side**: Heatsink covering SoC/RAM/eMMC - **Top right**: Red/black ribbon cable to display/UI board - **Bottom left**: Coin cell battery (RTC) ## USB Disk Mode The Tonverk has a **USB disk mode** (separate from rescue mode) that exposes the `/data` partition: - **Volume name**: `Tonverk` - **Size**: 62.3 GB (wait — device has 8GB eMMC, so this may be reporting wrong or there's additional storage) - **Mount point on device**: `/mnt/sdcard` - **Filesystem**: FAT32 or ext4 (macOS readable) ### Contents of `/data` partition ``` /Elektron/Tonverk Factory Library/   — Factory presets and samples /User/                               — User samples, presets, projects /.system/active_project/             — LevelDB/RocksDB database (RocksDB 8.1.1, aarch64) /Diagnostics/                        — Encrypted system diagnostic logs ``` ### Diagnostics (encrypted) The "Save Diagnostics" option in rescue mode writes gzipped tar archives to `/Diagnostics/`: - Contains `journal.log.enc` (encrypted system journal) and `journal.log.enc.key` (384-byte RSA-encrypted AES key) - Only Elektron support can decrypt these ## Rescue Mode Accessed by holding the main encoder while powering on. ### Menu Options 1. **Reset active project** — clears current project 2. **OS upgrade** — looks for `.swu` file on **SD card** (NOT USB!) 3. **Save diagnostics** — writes encrypted logs to `/data/Diagnostics/` 4. **Exit reboot** — normal reboot **Note**: Rescue mode does NOT expose any USB interface. No network, no serial, no mass storage over USB in rescue mode. ## NXP UUU (Serial Download Protocol) ### SDP Mode Details - **USB VID:PID in SDP**: `1fc9:0146` (NXP SE Blank 865) - **UUU installed**: v1.5.243 (`brew install uuu`) - **BOOT_MODE[1:0] = `01`** → Serial Download Protocol mode - **HAB**: RSA-4096 keys fused (SRK1_sha256_4096_65537_v3_ca), `hab_auth_img_or_fail` — authentication is mandatory ### How to Enter SDP Mode 1. **BOOT_MODE pins** — find test pads on PCB, set BOOT_MODE[1:0] to `01` during power-on 2. **Corrupt eMMC boot area** — via U-Boot or UART: `mmc dev 2 && mmc erase 0 8000` 3. **Short eMMC DAT0 to GND** — prevents ROM from reading eMMC, forces SDP fallback (risky) ### UUU Commands (once in SDP) ```bash uuu -lsusb                    # Check if device shows up as 1fc9:0146 uuu -b spl flash.bin           # Boot custom SPL into RAM ``` If HAB is **Open** (unlikely but possible on dev units), we can boot a custom Linux with SSH directly into RAM without touching the device's eMMC. ## Goal Get full shell access to run custom apps and hook into the audio pipeline (likely PipeWire/ALSA on the i.MX8MP) to add custom audio effects. ## Tools Used - **binwalk v3.1.0**: Firmware extraction and entropy analysis - **sasquatch**: SquashFS extraction (vendor-modified formats) - could not extract due to encryption - **unsquashfs**: Standard SquashFS extraction - **uuu v1.5.243**: NXP Universal Update Utility for SDP mode - **Elektron Transfer**: Official Elektron file management tool ## Files Location - Project root: `~/AI/Tonverk_OS/` - Firmware + extractions: `~/AI/Tonverk_OS/tmp/` - PCB teardown photos: `~/AI/Tonverk_OS/*.webp`

Hardware Teardown: Confirmed Active JTAG Port on the Elektron Tonverk
 
Target Device: Elektron Tonverk (Eimur)
SoC: NXP i.MX8M Plus QuadLite (ARM Cortex-A53)
Firmware Version: Latest (Tested & Confirmed Active)
Objective: Reverse engineering
 
📌 Executive Summary
 
Previous community analysis of the Tonverk OS concluded that custom firmware installation was practically impossible due to fully encrypted .squashfs partitions, signed bootloaders (HAB), and a disabled serial console (stdin=nulldev).
 
However, through physical hardware probing of the PCB, we have confirmed the presence of an active, un-fused JTAG debug port (J7). Tested on the latest available firmware, this port is operating at 1.8V logic and is actively powered by the i.MX8M Plus processor. This provides a highly viable hardware-level entry point for debugging, memory dumping, and potential bootloader manipulation, bypassing the need for the encrypted rootfs keys.
 
---
 
🔍 Hardware Mapping
 
1. The J7 Header
Located near the bottom right of the main PCB (silk-screened as J7, positioned above the QR code and Revision configure pads), there is a 2x5 (10-pin) unpopulated header.
 
· Pin 1 Indicator: The bottom-right hole has a square gold pad (standard pin 1 indicator).
· Pitch: Standard 2.54mm (0.1") spacing.
 
2. Pinout Verification (Multimeter Testing)
Testing was conducted using a digital multimeter, with the black probe grounded to the USB metal shield.
 
· Grounds (Continuity Test, Power Off): Pins 3 and 5 show continuity to ground.
· VREF (Pin 1): Reads 0V. The reference voltage pin is left unconnected on this board.
· Data Lines (DC Voltage Test, Power On): Pins 2, 4, 6, and 8 all read a steady 1.79V.
 
This confirms standard 10-pin ARM JTAG layout at 1.8V logic levels. The presence of steady 1.79V on all four data lines indicates that the internal pull-ups are active and the JTAG interface has NOT been fused off or disabled by Elektron in the latest firmware.
 
🔌 Confirmed JTAG Pinout
 
Based on the testing, the J7 header maps exactly to the standard ARM 10-pin JTAG specification:
 
J7 Pin Signal Standard JTAG Function Voltage State
1 VREF Reference Voltage 0V (NC)
2 TMS Test Mode Select 1.79V
3 GND Ground 0V (GND)
4 TCK Test Clock 1.79V
5 GND Ground 0V (GND)
6 TDO Test Data Out 1.79V
7 NC / TRST Not Connected / Reset -
8 TDI Test Data In 1.79V
9 GND Ground 0V (GND)
10 nRST System Reset -
 
(Note: The stable 1.79V on TCK (Pin 4) without a debugger attached is normal behavior; the CPU holds the clock line high until a debugger initiates the clock signal).