Patching an embedded synthesiser OS from 1996 with Ghidra

If you&#x27;re ever wondering what the load address of a piece of code is, my favourite trick is to:<p>1) identify relative addresses of all C-style strings from the start of the binary<p>2) identify all absolute read addresses<p>3) find the load address where the most read addresses correspond to the most strings<p>This solves the problem for me in the vast majority of cases. If you don&#x27;t have strings, function prologues work as well.<p>I don&#x27;t think there&#x27;s any tooling for this yet. I&#x27;ve had to write the same algorithm over and over. It works regardless of any header information at the start of the binary, though it will fail if there is data between chunks (but you may see multiple valid alignments that can hint to something like this happening)

I wish I had seen this article sooner. It’s a really nice and succinct primer to some of the basics of using Ghidra for firmware analysis.<p>I have an expensive robotic cat toy that the manufacturer stopped supporting and I’ve been working on reverse engineering the firmware in my free time to better understand how it works. I have no background in reverse engineering so I’ve been learning a lot about identifying hardware, reading data sheets, and of course fumbling through Ghidra to disassemble the firmware.<p>After getting your bearings it becomes pretty easy to recognize the patterns of various standard C library functions like strlen, memcpy, etc. Others can be more challenging. Of course, with bespoke embedded hardware it can be much more difficult.<p>Ghidra really is an amazingly useful tool (clunky, yes — but very powerful and of course it’s free.) It makes me curious about commercial offerings and if they are worth buying as a hobbyist.

Another interesting project along these lines is a couple of hackers managed to reverse engineer the firmware for the Elektron Machinedrum (a classic early 00’s digital drum machine) and add a bunch of new functionality, such as new effects, a melodic mode and more.<p>You can download it from <a href="https:&#x2F;&#x2F;www.elektronauts.com&#x2F;t&#x2F;machinedrum-sps1-uw-x-06-released-unofficial&#x2F;159097" rel="nofollow">https:&#x2F;&#x2F;www.elektronauts.com&#x2F;t&#x2F;machinedrum-sps1-uw-x-06-rele...</a>. They’ve unfortunately kept the details of how they did it somewhat private (I believe at the request of Elektron), though some notes on their initial reverse engineering can be found here: <a href="https:&#x2F;&#x2F;github.com&#x2F;jmamma&#x2F;MIDICtrl20_MegaCommand&#x2F;issues&#x2F;88" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jmamma&#x2F;MIDICtrl20_MegaCommand&#x2F;issues&#x2F;88</a>

Shout out to Hex Fiend! My favorite feature is the template system[0]. It makes it much easier to figure out file formats for which you have no documentation. You write a little tcl code to describe the parts of the format you understand as you go.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;HexFiend&#x2F;HexFiend&#x2F;tree&#x2F;master&#x2F;templates" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;HexFiend&#x2F;HexFiend&#x2F;tree&#x2F;master&#x2F;templates</a>

Very cool! This is really great work! It&#x27;s awesome that there&#x27;s been so many synthesiser related topics on Hacker News lately. I did a similar project myself to disassemble, and fully annotate the firmware for the Yamaha DX7: <a href="https:&#x2F;&#x2F;github.com&#x2F;ajxs&#x2F;yamaha_dx7_rom_disassembly" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ajxs&#x2F;yamaha_dx7_rom_disassembly</a><p>The biggest hint I could give anyone looking to disassemble a synthesiser operating system is to direct your attention towards the code processing individual MIDI messages. The code is invariably is <i>huge mess</i>, however you&#x27;ll be able to very quickly identify the operating system&#x27;s core functions, since the corresponding SysEx parameter numbers clearly identify what functionality you&#x27;re looking at.

Just this afternoon I was working on reversing a closed source library that wasn’t working on M1 under Rosetta, using Ghidra. If you get the chance, you should do a post on how you actually modified the program to get it to do what you want (as long as the fix isn’t trivial, like changing a constant).<p>My exercise today made me realize just how much more difficult the modification of the binary is than simply understanding it, as well as how much I hate the x86 architecture (and CISC in general).

Cool!<p>It&#x27;s unfortunate that he wouldn&#x27;t share what the goal was - what he wanted to patch and why.

Another approach for reverse engineering the format of the KOS file might have been to run the bootloader code through a 68k emulator, step through it with a debugger (and resolve any undefined syscalls or built-in functions etc.), and observe what it&#x27;s actually doing.

if you&#x27;re into this I highly recommend checking out Bob Grieb&#x27;s work[1]. He has reversed MCUs on many vintage synths and has a website dedicated to his explorations. Really impressive stuff...<p>[1]<a href="http:&#x2F;&#x2F;tauntek.com&#x2F;synthesizerinfo.htm" rel="nofollow">http:&#x2F;&#x2F;tauntek.com&#x2F;synthesizerinfo.htm</a>

Interesting, the checksum looks like a standard LFSR but uses addition instead of XOR.<p>1) Seed checkum with initial_value<p>2) Add a data uint sized to the checksum<p>3) Shift up by 1 bit while feeding back the MSB to the LSB.<p>4) GOTO 2 until you have consume all the data.<p>Not sure why you would process with usual addition instead of GF2 addition.

This is very, very impressive.<p>But I am almost existentially disappointed by the opening sentence - ‘For reasons I won’t get into’…<p>It’s like - <i>why</i>?<p>The reasons we drive ourselves to do these frankly insane hacking experiments are almost always as interesting as the process itself for me.<p>The reason for that is - in this case - there are literally thousands of sampler synths with frankly a shitton more features than even what OP has implemented - why use this particular one?<p>The turntablist community - for instance - vastly prefers a frankly ancient and specific model of turntable (Technical SL-1200 or equivalent) - therefore the community to mod and update this decades-old hardware is dedicated and does similarly amazing things.<p>The SL-1200 is preferred for its build quality, it’s amazing motor, it’s weight; and it’s reliability.<p>It however <i>lacks</i> some frankly essential features from newer turntables - reverse, ultrapitch, pitch lock, USB support - but it’s still the most highly sought after and standard unit for the craft.<p>What makes this particular synthesizer the same - so valuable, so irreplaceable to OP’s craft - that drove them to such an insane level of deconstructing and reflashing the software? I, like - <i>must know</i>…XD<p>I mean - cool flex - but <i>why</i>?

Very cool!<p>My observations:<p>- The renaming into *source = *destination was very confusing.<p>- I expected (sweet, sweet) 68k assembly, but it&#x27;s all decompiled to C!<p>- For some reason MAME supports this musical instrument, and OP&#x27;s work helped that project boot their emulation, sweet!

That synth was the Rolls Royce of synths in the 90s. Price wise at least. It seemed like it could do anything at the time.

If someone digs into MOTU synth firmware there is a an easter egg picture of a couple of dogs. No idea how to access it but I&#x27;ve seen it.