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.