bootmod3 update - 201101 DME tamper code

[BuLoOoSki]

Originally Posted by Sleeper

Where did I lie? The 90%? That's exaggerated obviously, but you get my point.

Hahaha, yeah the 90%. I get what you mean though

[BuLoOoSki]

Originally Posted by aboulfad

مرحبا DISCLAIMER: I am interested in learning stuff for the fun of learning, my car isn't and will never be tuned

Stupid of me I forgot that small gotcha of our DME, you are absolutely right... let's bring it back to the comment made in first post, I am trying to understand the tech details of this statement: "Note that a DME software update done at the dealership will have this code return though and you might still get flagged for warranty so take that into account."

Hypothetical scenario, So a BM3 tuned car comes in to dealer with no tamper codes, owner says don't update my car, dealer screws up and updates Istep, now depending on the Istep, there could be update to any of the following for DME: BTLD, SWFL, CAFD.

So how could that tamper code re-appear again? Not knowing any details of this tamper code delete, and knowing what a bootloader does in general, and assuming dealer Istep updates only swfl (as BTLD is rarely updated):

1- Then with above scenario, post dealer Istep update you have an unlocked/modified BTLD, a stock DME swfl without BM3 tamper code delete, which next time it runs will detect the program manipulation and throws that code. Correct?

2- let's go through the steps, car is plugged in to ISTA/P, ignition is ON, basic vehicle test done, FASTA data retrieved and sent to mothership (no tamper code). Update is completed which includes erasing all DTCs (automatic step) in the ISTA/P post flashing steps.

Now here's the interesting point, when does the DME run its software and check stuff, with ignition ON, or engine ON, and more specifically when does that tamper code routine run?

This could be all conjecture, but maybe just maybe, and if the dealer makes that mistake and updates Istep against customer wish, that the tamper code is thrown on the next engine start, which is when the tech moves the car to the delivery area and hence that code was not logged with mothership and car not flagged.

I'm aware that you specifically simply want to understand how it all works

Scenario 1: Correct

Scenario 2: I have a similar understanding to what you explained there. However, when exactly the car checks for this tamper code I'm not sure (whether at ignition ON or after running for the first time etc.). If it is only thrown after the first start, then it will fly under the radar (Assuming that the 201101 Tamper code is the only way the dealership checks for a modified DME). Otherwise you'll be flagged.

If you are really interested, I can find out for sure. I have a map without the tamper code removed. I'll flash the car, delete DTC and then scan the car again for fault codes with ignition ON. It will tell us for sure. OR proTUNING Freaks can simply explain it for us

[aboulfad]

@BuLoOoSki , I am interested but given that DME has a limited amount of flashes (60 or so), I feel bad that you use two for the sake of my curiosity btw, I don't think the dealership checks for this stuff, it is BMW, maybe once FASTA is uploaded, a big Red Alarm starts ringing: "TAMPER CODE DETECTED" at the dealership

[Sleeper]

Originally Posted by aboulfad

@BuLoOoSki , I am interested but given that DME has a limited amount of flashes (60 or so), I feel bad that you use two for the sake of my curiosity btw, I don't think the dealership checks for this stuff, it is BMW, maybe once FASTA is uploaded, a big Red Alarm starts ringing: "TAMPER CODE DETECTED" at the dealership

I'm guessing that the ~60-flash limitation on the DME has to be a soft limitation. In proTUNING Freaks's R&D on this platform, I'm going to make an educated guess that they've likely flashed a single DME hundred of times. PTF, can you confirm?

[aboulfad]

Originally Posted by Sleeper

I'm guessing that the ~60-flash limitation on the DME has to be a soft limitation. In proTUNING Freaks's R&D on this platform, I'm going to make an educated guess that they've likely flashed a single DME hundred of times. PTF, can you confirm?

Now we are digressing but for the sake of knowledge, data retention in flash depends on nb of erase/programming. Have fun reading! Sure maybe it's a soft limit, but why is DME the only ECU with this smaller limit, compared to much higher nb for other ECUs...

[G35POPPEDMYCHERRY]

Originally Posted by VF-Engineering

Yes, this customers car did have our HEX Tuning Stage TWO ECU and TCU Software.

As we have discussed many times prior, HEX Tuning software does not result in a 201101 DME "tamper code".

This has been the case since we initially released our software for the F8X S55 M3/M4 back in May of 2015, and is still the case today.


What happened in this particular situation will happen with ANY brand of flash tune when the vehicle is flashed back to stock by the dealership. This is why we have always advised our customers to decline software updates or re-flashes at the dealership level.

The ability to switch maps between stock and tuned maps is purely a convenience feature and has never been intended to hide the software from BMW's engineers. Our customers are educated on this before purchasing our software, and ALL flashed ECU's, regardless of tuner, run the risk of triggering the 201101 tamper code when flashed at the dealership.

For more information, or to ask questions regarding to HEX Tuning, please do so in one of our threads, or contact us directly so we don't have to interrupt another brands discussion.

so if we decline updates. the only way a tune can be found is through physical inspection of dme>?

[BuLoOoSki]

Originally Posted by G35POPPEDMYCHERRY

so if we decline updates. the only way a tune can be found is through physical inspection of dme>?

Not necessarily. One way I can think of is via checking the flash counter of the DME.

[G35POPPEDMYCHERRY]

Originally Posted by BuLoOoSki

Not necessarily. One way I can think of is via checking the flash counter of the DME.

think that happens during routine service??

[BuLoOoSki]

Originally Posted by Sleeper

I'm guessing that the ~60-flash limitation on the DME has to be a soft limitation. In proTUNING Freaks's R&D on this platform, I'm going to make an educated guess that they've likely flashed a single DME hundred of times. PTF, can you confirm?

The DME is in fact limited by 60 flashes. It's probably true that PTF must have tested more than 60 maps prior to releasing, but I believe what PTF might have done is used the two files they obtain during the unlock process to restore the DME to its original status once they hit the limit in order to reset the counter.

[hakcar]

[aboulfad]

Originally Posted by BuLoOoSki

The DME is in fact limited by 60 flashes. It's probably true that PTF must have tested more than 60 maps prior to releasing, but I believe what PTF might have done is used the two files they obtain during the unlock process to restore the DME to its original status once they hit the limit in order to reset the counter.

Oh that assumes that the counter is in DMEs flash memory which would get erased post flash, is it?

[proTUNING Freaks]

Limits are for the weak

We've got well over 400 flashes on our development M4, that's been taken care of otherwise map switching would kind of be a little limiting

Tamper code, the best thing to say here is this: "if you're concerned about your warranty, do yourself a favour, don't modify at all. Not just flashing the DME but also applies to hardware and piggybacks". No beating around the bush here on this topic ever from our side. The code can trigger at any time after an unlocked/tampered bootloader is present with untampered/stock software.

and to those being honest with their Service Advisors and Techs. It goes a long way in most cases, more than most can imagine.

Lastly, to answer what we get asked often, you CAN re-lock flash over OBD but that may/may not leave traces of tampering in other areas of the DME. However, the best way of going back to stock is via bench flash, using the readout that was done before any tuning (aka TaMpErInG) took place.

[aboulfad]

Originally Posted by G35POPPEDMYCHERRY

so if we decline updates. the only way a tune can be found is through physical inspection of dme>?

Maybe, there are also other operational parameters being logged and retrieved through FASTA, that maybe BMW is looking for out of bounds params.

Originally Posted by BuLoOoSki

Not necessarily. One way I can think of is via checking the flash counter of the DME.

ok, that is done using PROG_ZAEHLER_LESEN, and that job for DME is not run by basic vehicle test and isnt logged in FASTA. Bizarre enough, it is run for only ICM out of all my ECUs ! And let's say some special magical service/process "somehow" queries that counter, how could that data be interpreted ? of course if you have 50/60 flashes, something is fishy...

Originally Posted by G35POPPEDMYCHERRY

think that happens during routine service??

The likelihood is very small, I'd need to verify someone else's FASTA data. Everytime our car is hooked up to dealer's ISTA system, the vehicle basic test queries all ECUs for many many things, and then is transmitted using FASTA service. I've deciphered 99% of FASTA jobs and have a good idea what the basic vehicle test is doing. see my notes above.

Job: PROG_MAX_LESEN
=== Request : readProgrammingCounterMaxValue =========
10->F4 62 25 03 27 10  // max prog counter: 10000
41->F4 62 25 03 03 E8  // max prog counter: 1000
67->F4 62 25 03 04 00  // max prog counter: 1024
42->F4 62 25 03 03 E8  // max prog counter: 1000
5E->F4 62 25 03 04 00  // max prog counter: 1024
6D->F4 62 25 03 04 00  // max prog counter: 1024
17->F4 62 25 03 08 00  // max prog counter: 2048
3F->F4 62 25 03 28 00  // max prog counter: 10240
40->F4 62 25 03 FF FF  // max prog counter: 65535
35->F4 62 25 03 04 00  // max prog counter: 1024
06->F4 62 25 03 04 00  // max prog counter: 1024
61->F4 62 25 03 60 00  // max prog counter: 24576
56->F4 62 25 03 04 00  // max prog counter: 1024
01->F4 62 25 03 04 00  // max prog counter: 1024
72->F4 62 25 03 01 F3  // max prog counter: 499
18->F4 62 25 03 04 00  // max prog counter: 1024
6E->F4 62 25 03 04 00  // max prog counter: 1024
30->F4 62 25 03 03 E8  // max prog counter: 1000
12->F4 62 25 03 00 3C  // max prog counter: 60
78->F4 62 25 03 04 00  // max prog counter: 1024
0F->F4 62 25 03 04 00  // max prog counter: 1024
76->F4 62 25 03 04 00  // max prog counter: 1024
60->F4 62 25 03 04 00  // max prog counter: 1024
37->F4 62 25 03 FF FF  // max prog counter: 65535
1C->F4 62 25 03 04 00  // max prog counter: 1024
63->F4 62 25 03 FF FF  // max prog counter: 65535
29->F4 62 25 03 03 E8  // max prog counter: 1000

[BuLoOoSki]

Originally Posted by aboulfad

Oh that assumes that the counter is in DMEs flash memory which would get erased post flash, is it?

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.

[BuLoOoSki]

Originally Posted by aboulfad

ok, that is done using PROG_ZAEHLER_LESEN, and that job for DME is not run by basic vehicle test and isnt logged in FASTA. Bizarre enough, it is run for only ICM out of all my ECUs ! And let's say some special magical service/process "somehow" queries that counter, how could that data be interpreted ? of course if you have 50/60 flashes, something is fishy...

Agree, but G35POPPEDMYCHERRY question was if physically inspecting the DME was the only way to tell if you're flashed while also assuming the car doesn't throw a detectable DME Tampered code. So what I was trying to say is if you were to get a major drivetrain breakdown and they wanted to investigate, one way would be checking the flash counter.

[hakcar]

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.

JTAG will always win over OBDII (and anything that isn't JTAG generally).

If JTAG is a wrecking ball and a construction crew, OBDII is a guy with a paintbrush.

[aboulfad]

Originally Posted by BuLoOoSki

...So what I was trying to say is if you were to get a major drivetrain breakdown and they wanted to investigate, one way would be checking the flash counter.

gotcha, and I was saying how and who can check that counter, there are no facilities in ISTA, and FASTA doesn't log it... BTW, i'd like to pick your brain but in the DIY section, i'll create a thread so we don't create undue traffic for this thread and lie low a bit ;-)

[proTUNING Freaks]

Originally Posted by hakcar

If JTAG is a wrecking ball and a construction crew, OBDII is a guy with a paintbrush.

[schnell1982]

Originally Posted by G35POPPEDMYCHERRY

so if we decline updates. the only way a tune can be found is through physical inspection of dme>?

If you decline updates, there will be notes made in your file and the topic of declining to update your modules will come up again and or raise concerns on why you don't want updates.
This was told me to by many service advisors regarding software levels

[CaryTheLabelGuy]

Originally Posted by schnell1982

If you decline updates, there will be notes made in your file and the topic of declining to update your modules will come up again and or raise concerns on why you don't want updates.
This was told me to by many service advisors regarding software levels

There are many reasons one would decline updates for their F8x. If I wasn't tuned I'd probably still decline updates unless something was wrong. If it's not broke, don't fix it.

[FSociety]

Originally Posted by CaryTheLabelGuy

There are many reasons one would decline updates for their F8x. If I wasn't tuned I'd probably still decline updates unless something was wrong. If it's not broke, don't fix it.

Nothing beneficial to gain from an update if its available?

[aboulfad]

Originally Posted by FSociety

Nothing beneficial to gain from an update if its available?

Yes and no, just check some of the various threads around on that topic. BTW, what's w the BM3 logo that some of you have?