Rooting the KORG Kronos



Dienstag, 26. Mai 2015

About the Linux kernel used in KORG Kronos

It is well known that KORG's Kronos Synthesizer uses a (more or less) standard Intel Mainboard/CPU for a large part of its functionality. The Intel CPU is running the Application Software with the User Interface, handles Storage and USB Host / Network connections, generates the synthesizer voices and does all the effects. Inside the Kronos, there is also a OMAP CPU that connects most of the audio related I/O Ports (Analog Audio, MIDI, USB Device). This OMAP CPU is connected to the PC as an USB device.

If we look at the software running on the Intel CPU, it becomes pretty clear that there is a Linux Kernel with RTAI realtime extensions. KORG provides the source code for the kernel and the RTAI extensions on the recovery discs as required by the GPL. However, if you try to replace the Linux Kernel with a kernel you compiled yourself, this will not work. To prevent people from modifying their Kronos, KORG did some subtle changes to the Linux kernel that make it impossible to load the driver modules for the OMAP CPU into a kernel that was not compiled by KORG.

The first problem we have do deal with when replacing the kernel is that KORG does not provide the kernel configuration file. It is also not included in the original kernel. This might be regarded as a violation of the GPL since the kernel configuration is clearly a source file required to build the kernel. Futhermore, KORG has modified specific functions (register_cdrom() and init_cdrom_command()) to provide some kind of Challenge/Response authentication mechanism. The driver modules call those modified functions and expect a certain behaviour that only the kernel compiled by KORG exposes.

This is a clear GPL violation since the modifications done to the kernel are not provided with the binary.

The register_cdrom()/init_cdrom_command() mechanism works like this:

  1. Proprietary module calls register_cdrom() with a magic number in cdrom_device_info.for_data to identify itself to the kernel
  2. register_cdrom() writes a pointer to a statically allocated struct cdrom_generic_command into cdrom_device_info.handle (acutally, the pointer is obfuscated by some bitshifting and offset adding) and returns the (otherwise unused) errorcode -42
  3. Proprietary module inserts another magic number into the *(struct cdrom_generic_command) retrieved in step 2 and calls init_cdrom_command() with that pointer as argument
  4. init_cdrom_command() does a lot of obfuscation, looks up some magic values in static arrays and returns some values by writing them into the static struct cdrom_generic_command
This mechanism is used mainly by loadmod.ko - a proprietary module that is responsible for software update and software encryption. The module refuses to load if register_cdrom()/init_cdrom_command() are not implemented as described above.It also uses the scrambling done in init_cdrom_command() to deobfuscte the keys required to loop-mount Eva.img, Mod.img and WaveMotion.img after reading those keys from the security IC.


  1. Have you considered reporting all the GPL violations to the folks at so their lawyers can draw Korg's executives' attention to the problem?

  2. So how is Korg getting away with violation the GPL but if you or I violates it they put a CEASE ORDER on us? Is Korg paying some folks to look the other way? The way Korg structured the Kronos has me decided I will never buy another Korg product ever again. Example: User Banks. I have an Old Alesis Fusion built in early - mid 2000s and it allows as many banks the user can hold on a HDD. The Alesis Fusion allows the user to name their banks to whatever they want. Each bank has 128 patches. So, why didn't Korg go this route with the Kronos? This is why I will not buy any expansions because there just is not enough banks to hold all of them in my Kronos. Also we should be allowed to rename each user bank to whatever we want.