I really like my Electribe 2. I know, it gets a lot of hate from the EMX/ESX lovers, but the workflow really suits me, and, as you might know, I’ve got a heart for underdogs, especially when they are from Korg – don’t you think that even Korg’s blunders are more interesting than Roland’s successes?

StableDiffusion 1.5 hallucinating the hell out of an Electribe with IMG2IMG and “Superman Drum Machine” as prompt

Which doesn’t mean that Korg does everything right. As Electribe users know, you have to make up your mind: 

• Do you want the (blue or grey) E2 synth (“BlueTribe”), or
• the (red or black) E2S sampler (“RedTribe”)? 

The RedTribe sampler, gravitating a bit more towards hip-hop compared to the dancefloor-oriented BlueTribe, is generally more flexible – but you have to sacrifice the BlueTribe’s many additional filter types and synth oscillator models.

Which is a real shame considering that the hardware for BlueTribe and RedTribe is absolutely identical – apart from the colour scheme and the built-in samples. You can even crossgrade from BlueTribe to RedTribe and vice versa (involves a bit of hex editor manipulation and a sizeable risk of bricking the Electribe, but it’s doable – I did it once before settling on a black RedTribe for good).

So why doesn’t one just analyze the firmware, and copy&paste the BlueTribe goodness to the RedTribe ROM? It’s that kind of project you dream of for about 15 seconds until you realize how cumbersome this really is, and that it would be madness to commit yourself to that kind of ambitious hacking project.

Luckily, bangcorrupt has already done just that.

Behold: The Hacktribe!

In case you lived under a rock and haven’t heard of it: Hacker bangcorrupt has analyzed the Electribe’s bootloader, finding the requirements for installing modified firmware. And he modified Korg’s 2.02 Electribe Sampler firmware, adding the BlueTribe’s extra capabilities concerning filters and oscillators to it – and even more: VPM, Korg’s version of FM synthesis for people without a degree in acoustics.

It’s as simple as downloading the factory firmware, running a Python script that patches it, and updating your E2 to the Hacktribe firmware. If you want to keep running your existing RedTribe patterns, I created some small additional scripts for that – my tiny contribution to the project – and you will find soon find a step-by-step tutorial as a Python notebook that you can just click-and-run on Google Colab, saving you the intimidating Python installation business.

But for the moment, let’s geek out for a bit: I reached out to bangcorrupt, the hacker who did this, and asked him how he did the hack.

Hacktribing your RedTribe

We were communicating via mail – he answered my first set of questions – which were originally intended just to tell him what I wanted to know – in bulk. These are his answers; I’ve just added some links and notes in italics and square brackets where I felt like it. Everything else is bangcorrupt’s answers.

Q: How did you get the idea of doing it?

bangcorrupt: I got the idea from the firmware swap posted on korgforums years ago.
I wanted to create a hybrid based on the latest firmware version, with some added features and configuration options.

[With the first couple of firmware revisions, it was quite easy to swap the firmware of a RedTribe for a BlueTribe; with v2.02, Korg added checks to keep you from crossgrading, so you had to do a bit of hex editing and downgrading to do the swap. It was quite a feat and, honestly, not worth it, as you wouldn’t get the samples of the other machine – these seem to be stored in ROM, separate from the firmware. While it is quite easy to get someone with an E2S to perform an “Export All Samples” for you, I have not seen the BlueTribe factory sample set in the wild yet.]

Q: Why didn’t you just stop when you realized how overwhelmingly complex the whole thing would become?

[Think about it.The Electribe is a complex machine – see this hardware breakdown in the Korg forums from 2015 which is one of the first things a prospective hacker might end up with. It hasn’t got just one microcontroller but three: The main processor is an ARM9 processor called AM1802 (datasheet), accompanied by a Blackfin 523 DSP from Analog Devices (datasheet) – a type of microprocessor optimized to process real-time data. There is also an additional feeble ARM Cortex M3 reading the front panel dials, which we may safely ignore if we’re lucky. Scanning the datasheets, you will find all sorts of scary words like “protecting code integrity”. There is obviously some kind of bootloader involved which you have to analyze to find out what it accepts as a firmware, and how it is loaded into memory. And once you mess things up, there is a considerable risk of bricking your Electribe for good – which did indeed happen, see below.]

bangcorrupt: Once I started seeing patterns and how they interrelate it was difficult to stop. I was really obsessed with it for a while; hopefully I can find the time to dedicate to taking it to the next level.

Q: Did you have a background in microcontroller development before?

bangcorrupt: I had a basic understanding of computer architecture and electronics, but most of what I know about microcontrollers and reverse engineering comes from working on Hacktribe.

[Which I, as a full-blown blunderer and tinkerer, find wonderfully serendipous and inspiring.]

Q: What were the challenges in doing it?

bangcorrupt: Everything. I’m learning how to do this as I go along, most of the tools and protocols are new to me. At one point I bricked my electribe and had to hack some other things to learn how to fix it.

Q: What kind of tools does one use for rewriting Electribe code?

bangcorrupt: A J-Link or a Raspberry Pi running OpenOCD will work as a JTAG debugger for the CPU.

[Let’s stop here for a moment and explain what a JTAG debugger actually is. Imagine you have some sort of program, and want to see what it does – especially if it doesn’t do what you want it to do. In that case, it would be handy to stop the code and look at registers and memory.

As long as the program is still running on your desktop computer, you can simulate and debug your program there, but once it has been transferred to the machine, you will have to use special hardware to do that.

When I did my first 8-bit development project some 30 to 40 years ago, we had to buy a murderously expensive type of hardware called a Z80 In-Circuit Emulator, a blue box that could act as a microcontroller in my machine but kept transmitting data on order to a PC. It has become much, much simpler these days, as all modern microcontrollers have a standard serial interface called JTAG. It takes orders and code, and transmits data if you want to talk to the processor, but you still have to have special hardware and software which does the talking.]

bangcorrupt: I couldn’t get the Raspberry Pi [running the OpenOCD JTAG debugger] working with the Blackfin DSP, but thanks to people sponsoring Hacktribe I was able to buy the official Analog Devices debug adapter.
Raspberry Pi will also work with the Cortex M3 on the panel board, but I want to try using Black Magic Probe [an open-source standalone JTAG debugger for ST Micro’s M3 hardware and others] on an STM32F103.
On the software side I’ve been using Ghidra for static analysis, with Rizin for patching and debugging.

[What is this for? The original programmers wrote high-level code in languages like C, and probably low-level Assembler code handling single processor instructions, before compiling and assembling their program code into the string of bytes in the SYSTEM.VSB file. Disassembler frameworks like Ghidra – by the NSA, for god’s sake! – and Rizin help you turn back these bytes into readable code, much like turning a meal back into a recipe – so you end up with code that your brain can process, and the JTAG debugger which helps you watch what it is actually doing. This gives you a good chance to understand what the code does, and how to expand it.]  

Q: How much of what your HackTribe code does was already in there, and what did you have to write from scratch?

bangcorrupt: This is hard to answer, it’s all interlinked. At the start I was hex editing the binary directly, changing pointers and conditional tests to run existing functions with new data. I’ve started reworking it into separate assembly code; the most new code I’ve written is probably for NRPN handling or FX editing. Even here I am using the existing functions as much as possible, just calling them in a different order with different arguments.

Q: And have you got a clue what the hell Korg thinks about all this?

bangcorrupt: I have nothing to do with Korg. I try to stay within the law and the license agreement, and as far as I know I have.

bangcorrupt’s answers are printed as they were given. All errors in the italics are mine.