Update IPC

[Go4IT]

I recently updated a preFL Convers with UCDS and took a log of the MS-CAN.

HW: 8M2T-10849-VC
Calibration: 8M2T-10849-VE
FW (DID F188): Updated from 8M2T-14C026-CC to 8M2T-14C026-CE
ECU Software (DID F121) from 8M2T-14C026-EC to 8M2T-14C026-ED
Bootloader (SBL) used for Update 7M2T-14C025-AA
(The firmware-files could be downloaded here http://www.ucdsys.ru/calibration/ by enterind the partnumber)

The update-procedure in UCDS is given like this:

Code: Select all

00:00:09.914: Requesting security mode...Please wait...
00:00:09:929: Security mode granted!
00:00:09:928: Loading Secondary Bootloader...
00:00:10:363: Secondary Bootloader successfully loaded and initialized.
00:00:10:427: Erasing flash...
00:00:10:431: Erasing flash block 1 from 1...
00:00:18:170: Erasing flash finished.
00:00:18:231: Programming flash block 1 from 1...
00:03:45:755: Checking...
00:03:55:549: Erasing flash...
00:03:55:557: Erasing flash block 1 from 1...
00:04:06:015: Erasing flash finished.
00:04:05:071: Programming flash block 1 from 1...
00:10:59:132: Checking...
00:11:19:315: Performing check routine procedure...
00:11:19:530: Reset modules...
00:11:19:639: All operations done.

Inside the log the messages with ID 0x720 are send from UCDS to IPC and the answers from IPC to UCDS having ID 0x728.

The upload of the SBL starts in line 691 of the logfile, beginning with the green bytes: "46,718 720 8 13 FE 36 01 01 00 FF 71"
and ends in line 851: "46,923 720 8 2A 50 45 56 33 30 31 46" (Note: Byte 0x46 is not part of the image)

The binary part of the Firmware (*-CE) starts at line 968: "54,967 720 8 13 FE 36 01 7C C7 55 AA "
and ends in line 152.278: "22,454 720 8 28 C7 55 AA AA 55 C7 F0 "

And the ECU software (*-ED) starts in line 152.307: "42,817 720 8 13 FE 36 01 00 00 00 FF "
and ends in line 460.957: "35,872 720 8 24 EF EF EF 85 B6 24 CD "

This means all update setup (security mode) is done in the lines prior to 690 and i guess we can focus on ID 720, 728 there. Which in fact leaves only these lines:

Code: Select all

Time   ID     DLC Data                    Comment
45,613 720      8 02 10 02 00 00 00 00 00 
45,624 728      8 06 50 02 00 19 01 F4 00 
46,633 720      8 02 27 01 00 00 00 00 00 
46,634 728      8 05 67 01 BA AB EF 00 00 
46,637 720      8 05 27 02 42 6C 4B 00 00 
46,641 728      8 02 67 02 00 00 00 00 00 

46,703 720      8 10 0B 34 00 44 00 00 00 
46,704 728      8 30 00 01 00 00 00 00 00 
46,706 720      8 21 00 00 00 06 CC 00 00 
46,710 728      8 04 74 20 03 FE 00 00 00 

46,718 720      8 13 FE 36 01 01 00 FF 71 

From the used ID-Scheme i would think this is OBD2 protocol traffic. There the first byte is the "PCI" byte and tell us the number of bytes following. For example: "45,613 720 8 02 10 02 00 00 00 00 00 " means 2 bytes following.

The next byte is the "OBD SID" ("Service ID" or sometims called "Mode"). Here it is 0x10, which from this table https://www.obd-2.de/programmierer-tips.html means: "Initiate diagnose function".

The last byte in the first message, 0x02 is the "OBD PID", a kind of parameter for the mode.

The OBD2 standard defines that each request is answered by using the requested Service added a ACK or NAK flag in the requested service-ID. By adding 0x40 to the ID it tells us, "OK". So 0x10 becomes 0x50 in the answer, 0x27 becomes 0x67, and so on.

In the next request it uses 0x27 = Protected access.

At 46,703 things are changing. The first data bytes does not seem to have the length of data, but seem to be direct data somehow. From timecode 47,718 on, the binary image of the bootloader is send. As from the VBF files the length of the bootloader is 0x6CC which we find in this message: "46,706 720 8 21 00 00 00 06 CC 00 00 "

[Ursadon]

Great!
I parsed your dump and created a table with comments.
https://docs.google.com/spreadsheets/d/ ... sp=sharing

Is it full dump? It seems that your dump lacks some of the last lines.

Also about NACK's in dump (from ISO 14229 spec):
requestCorrectlyReceived-ResponsePending
This response code indicates that the request message was received correctly, and
that all parameters in the request message were valid, but the action to be
performed is not yet completed and the server is not yet ready to receive another
request. As soon as the requested service has been completed, the server shall
send a positive response message or negative response message with a response
code different from this.
The negative response message with this response code may be repeated by the
server until the requested service is completed and the final response message is
sent. This response code might impact the application layer timing parameter values.
The detailed specification shall be included in the data-link-specific implementation
document.
This response code shall only be used in a negative response message if the server
will not be able to receive further request messages from the client while completing
the requested diagnostic service.
When this response code is used, the server shall always send a final response
(positive or negative) independently of the suppressPosRspMsgIndicationBit value.
A typical example of where this response code may be used is when the client has
sent a request message which includes data to be programmed or erased in flash
memory of the server. If the programming/erasing routine (usually executed out of
RAM) is not able to support serial communication while writing to the flash memory,
the server shall send a negative response message with this response code.
This response code is, in general, supported by each diagnostic service, unless
otherwise stated in the data-link-specific implementation document; therefore, it is
not listed in the list of applicable response codes of the diagnostic services.

[Go4IT]

Way cool, Ursadon! I still don't get the mix of OBD and UDS messages, but i understand them.
Your Excel is great and really helpfull by the comments you made, thanks a lot for the whole work! I'd love to see it added as file here, in case the Google-Doc gets removed some day.

Would you enlighten me in some things, please:

1.) The Session ID, what is it used for? Because it never show up later on. Or is it just standard that the receiver send it in response in case one have multiple connections? And if, how would it be used lateron? I thought in terms of OBD-communication, the Message-ID denotes different senders/receivers (receiver is always 8 bytes ahead from senders CAN-ID, which in turn is simply choosen from 0x720 onwards 0x727).

2.) What about that security code? If i understand right, it's some kind of easy encryption within a 2-way handshake. So the sender request a "Seed" from the receiver, which may simply be 3 random generated Bytes, and uses them to "encrypt" a security token (hash of a password) or a password itself (3 byte key) and send it to him in turn. This encryption enshures that no one on the wire could simply catch the security key (call it password or whatever). So because the key and also the encryption method is unknown, there is no chance to extract the password out of the encrypted token.
Any ideas how to get this mechanism? I guess the developers keep it safe, but at least, each software who is able to update must known it. Also UCDS must know it, because here it doesn't look as they simply "try" some combinations (bruteforce it)?!

3.) The memory address where to load the data to is a bit misleading for me. The memory location of the SBL (bootloader, which get's loaded first) is set to 0x0000 0000. On the chip (MAC7116) the internal SRAM begins at 0x4000 0000, whereas at 0x0000 0000 is the start of the internal program flash! So would it be that it gets programmed as the bootloader of the chip? I'm not really convinced. Maybe there is some remapping involved, which translates what gets loaded into the SRAM area and 0x0000 0000 means "start address of sram"?

Next there are two function execution calls send to the receiver. It looks like a simple "call a function". The question for me is "what is those routine Identifier 0x0301 or 0x0103, depend on Endianess"?

The NACK's seems to be more like "i am busy" messages, as from you cite of the standard docs, until the real response code arrives.

I'm really curios about the bootloader. It does make sense that the SBL gets written into Flash, because the sender could not know which RAM memory location it can be but into (RAM may be also fully used by the currently running application, even the one transfering the bytes from UCDS into the module). So if this SBL is really the one to put into the lower 0x5000 byte area of the program flash, i could try to recover my bricked Convers by doing a mass erase and programming this code using JTAG.

Oh, BTW what about disassembling the SBL code? I tried but failed. I'm really curios to find the calls which programs the CFM to unlock the Flash for doing the programming. It must be somewhere in the code, but maybe not in the SBL itself but in the Main code.

[Ursadon]

1.) The Session ID, what is it used for? Because it never show up later on. Or is it just standard that the receiver send it in response in case one have multiple connections? And if, how would it be used lateron? I thought in terms of OBD-communication, the Message-ID denotes different senders/receivers (receiver is always 8 bytes ahead from senders CAN-ID, which in turn is simply choosen from 0x720 onwards 0x727).

SID description have two words:
06 | 50 |02 | 00 | 19 | 01 | F4 | 00
P2max (ms) - Performance requirement for the server to start with the
response message after the reception of a request
message. 0x0019 = 25ms
P2*CAN_Server (ms) - Performance requirement for the server to start with the response message after the transmission of a negative response message (indicated via N_USData.con) with response code 78 hex (enhanced response timing). 0x01F4 = 500 ms

2.) What about that security code? If i understand right, it's some kind of easy encryption within a 2-way handshake. So the sender request a "Seed" from the receiver, which may simply be 3 random generated Bytes, and uses them to "encrypt" a security token (hash of a password) or a password itself (3 byte key) and send it to him in turn. This encryption enshures that no one on the wire could simply catch the security key (call it password or whatever). So because the key and also the encryption method is unknown, there is no chance to extract the password out of the encrypted token.
Any ideas how to get this mechanism? I guess the developers keep it safe, but at least, each software who is able to update must known it. Also UCDS must know it, because here it doesn't look as they simply "try" some combinations (bruteforce it)?!

Yes, you're right about seed/token.
I just tried spam requestSeed message and collect responses. There is no duplicates (for over 2000+ seeds), so we need a some sort of keygen . Maybe we need reverse engineering Ford IDS tool (if it can update IPC)

3.) The memory address where to load the data to is a bit misleading for me. The memory location of the SBL (bootloader, which get's loaded first) is set to 0x0000 0000. On the chip (MAC7116) the internal SRAM begins at 0x4000 0000, whereas at 0x0000 0000 is the start of the internal program flash! So would it be that it gets programmed as the bootloader of the chip? I'm not really convinced. Maybe there is some remapping involved, which translates what gets loaded into the SRAM area and 0x0000 0000 means "start address of sram"?

Next there are two function execution calls send to the receiver. It looks like a simple "call a function". The question for me is "what is those routine Identifier 0x0301 or 0x0103, depend on Endianess"?

Yes, it seems that the bootloader changes the address if it is not within certain limits. The same mechanism is implemented in the PAM module.

Oh, BTW what about disassembling the SBL code? I tried but failed. I'm really curios to find the calls which programs the CFM to unlock the Flash for doing the programming. It must be somewhere in the code, but maybe not in the SBL itself but in the Main code.

After writing own flash driver

[Go4IT]

I don't expect those old Ford modules to be smartest, nor that they really expect hackers those days, but shure they implemented brute force detection and simply lock down the module until reset.

I will go digging a bit deeper into this seed thing. Let's see what i can find out. What do you use for those pen-testing-tasks? How did you automate it? I'm thinking about to use my most liked USB/CAN board using a STM32 micro emulating SLCAN and write some PHP scripts to do, because for me it's the leanest way.

As soon as i get some results i post it back here.

[Ursadon]

I don't expect those old Ford modules to be smartest, nor that they really expect hackers those days, but shure they implemented brute force detection and simply lock down the module until reset.

I will go digging a bit deeper into this seed thing. Let's see what i can find out. What do you use for those pen-testing-tasks? How did you automate it? I'm thinking about to use my most liked USB/CAN board using a STM32 micro emulating SLCAN and write some PHP scripts to do, because for me it's the leanest way.

As soon as i get some results i post it back here.

There is no bruteforce detection. Seeds i got using Br@y terminal (http://sites.google.com/site/terminalbpp/) by spamming secureAccess command via ELM327

So I found the key generation algorithm - Galois LFSR with modified multiplicator.
Here is implementation in C - https://gist.github.com/Ursadon/92b9b5e ... 5dd963f35f

I tried to bruteforce constants s1-s5, using 32-core server, it tooks ~7 hours, but i got too many results. So i need more dumps with succesful secureAccess to crack the algo.

[Go4IT]

Awesome work, pal!!
How did you found out about te algo? I only know the LFSR as a random number generator (e.g. for seeds). Could you tell more how it is used? And most important, is it reversable, to get password out of the access token?
I look if there are any other functions UCD utilizes where an AccessKey is needed. Doing an update of Convers takes a long time so i look for others to generate a lot of them.

The terminal prog you use is scriptable abd seems pretty cool. I'm just using Hterm which is not able to automate things. Would you share your spamm script or tell how you did it?

[oscarboiro]

Hello! this week I was playing with my ford kuga mk1 instrument cluster. I tried to reset the Km to 0 with UCDS and record the CAN BUS sequence with an elm327. From what I see, the process to record information in the frame's memory is similar to mondeo. it is written in the address 720 and the Instrument cluster answers in 728.
I write:
720 02 10 85 00 00 00 00 00 (After send the IC turn off and blink turn signals lamps, this is a program mode?)
Ic answer:
728 02 50 85 00 00 00 00 00
i write:
720 02 27 01 00 00 00 00 00
ic answer:
728 05 67 01 xx xx xx 00 00 (The xx groups It's different every time I try)

i have problen in this time, i dont know the response. when the code is good unit request:

728 02 67 02 00 00 00 00 00

but when the code is wrong request this:

728 03 7F 27 35 00 00 00 00

now the questios in, what is the algorithm? im try to calculate some easy algorithm with bad results.

[Ursadon]

I write:
720 02 10 85 00 00 00 00 00 (After send the IC turn off and blink turn signals lamps, this is a program mode?)
Ic answer:
728 02 50 85 00 00 00 00 00
i write:
720 02 27 01 00 00 00 00 00
ic answer:
728 05 67 01 xx xx xx 00 00 (The xx groups It's different every time I try)

i have problen in this time, i dont know the response. when the code is good unit request:

728 02 67 02 00 00 00 00 00

but when the code is wrong request this:

728 03 7F 27 35 00 00 00 00

now the questios in, what is the algorithm? im try to calculate some easy algorithm with bad results.

It's not a stanadart algorithm. As i described above, it is modified Galois LFSR i've posted a C example, but we need to know 5-bytes secret. I have access to many multicore servers and i can quicky crack (2^24 values), but i need many dumps with session init - "728 05 67 01 xx xx xx 00 00" and responses (approx. 10-20). I think, i need to make CanHacker hw & sw

Also you log have interesting thing- 720 02 10 85 00 00 00 00 00. It is description for a session type.
01 - defaultSession;
02 - programmingSession;
03 - extendedDiagnosticSession;
04 - safetySystemDiagnosticSession;
60-7E - systemSupplierSpecific.
I thought it was done either in defaultSession or in extendedDiagnosticSession.
Also answer doesnt contain session timeouts - 728 02 50 85 00 00 00 00 00.

Awesome work, pal!!
How did you found out about te algo? I only know the LFSR as a random number generator (e.g. for seeds). Could you tell more how it is used? And most important, is it reversable, to get password out of the access token?
I look if there are any other functions UCD utilizes where an AccessKey is needed. Doing an update of Convers takes a long time so i look for others to generate a lot of them.

I've just googl'ed mucked_value, wich i found in PAM firmware. Yes, it reversable, but we need more securityAccess snapshots

The terminal prog you use is scriptable abd seems pretty cool. I'm just using Hterm which is not able to automate things. Would you share your spamm script or tell how you did it?

Here is it:

term.png

Then i parsed file in Excel and notepad

[oscarboiro]

I try some times and always repeat same codes, y try aroun 35 times and only have this codes:
1-----------------------------------
H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 DA CD C6 00 00
H: 720 05 27 02 E3 AD D2 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00


2--------------------------------------
H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 53 A6 17 00 00
H: 720 05 27 02 C6 1D 0D 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00

3---------------------------------------
H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 3B 61 CB 00 00
H: 720 05 27 02 A7 F7 A5 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00

4---------------------------------------
H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 1A EC 70 00 00
H: 720 05 27 02 99 FB 69 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00

5--------------------------------------

H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 A8 B6 7B 00 00
H: 720 05 27 02 6A FC AD 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00
6---------------------------------------

H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 7B 0F 75 00 00
H: 720 05 27 02 8A 48 6E 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00
7--------------------------------------

H: 720 02 10 85 00 00 00 00 00
H: 728 02 50 85 00 00 00 00 00
H: 720 03 22 D1 00 00 00 00 00
H: 728 04 62 D1 00 85 00 00 00
H: 720 02 27 01 00 00 00 00 00
H: 728 05 67 01 87 35 20 00 00
H: 720 05 27 02 2B 73 68 00 00
H: 728 02 67 02 00 00 00 00 00
H: 720 10 09 34 00 00 00 00 00
H: 728 30 00 01 00 00 00 00 00
H: 720 21 00 03 00 00 00 00 00
H: 728 03 74 01 01 00 00 00 00
H: 720 11 01 36 0D 00 03 12 00
H: 728 30 00 01 00 00 00 00 00

when i have more, i write on a file and upload it.