u/tntexplosivesltd

Ongoing project reverse-engineering the Valeton GP-200 (NXP i.MX RT1062, Cortex-M7). The last public release had a single mod in it. This one has eight, and it covers the LT as well as the full-size pedal.

At the end of the tuner post I said the LT was a different product with different firmware, that I did not own one, and that I would like to hear from anyone who did. People turned up. I traced the LT support in this release against Valeton's own LT image, and then LT owners proved it on their pedals rather than me on mine. That is a weaker standard than I have held the GP-200 mods to, and you should know which one your build got.

Those people put unreleased firmware on pedals they paid for. When I asked how they wanted to be credited, not one of them asked for it and several told me not to bother, so there is no list of names here. They are the reason the LT is in this release at all.

What you can tick:

• Tuner. Stock lets a note sit a full 5 cents off and still show solid green. This tightens that to 1.5 cents, mirrors tuning state onto the footswitch LEDs, and adds an optional strobe display.
• Carry-over tap tempo. A Global Settings toggle makes a tapped tempo follow you across patches instead of resetting. It never rewrites your patches.
• Footswitch labels. A/B/C/D show the name of the patch they switch to, and CTRL 1-8 show the block they toggle.
• Fast patch change. The fade-in after a patch load drops from 113 ms to 9 ms. It is still a ramp, so it still suppresses the switching click.
• Global output balance. A cut-only left/right balance on the main outputs. USB recording is untouched.
• Language unlock. Restores the full language list on units that shipped with it restricted.
• Brazilian Portuguese. Replaces the pedal's built-in Spanish menus in place. No other language changes.
• Factory-reset cleanup. A reset now clears mod settings too.

The mechanics are unchanged. It is one self-contained HTML file that you open from your downloads folder, with no server and no network calls. It works out which pedal you have from the SHA-256 of the firmware file you load, so it cannot hand you a GP-200 build off an LT image or the other way round.

One thing did change. Previous releases produced exactly one file with one known-good name, and the README told you to check for it. With eight mods to pick from that check means nothing, because every combination produces a different file. So the file is now named after the first eight characters of its own SHA-256, and the page prints the full fingerprint when it builds. The file checks against itself.

The GP-200JR is still unsupported. It has its own firmware, nothing here has been built for it, and the patcher refuses a JR image rather than guess. If you have one please get in touch.

There is a companion post going up at the same time. Two of these mods, the output balance and the carry-over tap tempo, have to hold a setting across a power cycle, and the GP-200 has no separate place set aside for that. Where a setting can actually live turned into the more interesting half of the writeup: https://gp200-reversing.hashnode.dev/eight-mods-and-how-the-pedal-saves-your-settings

Patcher: https://github.com/tntexplosivesltd/gp200-patcher/releases/tag/v1.0

Previous posts: Post 1, Post 2, Post 3, Post 4, Post 5, Post 6, Post 7

Sixth post in an ongoing series reverse-engineering the Valeton GP-200 multi-effects pedal (NXP i.MX RT1062, Cortex-M7).

This is the one where "can this be modded" finally gets a yes you can use yourself, not just a proof of concept on a bench.

What's in it:

• Full RE of the front panel: the LED frame format behind every footswitch and effect-block indicator, and the complete 20-screen registry decoded id by id, including two screens with no normal menu entry, a live on-screen debug log and an undocumented factory hardware-monitor/QC mode.
• How the tuner actually works internally, including why a note at 0, +3, and +5 cents produces a byte-identical screen on stock firmware, and the deadband/box-range coupling that had to be solved together to tighten the tuner without shrinking the display's range.
• The mod itself: deadband tightened from 5 cents to 1.5, tuning state mirrored onto three footswitch LEDs, and an optional strobe-style display, built from a single retargeted call into unused flash space.
• A self-contained patcher that runs entirely in your browser: point it at your own stock firmware image, and it verifies and patches it locally.

Only verified against the full-size GP-200 so far, not the LT or JR (different firmware entirely, not just a smaller panel). If you own one of those, I'd like to hear from you.

Download the patcher and full writeup: https://gp200-reversing.hashnode.dev/the-front-panel-and-a-tuner-that-actually-locks

Previous posts: Post 1, Post 2, Post 3, Post 4, Post 5

Fifth post in an ongoing series reverse-engineering the Valeton GP-200 multi-effects pedal (NXP i.MX RT1062, Cortex-M7).

The previous post finished reversing the firmware-update protocol. This one asks the next question: if you understand the protocol completely, what does it take to build your own firmware tooling that can safely write to real hardware?

What's in it:

• Designing a firmware patching and update pipeline around recoverability, with each stage validated before the next depends on it.
• Building the tool module by module: locating patch targets inside an update image, applying same-length patches, packing valid SysEx update streams, and implementing the transport layer.
• Using offline golden-reference testing to verify generated firmware traffic before attempting a single write to the device.
• The first real hardware bring-up, including the kinds of problems that only appear once software leaves the bench and meets a physical device.
• What actually constitutes proof that an independent firmware updater works.

This is the post where the project stops analysing the updater and starts building one. It's less about reverse engineering than about turning reverse engineering into engineering.

Full post: https://gp200-reversing.hashnode.dev/building-gp200fw-design-build-and-a-firmware-patch-that-boots

Previous post: Post 4

Fourth post in an ongoing series reverse-engineering the Valeton GP-200 multi-effects pedal (NXP i.MX RT1062, Cortex-M7).

Previous post pulled the full flash dump and settled the secure-boot question at the fuse level. This one decodes the resident MIDI updater built into the app firmware itself, the protocol Valeton's own official updater speaks to flash a new image over USB-MIDI.

What's in it:

• Full command-set decode of the resident update dispatcher, the USB-MIDI SysEx protocol it runs, and the four-region flash partition map behind it.
• The mystery that took the whole post to close: a hidden extra byte on every 180-byte data block, checked before the device will write a single one. An exhaustive empirical attack against tens of thousands of captured blocks ruled out every standard checksum/hash family and still came up empty.
• The tool that cracked it, and the false lead it took to get there once the actual firmware code was finally in hand.

This is the post that unblocks writing to the device, not just reading from it. The actual proof-of-mod tooling is next.

Full post with the command tables, protocol details, and full derivation: https://gp200-reversing.hashnode.dev/decoding-the-updater-and-the-byte-that-fought-back

Previous posts: Post 1, Post 2, Post 3

Third post in an ongoing series reverse-engineering the Valeton GP-200 multi-effects pedal (NXP i.MX RT1062, Cortex-M7).

Previous post got a working SWD connection over the debug port. This one uses it to pull the entire 8MB external NOR flash and go after the question the series keeps circling: is there a cryptographic barrier to running custom firmware on this hardware, decided at the chip level rather than guessed from the update file's format.

What's in it:

• Full flash dump via OpenOCD (dump_image against the RT1062's FlexSPI-mapped range), verified against five independent checks before trusting it: boot config tag, IVT self-consistency, a signature pointer, a byte-value histogram ruling out on-the-fly flash encryption, and legible version/product strings matching known hardware.
• Why a null code-signing pointer in the image isn't enough by itself to answer the security question, and what it actually takes to settle it properly: a direct, read-only eFuse dump over SWD, no programming registers touched.
• An unrelated side-finding that came out of loading the full dump into Ghidra, about how this firmware actually executes at boot, that has nothing to do with the security question but changes how you'd think about attacking the update path.

Also touches on a community patch project that's already pushing modified firmware onto real hardware through Valeton's own official updater, well before this project's own tooling exists, credit where it's due.

Full post with the actual commands, register values, and reasoning: https://gp200-reversing.hashnode.dev/flash-dump-secure-boot-state

Previous posts: Post 1, Post 2

Part 2 - Inside the GP-200

https://gp200-reversing.hashnode.dev/inside-the-gp-200

Here is part 1 of a blog series I am writing about reverse engineering the GP-200:

https://gp200-reversing.hashnode.dev/the-gp-200-landscape