Cracking the Soundaktor firmware checksum: We did it!

Found on photo: 4G0907159B, FO404, 000000005900

For some time, Dark and I have been investigating the Soundaktor firmware.
Read the previous chapters of this story here:
Активный выхлоп / Audi Active Exhaust Sound System
Investigating soundaktor firmware
Investigating Soundaktor firmware part 2!
What is CRC32ADLATUS? The answer is here! (+ free calculator)

You might think: Why on earth would you want to investigate the firmware of a part which is hated by so many people? A lot of people are removing their soundaktor, because they don't like the sound. However, we've learned a few interesting facts which might change your opinion on this matter:
— Different cars, brands, types and engine-setups have different sounding sountaktors. The hardware is equal, but software and configuration can make big changes.
— The internal soundaktor control module is virtually identical to the external soundaktor, the firmware is identical.

So, by making changes to the firmware, we might get more control over the way your car sounds on the inside and on the outside! Do you want it to sound like a standard diesel or like a V8? Or even like a VW Beetle? All should be possible, but until now only in theory.

I'll take you through the journey from there, explaining how we found the checksum. There were a lot of failed attempts, but failure is the key to success and learning.

Dark did an extremely awesome job matching the configuration tables inside the firmware to official documentation. The info we knew could be matched to what was found in the data, and we made a 010 Editor template to help us analyze the file (get it here: github.com/jilleb/mqb-soundaktor)

Perfect match! So then there was this little annoying challenge, where we couldn't find the checksum for the data file. Only 2 bytes were keeping us from making our own custom unlocked profiles that could be used on all cars and engines.
We tried and tried and tried… I contacted several friends, and even emailed the manufacturer of the soundaktor module to ask for help. I even dreamed about it and got up in the middle of the night to try some calculations.

We tried CRC reverse engineering tools like CRC RevEng. It's a very useful tool to reverse engineer potential CRC mechanism. No luck.

We tried CRC Galore, which will generate all kinds of CRCs, and variations of it. No positive results there.

And then there was delsum, another CRC reverse engineering tool, which did find the CRC16-CCITT inside the data files. But no luck on the first 2 bytes. We got the feeling that it was not a CRC at all, but just some other crazy method. How to find it?

What about decompiling the 156kB application part of the firmware? That could possible have a checksum algoritm hidden away somewhere. So we took Ghidra, a decompilation tool made by the NSA, and we decompiled the firmware.

This was pretty hard to interpret. The code hardly has any strings inside, so to me it was like pure guessing and interpreting what happened in the decompiled functions. I made some test scripts based on the calculations I found inside the code. For instance, an algoritm to make a sum of all bytes, XORred with some other value. I filled thousands of Excel sheet records to try and find any link to the checksum, but unfortunately, no luck there either. Dark made all kinds of awesome tools to try and calculate all kinds of variations. Maybe the checksum was part of the RIPE160 checksum? Maybe it was based on the MD5 hash of the data? We found nothing conclusive that would match for all files.

Then I contacted Willem, the man that wrote this awesome blog about hacking his car steering firmware, maybe he had some ideas: blog.willemmelching.nl/ca…king/2022/01/02/vw-part3/ (make sure you read it, it's very educational, even if you're not a programmer, he's a great teacher) I got some great inspiration thanks to him but… no luck there.

And then I gave up. I decided not to look at it anymore for 2 days, as I was totally frustrated, it kept me awake to not know the answer to this puzzle. Only 2 bytes, how hard could it be?! And then yesterday afternoon, while finishing up my work, I decided to have another go. The last script I tested before I gave up was this:

for (i=2;i<0xe000-2;i=i+2){
calculated_checksum = calculated_checksum + ReadUShort(i) ^ 0xff00;
}

In case you don't read any code, this means: sum all unsigned short values (short = 2 bytes), and do a XOR operation with 0xFF00. I guess it was based on some of the disassembled code. The output didn't look like the checksum at all. I decided to remove the XOR operation, hoping maybe there was a relation between the total sum and the checksum that I didn't see before. The plan was to make an analysis of the byte sums and short sums of all firmwares I had, to find out if there was anything relating to the checksum. I ran the script. and then something funny happened.

…I vaguely recognized the output number! After a few weeks of looking at the checksums, bitflipped values of the checksums, and even dreaming about the numbers, I guess some of them sticked somewhere in my brain. The total sum was: 0xda80a4db while I was looking for 0x265B. Of course, those numbers don't look alike. But look what happens when you bit-flip 0x256B: d9a4.

0xD9A4 looks a lot like 0xA4DB. I tried to repeat the same on an other file, which had 0x052C as the checksum, which is 0xFAD3 when bit-flipped. The total sum turned out to be 0xf943d3fc… FAD3 versus FCD3. Too close to be a coincidence! I could repeat this on all firmwares I have, and the difference would always be 2 (and the bytes swapped around, but that's arbitrary) so then I could confirm that this has to be it:

checksum = ((sum_of_all_unsigned_short_values-2) & 0xffff)^0xffff;

Eureka! I couldn't believe it at first, but the mechanism was relatively simple. Dark made some very useful remarks on the algorithm, because the -2 wasn't actually needed, because the difference was created by signed/unsigned value conversion.

So then the algorithm became as follows:
checksum = ((sum_of_all_unsigned_short_values-1) & 0xffff)^0xffff;

Which is in fact exactly what happens in Two's complement. I'll spare you the exact mathematical theory, but if you're into that kind of stuff, please read the wiki.
So it turns out, the algorithm is based on a standard mathematical operation. In retrospect, there are a lot of lessons to be learned from the process, which was fun, educational, and at times very frustrating! But we did it, we broke the code, and now we can make custom, unlocked Soundaktor firmwares! Awesome teamwork, and I would like to thank all who inspired us the last weeks, all who cooperated with us to help find the answers!

What's next? Make custom firmware, and flash it on the device!

If you have any stock soundaktor (xxx907159 for internal soundaktor or xxx907160 for external soundbooster) firmwares to share, (especially from Porsche or maybe even Lamborghini!), feel free to share them, so I can make an unlocked version of them.