ok, I want my install program to fix in all the rest of my exe files some
kind of a PC -specific information. Such that, once the EXE files are copied
to another PC (without my installation routine) using a floopy disk (assuming
somoen makes illegal copies). then.. the exe files wont run as they have info
of the original PC.

I'm looking for some such PC-specific environment variable which Quickbasic
can access ? i tried Environ$ but can't get any clues about what speicifc
info to look out on a PC>. ( can any two PC's be identical ?).

this is the only "Soft" way of avoiding illegal copies of your EXE files
being made via DOS copy . I don't want to use a hardware lock. Is there any
other way of avodiing multiple copies being made ??

thanks

alok

--
------------------------------------
Very funny Scotty !                                
Now Beam down my clothes !                      

                 Capt.James T.Kirk
------------------------------------

I have seen programs that do exactly that and I'm not sure how but I suspect
they do something along these lines.

On the original floppy disk is a file that was originally say 200 bytes long
with the last byte or two (or more) holding install info.(say AA & 55)
Prior to distributing the floppy you modify the directory entry for that file
and change the file size to say it's only 198 bytes long.

Now if someone trys to just copy the file the copy process only copies the
first 198 bytes. (They don't get the AA & 55 bytes)

When your install program runs it changes the size of that file back to 200
bytes then checks those two bytes for the proper values and if correct proceeds
with the install process. When the install is complete it changes the AA & 55
to say A5 & 5A to indicate that the program has already been installed once.

The next time someone trys to install the program either from the original
floppy or a copy the install program can again check those two bytes and
refuse to complete the process if they are not the correct values.

You would also need an uninstall program to reverse the process if someone
wanted to move the program to another machine.

The trick is, how does one modify the directory entry for a file?
I don't have the answer to that. Maybe someone else does.

Like I said I've seen programs that do what you want and have copied the
original floppy then ran the install then compared the original files to
the copies and nothing appeared to have changed...but something had to.
So my only guess is that they are writing beyond the end of a file or are
doing some kind of absolute sector write to the disk.

I hope you followed all that...I think I did.
Not a solution...but food for thought.
--

Bangor, Pa. USA

is a slight modification to an area of the DISK whick MS-DOS does not

format. There is about 300K of unused or unseen space on each 1.44 M

disk.  Special programs (FDFORMAT.EXE) allow a 1.44 M to be formatted

to 1.7 M but MS-DOS is NOT capable of looking at anything above 1.44 M

...The INSTALL or SETUP program can look at this area to check for

the validity of the DISK.

Beau Schwabe

The idea of changing the END of the file can be modified by using

Norton-Utilities.

        Beau Schwabe

: ok, I want my install program to fix in all the rest of my exe files some
: kind of a PC -specific information. Such that, once the EXE files are copied
: to another PC (without my installation routine) using a floopy disk (assuming
: somoen makes illegal copies). then.. the exe files wont run as they have info
: of the original PC.

: I'm looking for some such PC-specific environment variable which Quickbasic
: can access ? i tried Environ$ but can't get any clues about what speicifc
: info to look out on a PC>. ( can any two PC's be identical ?).

: this is the only "Soft" way of avoiding illegal copies of your EXE files
: being made via DOS copy . I don't want to use a hardware lock. Is there any
: other way of avodiing multiple copies being made ??

: thanks

: alok

: --
: ------------------------------------
: Very funny Scotty !                                
: Now Beam down my clothes !                      

:                  Capt.James T.Kirk
: ------------------------------------

how about this..:

let the target drive be C:\ (as usual) INSTALL be the installing program
and A & B be my EXE files.

INSTALL installs A & B on a particular PC, and records the disk bytes &
free bytes in encoded form in a file (whose format is binary & can be filled
with lot of other junk detail to confuse the hacker). The EXE files b4
running check for the disk bytes & free bytes on the PC and compare it with
that in the encoded file. the files run only if both the info matches (u
can compare more info to increase the complexity of encryption).

with this approach.. one cannot make multiple copies on the SAME PC becoz
upon making the copies the free bytes & disk bytes info will change and the
exe files will obviously not run.

if the files are copied to ANOTHER PC.. then I wonder what the probability of
any two computers having the same DISK bytes & free bytes is .. (pls note
disk bytes & free bytes are two parameters I choose.. u can choose more to
confuse the hacker).

 will this work ??

thanks

--
------------------------------------
Very funny Scotty !                                
Now Beam down my clothes !                      

                 Capt.James T.Kirk
------------------------------------

: I'm looking for some such PC-specific environment variable which Quickbasic
: can access ? i tried Environ$ but can't get any clues about what speicifc
: info to look out on a PC>. ( can any two PC's be identical ?).
:
:

well here's one possible solution:

The idea here is to find something about the system that will probably
be specific to that machine and will never change.

The one thing most people don't mess with is BIOS.  I don't know if the
BIOS has a serial number but if it does then you could have your install
program read that number and encode it into the program.  Then when your
program runs it simply compares the number encoded in the program to the
number in BIOS.

Now let's assume BIOS doesn't have a serial number encoded in it.
In that case you could probably read the drive type, but that could be the
same on multiple systems.  So how about combining that with something like
the volume label of the HDD?

What you would have is a program that would only be able to be run on that
machine.  This, ofcourse, doesn't solve the problem of someone reinstalling
the program on another machine.

When your install program runs it could encode the machine information on
the install disk.  Then if the user ever needs to re-install the program
the install would compare the encoded information to the machines information.
This is where using any info from the HDD is faulty.  What would happen
if the user gets a new HDD and changes the volume label?

For that matter, what if the user upgrades the motherboard?  Then you loose
the BIOS information and your program wont run.  The only way around this
would be a "partial-reinstall" whereby the install disk would look at the
program on the HDD and compare it to information stored on itself.  if the
information matches then the install program will update the info in the
program on the HDD so the program will run.

This is a facinating problem.  I don't think I'm going to sleep for a week
now. :)

Cheers,
Damien

========================================================
Are you a shareware programmer? E-mail me for info on
something I'm writing to make your life a lot easier!!!
=== "http://204.101.50.93/students/damien/dmhome.htm" ===

HD serial number
CPU type
amount/type of RAM
....

HD serial number is easily altered because it is *software*. Worse, if
the person installs the software in a privaye directory on a LAN, he's
gonna be *real* upset when he can only use it on one machine.

CPU type, RAM, etc all suffer from the problem of what do you do if the
user upgrades his machine? The same goes for HD serial number if the
person upgrades his HD.

The whole idea with modern PCs is that parts are *supposed* to be
interchangeable. So *no* software test will work unless it relies on a
unque item. Either a hardware "dongle" or a "key disk".

Key disks wear out, and most kinds can be "cracked". Dongles are a
pain, but do work.

Leonard Erickson (aka Shadow)