SSM FlashWrite PAK files reverse engineering

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

Hi guys!

As you know, Subaru Select Monitor comes with flash tool called FlashWrite and a lot of ROMs that are encrypted and packed to PAK files. I managed to extract a ROM from a PAK file and to decrypt it. A file I get is definitely ROM file without protected area. But it is still encrypted with some sort of swap cipher or something like that. I found that Toyota does something like this. But this one is much more complicated than Toyota's.

The cipher works with every 4 bytes. Change of a single bit changes all 4 bytes alot. But the same 4 bytes are always encrypted to the same 4 bytes.

Did someone have an experience with this? I attach AZ1G202G encrypted ROM file.

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

With great help of rimwall I managed to wrote ROM decryptor. Now you can unpack and decrypt PAK files. Here's the repo link.

SergArb · **Posted:** Wed Apr 24, 2024 9:16 am

Awesome, good work! :idea:

SergArb · **Posted:** Thu Apr 25, 2024 7:14 am

Is there any way to find pak files from JDM base of FlashWrite?
For example JDM Legacy 2005 EJ204 with Mitsubishi ECU?

jimihimisimi · **Joined:** Tue Apr 05, 2022 4:57 pm **Posts:** 60

Had a couple of thoughts on how to more rapidly brute force an encrypted file, if needed:

0) the goal is to guess the 4 decryption keys somewhat efficiently
1) Scan the encrypted file in 4 byte chunks, look for the most common repeated chunks, these should be 0xFFFFFFFF and 0x00000000 as the ROM is usually padded with a lot of these values. in the file you posted 0xFFFFFFFF encrypts to 0x96554f6e, and 0x00000000 encrypts to 0xE7E21430 so I will use that as an example.
2) Set up some dumb nested 'for' loops for decrypting the first 3 keys, after the 3rd key decrypt the lower two bytes should match the data to decrypt. 0x96554f6e will transform into 0xDCDCFFFF after the 3rd key. you can leverage this to break out of the 3rd loop if the lower order bytes don't match 0xFFFF.
3) if the bits do match you can try the same 3 keys against 0xE7E21430 and (if successful) it should have the 4 lower bytes all zeros -> i.e., 0x47590000 has the lower 4 bytes 0x0000
4) continue on to the 4th key and see if the data fully decrypt into 0xFFFFFFFF and 0x00000000 with the same set of 4 keys.
5) On a decent machine this would probably take several days and you will end up with multiple sets of keys. You can use each set to decrypt the data and see if you can find the ECU_ID in the data (matches the file name) 'AZ1G202G' in hex -> 0x415A314732303247. This step should go pretty fast, once programmed.

If you know the location of other encrypted data in the file you can use this to further optimize the process. For example, knowing that 'AZ1G202G' is in the data at address 0x2004 and 0x2008 lets you use this as another set of data to test keys against in steps 3 and 4, and will reduce the number of sets of keys generated.

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

SergArb wrote:

Is there any way to find pak files from JDM base of FlashWrite?
For example JDM Legacy 2005 EJ204 with Mitsubishi ECU?

Yes if there were updates to that car. The fie is called 'PAK FILE LIST OF JAPAN.mdb'. This is MS Access DB. You'll need ECU part number.

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

jimihimisimi wrote:

Had a couple of thoughts on how to more rapidly brute force an encrypted file, if needed:

Thank you. I came to the similar conclusion yesterday. And I spent today in writing multithreading bruteforcer. It looks like your 3rd step could add some speed. I'll check this.

Thank you very much again!

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

Holy crap, it worked! On my work notebook that is pretty old, keys that are 'far' from correct (for example, correct key starts from 0x6587 0x0 0x0 0x0, and I test key that starts from 0x0 0x0 0x0 0x0) tested for about 3 minutes for every 3 words, and keys that are 'close' to correct, tested for 5-8 minutes. And keys that starts from 0x6587, tested for 16 minutes. But now it takes 3.5 minutes instead of 16!

I'll publish my work later after some testing (and code cleanup of course).

Thank you jimihimisimi, that was awesome!

SergArb · **Posted:** Fri Apr 26, 2024 1:34 pm

alesv wrote:

Yes if there were updates to that car. The fie is called 'PAK FILE LIST OF JAPAN.mdb'. This is MS Access DB. You'll need ECU part number.

I have only EC_AU databases. JDM ECU's part numbers is 22611ak190, and updated one has 22611ak191. And 22611AH810, 22611AH811.

jimihimisimi · **Joined:** Tue Apr 05, 2022 4:57 pm **Posts:** 60

alesv wrote:

Holy crap, it worked! On my work notebook that is pretty old, keys that are 'far' from correct (for example, correct key starts from 0x6587 0x0 0x0 0x0, and I test key that starts from 0x0 0x0 0x0 0x0) tested for about 3 minutes for every 3 words, and keys that are 'close' to correct, tested for 5-8 minutes. And keys that starts from 0x6587, tested for 16 minutes. But now it takes 3.5 minutes instead of 16!

I'll publish my work later after some testing (and code cleanup of course).

Thank you jimihimisimi, that was awesome!

I will keep looking at it and see if there are some more efficiencies to gain, but happy to help!

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

I'm working on OpenCL version - I want it to run on GPU.

jimihimisimi · **Joined:** Tue Apr 05, 2022 4:57 pm **Posts:** 60

alesv wrote:

I'm working on OpenCL version - I want it to run on GPU.

That should make it go quite a bit faster!

A few more optimization ideas:

Keyword 3/Keyword 4 odd even test

data_to_encrypt = encryption_key ^ word_to_be_encrypted + (word_to_generate_index<<16);
ignore the left_shifted bits
data_to_encrypt(simplified) = encryption_key ^ word_to_be_encrypted

looking at the encryption_key loop:
if we are hunting odd data (0xnnnnFFFF) the XOR operation means that one variable must be odd and the other even
if we are hunting even data (0xnnnn0000) the XOR operation means that both variables must be odd or both must be even

it is hard to know if word_to_be_encrypted is odd/even, as it has gone through a lot of manipulation/substitution at this point, so not sure there is a good vector to improve on that. the encryption_key gets generated for each keyword, so there is some room to optimize this:

the encryption_key gets bit-shifted >>3 before calculating data_to_encrypt, so if the upper bit of the lower byte <8 then key is even. otherwise, if the upper bit >=8 the key is even.

this upper key comes from the substitution step in the first loop of key generation:
encryption_key += index_transformation[(index >> (n * 4)) & 0x1F] << (n * 4);
since it is the first itteration of the loop, n = 0, so
encryption_key(simplified) = index_transformation[index & 0x1F];

at this point and 'odd even' test could be ran to see if the key is a candidate after the 1st encryption_key step, instead of having to go through all four

Code:

uint32_t decoded_data = 0xFFFFFFFF;

{previous code here}

for(uint16_t key3 = key3_start; key3<0xFFFF; key3++) {   
                word_to_generate_index = data_to_encrypt32;
                index = word_to_generate_index ^ key3;
                index += index << 16;
                
                encryption_key = index_transformation[index & 0x1F];
                
                // odd_even test - this same test can be used when testing 0xFFFF or 0x0000 encoded data and testing the 4th keyword
                if(!( (decoded_data%2 ) ^ ((encryption_key>>3)%2)) )
                    continue;
                
                for (uint8_t n = 1; n < 4; n++) {
                    encryption_key += index_transformation[(index >> (n * 4)) & 0x1F] << (n * 4);
                }
        
                encryption_key = (encryption_key >> 3) + (encryption_key << 13);
                word_to_be_encrypted = data_to_encrypt32 >> 16;
                data_to_encrypt32 = (encryption_key ^ word_to_be_encrypted) + (word_to_generate_index << 16); 
                
                //test trailing bits
                if( (data_to_encrypt32 & 0x0000FFFF) != (decoded_data & 0x0000FFFF) )
                    continue;

               {code continues here}

Keyword 2, Key-Pair Test

Not sure of the math on this, but with a limited known dataset (0xFFFFFFFF & 0x00000000) there should be multiple keypairs (mostly invalid) generated when testing these. take keyword1=0x92a0 and looping through all of keyword_2:

Quote:

key2 loop: 0
key CONFIRMED: 0x92a0 0x282 0x38c0 0x285b
key2 loop: 4095
key2 loop: 8190
key2 loop: 12285
key2 loop: 16380
key2 loop: 20475
key2 loop: 24570
key2 loop: 28665
key CONFIRMED: 0x92a0 0x7922 0x3cda 0xdba8
key2 loop: 32760
key2 loop: 36855
key CONFIRMED: 0x92a0 0x9922 0x36da 0x3ba8
key2 loop: 40950
key2 loop: 45045
key2 loop: 49140
key2 loop: 53235
key2 loop: 57330
key CONFIRMED: 0x92a0 0xe282 0x32c0 0xc85b
key2 loop: 61425
key2 loop: 65520
key2 loop: 0

only one of those values is valid, but my thought is instead of looping through every possible keyword 2, loop through all keyword 1's but only loop keyword_2 from 0x0000 to 0x3FFF. Use that to collect valid keyword_1 and then fully retest all the keyword_1s for every value of keyword_2.

I'm not sure of the math on this, I would be more confident if the substitution table were more balanced, but it could help streamline the bruteforcing.

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

Wow. I need a time to understand this, because it looks quite complex to me for now.

In turn, I want to say that a GPU greatly speeds up bruteforce. My Radeon HD8670M is 30 times faster than my CPU. And it's a graphics card from 10 years ago! Some fresh GPU I think can find a key in less than one hour.

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

I can't get the odd even test to work on the 1st iteration, only on the 3rd. But this still gives about 20% speedup.

Code:

bool subaru_denso_calculate_32bit_payload(const QByteArray &buf, 
                                        const uint16_t *key_to_generate_index,
                                        const uint8_t *index_transformation,
                                        QByteArray &encrypted,
                                        const QByteArray &decrypted)
{
    uint32_t data_to_encrypt32, index;
    uint16_t word_to_generate_index, word_to_be_encrypted, encryption_key;
    int ki, n;

    uint32_t decoded_data;

    for (uint32_t i = 0; i < buf.size(); i += 4)
    {
        data_to_encrypt32 = ((buf[i] << 24) & 0xFF000000) | ((buf[i + 1] << 16) & 0xFF0000) | ((buf[i + 2] << 8) & 0xFF00) | (buf[i + 3] & 0xFF);

        decoded_data = ((decrypted[i] << 24) & 0xFF000000) | ((decrypted[i + 1] << 16) & 0xFF0000) | ((decrypted[i + 2] << 8) & 0xFF00) | (decrypted[i + 3] & 0xFF);

        for (ki = 0; ki < 4; ki++)
        {

            word_to_generate_index = data_to_encrypt32;
            word_to_be_encrypted = data_to_encrypt32 >> 16;
            index = word_to_generate_index ^ key_to_generate_index[ki];
            index += index << 16;
            encryption_key = 0;

            //Additional odd/even test start
            //n=0, see later for loop
            encryption_key = index_transformation[index & 0x1F]; //-V519

            if (ki == 2)
            {
                if(!((decoded_data % 2) ^ ((encryption_key >> 3) % 2)))
                {
                    return false;
                }
            }
            //Additional odd/even test end

            //Value for n=0 calculated earlier
            for (n = 1; n < 4; n++)
            {
                encryption_key += index_transformation[(index >> (n * 4)) & 0x1F] << (n * 4);
            }

            encryption_key = (encryption_key >> 3) + (encryption_key << 13);
            data_to_encrypt32 = (encryption_key ^ word_to_be_encrypted) + (word_to_generate_index << 16);
        }

        data_to_encrypt32 = (data_to_encrypt32 >> 16) + (data_to_encrypt32 << 16);

        encrypted[0]=((data_to_encrypt32 >> 24) & 0xFF);
        encrypted[1]=((data_to_encrypt32 >> 16) & 0xFF);
        encrypted[2]=((data_to_encrypt32 >> 8) & 0xFF);
        encrypted[3]=(data_to_encrypt32 & 0xFF);

    }
    return true;
}

alesv · **Joined:** Fri Aug 26, 2016 8:21 am **Posts:** 154

OpenCL version with odd even check is 5% slower :shock:

RomRaider

SSM FlashWrite PAK files reverse engineering

Who is online