Remap

[W8PMC]

This is the CVN number which is stored in the serial eeprom of the ECU. If you write whether it be a stock file or modified, it will change the CVN number.

This number is what the dealership computer can see. You do not need to download the IROM (where the maps are stored) and compare against ori to see this. All they can see is the original file or 'a' modified file has been tuned.

Any software update will overwrite the ecu information and lose the map so to speak.

BMW have been able to spot an ECU remap by OBD, or BDM/Tricore mode since 2009 (Possibly earlier).

I agree it has to be spotted to be voided, but modern day things have changed. Doesn't mean there is a way around them, however once a TD1 stamp is on the car, it cannot be removed.

Likewise.

Well agree to disagree but willing to wager highly on it!

How confident are you that all ECU's/Dealers/Tunes are the same or at least similar enough that the above always applies?

My experiences differ somewhat & perhaps a proportion of that has been luck, however i've been told by several sources that 'some' tunes are easily detectable, especially simple flash remaps where as you say these can be detected easily from a pure flash count, however bench modified ECU's where only certain lines of code are amended (i can't explain the exact process) would need significant investigation to find the changes both with the tune present & with those altered lines of code being returned to stock. This investigation would be at a far higher level than a UK dealer.

[doodlebug]

Change one character the hash changes, the light comes on. Simple. Code analysis not required.

[W8PMC]

Change one character the hash changes, the light comes on. Simple. Code analysis not required.

Furry muff

So by what method can a dealer see that?

I understand how a flash count is fairly obvious to spot which is why i've in the main avoided OBD remaps.

[bam_bam]

Change one character the hash changes, the light comes on. Simple. Code analysis not required.

Didn't I say this a million posts ago?

[doodlebug]

Change one character the hash changes, the light comes on. Simple. Code analysis not required.

Didn't I say this a million posts ago?

Pretty sure you did!

[W8PMC]

Change one character the hash changes, the light comes on. Simple. Code analysis not required.

Didn't I say this a million posts ago?

Perhaps, but a key question still remains unanswered.

Nobody disagrees that changes take place, as it would be a bit of a pointless tune if nothing within the ECU was altered, but how can a 'Dealer' detect the hash change on their diagnostics puter? What can said puter spot as we all know it won't shout FOUL PLAY the minute the car's connected.

[doodlebug]

Should be straightforward. Hash will be stored specifically, it can be retrieved and compared against a DB of known good values.

This is all billy basic stuff from an IT perspective.

[W8PMC]

Should be straightforward. Hash will be stored specifically, it can be retrieved and compared against a DB of known good values.

This is all billy basic stuff from an IT perspective.

Thanks & to bb for the explanation.

So the dealers puter wouldn't offer up anything unless the dealer or Mfctr asked for the Hash detail & then this was cross referenced against the relative DB? I assume the DB is held by the Mfctr rather than the dealer? Is this the same for all Mfctrs?

[doodlebug]

Should be straightforward. Hash will be stored specifically, it can be retrieved and compared against a DB of known good values.

This is all billy basic stuff from an IT perspective.

Thanks & to bb for the explanation.

So the dealers puter wouldn't offer up anything unless the dealer or Mfctr asked for the Hash detail & then this was cross referenced against the relative DB? I assume the DB is held by the Mfctr rather than the dealer? Is this the same for all Mfctrs?

All the dealer needs to know is good or bad. I don't see why the software couldn't hold the relevant codes - after all when they do a software update you'd only want to apply this to a known starting point. All the data and tools are there.

[SuprSi]

The thing is if something engine/drivetrain related let go and it was likely caused by a remap then the owner should have to stump up the cost. That's the risk you're taking with any modifications we make.

What is unfair is if audi use the remap to void the warranty totally, ie anything goes wrong even unrelated to the remap, they still won't do it under warranty.

I don't have a warranty to worry about anyways so not really bothered.

[DragonRR]

Should be straightforward. Hash will be stored specifically, it can be retrieved and compared against a DB of known good values.

This is all billy basic stuff from an IT perspective.

Thanks & to bb for the explanation.

So the dealers puter wouldn't offer up anything unless the dealer or Mfctr asked for the Hash detail & then this was cross referenced against the relative DB? I assume the DB is held by the Mfctr rather than the dealer? Is this the same for all Mfctrs?

All the dealer needs to know is good or bad. I don't see why the software couldn't hold the relevant codes - after all when they do a software update you'd only want to apply this to a known starting point. All the data and tools are there.

It is entirely possible that on some cars - simply hooking the car up could flash a warning on the dealer's computer. The manufacturer could design it so that a siren screamed out and red lights flashed everywhere when it detected a problem, it would be quite amusing... It could be the case that they get nothing unless they actually check the data... It could be that the dealers don't have access to the correct checksum and/or access to the default files/lines of code. Endless possibilities really.

I asked my friendly Porsche dealer today (I've been mulling over a Panamera Turbo S) for his thoughts on tuning. He is "just" a salesman so he could only speak from his experience:

Needless to say he had no idea how a tune could be detected but he said that they have been many times. This particular chap used to work for BMW and he said that it was actually turbo diesels that were the worst offenders and were the cars most often in with a power train related problem (probably) due to a remap. He believes that, essentially, they can detect a tune at dealer level at both Porsche and BMW. He said that some customers had serious problems corrected under warranty after a remap had been detected, he also said that it was just as common for the warranty to be voided for anything directly or loosely connected to the tune. He said that they had had cars come in as trade ins which they knew had been tuned simply because they seemed to be faster than normal. Porsche are very strict about extended warranties which were refused/completely voided if even a minor modification (like an exhaust) was done.

[W8PMC]

Should be straightforward. Hash will be stored specifically, it can be retrieved and compared against a DB of known good values.

This is all billy basic stuff from an IT perspective.

Thanks & to bb for the explanation.

So the dealers puter wouldn't offer up anything unless the dealer or Mfctr asked for the Hash detail & then this was cross referenced against the relative DB? I assume the DB is held by the Mfctr rather than the dealer? Is this the same for all Mfctrs?

All the dealer needs to know is good or bad. I don't see why the software couldn't hold the relevant codes - after all when they do a software update you'd only want to apply this to a known starting point. All the data and tools are there.

I had assumed regarding software updates, that detail would be on the car not the dealers puter. Or the dealer would check within the vehicle what version of software the car was running & then apply said update if required. Surely if held at dealer level it would need to be centralised as the car could go into any dealer for an update or for any warranty work.

[W8PMC]

The thing is if something engine/drivetrain related let go and it was likely caused by a remap then the owner should have to stump up the cost. That's the risk you're taking with any modifications we make.

What is unfair is if audi use the remap to void the warranty totally, ie anything goes wrong even unrelated to the remap, they still won't do it under warranty.

I don't have a warranty to worry about anyways so not really bothered.

I agree & the exact reason i'd only use a reputable Tuner who offered a fully insurance backed warranty.

I'd hope no dealer/mfctr would be stupid enough to refuse any warranty claim on items (the majority of the car) that could have no direct relevance to the modification. Using an exhaust as an example, assuming it was cat-back then no other component on the car that may fail could be directly attributed to the aftermarket exhaust, except perhaps the cats. Same would apply to brakes, although i guess it could be argued if you had aftermarket pads then a failure of the clippers &/or discs might be attributable.

That said & as per the above point, if you spend wisely you should be well covered for any eventuality.

[DragonRR]

I had assumed regarding software updates, that detail would be on the car not the dealers puter. Or the dealer would check within the vehicle what version of software the car was running & then apply said update if required. Surely if held at dealer level it would need to be centralised as the car could go into any dealer for an update or for any warranty work.

Perhaps my previous post might have answered this but:

Your ECU is a computer running software which has a version number. The ECU "map" which is really data may also have a version number. The software and data can be "hacked" by a tuner who would leave the version number unchanged.

If you went into a dealer they might check the software and data versions, notice there is an update and install it. This would almost certainly remove any remap you have.

However "version" is not a "checksum/hashcode". A checksum is basically an error check where a person or program can check that not one single piece of code or data has been changed in a system. It is normally used as a back check to make sure nothing has corrupted and just about any properly written piece of software or chunk of data will have a checksum. In it's most basic sense a checksum might simply be the sum of all the data added together (this method wouldn't be used tho because it doesn't cover all bases).

So - as soon as a tiny piece of code or data is changed in the ECU the checksum will (unavoidably) change and this would be very, very easy to compare to the checksum held on either the dealer's server or the manufacturer's centralised system where alarm bells may or may not ring that something is wrong.

[W8PMC]

I had assumed regarding software updates, that detail would be on the car not the dealers puter. Or the dealer would check within the vehicle what version of software the car was running & then apply said update if required. Surely if held at dealer level it would need to be centralised as the car could go into any dealer for an update or for any warranty work.

Perhaps my previous post might have answered this but:

Your ECU is a computer running software which has a version number. The ECU "map" which is really data may also have a version number. The software and data can be "hacked" by a tuner who would leave the version number unchanged.

If you went into a dealer they might check the software and data versions, notice there is an update and install it. This would almost certainly remove any remap you have.

However "version" is not a "checksum/hashcode". A checksum is basically an error check where a person or program can check that not one single piece of code or data has been changed in a system. It is normally used as a back check to make sure nothing has corrupted and just about any properly written piece of software or chunk of data will have a checksum. In it's most basic sense a checksum might simply be the sum of all the data added together (this method wouldn't be used tho because it doesn't cover all bases).

Ta & totally understand the explanation around coding differences. That said, what can/can't be seen doesn't tally with what i've been told by both BMW & Audi. Albeit at BMW they are/were Regular Technicians, but at Audi it was a long standing Master Technician.

Point is i don't doubt any change to the code 'could' with the relevant level of investigation be uncovered, where my either confusion or misinformed knowledge is struggling is that this isn't a simple dealer diagnostic computer check. I accept certain changes such as flash count & obviously software version can be viewed by a dealer, but changes to a few lines of code (using the language that was used with me) can't be & that would require some detective work which would likely mean the ECU being shipped to either the Mfctr of said ECU or perhaps a 3rd party.

So - as soon as a tiny piece of code or data is changed in the ECU the checksum will (unavoidably) change and this would be very, very easy to compare to the checksum held on either the dealer's server or the manufacturer's centralised system where alarm bells may or may not ring that something is wrong.