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.

Posted on 2002-03-18 06:03:29 by goto

The problem is that windows will not let you write to a running EXE file on disk. Its the same reason why you cannot delete a running EXE file. The technique was fine in DOS because it did not have this restriction. I would look for another way to do what you are after as it is not a successful technique in win 32.

Posted on 2002-03-18 06:26:45 by hutch--
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.
Posted on 2002-03-18 06:32:57 by iblis
Hi Hutch,
Would it be possible to create another process which inherits the same address space of our process, and then ExitProcess() the first process, and continue with the second? (of course I mean that we'd have to commit all of our program, a bit like decrunchers do)

CreateProcess() seems to be able to launch only a file.. it'd suxx to have to create another EXE e.g. in Windows\Temp in order to do this. Is it possible to CreateProcess() not from a disk file, but from memory?

Posted on 2002-03-18 06:40:24 by 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.

Posted on 2002-03-18 06:48:28 by hutch--
the easiest way would be something likea overhead or
frontend... then it would be no problem anymore... there
are lots of "unused" spaces in the pe-header so i wouldn't
use fuzzy variable offsets. if you want to reach this value
AFTER startup you can scan your own pe-image via your
Posted on 2002-03-18 07:30:28 by mob
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.
Posted on 2002-03-18 08:03:57 by Maverick

Rather than modifying the EXE, couldn't you modify a DLL, and only load it as and when?

Posted on 2002-03-18 09:36:55 by Mirno
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.
Posted on 2002-03-18 09:44:25 by f0dder


Rather than modifying the EXE, couldn't you modify a DLL, and only load it as and when?

I like single-file projects. ;)

..and I really mean it!


PS: with single file projects of course I do not mean that I code all in a breath, maybe neither using include files.. I rather mean I append my own filesystem's volume with lotsa directories, subdirectories and files.. but externally all is into a single EXE (Dos/Windows, when possible).
Posted on 2002-03-18 16:35:21 by Maverick
there is also CRC field in PE executable header.
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.
Posted on 2002-03-18 16:59:16 by sluggy

write encrypted info to an obscure registry key.

Pretty lame. Anybody with regmon can detect that. And there are
very easy ways to avoid anti-regmon code. Also on NT, you can't
just blindly write to any regkey you want =).
Posted on 2002-03-18 17:05:51 by f0dder
Thanks for the info...

Posted on 2002-03-18 17:44:26 by Sliver
There are other ways...

1. Registry
2. Check the last time it was installed.
3. A different encrypted file.

<start edit>
This encrypted file is usually placed in a different directory.
<end edit>

Posted on 2002-03-18 18:53:37 by stryker

There are other ways...

1. Registry
2. Check the last time it was installed.
3. A different encrypted file.

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?
Posted on 2002-03-18 19:16:42 by CodeLover
Use a dongle ;p
Posted on 2002-03-18 19:18:37 by iblis
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!!!
Posted on 2002-03-18 19:39:56 by stryker
Too bad that full stuff like maya, 3dsmax (et cetera) is spread as
well as the puny little shareware apps. People either have broadband
internet connections, or buy w4r3z CDs. flexlm is removed (even
without valid licenses), dongles are circumvented, et cetera.
The only thing you can do is to slow down attackers, and what most
people do is merely a 5-minute job for many of the guys out there.
So you end up losing time/money trying to implement protection,
annoy the end users because they have to go through a lot of
trouble (slow/annoying dongles, slow CD checks, et cetera).
Posted on 2002-03-18 19:46:51 by f0dder
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 ;)
Posted on 2002-03-18 19:57:01 by iblis
Too bad that this probably means you will either get lost in your own
code, or spend more time on the protection than the rest of the

And as for using VXDs, that's just lame. Unless you do *very* dirty
stuff it's not harder to trace ring0 code than it is to trace ring3 code.
And the "dirty stuff" is usually pretty easily identifiable.

Just give up, and stop hurting the end-users!
Posted on 2002-03-18 20:13:31 by f0dder