Electribe 2 Firmware Disassembly

Welcome back to this series on probably bricking the Korg Electribe 2!

Last weekend, someone finally got up the courage to install a re-headered E2S firmware on the E2, and it worked (with some exceptions). It’s only been, I don’t know, 6 months since the Korg Forums showed that this was possible? It’s surprising how long it was before someone was brave or stupid enough to risk their $400 toy on this. It’s not much of a hack, since the E2S firmware doesn’t actually give the E2 the ability to sample, and the E2 firmware doesn’t give the E2S any waves, but it paves the way for all kinds of arbitrary code.

Some key things that this news and my own research indicate:

• The Electribes will load any 2mB file into RAM if you ask them to
• Updates are performed entirely from RAM and not program ROM
• The update must include code that directly writes onboard flash, which I haven’t found
• Some functions were disconnected but not removed from the Sampler

Since my last update, I’ve gotten my hands on IDA and started to haphazardly hack away at code I didn’t understand with a tool I didn’t know how to use.

For the first few days, I was just keeping the default options and setting the CPU to an ARMv5TEJ in the “new file” options. This effectively made the assembly impossible to read and led to a large chunk of misaddressed functions and false positive regions. I wasted Monday through Wednesday trying to correct all the false positives and re-define strings.

Ultimately, no amount of redefinition or labeling was going to help, because every address and pointer in the program was to a location between 0xC0000000 and 0xC06000000, while the program itself sat in 0x00000000 to 0x00200000. I was offset by 0xC0000000, which meant that I needed an accessible segment at 0xC0000000.

My assumption here was that the 2mB SYSTEM.VSB file was being written directly to the program ROM on the ARM926EJ-S, and then running to set itself up. For future reference, this is generally not how anything is done in embedded apps. The program ROM is actually only 64kB. In fact, pretty much all of my assumptions were wrong.

Going on those wrong assumptions, I looked up a quick 926EJ-s memory map and found that the range 0xC0000000 – 0xCFFFFFFF is reserved for RAM access. I thought that must be why there were so many pointers to the 0xC******* range, that the program must be loading values into RAM. So I made a second segment in IDA from 0xC0000000 to 0xCFFFFFFF to hold all the things it would presumably load.

That didn’t work.

Now I just had twice as many broken pointers because I wasn’t initializing anything (which meant more false positives). This was the bulk of Wednesday.

Yesterday (Thursday) I brought my work with me to the hackers and asked for help. I got a lot of suggestions that were exactly what I had already done (incorrectly). I knew something was wrong with the addressing, but nobody could give a general solution. I was still operating under the assumption that execution takes place in the program ROM.

I sat at home that night examining the subroutines that weren’t mangled by the broken addressing. One new piece of advice I had gotten was that large jumptables are often entry points, where a program will iterate through the table and pick each option in order. I found an 89-case table and looked at where it pointed.

The first option (and the default case) pointed to 0xC00046E0. The first subroutine below it was located at 0x000047E0. There was no way this was a coincidence. The next subroutines were located at the same offsets, whatever the table said, -0xC0000000 +0x100. It was suddenly very clear. All of the instructions were offset by this value, not just the RAM. The 0xC0000000 represented the position at which the file was loaded into RAM, and the 0x100 represented the first 256 bytes, which were header data, not program.

I made a new file, which would load SYSTEM.VSB at 0xC0000000, skipping the first 256 bytes, and suddenly the graph was flawless. A single chunk of instructions at the beginning and a single chunk of data at the end. I went through and corrected some string identification issues in the data section, and many of the pointers gained names.

Now the big jumptables connected to exactly the prescribed number of subroutines, and some of them even came back together in a single step.

Of particular interest was the filter-switching code. Since the weekend when firmware swap was found to work, people discovered that their Samplers now had access to all 16 filter types. This would be great, if only they had retained their ability to load samples. Unfortunately, the E2 firmware has no such menu or relevant back-end code.

The good news is that the menu system to switch filters still exists in the unmodified E2S firmware. That’s not saying the filters themselves exist, but the fact that switch cases pointing to each menu option still exist bodes well for their presence. I want to dive into these specifically as a proof-of concept, because unlocking the other filters proves that we can recover functionality that Korg half-assedly removed.

Cycling switches like the filter buttons (where each press brings up a series of options in a loop) are controlled by a single variable passed from the main input scanner all the way down to a small switch case which reads it in and jumps to the appropriate option. Unfortunately, the value has to be transformed and handed off about 10 times to go from an input flag to a switch case, each time being effected by it’s current position, the previous switch selection, and a number of offset constants that take the button’s original flag address into account. I spent a long time going over the chain and still haven’t found the source. The good news is that once I find the data that the input chip is responsible for updating (it’s a separate ARM-M3 on a different board), I’ll be able to work downwards from a list of buttons, which should be much easier than climbing the ladder back from a known label.

Right now, climbing the ladder back from anything is the top priority. I can’t do anything until I can hook into button press detection. Realistically, I could just add a branch out that adds additional commands to a filter switch branch, but that doesn’t bring me any closer to a usable standard for extending functionality.

Finally, there is a ton of debug text in the data section, much of which still has cross references in the program. It would be invaluable to hackers if we could find the button combination that triggers these menus. I am still searching for a recovery menu that would allow a user to factory-reset a bricked device.

There’s a lot of work to be done, but I think I’ve passed the biggest walls (which incidentally had nothing to do with the firmware itself) and can now move on to executing these clear, but very time-consuming solutions.

I’m hoping that all this keyword-dropping will bring some other enterprising reversers to this blog. If you’re interested in sharing work, please message me directly or leave a comment. I can’t set up a public repository for this project for copyright and licensing reasons, but I can share key addresses and analysis directly with any interested parties.

Updates that didn’t deserve a new entry:

1. Sadly, there are no references to the sampling menu in the VSB file, which means there’s no code available for the menu itself. It’s possible they stuck this on different chip or just a different segment. Considering that the E2 hack adds the sampling menu to the E2, it would seem that this is yet another thing Korg disconnected but didn’t remove.
2. The main menu is divided into 8 categories, indicated in a bar at the top of the screen. Each category is its own routine which must be unloaded before the new item is loaded. This leads to a visible flicker when changing between categories. Strangely, some submenus are beneath an option, while some are displayed as if they were top-level options. Why there isn’t a “Part Options” and “Pattern Options” category is baffling; it adds around 22 clicks of tedious scrolling.

Update: I’m an Idiot.

Well, there goes most of last week’s work. I was mistakenly disassembling a modified E2 firmware which I had re-headered as E2S months ago. I’d left on my desktop because I was afraid to install it. Man, this is frustrating. At least the key function signatures won’t change. This is both a huge setback but also some encouragement, since it means that the sampling menu isn’t actually missing, I was just looking at the wrong firmware. It does mean that the filter menu isn’t as deep as I thought it was. I’m sorry for making fun of Korg for being lazy, at least until I ascertain that the menu is missing from the real Sampler firmware.

Of interest – the E2 firmware contains names for most, if not all, of the default Samples built into the E2S. There’s no wav data in the firmware, but I thought this was interesting. What use could it have for those names?

11:25am: Good news, the 17-case filter switch code is still there, in exactly the same form. All that changes is the input. I still get to make fun of Korg for this… or maybe thank them. They’ve been sneaking things like this into their products for a while.