How to limit the number of duplicate .hex file

[aydi]

Good morning.
I have my ccs program and I want to send my .hex file
to someone. I want that this person be able to
program a limited number of pics using this hex file.
For example 5 microcontrollers and the .hex file could not
be used again.
If it is possible, how can I do it?
Yours faithfully.

[Ttelmah]

No.

If you send them the .hex file then there is no way to limit it.

However if you are going to use a bootloader, then it is potentially possible to write your own encrypted bootloader program for the PC, that does something like take a checksum from the file, and put this together with a count into the registry of the system, then checks this each time it is used. ideally you'd 'keystamp' the file to the system it is going to work on (you encrypt the transmitted file using the system ID, or disk ID as part of the encryption), which then makes it quite hard to move to other systems.

[aydi]

I understand. But I'm looking for something like the instruction
Protect in the source file to protect the code.
I will just give him the hex file.

Yours faithfully

[aydi]

Is it possible that I connect my .hex file with the time of the system ?

[MikeW]

My idea would be to write a program (app) on the PC in Delphi, Visual Basic, C#, etc., which at base would encrypt the hex file (maybe just changing a few bytes to corrupt it).
Then send a similar program to the client which will decrypt the modified hex file, increment a counter to limit the number of times, and run the programmer software (bootloader or hex file download such as ccsload).

[Ttelmah]

Only by writing your own program.

Windows itself only offers the standard permissions. Some types of specific file do offer such abilities in the programs that use them. So (for instance), VBA contains controls that allow Office documents to be count limited, but if you have once distributed the hex file, it is readable by anyone.

What you could do, is use PKZIP to encrypt the file. Then write your own little program that calls the unzipper on the system with a secret password to unzip it, and passes the resulting hex directly to the programmer code.

[aydi]

Normally when he received my zip file he unzip using a secret code.
So he will have the .hex file, then he use the Pickit3 to program the
microcontroller. So he can program the number that he wants.
That is the problem. For me I should limit this number. How???

[temtronic]

MikeW says what I was thinking of how it can be done.
There are a couple of points though.
The actual PIC.hex file MUST be encrypted.This is the first line of defence.
The 'program ap' MUST store the 'times used' counter within itself, NOT in a separate file. Otherwise a clever guy will see this new 'PICsprogramed' file and simply modify or erase it.
This program also has to call/control the actual programming of the PIC(run the PK3 software) AND clear all cache, temp files, etc. after burning the PIC. Again, a clever guy could read those temp files and get the good PIC hex data and save it for unlimited copies.

Another security feature would be to have the upgrade software to test the PIC for a 'serial number'. This only allows a specific version of the PIC program to be installed into a specific PIC. Commercially some vendors use a combination of PC harddrive serial number, BIOS version, etc. to form a unique 'platform' that their software will be installed into.

Jay

[Ttelmah]

Exactly.

Though it could still be interrupted and the file retrieved, a reasonable version can be scripted fairly easily.
So you write a program that decrypts the file (perhaps calls PKUNZIP), with a password 'internal' to itself (you perhaps give him a password, that is itself modified by a password inside the program to generate the one used), and this then directly calls the programming code with the resulting decrypt.
PKZIP implements better encryption than you will manage without a lot of work. The original authors were specialists in encryption, and it is still a very good encryption program.
CCS's command line programmer (ccsloader.exe), can be called directly from a program.
You have all the exit routes delete the temporary files on exit.

You use an installer to put the program on the system, which adds a registry entry when the program is installed.
The program on first execution, requires a 'unlock' key from you, which you generate from the system ID, which you ask for.
The program itself tests for the registry entry being present, and you store the count both in here, and in the file itself together with the unlock, which it tests to match the system ID. Copying the file won't then work without the registry entry being present and matching, or if the system ID changes.

It's not perfect, but makes it very hard to get the files directly.