Programming china PCF7953 EROM BMW E90 key

[pyyardyas]

Key after sending "09 00 00 01 00" responds with "91" indicating its locked, I proceed and send "09 01 00 01 00" to erase chip memory - response "06", found EROM file for my key, added 5 bytes at beginning "2B 00 00 00 20" and added last 4 bytes as the CRC32. I send the file and get a confirmation of "06", send program "4B 00 00 00 02" and also a response "06". Trying to verify and read the memo back "0D 00 00 00 02", I get a response of "04" and trying to re-connect to the chip still responds with "91" as it would still be locked.

Im using HTerm and a keyless-go e90 PCF7953 868mhz keyless key and a "bluepill" for communication .

[tusker-tools]

Hi,
thanks for your feedback! It was a while ago when I worked on the project, but nevertheless let's try to get it working ;-)

Could you pls. try a few things?

1. After issuing the Connect&Erase command "09 01 00 01 00", could you try to send a "09 00 00 01 00"? This should return "06", indicating an unlocked chip.
2. After 1. could you try to read the memory with command "0D 00 00 00 00"? With "0D 00 00 00 02" you were using, you would basically only read one byte from adress 0x200 (specified by the length parameter 0200).
3. Could you try again programming data to the PCF using "0B 00 00 00 00"? This is the PROGRAM_ER64 command, which is required for programming the full 8kB. The 4B (PROGRAM_ER) command can only write the first 4kB. But anyhow, the 4kB command should not have failed.
4. Did you use the correct EROM data? I discovered (after weeks of debugging), that most files in the internet have a wrong byte order (or bit order....don't remember exactly). You need to use the one for VVDI tool, this should be correct.

[pyyardyas]

Hi, thanks for your feedback! It was a while ago when I worked on the project, but nevertheless let's try to get it working ;-)

Could you pls. try a few things?

1. After issuing the Connect&Erase command "09 01 00 01 00", could you try to send a "09 00 00 01 00"? This should return "06", indicating an unlocked chip.
2. After 1. could you try to read the memory with command "0D 00 00 00 00"? With "0D 00 00 00 02" you were using, you would basically only read one byte from adress 0x200 (specified by the length parameter 0200).
3. Could you try again programming data to the PCF using "0B 00 00 00 00"? This is the PROGRAM_ER64 command, which is required for programming the full 8kB. The 4B (PROGRAM_ER) command can only write the first 4kB. But anyhow, the 4kB command should not have failed.
4. Did you use the correct EROM data? I discovered (after weeks of debugging), that most files in the internet have a wrong byte order (or bit order....don't remember exactly). You need to use the one for VVDI tool, this should be correct.

1. 09 01 00 01 00 - responds with 06
   09 00 00 01 00 - responds with 91
2. 0D 00 00 00 00 - responds with 04 (same as 0D 00 00 00 02)
3. 0B 00 00 00 00 - responds with 06, although I get 04 after trying to read with "0D 00 00 00 00"
4. yes, im using the version for vvdi, I think I got it from a website called "transpondery.com", im using "5WK49145 EROM FOR VVDI", Ive added 5 bytes on the beginning and calculated CRC32 from the raw, unchanged EROM file - added 4 bytes at the end of the EROM file - because Im meant to add first 5 bytes, add 4 last and not modify the first 5 bytes and last 4 bytes right?

Im not 100% sure what chip is that but Hitager detected it as PCF7953/PCF7945 and the chip has the same amount of legs as PCF7953 but there are no markings on it at all because its a china key,

[tusker-tools]

That's a bit strange. When the chip is unlocked, 09 00 00 01 00 command should always respond with 06, Can you try the procedure for 26A0700? This was the chip I found in china key. Just try 09 00 00 01 00 and then 09 00 00 00 00.

Are you sure that there is no marking on the chip at all? This sound suspicious. Maybe it's some chinese clone where MDI interface is not working as expected.

Do you have a logic analyzer to check the chip communication?

[pyyardyas]

Yes, strangely theres no marking on the chip at all. Ive earlier bought a (non keyless) pcf7945 and received a 26A0700 aswell (and programmed it without a problem to a CAS3). Im trying to unlock this pcf7953 chip since when programming crypto something must have went wrong since even if i input the correct crypto it wont let me read the chip (crypto error)

09 00 00 01 00 responds with 91
09 00 00 00 00 responds with 90

the 90 response seems weird though, Ive made the wires fairly short and soldered them well - and it responds to other requests.

well, if it wont work out I will most likely try and return it, probably some really bad quality clone

[tusker-tools]

Well, this response is strange. I really don't trust that chip. Usually the wiring isn't critical, so I don't expext that to be a problem.
Can you make some logic analyzer captures?

[pyyardyas]

How should I paste it here? it doesnt allow me to attach a .sal file

[tusker-tools]

Can you attach it as zip?

[pyyardyas]

yes, it worked now, I tried earlier as .rar and it didnt let me either

heres what the log contains from start to end:

09 00 00 01 00
09 00 00 00 00
09 01 00 01 00
0D 00 00 00 00

MonitorInterfaceChinaPCF7953.zip

[tusker-tools]

Very hard to tell. I will have a look tomorrow. If you like, you can try to compare the signals with the MDI Spec in the meanwhile:
https://github.com/w01230/PCF7953/blob/dd764cd7ac998fa4511c0260258db5e5e0c79dea/f7953mdi.pdf

As far as I remember, my program worked the last time I tried.

On your screenshot it looks like the MDI is correctly initialized:

The second command here is a C_TRACE, which halts the chip to prevent the watchdog reset.

But when the next communication is initiated by pulling MSDA low at 34.014s, the chip does not respond anymore.

[pyyardyas]

hm, quite interesting, seems like it could really be a badly cloned chip, Im gonna try and acquire a used BMW key with a PCF7953 chip and retry

[pyyardyas]

btw, I forgot to mention something - the chip isnt actually "locked", I can still for example read remote data using Hitager since the P3 wasnt ever set to lock, seems like the EROM didnt get erased either? The only problem is that the key has unkown crypto, something must have went wrong while programming - not sure. Brute forcing the crypto isnt a option due to like 300 trillion possibilities. Is there any other way to overcome this other than renewing the key?

[tusker-tools]

I think the lock state of the EROM/EEROM is independend from the lock state defined by the Hitag2 memory pages. At least for PCF7945 I experienced that key was not even responding when EROM was not locked. Seems that the software only boots up if it detcts a locked key, most likely for security reasons.
I haven't heard of any attacks revealing Hitag2 crypto pages. This would only be possible if you have a matching reader e.g. in the car .

[pyyardyas]

well, I guess the key will just end up on the bottom of the drawer, either way really appreciate your help

also heres the blank chip pic

[tusker-tools]

I just had another look to you capture. There is still sth. I do not understand: I can't see the erase command sent to the key. I only see the 0x55 resonse from the key and afterwards C_TRACE (0x02) is sent. But instead, a C_ER_EROM (0x08) should be sent.

Are you sure you sent me a capture where you actually sent 09 01 00 01 00?

Actually, a delete procedure should look like this:

[pyyardyas]

here, Ive sent "09 01 00 01 00" 3 times

monitorinterfaceerase.zip