BA Falcon BEM EEPROM via CAN

[pman92]

Anyone know if the BA/BF ACM (audio module) EEPROM can be read/written over OBD in a similar way?

Apparently the security code error (like you get when you have PATS off) can be disabled:
https://www.youtube.com/watch?v=zVA4_IWcCwI
But it would be even better if you didn't have to pull everything apart to do it.

[jakka]

If anything it would be done via traditional diagnostic services, so unlocking the module, request download, transfer data. It won't be anything like this because this is module manufacturer specific protocols and they were manufactured by different companies.

[pman92]

I got a set of BA modules and set them up on the bench to start playing around.
I thought I would give reading the BEM EEPROM a go since you've already laid out how to do it, but I didn't get very far:

TX: 726 [02 10 87 00 00 00 00 00] // Request ECU Adjustment session
RX: 72E [03 7F 10 11 00 00 00 00] // Negative Response 0x11: mode not supported

Is there something that needs to be done beforehand?

[jakka]

Module obviously doesn't support that diagnostic session, likely it only supports mode 10 81, standard diagnostic session, 85 will definetly not be supported. Just skip starting a diagnostic session and go straight onto the service 2F request.

[pman92]

Module obviously doesn't support that diagnostic session, likely it only supports mode 10 81, standard diagnostic session, 85 will definetly not be supported. Just skip starting a diagnostic session and go straight onto the service 2F request.

Thanks. I've been playing around with python can and am learning a heap. Built a python library to handle all the GDS formatting and another to log data with pretty colours to the terminal, html file or csv file - with descriptions of what the message is. Making it super easy and I'm having fun

Ive also removed the SOIC8 EEPROM from an ACM. Hooked up an Arduino in it's place acting as an I2C slave simulating the 24C02 eeprom. Talks to the PC via serial. Another python script provides a GUI with a visual representation of the eeprom contents and callbacks to the CAN python script. I can then tell exactly when the ACM is accessing or writing eeprom, which address, what it's reading or writing etc. As well as set the eeprom to whatever I want without having to desolder it every time.

At this stage all I've done is run a brute force read / write common identifier on the ACM. Took about 8 hours. Got a list of all identifiers it supports (ie. Didnt return request out of range). And for the ones that were a success (ie. Didn't return conditions not correct) and involved eeprom access, I've got the eeprom locations it read / wrote for that request.

With the arduino simulator I know the eeprom location I'm interested is only read when battery is first connected. So not expecting theres a write identifier that will change it.

It also looks like the ACM does support diagnostic session 85 programming, but the request returns conditions not correct.

I'll have another play with the BEM tonight when I get home

[jakka]

If it supports diagnostic session 85 (ECU programming session) then it is likely that the firmware can be flashed using service 34, 35,, 36 and 37. Request Upload and Transfer Data, as well as possibly service 23 direct memory read.

[pman92]

If it supports diagnostic session 85 (ECU programming session) then it is likely that the firmware can be flashed using service 34, 35,, 36 and 37. Request Upload and Transfer Data, as well as possibly service 23 direct memory read.

That would make sense.
The problem seems to be getting it to start a session 85 (always returns 0x22 - conditions not correct)
0x34 / 0x35 request download / upload both respond 0x11 - service not supported (but I assume this may be because it isn't in a 0x85 programming session)

It does accept and respond to 0x3E tester present, but having it makes no difference.
It doesn't support security access 0x27 (reply 0x11 - service not supported).
It doesn't support module reboot 0x11 (reply 0x11 - service not supported).
I tried FF'ing and 00'ing out the eeprom in case there was a flag there to prevent it, didn't help.
It responds to 0xB1 diagnostic command with the same error - conditions not correct

[pman92]

I might start looking at an emulator to keep the ACM happy rather than trying to modify the eeprom.
It must require the 6F6 PCM messages that aren't transmitted when PATS is off, or the corresponding 6F8 BEM messages.

ACM module initialization looks pretty simple.
1. Read seed DID (0x22) "E231" > returns 4 bytes (which happen to be stored at 0x00 to 0x03 in eeprom)
2. Do some sort of calculation on them
3. Write key DID (0x2E) "8200" with the 2 bytes you came up with. The valid 2 bytes are stored right after at 0x04/0x05 in eeprom. The ACM accesses them and confirms your response was correct
4. If correct, ACM sends positive response to 0x2E write request, and writes 4 bytes to 0x06-0x09 in eeprom. Plus sets a single bit at 0x0C (I assume is a flag). I assume this the link data, somehow relates to the BEM/PCM messages

I've done a bunch of seed / key exchanges:
18 03 94 4F = 91 91
00 00 00 00 = 50 05
FF FF FF FF = AA AA
AA AA AA AA = F5 4F
55 55 55 55 = 00 00
01 02 03 04 = 42 15
04 03 02 01 = 11 25
12 34 56 78 = 77 32
87 65 43 21 = 23 77
DE AD BE EF = BD FB
AA AA 55 55 = F4 00
55 55 AA AA = 01 4F
55 AA 55 AA = 14 0F
AA 55 AA 55 = F1 40
01 00 00 00 = 40 05
00 01 00 00 = 59 05
00 00 01 00 = 50 95
00 00 00 01 = 50 05
00 00 02 00 = 50 25
00 00 FF FF = 50 AA
FF FF 00 00 = AA 05
00 00 00 02 = 50 05
00 00 00 10 = 50 04
00 00 00 11 = 50 04
00 00 00 20 = 50 07
00 00 00 30 = 50 06
00 00 00 40 = 50 01
00 00 00 50 = 50 00
00 00 00 60 = 50 03
00 00 00 70 = 50 02
00 00 00 80 = 50 09
00 00 00 90 = 50 08
00 00 00 A0 = 50 0F
00 00 00 B0 = 50 0E
00 00 00 C0 = 50 09
00 00 00 D0 = 50 08
00 00 00 E0 = 50 0B
00 00 00 F0 = 50 0A

Kind of looks like the first 2 seed bytes make up the first key byte, and 2nd 2 make up the 2nd.

Once that's worked out, just a matter of working out what 6F6 / 6F8 messages are required, and you could make the ACM think its happily linked and work fine

[antus]

I've been having a play around with this, the only thing is you have

55 55 55 55 = 00 00
and
55 55 AA AA = 01 4F

So looking at only the first 16 bits of the seed and first 8 bits of the key, there must be something else to set a bit in the second example, or an error in that one row.

I'd be interested to see a couple of the last seed and keys in list but with 00 01 in the first 16 bits where you have 00 00 above to see what changes, as well as a couple more sequences. eg

55 55 55 56
55 55 55 57
00 00 00 01
00 00 00 02
00 00 00 03
55 56 AA AA
55 55 AA AB
00 00 00 12 (and increment until something else changes. this one to see if the last nibble makes any difference at all).

[pman92]

I'd be interested to see a couple of the last seed and keys in list but with 00 01 in the first 16 bits where you have 00 00 above to see what changes, as well as a couple more sequences.

They were done by hand so human error is possible, but I've double checked and confirmed 55 55 AA AA = 01 4F.

There's a couple of things read by IDS / Forscan when connecting to the module. Thought maybe they were used but changing them has no effect, so it seems the result is calculated only from those 4 bytes.

00 00 00 13 --all the way to-- 00 00 00 19 = 50 04
55 55 55 56/57/59 all = 00 00
55 55 55 AA AB/AC/AD/AF all = 01 4F
00 00 00 00 to 0F all = 50 05
looks like the last nibble has no effect. I guess its bit shifted out at some point

I did a bunch more:
00 00 01 00 = 50 95
00 00 02 00 = 50 25
00 00 03 00 = 50 15
00 00 04 00 = 50 65
00 00 05 00 = 50 55
00 00 0A 00 = 50 A5
00 00 0B 00 = 50 95
00 00 0C 00 = 50 45
00 00 0F 00 = 50 55

And then this, and they all returned the same results as above
(doesn't matter which nibble the value was in on the 3rd byte):
00 00 10 00 = 50 95
00 00 20 00 = 50 25
00 00 30 00 = 50 15
00 00 40 00 = 50 65
00 00 50 00 = 50 55
00 00 A0 00 = 50 A5
00 00 B0 00 = 50 95
00 00 C0 00 = 50 45
00 00 F0 00 = 50 55

then with both nibbles:
00 00 FF 00 = 50 A5
00 00 55 00 = 50 05
00 00 11 00 = 50 85
00 00 22 00 = 50 45
and then I was thinking "3rd seed byte = 3rd key nibble" again, until:
00 00 AA 00 = 51 45
which is the same thing happening you pointed out above.
AB does the same overflow into the 2nd nibble thing:
00 00 AB 00 = 51 35
But then it goes back to 50:
00 00 AC 00 = 50 E5
00 00 AD 00 = 50 D5
00 00 AE 00 = 50 05
00 00 AF 00 = 50 F5

Here some samples from the first 16 bits:
00 01 00 01 = 59 05
00 02 00 02 = 52 05
00 01 00 10 = 59 04
00 02 00 10 = 52 04
00 FF 00 FF = 5A 0A
00 0F 00 00 = 55 05
00 F0 00 00 = 55 05
00 0F 00 AA = 55 0F
00 F0 00 AA = 55 0F
00 0A 00 AA = 5A 0F
00 A0 00 AA = 5A 0F

01 00 00 01 = 40 05
02 00 00 01 = 70 05
03 00 00 01 = 60 05
01 01 00 00 = 49 05
05 05 00 00 = 05 05
F0 00 00 00 = 50 05


Started recognizing some patterns, and predicted this, and sure enough:
55 55 00 50 = 00 00

Got me thinking about how do we get FF FF? Had it all worked out except the 2nd nibble of the result (just from looking at previous results), and confirmed:
AA 00 BE AA = F0 FF
Hmm, what if they are just mirrored? Yep:
AA EB BE AA = FF FF

So it seems that each byte basically does effect the corresponding nibble is the result (4 bytes in, 4 nibbles out).
However there must be some edge cases with overflow or something (such as AA and AB of the 3rd byte, setting the LSB of the 2nd nibble)

And it also look like the first nibble of first byte has no effect (same as how the last nibble of the last byte has none):
00 00 00 00 = 50 05
A0 00 00 00 = 50 05
F0 00 00 00 = 50 05

And it makes sense why we get 50 and 05 (they are mirrored nibbles of each other)

And sure enough, the 2nd byte nibble order has no effect:
00 0A 00 00 = 5A 05
00 A0 00 00 = 5A 05 also

Anyway not sure if its ever going to be any use to anyone, but I've uploaded the python scripts I'm using to play with this to GitHub:
https://github.com/pman92/FordGDS