ASM Community

AoA

i want to store the number of times the program is executed.
but i do not want to store its value in the windows registery or some other file.

i was thinking if there is a way to store this value in the execuatable itself.

does anybody know any way to do it?

there is also CRC field in PE executable header. Win95/98 does not verify it (i think) and it is usually zero. We might have to modify it if we change the executable.

the main problem that i see is to know the offset of a variable (counting the number of times the file is executed) in the file and then increment that value.

some area of the file are not writeable. i dont know if that variable will be in that area or not.

maybe i can use some field of PE header to store the count.


regards
goto

See the thread on self-deleting .exe's. If you're incrementing the count from within the .exe itself then it's going to be tricky. Windows locks your .exe while it's running and there are a lot of tricks you can use, but not all of them work on all versions of Windows.

Also if you're doing this as a copy protection scheme for a potentially commercial release of your software, keep in mind that a lot of virus protection programs and firewalls record the cumulative MD5 signature of .exes and will alert the user if a change occurs. Some of your less computer savvy users may think you gave them a virus. ;)

Of course that's all speculation, as I've never tried it.

Maverick,

I posted in the self deleting file thread an ancient dos trick of writing an EXE file to disk that was a DOS 16 bit EXE file from the PE exe and then call the dos exe on exit from the PE file to delete both the PE file and the dos exe file.

It worked OK in win95b, not tested on any other version but it still shows the console for a moment as its called.

It could be used to patch the PE exe file but it sounds like an untidy way to do it even if it works on later versions.

Regards,

hutch@movsd.com

Really, I think that having in mind just "self-deleting the app" is limiting. Personaly, I'd have other use for that.

Is it impossible to Create another Process which is not a file on a disk, but something in RAM, or at least a "RAM Disk" file?

Damn, I feel Win32 so limiting at times.. it seems it has been designed by a newbie. On the Amiga there was a flag telling you if your app was launched by the GUI or by a console.. for example.. but it seems like at Microsoft they think they know all about what programmers need, and they always fail in guessing all of them. I'd just prefer freedom and flexibility instead.

I don't know any way of creating a new process except for CreateProcess
and friends - perhaps it's possible if you use the NT native api?
As for storing program count, I'd find some other way than the
executable... there's too many problems with it. Antivirus software,
the obvious problems with not being able to write to a running image,
et cetera.

I believe that this field is used by Win2K onwards (i don't think it is used by NT4), and only in executables that are registered as drivers. The OS uses it to do a quick CRC before loading it to make sure the driver is valid, not broken.

As for modifying your exe as a means of limiting it in some way: this will only work as long as the user doesn't re-install the app. Say you program for a max of 15 uses. When the user runs it the 16th time, and realises their trial period is up, they may just uninstall it, then reinstall it, and start the trial period all over again. IMHO, a better idea would be to write encrypted info to an obscure registry key. And if you use a commercial installer to install your app, do not create the registry key at install time, as the uninstall process will remove it. Instead, check for the existence of the key when your app starts, and if it doesn't exist then create it, and start counting the number of uses.

Thanks for the info...

Sliver

1. Easily identificable, so it is not a good option.
2. That could be a good option, but it is still easily crackeable.
3. The encrypted file can be replaced e.g:You copy it to a certain folder and whenever you need to reduce the number of times you executed the program, you just replace this encrypted file.

Would it work fine to write in Windows DLL's and EXE's?

Actually there is no 100% to prevent crackers. EXE files always depends on external sources, like dll's, encrypted files, registry for this information...What if the dll is modified in a way to prevent this software 30 day/60day trial. The best solution I can think of is:

When your releasing a trial version, make sure not all functionalities of the commercial version is included. Just pick out the "exotic" ones. And make sure the consumer bought the software directly from the company who made it or through an authorize reseller.

Another good example is aliaswavefront, who created maya. You can't buy the maya software without directly calling them or their authorized reseller. Their installation is very different, there is no patch, you need an external file(FLEXLM license) that will be given to you by their authorized employees and then you need to run another software called lmtools to read this file. Now this file is just an ordinary text file but it contains somewhat like a checksum value, I can't remember from here. :(

A patch isn't good for shareware or commercial apps. Activation through verification to the main server of the company isn't good either.

That's why there is no 100% solution to this!!!

I think a close-to-100% solution is to just fill your program up with so much copy protection that hacking or cracking it would take more time than the average lazy hacker is willing to spend.

Stuff copy protection everywhere, and make it all inline. Use self-modifying code, checksums, registry writes, file checks, etc... every trick in the book at every opportunity where speed is not an issue. Try to write code that can't be NOPped out so easily, or maybe even stuff some critical code in a .VxD.

Basically make it so that in order to hack your program, a hacker would have to almost rewrite the whole thing in hex ;)