Author |
Topic: Copy protection (Read 24 times) |
|
Monkfish
Full Member
member is offline
Gender: 
Posts: 104
|
 |
Re: Copy protection
« Reply #1 on: Aug 19th, 2015, 1:09pm » |
|
The simplest method I could come up with was to place a hidden file on the pendrive that needed to be present for the main program to work. Non-techie users probably can't see hidden files.
But is there a better method?
|
| « Last Edit: Aug 19th, 2015, 1:10pm by Monkfish » |
 Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Copy protection
« Reply #2 on: Aug 19th, 2015, 1:47pm » |
|
Hidden file will likely be copied along with program folder.
Put it *outside*?
Create some weird directory structure outside program folder?
(I remember it was possible on FAT filesystem to create two filenames for single file. Now I wonder how it will be copied?)
I wonder if there is an reliable way to tell if drive is a removable one.
And - drive could have LABEL, there should be some API to check it.
|
| « Last Edit: Aug 19th, 2015, 1:50pm by tsh73 » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Copy protection
« Reply #3 on: Aug 19th, 2015, 2:46pm » |
|
on Aug 19th, 2015, 1:09pm, Monkfish wrote:| But is there a better method? |
|
Your program could check the drive's Volume Serial Number and refuse to run if it is different from what it expects:
Code: struct volumeserial, value as ulong
calldll #kernel32, "GetVolumeInformationA", 0 as long, _
0 as long, 0 as long, volumeserial as struct, 0 as long, _
0 as long, 0 as long, 0 as long, ret as ulong
print dechex$(volumeserial.value.struct)
Of course if you need the program to run on several different USB drives you will need to compare the serial number against a list of 'permitted' values.
This is a very simple, but effective, technique. I use it myself.
Richard.
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #4 on: Aug 19th, 2015, 6:53pm » |
|
Thanks guys 
As always Richard, spot on! Thank you 
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #5 on: Aug 20th, 2015, 2:05pm » |
|
So that works great.
As you said Richard, I need to change the serial number in the program code each time to match the drive it is saved to.
Is there a way to automate this process?
I can probably do it using the command line switches, the only problem is that when I use the statement below in a batch file it brings up the save screen and requests acknowledgment. I need it to automatically acknowledge if the whole process is going to be totally automatic.
LBB -C -A -M file.bas
|
| « Last Edit: Aug 20th, 2015, 2:45pm by Monkfish » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Copy protection
« Reply #6 on: Aug 20th, 2015, 4:12pm » |
|
on Aug 20th, 2015, 2:05pm, Monkfish wrote:| I need to change the serial number in the program code each time to match the drive it is saved to. |
|
I had assumed that rather than having several different executables, one for each USB drive, you would have a single executable containing a list of allowed serial numbers. That's the method I adopted; is it not convenient for you to do that?
Richard.
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #7 on: Aug 20th, 2015, 6:15pm » |
|
Well I am supplying the software on memory sticks that all seem to have a different serial number, which is a good thing from a security point of view. I can write a semi-automated process, that just needs the save and file overwrite to be acknowledged. That's better than changing the code manually.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Copy protection
« Reply #8 on: Aug 20th, 2015, 6:47pm » |
|
on Aug 20th, 2015, 6:15pm, Monkfish wrote:| I can write a semi-automated process, that just needs the save and file overwrite to be acknowledged. That's better than changing the code manually. |
|
Maybe I'm being thick, but I can't see why you would want to automate the compilation process. Putting a different EXE onto every memory stick seems a lot of work for no obvious benefit.
Surely it's easier for all the EXEs to be identical? Then there's no need for any 'automation' (other than creating the list of serial numbers, which you'll need to do anyway).
Of course I'm assuming that all the USB sticks are going to be available at the start, but even if you need to do it in batches you'll only need to recompile for each batch, and the new EXE will still work on the earlier sticks.
What am I missing?
Richard.
|
|
|
|
RobM
Junior Member
member is offline
Posts: 91
|
|
Re: Copy protection
« Reply #9 on: Aug 20th, 2015, 7:21pm » |
|
How many programs will you be selling/distributing? How will you handle releasing an updated version?
My program's registration system also uses the drives serial number but I have only one version of the .exe, not a unique one for each customer. That would be a nightmare for me.
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #10 on: Aug 20th, 2015, 8:13pm » |
|
Yes Rob, program updates are a concern.
Maybe I don't understand Volume Serial Numbers? Can I set the volume serial number of each pendrive myself? I thought this was hard-wired into each drive?
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Copy protection
« Reply #11 on: Aug 20th, 2015, 9:18pm » |
|
on Aug 20th, 2015, 8:13pm, Monkfish wrote:| Can I set the volume serial number of each pendrive myself? I thought this was hard-wired into each drive? |
|
It's not hardwired, it's set when the drive is formatted (there is a 'hardwired' serial number, but that's something different). There are 'unofficial' utilities that allow you to change it, but I wouldn't advocate using those.
Why do you have a difficulty with the drives all having different Volume Serial Numbers, but using a common executable that they all share? It's what I do, so there's still something I'm missing. Admittedly in my case there's only about half-a-dozen serial numbers in the list for my code to check against, but there could be hundreds without any noticeable performance hit.
Richard.
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #12 on: Aug 20th, 2015, 10:51pm » |
|
Well say I buy 50 pen drives all with different serial codes and then later on I buy 50 more all with different codes, how do I cope with that?
Of course, if I can change the volume serial number of all the drives to the same value, that will solve the problem.
Sorry if I'm not being clear.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Copy protection
« Reply #13 on: Aug 20th, 2015, 11:06pm » |
|
on Aug 20th, 2015, 10:51pm, Monkfish wrote:| Well say I buy 50 pen drives all with different serial codes and then later on I buy 50 more all with different codes, how do I cope with that? |
|
The way I would cope with it would be to add the 50 new serial numbers to the program (so there are now 100 in the list) and recompile it. Yes it's a manual operation, but you only have to compile the program twice rather than 100 times!
Richard.
|
|
Logged
|
|
|
|
Monkfish
Full Member
member is offline
Gender:
Posts: 104
|
|
Re: Copy protection
« Reply #14 on: Aug 21st, 2015, 1:04pm » |
|
I've decided to change the serial number of all my supplied pen drives to the same value. That seems the best option and appears to work fine.
|
|
Logged
|
|
|
|
CryptoMan
New Member
member is offline
Gender:
Posts: 46
|
|
Re: Copy protection
« Reply #15 on: Aug 25th, 2015, 9:56pm » |
|
Use RSA algorithm.
Create yourself a Private and Public key pair.
Keep private part on your side and embed public key in your app in pendrive.
At the activation stage read the volume serial number say a 16 hex digit number, append 240 randox hex bytes to the right and sign this with private key and put that certificate to thr pen drive.
At the start and at critical points read volume number and check certificate with embedded public key by raising certificate to power 3 mod N and look at the firrst 16 hex digits.
Or, create a constant unique string of 20 bytes and write zzzzzzzzzzzzzzzzzzz and find its position in your exe file. at activation step get volume number and xor 20 byte random fix number and then calculate SHA1 of this and open your exe as a random file and seek to the position zzzzz... you found before and place this SHA1 hash there.
And in normal use mode at the start open your exe as a random file seek to the same position and retrieve the hash , read volume no and xor same fixed random and recalculate SHA1 and check if they are same number.
Probably, a casual user can not break such a scheme.
|
|
Logged
|
|
|
|
|
