![]() |
|
Tonverk ...what I found out some time ago about it - Printable Version +- Elektronmods (https://elektronmods.com) +-- Forum: Elektron Hardware (https://elektronmods.com/forumdisplay.php?fid=1) +--- Forum: Tonverk (https://elektronmods.com/forumdisplay.php?fid=27) +---- Forum: Software (https://elektronmods.com/forumdisplay.php?fid=66) +---- Thread: Tonverk ...what I found out some time ago about it (/showthread.php?tid=87) |
Tonverk ...what I found out some time ago about it - petedorky - 10-23-2026 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`RE: Tonverk ...what I found out some time ago about it - CyberDuck79 - 10-28-2026 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. RE: Tonverk ...what I found out some time ago about it - petedorky - 11-03-2026 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... RE: Tonverk ...what I found out some time ago about it - heavymorphine187 - 11-05-2026 What's the progress? I've tried got so far as to identify 3/5 are gnd ports on j7 RE: Tonverk ...what I found out some time ago about it - misterairplane - 11-05-2026 (10-28-2026, 04:14 PM)CyberDuck79 Wrote: OK, thanks for sharing. It's coherent with what I found. working on op-1f?? keep me posted!! are you in the discord “custom operator”? RE: Tonverk ...what I found out some time ago about it - heavymorphine187 - 11-07-2026 (10-23-2026, 06:56 PM)petedorky Wrote: 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). |