Recommended

Rooting the KORG Kronos

Disclaimer: The following file is provided without any warranties. Backup all your settings before using it - maybe you'll need to ...

Dienstag, 31. Mai 2016

Kronos encrypted file systems

Korg uses Cryptoloop to hide the important parts of it's Kronos firmware from prying eyes. The mount mechanism is somewhat obfuscated and hidden in loadmod.ko and loadoa. Here is a brief description:
  1. loadoa loads the kernel module loadmod.ko
  2. loadmod.ko replaces the kernel's mount syscall with it's own implementation (but only if filesystem check, kernel check and communication with the security chip are ok).
  3. loadmod.ko reads and decrypts /.pairFact3 to retrieve the Cryptoloop keys. The Cryptoloop keys are the same for all devices, but the keys to decrypt /.pairFact3 are individual for each device. When you "authorize" your Kronos, you actually get the Cryptoloop keys encrypted with your individual device keys.
  4. loadoa mounts issues a mount command that looks like this:
    /bin/mount -n -t ignoreType ignoreDev /korg/rw/PCM/WaveMotion
  5. loadmod.ko gets the syscall and recognizes the "magic" mount point name (/korg/rw/PCM/WaveMotion). Now it initializes the Cryptoloop device and calls the kernel's normal mount syscall handler to mount the loop device.
Now, it would be nice to have the Cryptoloop keys for the encrypted file systems inside the Kronos firmware. You can easily extract the encrypted files from the Kronos firmware updates published by Korg. If we just had the keys, we could mount and examine them on any PC around.

The possibility to boot our own kernel helps a lot, here. One could just add some printk() to a function that handles the cryptoloop keys (for example loop_set_status).

This is the kernel patch. Let's see what happens...

loop_set_status(0): lo_file_name=/korg/ro/Eva.img lo_encrypt_type=18 lo_crypt_name=aes lo_encrypt_key=342ee59d549c7d329d835537be0540d
loop_set_status(1): lo_file_name=/korg/ro/WaveMotion.img lo_encrypt_type=18 lo_crypt_name=aes lo_encrypt_key=3e72c0e59fc017a9eb7d7e1168a4cdb
loop_set_status(2): lo_file_name=/korg/ro/Mod.img lo_encrypt_type=18 lo_crypt_name=aes lo_encrypt_key=a336a15cd841ec8926b99e7c3884eaa


Crazy keys

Looking at struct loop_info64 it is pretty clear that the simple printk("... lo_encrypt_key=%s ...", status->lo_encrypt_key) should not have worked. lo_encrypt_key should be binary, not a null terminated string!

Someone had no real clue about how to use loop_set_status() and used 31 (plus a \0 byte for string termination) hex digits (containing only 124 bits of information) as AES256 key.

I am still wondering if this is just a stupid mistake or just one more strange obfuscation. 

1 Kommentar:

  1. Did i understand you right? Those 3 keys you showed here by using printk are actually the hidden keys from inside /.pairFact3 ? the keys that are the same across all KRONOS 1+2 as you asume ? OF so... WOW!! nice job!! and what a great job, debugging or reverse engineering the things there are going on!! how did you find out that loadmod.ko actually replaces the kernel's original mount syscall with something of their own? r u diving into ASM or monitor the RAM like Neo in the Matrix ? or are there ways to get some C from KORGs crippled bin files ? however, my honest respect to the Kronos Hacker for all that work and documentation so far!!!

    AntwortenLöschen