OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
In-Tech
Posts: 785
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

Hiya Folks,
Very interesting stuff Tazzi.
Well, I have booked myself into shitshow Friday, Saturday, Sunday, Monday and Tuesday so far :lol:
Very possible I can hook up an EECV on the test bench and log some data Saturday night. This might get fun :thumbup:
Whiteford
Posts: 33
Joined: Mon Jan 21, 2019 10:35 am
cars: Ford Falcon

Re: OBDX Development - Developer Tools and Suggestions

Post by Whiteford »

Tazzi wrote:I tinkered around with the PWM AU ECUs quite a bit today. Neither seemed to want to play nicely with IDS for flashing.

It requests to ignition off, then it applies FEPs, then asks to ignition on (All simple tasks). I have confirmed 18v goes to pin13 on the AU falcon ECU as per the wiring diagrams.

When ignition turns on, we get a few frames spit out from the ECU, then 1 from the Scantool, and then no more responses.

Code: Select all

00 05 10 04 00 08 0B 61 00 31 - From ECU
00 05 10 04 00 08 0B 61 00 31 - From ECU
00 05 10 04 00 08 0B 61 00 31 - From ECU
C4 10 F5 31 A0 00 D8 39 01 9F - From Scantool
C4 F1 10 7F 31 A0 00 D8 22 66 - From ECU
C1 5A F5 B0 FD - From Scantool
We then get an error on the IDS screen saying Error 9 - 0x0851082

I played around with the numbers repeating it back to the ECU, and the "D8" in the ECU response after the scantool message is just repeating the D8 from within the scantool message.

The "22" in the ECU response seems to occur no matter what I send when using mode 31. If I send the frame and manually spam the frame, the 22 turns into 12. But then nothing else happens.

I feel like IDS was suppose to unlock the ECU first, but it doesnt appear to be doing that which is very odd.
When I request the seed from the ECU quickly, I also get a "22" at the end, so this would make me believe it means security timeout.

I then tried a security unlock request, and this to my surprise is a 2byte seed. I have always been use to seeing the 3byte seed/key on Fords.
When we do this:
64,10,F1,27,01

We get back:
C4,F1,10,67,01,00,XX where the XX is a byte that changes each time.

The seed can be requested every 6second.
OR
If you send an attempted key, it seems you can request the next seed straight away... so.. with that logic... we *could* brute force every single combination of seed/key.
Since it appears only 1 byte of the seed is changing, there is 256 possibilities (00 to 0xFF), and the response from the ECU is seems to indicate 2byte response, assuming there is only 1 byte that actually changes, then there would only be around 65,000 is combinations.

Or, alternatively if the Key ends up actually being 2bytes used, we have 256*65,536 = 16,777,216 combinations. Assuming there is no time lockout, we could request frames pretty quick.

Alternatively... I just find another software to try on the ECUs :lol:
Code 9 relates to the ECU not responding to the message sent by the diagnostic tester.

This looks like the ECU you have is faulty or you are missing something in your wiring.
User avatar
Tazzi
Posts: 3550
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

In-Tech wrote:Hiya Folks,
Very interesting stuff Tazzi.
Well, I have booked myself into shitshow Friday, Saturday, Sunday, Monday and Tuesday so far :lol:
Very possible I can hook up an EECV on the test bench and log some data Saturday night. This might get fun :thumbup:
A log would be fantastic!
I only need 1 valid seed key and I can run it through some of my algos to find which one matches.
Just sitting down for the day to see if brute forcing will work or not.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3550
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Whiteford wrote:
Code 9 relates to the ECU not responding to the message sent by the diagnostic tester.

This looks like the ECU you have is faulty or you are missing something in your wiring.
When I searched the fault online, a lot of people just randomly get it. Some was fixed through trying newer versions of IDs, others didn’t have a fix.

The ecu is responding, but as far as I can tell, it’s saying “not ready”. I tried varying the voltage to FEPs and there’s no other ground/powers to connect at all.

Maybe I have damaged these two ecus? Not sure!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3550
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Well, I can confirm the ECU only seems to change 1 byte on the seed request. I attempt every single combination of a 00 XX key sent for all possible seeds, but none were accepted.

So, I would assume both bytes will vary on the key side. I wonder if its not just like a simple XOR challenge of some similar.

My calcs showed I could do around 25 requests per second. Which isnt exactly great, about 40ms per request.

So, to try all seeds (0xFF combos) with a 2byte key (0xFFFF) would be 16,711,425 combos.
Sooooooooo this would be 16,711,425/25 = 668,457seconds = 11,140.95minutes = 185.6825hours =7.737 days.

If I bought a bunch of units, I could probably get through it under a couple days. This is also assuming the ECU doesnt actually have some sort of timeout between seed/key requests, but from what I can see.. a new seed is generated so long as I send a key request.

Going through all my Ford documentation, everything i see is 3byte or more for seed/key. I don't see anything specifically for 2byte, so I would assume this must run through its own separate security algo DLL in the factory IDS software.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3550
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Since reverse engineering each Ford PWM seed/key algo will be roughly 7days per unlock level, theres potentially up to 21days worth of unlocking to complete. This is more time then I am willing to commit the bench setup to, since there are other tasks to complete including CAN FD support.

If IDS was working for flashing the ECUs, I would be able to simply emulate seeds to calculate the keys, or better yet, see whatever DLL its using to calculate. We will have to circle back to PWM as I unfortunately do not have the free time to be performing this level for reverse engineering for just adding a high speed enable for PWM. The standard 41.6kpbs PWM used for diagnostics works fine at this time.

Some useful links I have come across for the Ford stuff over the last few days though:
Explains diagnostic commands: http://www.nast-group.caltech.edu/~murr ... 2003.0.pdf
ISO14230: https://pdf4pro.com/view/ssf-14230-road ... a1960.html
Some more Ford Commands and bunch of other items: https://github.com/jakka351/FG-Falcon

Code: Select all

diagnosticSessionControl	0x10
reportDiagnosticState	0x50
diagnosticSessionControl standardDiagnosticSession	0x81
diagnosticSessionControl ecuProgrammingSession	0x85
diagnosticSessionControl ecuAdjustmentSession	0x87
diagnosticSessionControl systemSupplierSpecific	0xFA
clearDiagnosticInformation	0x14
readDTCByStatus	0x18
readDataByLocalID(As Built)	0x21
readMemoryByCommonID(Data IDentifiers [DID])	0x22
readMemoryByAddress(Direct Memory Read[DMR])	0x23
requestSecurityAccess	0x27
reportSecurityAccess	0x67
writeDataByCommonID(Write DID Memory)	0x2E
inputOutputControlByLocalID (Routine Entry)	0x2F
startRoutineByLocalIdentifier(Ecu Self Test)	0x31
stopRoutineByLocalIetdentifier	0x32
requestRoutineResultsByLocalID	0x33
requestDownload	0x34
requestUpload	0x35
transferData	0x36
requestTransferExit	0x37
writeDataByLocalId(Write As Built)	0x3B
requestReadMemoryBlock	0x3C
writeMemoryByAddress	0x3D
testerPresent	0x3E
testerPresent RequestResponse	0x01
testerPresentSuppressResponse	0x02
controlDTCSetting	0x85
requestDiagnosticDataPacket	0xA0
dynamicallyDefineDataPacket	0xA1
noStoredCodesLoggingStateEntry	0xB0
diagnosticCommand	0xB1
inputIntegrityTestStateEntry	0xB2
requestManufacturerStateEntry	0xB4
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Whiteford
Posts: 33
Joined: Mon Jan 21, 2019 10:35 am
cars: Ford Falcon

Re: OBDX Development - Developer Tools and Suggestions

Post by Whiteford »

Tazzi wrote:Since reverse engineering each Ford PWM seed/key algo will be roughly 7days per unlock level, theres potentially up to 21days worth of unlocking to complete. This is more time then I am willing to commit the bench setup to, since there are other tasks to complete including CAN FD support.

If IDS was working for flashing the ECUs, I would be able to simply emulate seeds to calculate the keys, or better yet, see whatever DLL its using to calculate. We will have to circle back to PWM as I unfortunately do not have the free time to be performing this level for reverse engineering for just adding a high speed enable for PWM. The standard 41.6kpbs PWM used for diagnostics works fine at this time.

Some useful links I have come across for the Ford stuff over the last few days though:
Explains diagnostic commands: http://www.nast-group.caltech.edu/~murr ... 2003.0.pdf
ISO14230: https://pdf4pro.com/view/ssf-14230-road ... a1960.html
Some more Ford Commands and bunch of other items: https://github.com/jakka351/FG-Falcon

Code: Select all

diagnosticSessionControl	0x10
reportDiagnosticState	0x50
diagnosticSessionControl standardDiagnosticSession	0x81
diagnosticSessionControl ecuProgrammingSession	0x85
diagnosticSessionControl ecuAdjustmentSession	0x87
diagnosticSessionControl systemSupplierSpecific	0xFA
clearDiagnosticInformation	0x14
readDTCByStatus	0x18
readDataByLocalID(As Built)	0x21
readMemoryByCommonID(Data IDentifiers [DID])	0x22
readMemoryByAddress(Direct Memory Read[DMR])	0x23
requestSecurityAccess	0x27
reportSecurityAccess	0x67
writeDataByCommonID(Write DID Memory)	0x2E
inputOutputControlByLocalID (Routine Entry)	0x2F
startRoutineByLocalIdentifier(Ecu Self Test)	0x31
stopRoutineByLocalIetdentifier	0x32
requestRoutineResultsByLocalID	0x33
requestDownload	0x34
requestUpload	0x35
transferData	0x36
requestTransferExit	0x37
writeDataByLocalId(Write As Built)	0x3B
requestReadMemoryBlock	0x3C
writeMemoryByAddress	0x3D
testerPresent	0x3E
testerPresent RequestResponse	0x01
testerPresentSuppressResponse	0x02
controlDTCSetting	0x85
requestDiagnosticDataPacket	0xA0
dynamicallyDefineDataPacket	0xA1
noStoredCodesLoggingStateEntry	0xB0
diagnosticCommand	0xB1
inputIntegrityTestStateEntry	0xB2
requestManufacturerStateEntry	0xB4
Jakka351 attempted to join this forum but was rejected...
User avatar
Tazzi
Posts: 3550
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Whiteford wrote: Jakka351 attempted to join this forum but was rejected...
Did he respond to the automated email thats sent which asks the person to message so the admins know its not just a bot trying to sign up?

If he has insight into the older Ford stuff, or where to look, that would be excellent.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
In-Tech
Posts: 785
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

Between shitshows this weekend, I was able to do a bit of logging. I have 3 different EECV's here as we get further to do some better testing.
The 11 60 at the start is of no reference. It appears we have a 3 byte seed of 01 94 6A. I haven't done this in a while so I can't remember all the other commands, if you can tell me what to surf for. I thought 27 01 was seed request??? Shoot, sry. I have notes somewhere but you can probably reply off the top of your head :)
A 3 minute log is an over 20mb .txt file :comp: I haven't figured out how to parse it correctly but can search for commands ok. Let me know what I can do to help :thumbup:

Code: Select all

Here are 3 examples on the same download.

000869: Bulk or Interrupt Transfer (UP), 2023-02-20 07:48:02.5386252 +0.0019169. (1. Device: FT230X Basic UART (Bridge(I2C/SPI/UART/FIFO))) Status: 0x00000000
Pipe Handle: 0x36580d8 (Endpoint Address: 0x81)
Get 0x4e bytes from the device
 11 60 49 01 10 27 01 03 01 94 6A 94 91 89 0D 76   .`I..'...”j”‘‰.v
 D4 22 30 47 CA 52 64 87 2E F7 9B 5E DD C0 B0 56   Ô"0GÊRd‡.÷›^ÝÀ°V
 7C 54 72 D4 A4 77 D2 84 C9 E2 46 4F AE 87 3F 86   |TrÔ¤wÒ„ÉâFO®‡?†
 F2 ED A2 27 C7 5C BC 2E 06 A6 04 FC 54 46 8A CA   òí¢'Ç\¼..¦.üTFŠÊ
 11 60 63 9C 55 21 E0 4B E0 91 72 2F 6E 00         .`cœU!àKà‘r/n.
 
 007363: Bulk or Interrupt Transfer (UP), 2023-02-20 07:48:11.0118994 +0.0019374. (1. Device: FT230X Basic UART (Bridge(I2C/SPI/UART/FIFO))) Status: 0x00000000
 Pipe Handle: 0x36580d8 (Endpoint Address: 0x81)
 Get 0x4e bytes from the device
  11 60 49 01 10 27 01 03 01 94 6A 94 91 89 0D 76   .`I..'...”j”‘‰.v
  D4 22 30 47 CA 52 64 87 2E F7 9B 5E DD C0 B0 56   Ô"0GÊRd‡.÷›^ÝÀ°V
  7C 54 72 D4 A4 77 D2 84 C9 E2 46 4F AE 87 3F 86   |TrÔ¤wÒ„ÉâFO®‡?†
  F2 ED A2 27 C7 5C BC 2E 06 A6 04 FC 54 46 8A CA   òí¢'Ç\¼..¦.üTFŠÊ
  11 60 63 9C 55 21 E0 4B E0 91 72 2F 6E 00         .`cœU!àKà‘r/n.
 
 017435: Bulk or Interrupt Transfer (UP), 2023-02-20 07:48:28.0464474 +0.0019174. (1. Device: FT230X Basic UART (Bridge(I2C/SPI/UART/FIFO))) Status: 0x00000000
 Pipe Handle: 0x36580d8 (Endpoint Address: 0x81)
 Get 0x4e bytes from the device
  11 60 49 01 10 27 01 03 01 94 6A 94 91 89 0D 76   .`I..'...”j”‘‰.v
  D4 22 30 47 CA 52 64 87 2E F7 9B 5E DD C0 B0 56   Ô"0GÊRd‡.÷›^ÝÀ°V
  7C 54 72 D4 A4 77 D2 84 C9 E2 46 4F AE 87 3F 86   |TrÔ¤wÒ„ÉâFO®‡?†
  F2 ED A2 27 C7 5C BC 2E 06 A6 04 FC 54 46 8A CA   òí¢'Ç\¼..¦.üTFŠÊ
  11 60 63 9C 55 21 E0 4B E0 91 72 2F 6E 00         .`cœU!àKà‘r/n.
  
  
In-Tech
Posts: 785
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

Hiya,
While on the phone, I was looking and found some of my notes. Let me know if this is correct.

27 01 = Request seed
67 01 = Return seed
27 02 = Send Key
67 02 = Positive response

26 04 = Request 4x
66 04 = Positive response

Sheesh, how fast I forget stuff :lol: Let me know if this sounds correct.

When I get some time I will try to break down the packets, but if you already know, save us both some time :study:
Post Reply