Password protection (Rally Antilag anytime soon?)

[opel]

Just de-solder the serial and usb ports... problem solved.

[kjones6039]

I'm thinking...... Retinal recognition?

[piledriver]

I'm thinking...... Retinal recognition?

IIRC that has been long ago defeated, along with Blu-ray.
Note the movie studios et al spent years//MILLIONS developing the DRM for blu-ray.
(but it still was only a speedbump to professional pirates, still a PITA for ~everyone else)

Looks like the simplest thing that might be secure (but not to anyone with a screwdriver or soldering gun)
BT adapter mounted internally with a good long PIN, no pins routed out.

[Reverant]

Desoldering serial/usb ports is plain silly. People are smart enough to resolder a single connector.

DRM systems can't be compared to an ECU.

Btw, most microcontrollers have the abiliity to lock down the firmware for further viewing or altering. To my knowledge, on most uCs, there's no way to bypass that system once locked down (in fact, the MS3 bootloader is locked down for fears of piracy/counterfeiting).

A system to prevent tampering (or different levels of access given a password) can be implemented, quite efficiently in fact.

No password = no lock
Password A set = read only. If you can provide the proper password, you can read the tune, but not overwrite the tune, nor flash a new firmware in place.
Password B set = write only. If you can provide the proper password, you can flash a new a tune, or flash a new firmware. You can't read the current tune.
Password C set = datalog only. If you can provide the proper password, you can datalog but can't do anything else. Which parameters can be datalogged can be selected. Alternatively, have a 2-level datalog (minimal datalog [RPM/MAP/TPS/CLT/IAT/BAT/Inj Duty?], full datalog) based on 2 different passwords.
Any combination of the above is also possible.

The problem is that at the current level of development, a lot has to change for this to implemented. The MS3 developers are already short of time.

The question is, if someone else were to develop this feature, would the developers integrate the code given?

[racingmini_mtl]

It has been mentioned more than once (much more in fact) that you can't do that without changing the bootloader. That means that it cannot be retrofitted by the user and would require returning the existing MS3s for reflashing. Also since no one has the source code for the bootloader except the developers and any such scheme would require a very tight integration with the bootloader code, it can't be done independently by someone else.

I should mention that I don't have access to the MS3 bootloader source code or know the details of how it works so I am making some educated assumptions for my claims above. But James has already confirmed most of it anyway.

Jean

[Reverant]

The bootloader modification is indeed something that has to be done by someone that has the source for it. Obviously no way around that.

[jsmcortina]

The monitor fully occupies the region allocated for it. I've not looked in detail, but to extend this would require fairly far reaching changes to memory allocation.

James

[gslender]

Reviving and old thread....

Another reason for simple password lock out for tune updates is some countries have a regulatory requirement that any ECU used for street use, that passes the emission controls (assuming it did) would also need to have a non-modifiable ECU/tune... so adding a password meets that requirement!

At least the competitive brand ECUs are being used for that very reason, and getting passed by local authorities who are too clueless to realize that 15 mins after being passed, they passwords are being wiped and the car is being driven with an open tune/config (but the owner has the certificate for having the engine emission passed etc).

Even a simple TunerStudio / ECU firmware option that refuses to play unless the password is correct would be a step in that direction (though old versions of TS would simply ignore that pwd field) - a further improvement could be an upgrade to the tune serial output that uses something simple like Rot13 to confuse old version of TS and that only the latest TS with the correct pwd would allow the tune to updated.

I know it could be bypassed, and it isn't DRM secure, but the point is to add that competitive simple feature that other ECUs have that people are buying so that they can get around a legislated rule for street driven tunes.

G

[jsmcortina]

Without a total re-engineering, any password scheme would be very easy to bypass. It could perhaps be useful to prevent accidental changes to the tune.

James

[piledriver]

Without a total re-engineering, any password scheme would be very easy to bypass. It could perhaps be useful to prevent accidental changes to the tune.

James

For that reason alone it may prove useful, even if it was just some (selectable) shennanigans with TunerStudio comms to inhibit writes.
Of course BT comms have a PIN that is technically DRM, would that count? (not that I'd suggest tuning via BT, still very iffy IME)

It would finally kill this thread

Idea: Implement a checksum function for msq in tunerstudio, and have a check field for that.
Would that be enough to satisfy the legal drones, if there was a checksum validation to the "tested" tune?

(That way you could have an emissions legal tune like all the modern Ford/GM guys, and just reload as needed.
Some ACVW people have complete motors they swap in annually for a day for California emissions checks...)

[gslender]

It must be locked - but locked isn't defined. So I guess physically locking the ECU in a case would qualify.

Whatever your view, competitive ECUs have this feature and I'm surprised that alone isn't good enough reasons to ensure customers don't shop elsewhere

[piledriver]

It must be locked - but locked isn't defined. So I guess physically locking the ECU in a case would qualify.

Whatever your view, competitive ECUs have this feature and I'm surprised that alone isn't good enough reasons to ensure customers don't shop elsewhere

A firmware checksum is all most of the factory ECUs could have (?), given the plethora of "tuning hardware" available.
A lot of "Tuners" won't switch anyway, they have one tool they know how to use and are not interested in learning anything else.

DTAFast seems to lack password protection? I thought that was just rebranded AiM like ~half the ECU brands out there.
I'm curious What "competitive ECUs" actually support it?

[JoseMiguel]

I second to gs arguments... Password protection is everywhere else

[gslender]

I'm curious What "competitive ECUs" actually support it?

AEM, Haltech and Motec all offer this.

In Australia, these ECUs are way, way more popular than Megasquirt.

So whilst the MS3Pro is now a viable a competitive option, it will need to offer similar features to sell.

I'm not sure if anyone cares about sales, but if they do, then they need to think about what features will stop or detract from sales.

G

[piledriver]

So on those ECUs, does the password "protection" somehow "protect" the person who owns the ECU and paid for the tune, or force the ECUs owner to come back to the tuner for any changes?

IMHO if someone pays for a tune, they own it, not the tuner.
Works the same way with Musicians, programmers, "work for hire" etc.
If tuners want to be some legally "special" class they may be disappointed.
(perhaps my US based viewpoint is biased vs the rest of the world)

If it is simply a method to extort customers and enforce going back to that same tuner, that sucks and is likely illegal in many locales...
Of course I could see some tuners would absolutely adore it.
Perhaps B&G and the suppotting coders here don't want to support that sort of lock down.

Ethically I hope the powers that be will never implement that sort of extortion-freindly password "protection".

[gslender]

So on those ECUs, does the password "protection" somehow "protect" the person who owns the ECU and paid for the tune, or force the ECUs owner to come back to the tuner for any changes?

IMHO if someone pays for a tune, they own it, not the tuner.
Works the same way with Musicians, programmers, "work for hire" etc.
If tuners want to be some legally "special" class they may be disappointed.

If it is simply a method to extort customers and enforce going back to that same tuner, that sucks and is likely illegal in many locales...
Of course I could see some tuners would absolutely adore it.

Who cares !? That's a philosophical argument that you can take up with your tuner.

Another way of looking at it is that technically, if you pay someone to install and tune the ECU, why would you want to modify the tune anyway? And if so, do you expect to be able to go back and complain if it doesn't idle in the cold (some 5 months later) ??? A lock or some way of ensuring no tamper has occurred is a good way to solve installer warranty. Some installers won't even consider an ECU that doesn't offer some way to protect them from customer who fiddle and screw up a good tune.

End of the day, it is a password on the tune. If you get/know the password then you can use it to change/update and even remove the password on the tune. If you don't, then unless you are really, really smart (like some folks on this forum who could reverse engineer a ROT13 encoded tune to derive the password) then you can't open/edit the tune and you'll have to start again.

G

[piledriver]

So on those ECUs, does the password "protection" somehow "protect" the person who owns the ECU and paid for the tune, or force the ECUs owner to come back to the tuner for any changes?

IMHO if someone pays for a tune, they own it, not the tuner.
Works the same way with Musicians, programmers, "work for hire" etc.
If tuners want to be some legally "special" class they may be disappointed.

If it is simply a method to extort customers and enforce going back to that same tuner, that sucks and is likely illegal in many locales...
Of course I could see some tuners would absolutely adore it.

Who cares !? That's a philosophical argument that you can take up with your tuner.

Another way of looking at it is that technically, if you pay someone to install and tune the ECU, why would you want to modify the tune anyway? And if so, do you expect to be able to go back and complain if it doesn't idle in the cold (some 5 months later) ??? A lock or some way of ensuring no tamper has occurred is a good way to solve installer warranty. Some installers won't even consider an ECU that doesn't offer some way to protect them from customer who fiddle and screw up a good tune.

End of the day, it is a password on the tune. If you get/know the password then you can use it to change/update and even remove the password on the tune. If you don't, then unless you are really, really smart (like some folks on this forum who could reverse engineer a ROT13 encoded tune to derive the password) then you can't open/edit the tune and you'll have to start again.

G

There are likely folks on this forum who could decrypt a PGP 256 bit encrypted file in a few days of computer time if it was worth the effort, particularly as parts of the files content//format etc are known..

A simple MD5 (or better) hash of the tune and loaded firmware for validation purposes would achieve all the confirmation a tuner needs for protection from "warranty" claims and likely many other legal validation purposes. If it was built into TS it would be a great feature.

[gslender]

A simple MD5 hash of the tune and loaded firmware for validation purposes would achieve all the confirmation a tuner needs for protection from "warranty" claims and likely many other legal validation purposes. If it was built into TS it would be a great feature.

I agree for many reasons that would be ideal. To make it simple, something like the bcrypt algo is well tested and used and available in licenses that should allow both TS and the ECU firmware to use.
http://en.wikipedia.org/wiki/Bcrypt

G

[gslender]

Oh, and it would improve the tune/project connection time - instead of reading the entire tune to confirm that it has/hasn't changed, it could just ask the ECU for the hash, and compare to the local hash of the tune and if the same, just connect. If not, it would only then pull down the 8 pages of memory etc.... much more efficient and intelligent that what is done now. An improvement from that could be to hash each page and only pull the page that is different/inconsistent etc.

G

[piledriver]

Excellent idea!
Could cut down on flash writes as well, or is it an all or nothing sort of event?