i've been cracking for 17 days, 5 hours, 1 minute, 9 seconds.

discoveries to date

» output audio problem solved
» .exe format is encrypted with key in rom
» ansi c code can be compiled with ti code composer
» key is 128-bytes long and is rotated in 16-byte increments
» seemingly variable oem boot sector string on cf cards
» only first 32-bytes of mp3 frames are encrypted
» bytes 11-26 in mpx file are checksum of key
» mpx files are longer than mp3 files by 26 bytes
» all id3 tags are stripped from mpx file

download a lyra mpx toolkit [ 438 kb ]

output problem seems to be solved. i have contacted someone over the internet about an honors project they completed that plays mp3 music over a tcp lan connection using the exact same dsp chip that the lyra uses. their project also has the right code to output sound to the audio buffer. this means that we can now play music. you can visit the webpage for this project, called project.

the .exe format seems to be encrypted, hence all of the error codes showing on the lyra screen when trying to run newer versions of .out files. this is (to the best of my knowledge) the effect of an decryption engine with a built in key in the lyra rom area. ok, everyone pull out your eeprom programmers and start probing the rom chip...

ansi c code can be compiled into machine code that the dsp chip used in the lyra will understand. because there are many free mp3 decoders built for c/c++, we can just re-compile that source for the lyra, right? wrong. the dsp chip uses a special interface to play the music, not the default pcm audio type in windows. after trying many hello world applications to no avail. (see note above)

16-byte rotation (?) we figured out that there is a 128-byte key involved, but a 16-byte chunk of data that means nothing at bytes 11-26 in the mpx file. could this be the checksum of the key? no, because the key is 128-bytes long. if you have 32 bytes encrypted multiple times in a file, and your microprocessor can only handle 16 bytes of floating data chunks; see microprocessor specifications; then you couldn't keep track of the 128-byte key all the way through the file. you also couldn't use more than a 16-byte key. unless you rotated the 128-byte key. the 32 bytes of the first frame in the mpx file encrypted are encrypted with a 16-byte chunk of a 128-byte key, evidently repeated once, hence the 32 bytes. then the player would progress down the chain of the key in 16-byte chunks. but how would the player know it started on the right chunk? it couldn't "listen" to see if it was spitting out junk or music. so we need a checksum. this is the 16-byte "mystery" chunk at the beginnning of the file. if the checksum and the key starting point matched, then it would play the file, if not, you would get an "error 4: corrupted file" on your lyra 2 player while junk on your lyra 1 player.

the below code takes the mpx file input and attempts to decrypt the first 32-bytes of the first frame using the checksum. i had to change some of the operations to get it to work. in the end, it will output the mp3 file, and you should just hear the beginning two or three seconds play normally, and then junk.

that's what should have happened. it didn't really work. but it may still be a possibility with a different type of decryption.

looking for the key this promises to be the hardest challenge yet. but first we need to find a string to look for. what, we just look for a 128 byte string that means nothing in particular? this is where my little utility for the patterns below helps out. the current version i was running didn't work, because the repeat would have never happened in only 256 bytes, which was what the program looked for to make it run faster. 128 byte key times the 16 byte chunk of the key means that you wouldn't find anything in the first 256 bytes of the file, meaning we had to upgrade to 1024 bytes. the thrill of being actually able to go get something to eat while my very-fast computer cracked away was more than i could describe!

looking for mirrors looking through the mp3 and mpx files for mirrors should show us where the encryption is being used. this was successful, but it was very time consuming. the results of this "mirror" test are below.

looking for key length by taking the length of data not associated with the mp3 file, that is data that does not appear in the mp3 file at all, and measuring it, we can get a length of the key involved. or at least that's what should happen. i ran it and it told me that bytes 1-10 were not found in the mp3, this being the "LYRAxxxx[chr0][chr2]" string at the beginning of the mpx file. it also reported that bytes 24-180, a 156 byte gap, were not in the mp3 file. after first glance, this seemed odd. 156 was not divisible by eight, so it probably wasn't the key length.

then i figured it out. 156 bytes minus the 32 byte mp3 header left 124 bytes for what, dog chow? add the 4 more bytes that appeared between the gap in the mp3 file that had nothing to do with the mpx file that my little program didn't detect, and you have 128 bytes, a number divisible by eight, and the current encryption standard!

looking for patterns by comparing the mpx and mp3 files you should be able to find a certian pattern that would be the key, and it would repeat itself every x bytes, being the strength of the key. in this experiment, based in visual basic, i took into account that the files may not be exactly aligned byte by byte. there is a popular encryption format below, but i have also changed it to other types as needed during testing. of course, this means nothing now that i discovered that the 128-byte key is rotated 16 bytes for each file.

this project is dedecated to jeff richter made fun of visual basic programmers and said that we shouldn't be allowed to have the title of "programmer".