Electribe 2 Sampler Firmware Examination

After my previous post, I was excited to check out the E2s’ firmware files, and I’ve already found some interesting things. Using a linux vm and binwalk, I’ve been exploring the contents of the file. I don’t really know much about this, but there are a few things that seem apparent:

1. Binwalk shows a DEF, x509 v3 encoded certificate. I have no idea what this means or if the Electribe even cares about it, but it is important. More on that later.
2. Korg pretty much never cleans up after themselves. The file is full of paths from the development environment that I’m pretty sure don’t belong in firmware. Names for seemingly random selections of .cpp files are given.
3. There are numerous references to features that are supposed to be E2-synth exclusive, notably the inclusion of multiple filter types. (MS20 LPF, MG LPF, P5 LPF, OB LPF, Acid LPF). There’s also settings for amp emulations. I don’t know why the strings would be here if the code that relates to them wasn’t, but the menu system might be discrete from the sound system.
4. A long set of menu items for testing and debugging still exists in the firmware, but not necessarily the code (just like with the previous two items). References to touchpad calibration, boot diags and hardware diagnostics are visible.
5. They forgot to correct the typos in the sample names “Painochord 1” and “Painochord 3” for 6 versions, but somehow they caught and updated “Pianochord 2”
6. There’s a string-formatted template for some kind of memory dump near the end of the file, presumably something readable they could get over a serial connection.

JobTime
HostIfInfo
HostIfDump
ChkRndPhase
Help

Start=
,End=
,Size=
Status :%04X
Command:%04X
%04X
Write %d
%08X %08X
Error !!
[[[ exit ]]]
MemoryDump Start,End[,L(=long:default)|W(=woed)|B(=byte)]
SendDSP [adrs,data]
Address +3+2+1+0 +7+6+5+4 +B+A+9+8 +F+E+D+C
Address +1+0 +3+2 +5+4 +7+6 +9+8 +B+A +D+C +F+E
Address +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
Clear JobTime[PK]
%d : %5lld : %5lld(nsec) : %5lld(peak)
m_HostIfCnt:%02X
HOST_CONTROL:%04X
HOST_STATUS :%04X
DMA1_CONFIG :%04X
DMA1_START_ADDR:%08X
DMA1_X_COUNT :%04X
DMA1_X_MODIFY :%04X
DMA1_IRQ_STATUS:%04X
Buffer 0x%08x : 0x%08x
[[[ X-11100 (DSP#%d) ]]]

So that’s what I know so far. Not sure what any of that means or if it’s actually worth the effort, but right now I think it’s a bad idea to try installing a modified SYSTEM.VSB file. Nothing about the structure says that Korg made any effort to secure their hardware, but it’s very possible that their ARM toolchain did that for them. Even if they weren’t careful enough to keep invalid files from installing, there’s a chance the hardware will keep them from running. Honestly, this is pretty careless of Korg, and considering the reports of failed updates bricking devices, it’s probably losing them money too.

The good news is that nothing is discernibly encrypted. The strings are visible everywhere and there’s a block of 600+ unobfuscated ARM instructions. Once I’ve done enough research and decided that it’s time to try my luck with installing, there should be some good points of entry to mess with the code.

After picking through the file further with binwalk, it has now come down to a question of whether or not the certificate actually exists. Although it is detected and shows the makings of an X509 asn1 DEF encoded certificate in the first 8 bytes, it breaks down after this point. It contains no information besides the pattern “30 82 XX XX” repeated twice. In the DEF standard, that means “Item type = sequence”, “2 length bytes follow this number”, “Length bytes go here”. Basically, it says that the sequence is 0hXXXX long starting just after the last XX byte.

But here’s the thing: the start of the certificate is odd-byte aligned, that is, it starts at an odd offset in the file. This is false positive flag #1. Then, when I extracted (with –dd) the cert from the binary, binwalk couldn’t find an end, so it just exported everything after the header. This is flag #2. Finally, when I cut the file down to a reasonable size by chopping off everything after the greatest “sequence length” value and passed the file into openssl using asn1parse, it found that only those first two blocks were valid headers, and the next bytes were unreadable. Since I’ve done an MD5 check and ensured the file isn’t corrupt, this is the third nail in the coffin.

The next thing was to check for other types of data in this same region. For what it’s worth, binwalk believes that the region is full of ARM instructions. If this were simply true, then it would be the end of my worries. Unfortunately, it’s not this simple, since the ARM instruction signature could be a false positive itself. The instructions overlapping the supposed header look pretty realistic. Long lists of “mov” and “add” with other short functions interspersed. The false-positive for the header would have arisen from a pair of str functions being read with an offset of 1. The key code was:

tst r3, #2
lsrne r3, r3, #1
lsreq r3, r3, #2
movne r0, #1
strne r3, [r2]
streq r3, [r2]
moveq r0, #2
bx lr

Which is a simple if/else setup. I think strne and streq are redundant, but the compiler didn’t want to break the comparison “parenthetical” surrounding these 6 instructions. I don’t really understand assembly, but I’m pretty sure that this is reasonable, functioning code and not garbage. It starts with a test condition and ends with a break, and that’s as much as I care about. That makes red flag #4 and brings me a step closer to believing that this file has no digital signing.

And with that, things are looking pretty good. I’m going to run my findings by some security and ARM experts tomorrow and see if they think otherwise. Even with thorough preparation, there’s still a pretty big emotional component to experimenting on my own (expensive) hardware. I know Korg covers failed flashes under the warranty, but I’d feel guilty sending it in if the flash failed because I was screwing around.

Update, 8/27:

After discussing the data with some experienced reverse engineers tonight, there weren’t any revelations, but there was definitely some reassurance. They expected that I was trying to crack into obfuscated or secure code, and had a good laugh at Korg’s expense when I showed them the binary. We also took a look at the online pictures of the PCB to see if there were any obvious JTAG/serial ports for future use. Right now, my plan is to get a working copy of Tribely out before I do anything to modify the device, because having to send it in for service would really slow down development. Once I’ve got that out the door, I’ve got to borrow IDA from someone to do a final runthough of the firmware before I actually try to install it.

Next In this series: Extracting Bitmaps from a Firmware Binary