Yesterday, Korg released a firmware update to their ribbon controller synth, the Monotribe. The firmware is just an audio file that needs to be played to the sync input of the box. [gravitronic] thought this was rather interesting, so he decided to decode the monotribe firmware. It’s the first step to custom Monotribe firmware, and on the path towards reverse engineering this neat box.
After converting the firmware update to a .wav, [gravitronic] looked at the file with a hex editor and found that each sample is two bytes, and the left and right channels are the same. That made enough sense, so after getting rid of one channel, he sent it through Python to take a look at the patterns of ones and zeros.
Of course, [gravitronic] arbitrarily chose high = 1, low = 0, and little-endianness. The first result didn’t produce a nice “KORG SYSTEM FILE” in the header, so he tried other combinations until the output file looked reasonable. The result is the actual .bin file that’s going to serve as the basis for a nice homebrew firmware. You can grab [gravitronic]’s Python script here and decode your own firmware.
“[gravitronic] though” missing a ‘t’ at the end there.
Interesting! Korg was nice enough to publish the schematic for the monotron mini-synth, but they seem to be a bit more reserved with this one…
They could have licensed some code from a 3rd party which restricts its publishing.
Pretty neat update system by Korg and nice work by gravitronic on decoding it.
I’d be wary about making any replacement firmware for it until its determined whether there is a safe fail bootloader which will still allow you to reflash via this audio input. You don’t want it to be wedged and then have an urgent need to take it apart to probe for a serial or JTAG interface.
High and low and what? I am from Indiana.
Endianess. You know, whether you eat your eggs from the big side or the little side.
Actually, it’s the direction of bit encoding. Is the first bit the most significant or least? It’s the difference between ‘1’ and ‘128’ in a 8-bit stream.
It’s whether the most significant BYTE leads. Not bit.
256 can be 0x0001 or 0x0100. Either way within the BYTE the 1 is the last bit.
@Gdogg,
Wikipedia says it can be either, though when people talk about big endian or little endian machines it’s byte order like you said. I was taught about it in a digital logic course, and it was bit order, not byte order. Bit order is very important when you work with a shift register…
It’s both.
In computers where you deal with bytes, it’s bytes. in electronics it’s bit.
0100 and 0010 are the same thing depending on endian. and those are nybbles.
@John Ah, so it is. Good to know. I’m purely a software guy though :)
Gravitronic’s post shows the entire sequence of commands he used to decode the data. Hack A Day’s summary misinterprets some of his early processing steps as being the format of the firmware data. The important thing he played around with was whether short square pulse = 0 and long square pulse = 1, or vice versa.
The hex editor part was just a preliminary glance at the raw wave data. Gravitronic could have known beforehand what byte size and endianness the faad conversion command was outputting, but just quickly guessed by looking at the data in a hex editor. And looking at the wave in Audacity was an alternative way to tell the left and right channels were the same.
When playing around with the wave data he did arbitrarily choose high = 1 and low = 0 in his first processing step. But the important part was later on when he chose short square pulse and long square pulse as either 0 or 1. The high/low choice had no effect on the lengths of the square pulses.
When analyzing the square pulse lengths, he first tested short=0, long=1, and endianness=big, but didn’t find an obvious text header as he was hoping for. His final Python program is used to play around with assigning short and long square pulses to 0 or 1, skipping possibly unneeded start bits, and testing endianness. A comment in the Python program says the working combination is “short 1, long 0, skip 0, little 1”.
Pretty much!
My blog post leaves out a LOT of the things I tried that were dead ends but I wanted it complete enough to explain what’s up to someone who has never reverse engineered a binary file before.
The part that took the most time was figuring out that a 1 or 0 was indicated by wave length and not bit value over time indicated by whether the signal was high or low.
Most likely FSK – what were the two frequencies (inverse of wave length or period)? One trick – in audacity run an FFT, you’ll probably see two big spectral peaks, corresponding to the 0/1 frequency encoding.
Wait, wait; why does this have firmware? Aren’t these mono ribbon synths all analogue? Isn’t that the entire point?
Oh, the microcontroller just controls the analogue synths. Right, that makes sense.
I so want one of these for Christmas, just looking at the firmware update from Korg tells me this thing is going to be a hacker’s paradise like the original monotron.
I’ve just bought one of these (not arrived yet).
So what’s all this about a firmware upgrade?
Have you guys tried holding down 1 & 8 on the sequencer and turning the monotribe on? You have to hit the power button twice, but then it powers on and makes noise, and boots into some sort of weird mode… Wonder if it’s a testing mode or something like that. Just thought I’d see if anyone else tried that.
That’s interesting! I think the weird noise is part of the auto-tuning system – if you use an audio probe to listen to the VCO wavforms (directly from the lm384 inside the ‘tribe) then you can hear the same noise constantly cycling whenever there’s no sound being played.
I agree, it’s probably some kind of test mode or diagnostics.
I’ll have a probe around inside next time the monotribe’s opened up. Maybe it’ll be useful somehow?
Thanks for sharing :)