▲ 148 points
back
24 comments
If I were an alien and saw this, I would run. Terrifying.
My brain hurts any time I hear about a completed hardware hack, but this write-up just takes the cake. My experience with hardware RE is limited to a class project hacking a cheap router, and there even after 3 weeks I couldn't make sense of the can of worms that is interfacing with JTAG using OpenOCD. It's like looking at bats and then shouting into the dark and somehow you get the right words for echolocation. Then you do it for 10 animals in a row. I will check out Wrongbaud's guide.
So my question is: how do you learn to speak the dozens of languages for hardware? Every step in this project, from soldering custom modules to figuring out correct JTAG settings to inferring flash layout to reversing checksums, seems like it would take me a lifetime. What was the path to be able to do this in one lifetime?
You read your chips' datasheets that go in detail on pinouts and protocols. You use logic analyzers that capture signals and programmatically decode a multitude of protocols from those signals. When you don't know what are the pinouts or protocols, you compare against similar enough known ones, or bruteforce them.
Some examples:
* Once you've learned a few chip pinouts, you can pretty much guess unknown pinouts just from identifying a few ground/control/address pins, as even chip-on-board globs follow similar layouts [1]. However, despite plenty of datasheet archives being publicly available, none of them allow you to actually search by pin function [2], so you potentially have to go through dozens of datasheets of similar model ids to find what you need.
* UART baud rates that are likely used are in the single digits, they can be easily bruteforced.
* JTAG pins you need to interface with can go up to a dozen or so, there are enumeration scripts you can run in an Arduino to identify which pin has which function. These scripts also identify the IDCODE which you can lookup against boundary scan files if you need so [3]. But in most cases, you will interface with JTAG without thinking of the state machine behind it.
* Reverse engineering memory maps is a matter of following data read/write patterns and inferring associated functionality. You will bump into several address cross-references that also hint at what are the base addresses of each map. It's a more general skill you develop as you go, and Ghidra's decompilation made it much more accessible in the last years. The author went with a elaborate linker script but a more bare-bones approach would be to link code as a distinct ELF object, then copy its text section over to offset 0x20A0000-0x2010000 in the firmware image, and patch the initializers.
* Soldering and associated skills can also be self-learned from tutorials, pick several videos and learn the tricks/mistakes each of them cover.
So, in practice? Each of these does not require a vast amount of knowledge for things to happen, even allowing one to skip required reading of huge bibles that are recommended to electronics beginners. This is how a lifetime gets reduced to a few months of non-working hours.
When getting into hardware hacking, what I felt was the main blocker is how a lot is described at a superficial level, without enough breadcrumbs one can follow to reproduce the same results. Sure, the pictures of spaghetti wires and decapped chips look awesome, but nobody learns from that. Unlike the software side where you are given the source and everything you need to lookup is in front of you.
[1]: https://qufb.gitlab.io/writeups/mysteries
Thanks for this response, this is awesome!
I agree with but extend your last point about breadcrumbs - it's not just that write-ups are hard to find, it's that even several great write-ups for adjacent projects may not be sufficient for a beginner to synthesize a path for his specific project. I spent a week watching YouTube videos and reading in preparation to dump the router firmware, and it still took me 3 days before I committed to actually soldering the wires to the UART contacts - the videos all had header pins! (Sounds dumb, but I'd never permanently altered hardware before.)
In case people are curious, the router automatically gave me a root shell when I accidentally pressed a key during startup once I was connected to UART (using a [programmer board](https://a.co/d/0aVp22Mq)), and I was able to dump firmware using `dd` on one of the device partitions labeled "firmware", then `netcat`ing it out.
I also tried dumping the SPI flash chip directly using tiny alligator clips and flashrom, but I think I literally didn't know to build the latest version of flashrom from source, and so couldn't connect. Maybe same issue with JTAG - old software couldn't find my new programmer board. But I wouldn't have known what to do with gdb access even if I had connected to JTAG! Oh, I also didn't know that I needed to solder together the 2 pins that were specified by the datasheet to activate JTAG - thought I could just hold a wire between them like stealing a car in the movies lol.
Final example of "no breadcrumbs": I wanted to modify the firmware, then flash it back, but I couldn't for several days and the life of me figure out how to repack the firmware after using binwalk to unpack it. Ultimately I flashed something badly formatted out of desperation (maybe wrong size??) and bricked the router. Every guide mentioned "flashing back", but none showed how to do it - I am actually still curious haha, what was I missing?
Isn’t this the basics of embedded engineering ? Nothing here seems magic just an engineer with a good set of curiosity and persistence (maybe people like that are magic though ?)
Posts like this are the reason why the internet and software development felt magic to me as teenager.
This stuff still is magic to me. Wonderful work!
Same but too late I realized almost nobody hires and pays for this type of fun work and I have to do stuff I hate, like migrating pipelines from Azure to Github, if I actually want to pay rent. And now AI can do both the unfun migration type of work and the fun reverse engineering work.
The pipeline to get to this work is starting as a solder junkie for a music store and documenting every repair and custom mod while also reaching out to the big companies for schematics....all while doing the fun stuff as work adjacent hobbies.
Eventually, you make contacts with the technical teams at the big companies and then you start applying....it's a long road, and I have been making audio electronics from scratch since I was 10.
I'm finally making those big industry contacts though, hoping to get in with either Kustom\Hanser or directly into JAM in Alberta (because I'm done with this country)
Wow, that is a deep level of commitment and learning/exploring; I love it. While I'm sure this is informed by deep preexisting knowledge (to a point -- it's still badass in its own right), I can't help but admire these skills and feel a little inferior about my own.
What a badass level of deep dive.
It is so easy to use signature verification and even encrypted XIP with Mcuboot it just blows my mind that companies don’t.
Also the level of reverse engineering here is kinda bananas. I almost don’t believe he was able to find the transfer functions for the dsp bias equations w/o some source guidance. I mean that’s just bad ass if he did it without help.
I followed the code path when you change the cabinet type, and saw it write some values to the DSP based on a 2D array of doubles, one for each cabinet, each with 41 values, and it was processing them 5 at a time. Looking at the values, they were all in the range -2 to 2, and were very reminiscent of biquad filters I had learned about in another project (https://mforney.org/blog/2025-06-06-babyface-midi-protocol.h...) which was still pretty fresh in my mind.
I tried plotting them, and I got something that looked right when I inverted the denominator coefficients. I guess this is fairly standard practice because then the difference equation is all positive sums and it can be implemented with a bunch of multiply-accumulates.
However there were still some discrepancies in overall gain between different types (most lined up, but a couple did not). I saw another array of integers indexed by the cabinet type that had negative values, most with -23 but a couple with -12, which I figured must be a decibel gain correction. It was only after accounting for that and seeing the final graph in the post where everything lined up and looked plausible that I was pretty sure I had it right.
So, mostly just general familiarity with digital EQ filters and a bit of luck.
> just blows my mind that companies don’t
i'm pleasantly surprised when products don't come with all the security features :) hopefully it was their intent and not a fluke.
the amount of hoops hobbyist hackers need to jump through in order to play around is really getting out of hand.
Why should they lock their customers out of their own devices?
Gross mischaracterization. Secure boot prevents malicious images. Also, you don’t own your device. Try reading a EULA some day. If people would stop buying gadgets in protest you would have better collective bargaining to own your device. But people are lazy and can’t go 15 seconds without a dopamine hit so we will never own our devices.
I’m always very impressed by this type of hardware/firmware reverse engineering. So many places to get completely stuck and fizzle out.
I assume that happens a lot, but few people would write a blog about their inability to break a protocol or decipher a memory layout.
Nice :) I did this for my Axe-Fx II and III a long time ago, but I never published any of it for fear of being sued. Really, I just wanted to learn about DSP techniques and that was enough for me.
Sorry WHAT?! I was under the impression this whole time that this wasn't feasible due to asymmetric key encryption with the private keys baked deep into the hardware. Perhaps I'm misremembering but Cliff (the founder) is very big on protecting trade secrets so I'm rather surprised you were able to. Or do you mean you were able to flash new firmware, not reverse-engineer the existing one?
Either way I don't blame you for not writing it up. The same guy just recently accused another industry player of "infringing on [his] idea" with a product because he "filed a preliminary patent". I've been using Fractals since long before they were cool but based on the guy's forum posts I think he's having a hard time navigating the modern internet cultural landscape (the tenuous nature of his legal argument notwithstanding). It's a real shame as he's clearly super talented but I think trolls have gotten to him.
I never encountered any encryption/protection of any kind on the II (had 3 bootloaders: a simple memory loader -> a huffman tree decompressor -> another simple memory loader) and even though I got pretty far on the III I could see there being some kind of key embedded in the firmware somewhere. I was able to disassemble any .syx firmware release that came out. I wrote my own IDA Pro modules for the TigerSHARC (II) and TI-C66x (III). II took a while but I learned a lot. When the III came out I started over. I spent a lot of time reverse engineering the amp block code, but stopped about 8 years ago. Back then he wasn't even compressing the firmware yet, so it was easy.
Love it! I have the THR10 non-"C" version of this amp and often wondered if it's hackable.
I join the adjacents club with my THR5 (also, non C)!
I have always been wondering if I could upgrade it to get closer to the THR10.
It's so portable but therefor lacks a couple of knobs. When using the USB connection and some unofficial controller app that I found somewhere, all the knobs were available!
It would be cool if I could just stick some knobs somewhere on the side and make it do more stuff :) But I've also been hoping the connectors for the knobs may just already sit there, unsused.
This encouraged me to finally open it up and check what I can find.
This is awesome, couldn't the firmware just be extracted from the updater though?
Would love to see this done for the Spark amp as well, this level of hardware hacking is beyond my skill set.
I recently built my own Multi FX app/plugin (https://guitar.soundshed.com) and am looking for ways to squeeze it (or a version of it's signal chain) into commodity hardware as replacement DSP signal chain.
Unfortunately there were no firmware updates for the THR10c, so the only way to get the firmware is to dump it from the device.
at this point you can submit a job application for them :)
Man I love this stuff. I'm not big on digital guitar amps, but digital synths are another story.