ECU counters and stats

[aboulfad]

DISCLAIMER: This investigation is intended so we learn about our cars, not responsible for any misuse of information below.

Chasing where car data, logs, counters, stats are stored in our vehicle, I have discovered many interesting facts that are summarized in various threads, one fun one is Interesting stats for DCT.

I have many theories but haven't yet done any testing to understand how and if any of those counters survive flashing. An interesting comment made by BuLoOoSki regarding DME programming counter.

Originally Posted by BuLoOoSki

It doesn't get erased post flash. To my understanding the only way to erase it is to restore the DME using the original readout files and that will restore the counter to whatever state it was at the time of readout. Now whether that can be done via OBD or it has to be bench flashed I'm not sure.

Original readout file = I assume is the dump of the DME memory when it gets read for the purposes to be unlocked, which I think is exactly 4Mb, the size of TC1797 Flash PMU0/1. If we look at the attached TC1797 mmap, there is 64Kb DFLASH (16Kb EEPROM) that I assume is storing these counters! So if you restore the original readout file, and the original file somehow contains the content of DFLASH, then yes, probably the counter will restore its original value. Or those counters are written into PFLASH (weird but possible and not common)

[aboulfad]

Originally Posted by aboulfad

...and the original file somehow contains the content of DFLASH, then yes, probably the counter will restore its original value. Or those counters are written into PFLASH (weird but possible and not common) ...

I am quoting myself but I just discovered this in my other mysterious thread, there's 64Kb, the same ones queried by those mysterious jobs, that are in the DME readout file... what's in them, come on figure it out imbecile

[BuLoOoSki]

Originally Posted by aboulfad

Original readout file = I assume is the dump of the DME memory when it gets read for the purposes to be unlocked, which I think is exactly 4Mb, the size of TC1797 Flash PMU0/1. If we look at the attached TC1797 mmap, there is 64Kb DFLASH (16Kb EEPROM) that I assume is storing these counters! So if you restore the original readout file, and the original file somehow contains the content of DFLASH, then yes, probably the counter will restore its original value. Or those counters are written into PFLASH (weird but possible and not common)

But if we are talking about restoring (which no tuned car wants as it will lock the DME), why not flash with the stock DME swfl, which would most likely wipe clean the DME's flash?

I believe this is correct. There is a 54KB file (.EPR file format) in addition to the 4MB file. You would use the 4MB to flash back to stock, but to restore the DME to it's original status you'd use the 64KB file as well. So my guess is the flash counter and the "unlocking" happens in the 64KB file.

[BuLoOoSki]

I was just going through the DME files I have and found something interesting. Prior to getting BM3, I had been flashed by another company. That company used CMD flash and the readout files they obtained are slightly different. First off, the DFLASH file is 128KB, and then I realized that they only obtain one of the two 2MB files and only modify that. So I'm guessing that they only modify one area of the DME and leave the other half unchanged? But not sure about the 128KB file.

[aboulfad]

BuLoOoSki , that is most interesting (read PM). 64Kb is also the size of our BTLD that is most interesting about that company modifying PFLASH0 only, that explain few things, its like I am connecting some dots, but not there yet... a futile exercise.

From region 0x8020 0000 to 0x8021 0000, which is the first 64Kb of PFLASH1 is the same data as in those mysterious stuff being dumped into FASTA (STATUS_TRIPRCRD*), given that other company modified the first 2Mb, it could imply many stuff without some details about the content of the 2nd 2Mb. Previous devices from Infineon only had 2Mb, the TC1797 being a high end chip has 2x2Mb (PMU0/PMU1). I gotta finish me mapping the TC1797 memory usage and stop being lazy...

The tamper code delete most likely does not lie in data, but rather in program memory, similar to the techniques to remove any other DTC, but i am only learning so don't quote me.

[Jaymax85]

Originally Posted by BuLoOoSki

I believe this is correct. There is a 54KB file (.EPR file format) in addition to the 4MB file. You would use the 4MB to flash back to stock, but to restore the DME to it's original status you'd use the 64KB file as well. So my guess is the flash counter and the "unlocking" happens in the 64KB file.

can this 64kb file be flashed via obd2 to restore locked status and flash counter?

[aboulfad]

Originally Posted by HELLOimJ

can this 64kb file be flashed via obd2 to restore locked status and flash counter?

It's all conjecture at this point... I know for sure you can't flash it with Esys/OBD, so maybe bench flashing tools or using the BM3 app that supposedly can bring your DME back to its stock unaltered version? There are too many moving parts, boot loader, swfl, data flash...

And we're guessing the contents of that file, I don't have it to look into it but it seems closely linked to triprcrd... and I have those via FASTA.

[BuLoOoSki]

Originally Posted by HELLOimJ

can this 64kb file be flashed via obd2 to restore locked status and flash counter?

Like it says in my post quoted in the OPs first post, I don't know. But I think so. There is an option on the BM3 that says Full Restore, haven't tried it.

[aboulfad]

Originally Posted by BuLoOoSki

Like it says in my post quoted in the OPs first post, I don't know. But I think so. There is an option on the BM3 that says Full Restore, haven't tried it.

And let me guess there is no documentation for that feature :

[aboulfad]

Originally Posted by BuLoOoSki

.. First off, the DFLASH file is 128KB, and then I realized that they only obtain one of the two 2MB files and only modify that. So I'm guessing that they only modify one area of the DME and leave the other half unchanged? But not sure about the 128KB file.

DFLASH for TC1797 is 2x32K as seen above from Infineon doc. I almost done finishing mapping our DME TC1797 memory and that 128K is the last piece of the puzzle (its at 0x8000 0000 - 0x8002 0000)

The first 64k (roughly) of the TC1797 is the bootloader and the next 64k is still not figured out. How do I know all this, well thanks to the .xml files we have in the psdZ, more to come

BTW, that company grabbed Segment 1 of DME, because at 0x8018 0000 is the DME variant file

[Celestion]

Originally Posted by aboulfad

BTW, that company grabbed Segment 1 of DME, because at 0x8018 0000 is the DME variant file

hmmm more questions (again, sorry if they are silly)....

A. So that is where the DME is identified as a ZCP, non-ZCP, GTS, etc?

B. Once you've mapped the DME memory, would it be useful to capture the I/O of an actual DME flash or two? Using your memory map as template, perhaps you could then track which regions are changing/not-changing when flashing different swfls. For example, if you captured the I/Os of flashing ZCP, non-ZCP, and ECE swfls, by process of elimination you might able to identify which regions are free of FSC or other write limitations and which ones aren't.

[aboulfad]

Originally Posted by Celestion

hmmm more questions (again, sorry if they are silly)....

A. So that is where the DME is identified as a ZCP, non-ZCP, GTS, etc?

Not exactly, as you know there is a DME common swfl file (lets call it file z) and DME swfl file [a..d] variant files (ECE, ECE DKG, US, US DKG), according to the .xml map, they are loaded in TC1797 memory at 0x8018 0000. What those variants file contain is a mystery, but I know for sure they contain engine maps, bcoz I found many !

B. ... would it be useful to capture the I/O of an actual DME flash or two? ...

Most definitely, but you cant dump our DME TC1797 over OBD, it requires special tools and removing the DME from the engine to unlock it, then allow read/write. If there are some people that would like to share their DME files for science, please do

As far to your comment for FSC, give it up, it is so much more complex than you can imagine, I wager it's easier that we figure out how to tune our engines than cracking engine FSCs, and tuning engines is an insanely infinitely complex task !

I'll post shortly the memory map, in the end it was easy, but wont be of much help to no one

[Celestion]

Originally Posted by aboulfad

Most definitely, but you cant dump our DME TC1797 over OBD, it requires special tools and removing the DME from the engine to unlock it, then allow read/write.

Right, I'm familiar with that stuff. That isn't what I meant by capturing the flash I/O (I'm probably not using the correct terminology).

I was referring to the use of a tool like tcpdump to capture the raw TCP/IP data transferred when flashing the DME with e-sys. Using the timestamp of the e-sys logs, the timestamped raw TCP I/O data, and your memory map, you may be able to specify further which regions of the DME memory remain constant amongst the various DME configs (260a, 260c, 38a8, 38ac, etc), as well as which ones change, during the actual flashing process.

[aboulfad]

Originally Posted by Celestion

Right, I'm familiar with that stuff. That isn't what I meant by capturing the flash I/O (I'm probably not using the correct terminology).

I was referring to the use of a tool like tcpdump to capture the raw TCP/IP data transferred when flashing the DME with e-sys. Using the timestamp of the e-sys logs, the timestamped raw TCP I/O data, and your memory map, you may be able to specify further which regions of the DME memory remain constant amongst the various DME configs (260a, 260c, 38a8, 38ac, etc), as well as which ones change, during the actual flashing process.

I understand ... the .xml memory map is what is used by ESys to know where to load the swfl segments into the TC1797 PMU0/1. But in order to capture traffic on a ZCP, one would need a ZCP and flash it's DME and sniff the traffic,... My goal is to understand things not necessarily figure out how to make my engine get the extra 19Hp that ZCP has... so my research is focused on understanding the logs, stats, counters and their usage and where are they stored, hence why I am drawing out the map usage. I honestly don't care about getting more power, i have more than enough to handle...

Btw, just to add mystery for your FSC/ZCP curiosity, I have a dB that contains pretty much all the software file list for all the variants and the ZCP has a special entry that does not map to any file!

[Celestion]

Originally Posted by aboulfad

I honestly don't care about getting more power, i have more than enough to handle...

I agree, HP is uninteresting to me as well. I'm also more interested in boosting my "knowledge power" lol.

17-04-23 22:10:07,860 [INFO] [FlashTask - vin:WBS8M9C55G5D30728 - ecu:DME2 - da:0x12] com.bmw.prodias.io.tcp.HsfzTcpCommunicationLink: will send data for host 169.254.113.41 on port 6801, SA= 0xF4, TA= 0x12, link data= 0x00 0x00 0x10 0x00 0x00 0x01 0xF4 0x12 0x36 0x84 0x3B 0x00 0x02 ... 0x37 0x01 0xE4 0xF1 [ParallelTask-41]
DiagAdresses: 0xf4 -> 0x12

Using above log code as an example, one could look for this in the raw tcp dump (specifically at the 22:10:07,860 timestamp):
0x00 0x00 0x10 0x00 0x00 0x01 0xF4 0x12 0x36 0x84 0x3B 0x00 0x02

If that was found in the TCP dump and was unique to the time of 22:10:07,860 within the TCP dump, then you could look for that data sequence (plus a large chunk of immediately adjacent data to maximize probability of have a unique piece of data), in the DME and swfl. This would allow you to correlate the swfl data and the DME memory data on a 1:1 basis. That would be pretty cool IMO.

[aboulfad]

Originally Posted by Celestion

I agree, HP is uninteresting to me as well. I'm also more interested in boosting my "knowledge power" lol.

If so why did you go thru the trouble to remove your charcoals ok we need a ZCP that is willing to flash his DME... maybe you can offer them a Euro MDM for free in exchange for capturing the flashing session traffic !
Oh what about your ESys psdZ log when you flashed DME. Can you me send it my way, please?

[aboulfad]

FYI, Celestion , putting aside FSC stuff, I've correlated 1:1 where stuff goes, because I have found an M4 DME file on the net I know exactly what goes where, minus that ~60k just before 0x8002 0000 (seg 1 of file Z)

I thought that was cool, but gives you almost nothing, it's step 0 for the next 100 remaining steps.

[Celestion]

Originally Posted by aboulfad

If so why did you go thru the trouble to remove your charcoals ok we need a ZCP that is willing to flash his DME... maybe you can offer them a Euro MDM for free in exchange for capturing the flashing session traffic !
Oh what about your ESys psdZ log when you flashed DME. Can you me send it my way, please?

Sent.

errr, I removed them for... science?

[Celestion]

Originally Posted by aboulfad

FYI, Celestion , putting aside FSC stuff, I've correlated 1:1 where stuff goes...

If it wasn't for that annoying flash counter, one could do lots of cool frankenstein swfl experiments with the 1:1 swfl:dME maps of various f8x cars.

[aboulfad]

Originally Posted by Celestion

If it wasn't for that annoying flash counter, one could do lots of cool frankenstein swfl experiments with the 1:1 swfl:dME maps of various f8x cars.

FYI, You can't modify the swfl's without re-calculating a special checksum and probably the hash is signed (or some weird stuff), so what experiments were you thinking about ? as I mentioned in my other thread, a previous BP member almost came close to prog max trying to get ZCP firmware to run on M4, I think you must be related to each other

[Celestion]

Originally Posted by aboulfad

FYI, You can't modify the swfl's without re-calculating a special checksum and probably the hash is signed (or some weird stuff), so what experiments were you thinking about ? as I mentioned in my other thread, a previous BP member almost came close to prog max trying to get ZCP firmware to run on M4, I think you must be related to each other

There is more than one way to skin a goat. The frankenswafl could be used for packet injecting the flashing of a normal swfl. I'm not sure when the checksum comes into play. If its a preflash md5 check of the swfl, then packet injecting the frankenswaffle may work.

You would need to have the TCP dump mapped to do this though.

[aboulfad]

Originally Posted by Celestion

...
Using above log code as an example, one could look for this in the raw tcp dump (specifically at the 22:10:07,860 timestamp):
0x00 0x00 0x10 0x00 0x00 0x01 0xF4 0x12 0x36 0x84 0x3B 0x00 0x02

Originally Posted by Celestion

There is more than one way to skin a goat. The frankenswafl could be used for packet injecting the flashing of a normal swfl. I'm not sure when the checksum comes into play. If its a preflash md5 check of the swfl, then packet injecting the frankenswaffle may work.

You would need to have the TCP dump mapped to do this though.

- UDS "SecuredDataTransmission (84 hex) service:
The purpose of this service is to transmit data that is protected against attacks from third parties, which could endanger data security"

- Most of the hex you see in your file are UDS request/response control messages, so yes you need the tcpdump, and sniffing a DME flash session may not be a great idea especially if you are running wireshark//tcpdump on the same host, but it is dooable.
- I appreciate your enthusiasm, there are specific checksum algos from each ECU manufacturer for each ECU, this is another world... (FYI, I know very little, but enough to know this is extremely complex) and without specialized tools, you/I/we are just shooting in the dark ok now I need to figure the remaining bit...