Hello, hope all are fine.

i have two qe. infact.

First : i want a CD-Write program source code.
does any know any ??

Second: I don't know if it is legal to mention it here .
i want to know a good ways to protect my program from crackers.
also i want to know anti-debug tricks , where can i find such . or could you plz share your experience ?

to smurf: I am Sorrryyyyy man I was so rude. I'm expressing my sorrow to you. hope you accept it .
Posted on 2002-05-29 12:17:02 by Sa6ry
I dunno if it's legal here either... but I can give you some ideas... if it isn't legal I wouldn't mind a moderator deleting this as long as I don't get deleted myself...


1) Self-modifying code can give a potential cracker quite a bit of a headache.
2) Try encrypting the code, and making the encrypter itself quite cryptic (jumps, compares that never get reached, etc.)
3) use bad programming habits (those things are hard to debug!)
4) Create a random data file, XOR it with the original code, and store the random data and the XOR'ed code somewhere. To decrypt, XOR them again together and store the code into a code segment.
Posted on 2002-05-29 21:02:57 by AmkG
there are so many ways around to make cracking harder, but:

1) if you use anti-debugging tricks, they get defeated. simply. only if you make really ****loads of code with anti-debugging, it will just slow down cracking

2) if you use a good serial protection (strong encryption), your program will not be attacked on the serial, but it will be patched.

protecting software from crackers is a waste of time imho, unless you have really a lot of time
Posted on 2002-05-30 02:34:35 by roeldebikkel

writing anti-cracking code or protection systems is a fully legitimate form of programming that is fully within the rules of this forum. While we will take a very dim view of any specifically cracking related code being posted here, as long as the questions and data are related directly to designing protection systems to slow down hacking, it is OK here.


Posted on 2002-05-30 03:07:02 by hutch--
I totally agree.
Even from the standpoint of a commercial programmer or software house, the notion of preventing cracking is flawed...

The guys who go to the trouble of defeating simplistic protection mechanisms are not going to pay for the software, and they in fact help promote your software to those who WILL pay for it.

Now we don't want EVERY MAN AND HIS DOG to have a freebie, and we should consider a separate compile for any demo rather than disabling functionality which could be re-enabled, but a few people running around with our software is not necessarily a bad thing from a marketing perspective.
Posted on 2002-05-30 03:09:34 by Homer
You can detect "application level debuggers" with 'IsDebuggerPresent" API (Windows98+ & Windows NT 4.0+)

call IsDebuggerPresent

eax = 0 <- not running in the context of a debugger
eax != 0 <- running in the context of a debugger

Try to 'hide' the call to this API ...

Also more application debuggers simply die with SEH.

There are lot of tricks more .. search the net.
Posted on 2002-05-30 03:52:30 by hunter
you can delete the debug registers and detect softice
in memory, there are 1000s of techniques out there.
maybe something like this is possible, i never saw it
before but i'm going to try it out sometime.

- ask for password
- DEcrypt the code-block with the pw
- calculate new checksum on the c-block
- check if the new crc matches the original one
- if no then quit
- jump to the DEcrypted code


- the ENcrypted program code


- quit


(in this case even the seh frame is nonsense...)

sure, the cracker can patch the crc check and the
prog will lead him to the code block, but with a wrong
pw the code should make no sense and will FOR SURE
Posted on 2002-05-30 04:11:23 by mob
mob, look at the "Synchronize It! (WinSin)" essay on my site.
Posted on 2002-05-30 04:34:17 by f0dder
Modify the return address of function calls!
If you then ever "step over" the call, the debugger will simply carry on going (until the next break point at least)!
Its a simple trick, but can annoy I'd suspect :)

You could also use function calls as multiple option jumps if you worked out some complex (or not so complex ie table) system for holding the new return addresses.

Posted on 2002-05-30 04:36:59 by Mirno

mob, look at the "Synchronize It! (WinSin)" essay on my site.

i read your essay and i must say it was a very interesting read
but this demonstrates only that this method seems to be very
reliable if you take care of a few things (for example avoid these
last two bytes). mh i've got another idea that bases on the
first one, imagine this:

- ask for password
- DEcrypt the code-block with the pw
- jump to the DEcrypted code


return a value

if we're here the code has been executed.
so if the pw was wrong and still no exception
occured (besides i think thats impossible) we
can check the return value and know if the pw
really was wrong (because wrong Decrypted code
will return a FALSE return-value)


the code-block raised an exception,
this means the pw was wrong -> quit.


first version
advantage - one can insert the whole prog code in the code-block
disadvantage - a few flaws (but can be fixed i think)

2nd version
advantage - more secure (???)

- very dirty
- code block must be small
- uhh if a jump op is generated by the decryptor you have
to wait until an exception occures...

:o damn... think the 1st one is better... :)
Posted on 2002-05-30 05:03:22 by mob
just want to give you some resources:


Most of the "AntiCrack" methods explained refers to the famous debugger "S*CE".

But is really IS a waste of time:

* packed exes can be unpacked with the use of a memory dumper
* same thing with section-crypters
* 99% of debugger-protections don't work if the cracker uses apps to hide his debugger
* the rest of the protections can be patched
* you can look for INT 3 (0CCh) that appears if a Breakpoint on execution appears but: breakpoint on memory-access can't be located this way.
* etc.

Maybe the best way is to leave out procedures that should not be available in the unregistered version. I have several ideas
to do this:

* Use a DLL
* NOP your source-code that should not be available in the unregistered version and write it into a keyfile that the user who paid for your software will receive. That keyfile could contain user-information etc.
* make use of CRC!
* make use of cryptography
* API is easyer to crack then VCL or MFC
* ...

Have a nice day
Posted on 2002-05-30 11:35:51 by Rennsemmel
I can give you just one advice:
Please, don?t end up your extra-genial-unbreakable protection with a loony TEST AX,AX
It could be the best protection ever, the best encryption algo, but if then you spoil it with that... ;)
Posted on 2002-05-30 12:03:30 by slop
Okay, and there?s also a good anti-debug utility in Iczelion?s page,
in sources,
its called Softkiller or killerice, or something like that.
Posted on 2002-05-30 12:16:22 by slop
Any linear approach is just a minor delay. A distributed approach is much more effective. There has to be a huge number of variables to track, and no where can the protection come down to a single branch. It's not easy to design such a system, but you will be rewarded with a longer delay before your program is broken.

What do people here think about software that has to be authorized regularly by web? Automatically, of course, but still required.
Posted on 2002-05-30 12:22:56 by bitRAKE
I am of the view that every little bit helps, stuff the EXE file through an obscure compressor that messes up the sections so that a memory dump does not work directly without a lot of messy fixups. CRC the compressed EXE file and length check it as well. Makes the workload harder.

Another trick, somewhere before the branch is required, try

; procedure calls
PUSH another proc address
; Some function calls
; procedure calls

This scruffy mess pushes a number of return addresses and then branches to the last one pushed by using the RETN mnemonic. If you put it at the end of a procedure, its real easy to mess up what is happening in a dead listing.

With the chained return addresses, a dead listing does not show the code being called and will appear as an unreferenced function. You can track it in a debugger but its no joy to patch.


Posted on 2002-05-30 12:49:46 by hutch--
To bitRAKE:
I've seen those schemes, softwarew authorized by web, but think of it as a "dongle" protection: If you have the program you can unprotect it ;)
(It?s sort of funny: they claim that it?s an "uncr***able" scheme, do you remember how was it when first dongles appeared) :)
Posted on 2002-05-30 13:10:14 by slop
hutch?s quote: "stuff the EXE file through an obscure compressor that messes up the sections so that a memory dump does not work directly "

Yo?re right, that works fine, most newbie-cr***ers stop there ;)

More quotes:"

. CRC the compressed EXE file and length check it as well. Makes the workload harder.

Another trick, somewhere before the branch is required, try

; procedure calls
PUSH another proc address
; Some function calls
; procedure calls

Have you heard about revirgin?
Great tool :))
Posted on 2002-05-30 13:14:51 by slop
Make all your code look like this. :grin:

pop eax
pop edx
pop ecx
push esp
xchg [esp],eax
push 0
push DWORD PTR [eax+4]
push DWORD PTR [eax]
push ecx
push edx
push eax
mov DWORD PTR [esp+(4*7)],0C201F083h
mov DWORD PTR [esp+(4*8)],090900008h
jmp ReadFile

[b]Instead of[/b]:

StreamInProc proc hFile:DWORD, pBuffer:DWORD, NumBytes:DWORD, pBytesRead:DWORD
invoke ReadFile,hFile,pBuffer,NumBytes,pBytesRead,0
xor eax,1
StreamInProc endp
Posted on 2002-06-10 01:49:57 by bitRAKE
Best and only non-crackable protection:

Posted on 2002-06-10 03:41:16 by bazik
And then sombody buys the full version and mass distributes it on Kazaa.

You can't win. :) :(
Posted on 2002-06-10 05:22:20 by iblis