Cobb AP td1 info?

[jimlloyd40]

I’ve no idea. Were they using synthetic fuel back then?

Yeah the Germans were.

 

[jimlloyd40]

No, just mustard gas.

With a touch of mayo.

 

[launchd]

For sake of simplicity everyone in the forum has always referred to it as a flash counter.
Whatever the technical terms are the fact is VW can tell the number of times the ECU has been flashed.

Again, it has nothing to do with a counter and NOBODY at Volkswagen is looking at the number of times an ECU has been flashed.

 

[jimlloyd40]

Again, it has nothing to do with a counter and NOBODY at Volkswagen is looking at the # of times an ECU has been flashed.

That's contrary to everything I've read over the years in the forum. Not saying you're wrong but it doesn't matter since VW will know you've flashed the ECU.

 

[shovelhd]

That's contrary to everything I've read over the years in the forum. Not saying you're wrong but it doesn't matter since VW will know you've flashed the ECU.

Because most of what you are reading is conjecture and theories.

launchd has given the best, most accurate description of how a TD1 is detected. It's not that complicated. A tuner can crack the encryption on the ECU in order to modify the tuning parameters. That's the easy part. But when they do that, they change the hash value. The algorithm that manages the hash is not in the ECU, it's in the VW system that scans the car and resides in Germany. If one bit is out of place, it's flagged. Like launchd says, a really good crypto programmer could put the correct bits back into place after the modifications and that may fool the VW scanner, but to date, nobody has successfully done that.

 

[Ghost GTI]

I have to say there has more to it than just comparing bits. If that was the case, there would be nothing stopping us from making a original backup of the data and restoring that backup in order to avoid it. There has to be some side counter for sure who is tracking modifications.

 

[the]

Like launchd says, a really good crypto programmer could put the correct bits back into place after the modifications and that may fool the VW scanner, but to date, nobody has successfully done that.

Only if the system is using a compromised hashing algorithm, such as SHA-1. Since the tech is relatively new, I would say that is unlikely. I'm still reading over the patents but so far I don't see anything about encryption of map data, if there is encryption it's more likely this is being accessed with the actual decryption key. My guess would be they are all encrypted with the same key, otherwise service would be a nightmare. This is far more likely than the encryption key being cracked, that kind of thing generally does not happen anymore unless the encryption is intentionally weak/vulnerable.

If stock maps are protected with a recorded hash, there's no reason to encrypt them, especially not with a weak encryption. Hashes are not reversible, you can't be a really good modder who fools one, that's like mixing up playdoh and then trying to separate it again. Hashing produces a unique string (mixed playdough) based off of the data that was submitted, submitting different data means a different string, period. If the point of the hash is to TD1 people for modifying the ECU, why encrypt that information and make it harder for people to TD1 their cars? An exposed hash is not vulnerable.

There has to be some side counter for sure who is tracking modifications.

I would agree, if the original maps have encryption that is "cracked" all that needs to be done at that point is re-encrypting that data with the same method VW used originally. Even if it's not cracked, that unmodified data should be able to be sent back to the ECU and have the same hash.

I have two theories for each scenario:

1. If encryption exists, it has never been cracked. This matches what tuners have said with their stock maps being "like-stock" but not OEM. Meaning they have the ability to flash new maps to the ECU, but no way of interpreting, modifying, or recreating the old data because it remains encrypted.

With this said, how does the Cobb default map work? I was under the impression the initial flash from a Cobb copies the map data from your car so it can add it back later? If it is copying encrypted data, and simply spitting that data back onto the ECU for the reflash, that data would be identical (same hash) unless a counter exists at some point to change that data in some way, thus changing the hash, and causing a TD1.

2. If encryption is cracked and we can see the true original map, there's still something modifying the hash in the ECU to alert VWoA even though we have that identical data to send back to the ECU. A simple +1 counter tucked away in the ECU code somewhere that changes some data every time someone remaps the ECU, meaning a completely different hash, i.e. td1. Thing is, if the OEM data was unencrypted ("cracked") and thus readable in plain text, someone would have found that already. So I'm thinking number 1 is more likely, but I need to know what is actually happening with the Stock map process to give a better answer.

 

[Keehs360]

but to date, nobody has successfully done that.

according to folks that are knowledgeable enough to do it. this isnt a hard thing at all. but no one dares do it. because law suit

 

[aaronc7]

I have a full bench read of my ECU and the string "C0BB" shows up 17 times in DFLASH memory, even though it's been quite some time since I have had Cobb on the car and many flashes since then.

 

[the]

I have a full bench read of my ECU and the string "C0BB" shows up 17 times in DFLASH memory, even though it's been quite some time since I have had Cobb on the car and many flashes since then.

If this is the case, comparing hash values would only be necessary in a future scenario where tuners find a way to clear this memory. My guess is that hasn't happened yet, and we're 10 steps ahead of ourselves in what can actually be done here. Do you also have timestamps in that data, such as the dates for the OEM flash event?

 

[launchd]

@okMK Not to be an asshole but, it sounds like you know just enough about a few topics that kind of relate to this and you're trying to apply that generalized knowledge here. You're way off-base.

I'm going to bow of this thread as I've provided OP with the information he needs, good luck friends

 

[the]

You're way off-base.

I've given you the opportunity to elaborate and you refused, put up or conveniently bow out of the thread before you get called out. Hashing is not a confusing concept, encryption is not a mystery. Suggesting something has been magically cracked is what I would consider way off base. @aaronc7's post completely validates everyone speculating on a history, meaning you have been wrong since the very first time you replied to "correct" me, stop projecting.

 

[Keehs360]

I've given you the opportunity to elaborate and you refused, put up or conveniently bow out of the thread before you get called out. Hashing is not a confusing concept, encryption is not a mystery. Suggesting something has been magically cracked is what I would consider way off base. @aaronc7's post completely validates everyone speculating on a history, meaning none of what was suggested with hashing or encryption even matters (yet), stop projecting.

So you’ve noticed too….

 

[the]

So you’ve noticed too….

Yea, kinda weird to see someone confused about a basic explanation of hashing and speculation on the encryption methods being used. Since I'm still trying to gather data about what exactly occurs during the flash process ( and actively requesting that information) it's strange to see someone become so defensive. But whatever, we can still take what second-hand data he was capable of providing and make this a constructive thread.