pcmhacking.net

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

In-Tech wrote:Hiya Folks,
Very interesting stuff Tazzi.
Well, I have booked myself into shitshow Friday, Saturday, Sunday, Monday and Tuesday so far
Very possible I can hook up an EECV on the test bench and log some data Saturday night. This might get fun

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.

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

Whiteford wrote: Jakka351 attempted to join this forum but was rejected...