Honda Development

dschultz · **Posted:** Thu Jul 26, 2018 1:37 pm

vadbut wrote:

It turned out that the device I used (Tactrix OpenPort 2.0) is not friendly with Honda's K-Line (an EPS unit I was looking for was on the K-Line).
I got another device which was able to communicate to the EPS and I was able to reflash it with a custom firmware.

I'd suggest that you contact Tactrix and forward this info so they can correct it. I have an almost similar issue with a Nissan ECU and K-line (I'll check first to make sure I'm running their latest firmware in the OP2).

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

I updated rwd-xray to fix the issues you guys have mentioned. I think it can now decrypt all the rwd files that I have seen explicitly named in this thread!

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

So has this just come to a halt since 2018?
I just started getting into this myself, and have managed to dump everything from my ECU via AUD port.
I am currently working on the SEED/KEY algo.
Anyone else make any progress since the last post?

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

I managed to decrypt, modify and generate a new RWD file with this code
https://github.com/gregjhogan/rwd-xray
Then flash it back to an ECU over CAN with this code
https://github.com/gregjhogan/autoecu

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

gregjhogan wrote:

I managed to decrypt, modify and generate a new RWD file with this code
https://github.com/gregjhogan/rwd-xray
Then flash it back to an ECU over CAN with this code
https://github.com/gregjhogan/autoecu

That is absolutely incredible! Whats the process to generate the new RWD files. Because i have noticed my aud dumps are exactly 1024kb
when the rwds are right around 993kb extracted? Not sure if thats part of the byte scrambling that HDS does or ?

And I haven't noticed the behavior of the seed/key being static in CAN traffic. like i believe it is in autoecu.. Either way Thats awesome.

[edit]
I am dumb, its not static haha. However i am struggling getting the correct security key for the version i am working with
its an RRB ecu.
When decrypted with rwd-xray i get a set of security keys like so
'\x00\x90\x83\x045\x84'

then the firmware keys

keys:
k0 = 0x43
k1 = 0x50
k2 = 0x41

and it says my cipher is as such
cipher: (((i ^ k2) - k0) + k1) & 0xFF

I have a list of known seed/key handshakes and none of them ever match up when giving the seed in BE format.
for example.

Seed = 0x18, 0x54
Key = 0x14, 0x70
Result from cipher = 0x50, 0x64
Is there something i am doing wrong here?

This is my code in c# (Since i dont have a panda and assume a openport wont work with pandajs)

Code:

 

        inMain
          ushort knownKey = (new byte[2]{0x18, 0x54});
          Attempt(knownKey);


        static string Attempt(ushort seed)
        {

            ushort s = seed;
            ushort k1 = BitConverter.ToUInt16(new byte[2] { 0x00, 0x90 }, 0);
            ushort k2 = BitConverter.ToUInt16(new byte[2] { 0x83, 0x45 }, 0); ;
            ushort k3 = 0;// BitConverter.ToUInt16(new byte[2] { , 0x84 }, 0);
            //if (keys.byteLength == 6)
            //{
            //    k3 = keys.readUInt16BE(4);
            //}

            ushort sa_key = Convert.ToUInt16((();

            byte[] b = BitConverter.GetBytes((sa_key));
            return BitConverter.ToString(b);

        }

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

[edit] ignore this, this is wrong ...
You don't pass the firmware keys through the security access key exchange, you have to request a seed from the ECU, transform it using the algorithm you found in autoecu, and then send it back as the key. The ECUs I have dealt with return random 2 byte seeds.

[edit] this is correct ...
Yes, you take the keys and pass them into the security access key exchange algorithm along with the seed. Maybe you have the wrong keys.

There are also firmware keys for encrypting the firmware that is sent to the ECU. You have to figure out what the encryption algorithm is for your ECU (hopefully there is an rwd update file and rwd-xray can tell you the algorithm, if you have to disassemble your firmware dump and find it). Once you know the algorithm you can use any keys you like (part of flashing is passing the firmware decryption keys through a routine control call).

Honda firmware updates are partial firmware updates, so the RWD files are smaller because there is a specific address range that can be flashed. This address range excludes the bootloader which dramatically decreased the chances of you bricking an ECU. Again, rwd-xray can tell you the address range if there is a firmware update available, otherwise you will have to find it through trial and error or disassemble the firmware and find it.

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

To generate rwd files I use this script:
https://github.com/gregjhogan/rwd-xray/ ... builder.py

You have to first slice your modified firmware to the appropriate size and encrypt it, then it is pretty much just passing in parameters that you get from rwd-xray for an existing rwd file for the same ECU

It actually sounds like you are trying the correct thing for the security access key exchange, are you using the correct key 1/2/3? They can change them for every firmware revision. I will be extremely surprised if the algorithm is different for any ECU that is flashed over CAN.

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

gregjhogan wrote:

You don't pass the firmware keys through the security access key exchange, you have to request a seed from the ECU, transform it using the algorithm you found in autoecu, and then send it back as the key. The ECUs I have dealt with return random 2 byte seeds.

The firmware keys are for encrypting the firmware that is sent to the ECU. You have to figure out what the encryption algorithm is for your ECU (hopefully there is an rwd update file and rwd-xray can tell you the algorithm, if you have to disassemble your firmware dump and find it). Once you know the algorithm you can use any keys you like (part of flashing is passing the firmware decryption keys through a routine control call).

Honda firmware updates are partial firmware updates, so the RWD files are smaller because there is a specific address range that can be flashed. This address range excludes the bootloader which dramatically decreased the chances of you bricking an ECU. Again, rwd-xray can tell you the address range if there is a firmware update available, otherwise you will have to find it through trial and error or disassemble the firmware and find it.

omg thats how that works. Ok.
So i have the algo for it. But it only passes back a 2 byte seed. So how do i transform it to a 6 byte seed and then apply the algo to it?

The firmware does have a RWD file and the cipher i got back was this

cipher: (((i ^ k2) - k0) + k1) & 0xFF

So if my key was 0x18, 0x54

how would i apply that to my cipher?
I think this is the step im lost on.

Or is it that in the cipher 'i' is my seed?

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

Why did you comment this out? All the keys I have seen are 6 bytes and the logic should work even if it is only 4. I haven't tested this on any ECUs with 4 byte keys because I haven't come across any yet.

kalisto2002 wrote:

Code:

 
            //if (keys.byteLength == 6)
            //{
            //    k3 = keys.readUInt16BE(4);
            //}

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

gregjhogan wrote:

Why did you comment this out? All the keys I have seen are 6 bytes and the logic should work even if it is only 4. I haven't tested this on any ECUs with 4 byte keys because I haven't come across any yet.

kalisto2002 wrote:

Code:

 
            //if (keys.byteLength == 6)
            //{
            //    k3 = keys.readUInt16BE(4);
            //}

my key is 5 bytes? i believe.
this is the header from my firmware update(a stock honda update)

Code:

headers:
= ['\x00']
= ['5`-P']
= ['\x10']
= ['37805-RRB-A110\x00\x00', '37805-RRB-A120\x00\x00', '37805-RRB-A130\x00\x00', '37805-RRB-A140\x00\x00']
= ['\x00\x90\x83\x045\x84', '\x00\x90\x83\x045\x84', '\x00\x90\x83\x045\x84', '\x00\x90\x83\x045\x84']
= ['CPA']

This is from a 07 honda civic SI ecu. 37820-RRB-A12

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

Yeah my bad, you were trying the correct thing originally for the security access key exchange.

Your key is 5 bytes (I figured they would all be 4 or 6 bytes). You will have to try some different combinations and see what produces the correct results. The leading 0x00 is suspicious, I would try removing that so you only have 4 bytes. If that doesn't work I would try to add a leading or trailing 0x00 byte since then you would have 6 bytes.

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

gregjhogan wrote:

Yeah my bad, you were trying the correct thing originally for the security access key exchange.

Your key is 5 bytes (I figured they would all be 4 or 6 bytes). You will have to try some different combinations and see what produces the correct results. The leading 0x00 is suspicious, I would try removing that so you only have 4 bytes. If that doesn't work I would try to add a leading or trailing 0x00 byte since then you would have 6 bytes.

I have tried pretty much everything i could for the seurity access keys.
It would be really helpful if i could use the web interface to test it buuut.
I dont have a panda. only an openport lol
I have tried these combinations with failure at every turn.

Code:

            ushort k1 = BitConverter.ToUInt16(new byte[2] { 0x00, 0x00 }, 0);
            ushort k2 = BitConverter.ToUInt16(new byte[2] { 0x90, 0x83 }, 0);
            ushort k3 = BitConverter.ToUInt16(new byte[2] { 0x45, 0x84 }, 0);

            ushort k1 = BitConverter.ToUInt16(new byte[2] { 0x00, 0x90 }, 0);
            ushort k2 = BitConverter.ToUInt16(new byte[2] { 0x83, 0x45 }, 0);
            ushort k3 = BitConverter.ToUInt16(new byte[2] { 0x84, 0x00 }, 0);  

            ushort k1 = BitConverter.ToUInt16(new byte[2] { 0x90, 0x83 }, 0);
            ushort k2 = BitConverter.ToUInt16(new byte[2] { 0x45, 0x84}, 0);
            ushort k3 = 0;

            ushort k1 = BitConverter.ToUInt16(new byte[2] { 0x00, 0x00 }, 0);
            ushort k2 = BitConverter.ToUInt16(new byte[2] { 0x90, 0x83 }, 0);
            ushort k3 = BitConverter.ToUInt16(new byte[2] { 0x45, 0x84 }, 0);

gregjhogan · **Joined:** Sun Mar 11, 2018 11:39 pm **Posts:** 11

I see the problem, your key is 6 bytes. There is a 5 in the key which is ascii 0x35. Python printed it as the string 5 since it is a known ascii character.

This has the number 5 as a string

Code:

\x00\x90\x83\x045\x84

Which is the same as this

Code:

\x00\x90\x83\x04\x35\x84

And then I get the expected security access key for your example seed!

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

gregjhogan wrote:

I see the problem, your key is 6 bytes. There is a 5 in the key which is ascii 0x35. Python printed it as the string 5 since it is a known ascii character.

This has the number 5 as a string

Code:

\x00\x90\x83\x045\x84

Which is the same as this

Code:

\x00\x90\x83\x04\x35\x84

And then I get the expected security access key for your example seed!

That is hillarous, I Should have noticed that because it was the only one with a 3 digit hex code lol

That is super strange because i still don't get the accepted key.
Can you give me an example of how you are parsing it?

Oh i got it i had to flip all the bytes backwards.
Thank you so much for you help Greg!!!!

kalisto2002 · **Joined:** Wed May 06, 2015 1:01 am **Posts:** 38

Thanks again Greg.
I grabbed keys from every rwd i could find that was canbus, we will see if it works or not

Now everything is unlocked and i am going to start working on a microkernel to dump everything 0x0000000 - 000FFFFF(Since i believe that is the complete rom size.
If im off point it out.

I will probably take a look at @fenugrec kernel for an idea, or maybe just bypass kernel stuff for now and get it r/wing with custom rwds
with the factory code.

The rwds are only calibration data though correct? not full romdumps(At least the 993kb ones?)

RomRaider

Honda Development

Who is online