Hi all,

I have an application that I would like to spread as a demo. However, it is nearly fully functional and I don't want it to be used commercially. So I'd like to show a splash-screen and count to five as a compromise...

The problem is of course to make this hard to crack. I know I can't make it fully uncrackable, but I'd like to get the best protection with the least effort. One idea I'm having is to encrypt some data or functions in the splash-screen bitmap. But of course any hacker would find this quickly and work around it. I'll also need checksums but don't know how to practically implement them.

All tricks welcome! :grin:
Posted on 2004-03-28 06:32:52 by C0D1F1ED
"Don't bother". Keep your code simple, it will be cracked anyway. The only thing you can hope is to stop the casual users, and delay the pirates just a little... no point in making overly complex code.
Posted on 2004-03-28 06:48:43 by f0dder
Well, I don't want to put too much effort into it, but I want to at least stop the script-kiddies and prevent that it becomes the target in a newbie's cracking tutorial. :( I want to at least test the cracker's advanced assembly skills. :grin:

So, please don't put too much attention on the practical use, I'm just here to learn some new tricks...
Posted on 2004-03-28 07:29:41 by C0D1F1ED

but I want to at least stop the script-kiddies and prevent that it becomes the target in a newbie's cracking tutorial.

Sleep(5000) or using a WM_TIMER message to post WM_DESTROY is probably a bit simplistic then :D

Well, how about this, then - just a quick idea. Compute a 32bit checksum of your splash screen. Store some 32bit value in the WM_TIMER "destroy splash screen" routine. Use this to form a decryption key, and decrypt pieces of code at runtime. A bit silly, and can rather easily be circumvented, but it will stop the really entry-level crackers.

For more advanced stuff, implement a virtual machine and handle bitmap loading and lots of parameter setting up, code decryption, etc. That will stomp a lot of people.
Posted on 2004-03-28 09:15:16 by f0dder

Well, how about this, then - just a quick idea. Compute a 32bit checksum of your splash screen. Store some 32bit value in the WM_TIMER "destroy splash screen" routine. Use this to form a decryption key, and decrypt pieces of code at runtime. A bit silly, and can rather easily be circumvented, but it will stop the really entry-level crackers.

Sounds cool! :alright:

I've done a little experiment with a checksum:


#include <stdio.h>

#ifndef NDEBUG
#define DGB true
#else
#define DGB false
#endif

#define ANTICRACK_HEADER(R, D) \
int checksum = DGB ? D : R; \
__asm{mov eax, __anticrack_header} \
__asm{sumloop:} \
__asm{movzx ebx, byte ptr [eax]} \
__asm{sub [checksum], ebx} \
__asm{inc eax} \
__asm{cmp eax, __anticrack_footer} \
__asm{jl sumloop} \
__asm{cmp checksum, 0} \
__asm{je __anticrack_header} \
__asm{jmp __anticrack_footer} \
__asm{__anticrack_header:}

#define ANTICRACK_FOOTER \
__asm{__anticrack_footer:}

void main()
{
ANTICRACK_HEADER(1956, 3245)

printf("Splash!\n");
printf("Application running\n");

ANTICRACK_FOOTER
}

Two big disadvantages are that I have to fill in the checksums 'manually', and that I have to redo it every time the function implementation changes. :( Is there any chance I could let the compiler (Visual C++) generate them? Also is there any shorter way to implement this, so it's harder to notice by the cracker?

Thanks!
Posted on 2004-03-28 11:21:33 by C0D1F1ED
One of the few things I miss in C/C++ is a more powerful macro language - there's a lot you can't do. So for things like checksums of code blocks, your best bet is to __emit some magic signature before and after a function you want checked, and have an external tool scan the exe and generate the checksums. Same goes for encrypted code blocks.

To do anything that's non-trivial to pack, you'll have to deal with some external tools anyway. Things of interest:

*) Virtual Machines with obscure instructionsets. Write a code generating backend for LCC or other compiler so you don't have to handcode it.

*) code mutation - can be done on binaries, take a look at z0mbie's mistfall engine for ideas. This includes obfuscation and code bloat, hide the needle in the haystack.

*) On-the-fly decryption, *and* re-encryption so it requires more work to dump a fully working executable from memory.

*) Import table wrapping and substitution - takes some work to come up with something that can't be automatically restored, though.
Posted on 2004-03-28 11:36:38 by f0dder
Originally posted by f0dder One of the few things I miss in C/C++ is a more powerful macro language - there's a lot you can't do. So for things like checksums of code blocks, your best bet is to __emit some magic signature before and after a function you want checked, and have an external tool scan the exe and generate the checksums. Same goes for encrypted code blocks.

Well, I haven't thought of that. Good idea! :)

BTW, what language really has a preprocessor that can do this? You need the complete linked code before checksums can be made...
*) On-the-fly decryption, *and* re-encryption so it requires more work to dump a fully working executable from memory.

A friend just suggested to use UPX. Seems like a really simple way to stop 99% of hacking attempts! :cool:
Posted on 2004-03-28 15:36:33 by C0D1F1ED
Hi :)


A friend just suggested to use UPX. Seems like a really simple way to stop 99% of hacking attempts! :cool:

:grin:
UPX is a packer, not an encryptor! In fact, doing this:
UPX -d myapp.exe

will unpack the original file.

You might want to try Petite (shareware) or Yoda's Crypter (freeware), that will do the job without any complications. If you really want to improve security you can modify yoda's code to make your own, slightly different encryptor. That would stop generic unpackers. :)
Posted on 2004-03-28 15:42:15 by QvasiModo
Dunno if there's some language that would support exactly this, but a more flexible preprocessor would be a *nice* thing - the C/C++ preprocessor isn't much more than text replacing. Funny, though - it's almost only when dealing with code protection I've grumbled about the preprocessor, C++ is in generally a pretty damn flexible language.


A friend just suggested to use UPX. Seems like a really simple way to stop 99% of hacking attempts!

Heh :P - "upx -d" and that is defeated. It's trivial to circumvent the header modifications to make "upx -d" fail, and it's very trivial to dump an UPX'ed program from memory. If you want some ready-made solution, have a look at asprotect. It's been attacked a lot, so while it slows down attackers for perhaps a couple of hours, it's still worthless if you don't use the "encrypted code blocks" feature. If that is used, the security is okay until a valid keyfile is leaked.
Posted on 2004-03-28 15:45:15 by f0dder

If you really want to improve security you can modify yoda's code to make your own, slightly different encryptor. That would stop generic unpackers.

Nah - it would stop specific unpackers targetted at versions of yodas crypter, but it wouldn't stop *generic* unpackers ^_^
Posted on 2004-03-28 15:46:05 by f0dder
UPX is open-source... hint, hint. ;) Most probably it would only take a minute to replace the packing algorithm with encryption. Together with some checksums and some run-time generated code it might scare off most of them.

I'll check Petite, Yoda and asprotect. Every tool to make it less trivial to crack is welcome. Thanks a lot for the ideas!
Posted on 2004-03-28 16:18:32 by C0D1F1ED


Nah - it would stop specific unpackers targetted at versions of yodas crypter, but it wouldn't stop *generic* unpackers ^_^

LOL, my mistake, I meant "generic" as "packed by a known encrypter like yodas" :grin:
Posted on 2004-03-28 16:18:39 by QvasiModo
I checked Yoda...

Unfortunately, I forgot to mention that my application, the part that needs protection, is a DLL. Yoda appears to be only for executables. :( Someone told me DLLs are easier to protect, but couldn't tell me why. Is there any truth in that?
Posted on 2004-03-28 18:02:02 by C0D1F1ED
C0D1, UPX is opensource but GPL - ick ick. I believe there's also some additional clauses in their license that makes it hard to use for protection. Ontop of that, the source is an unreadable mess, and the way it works isn't really that special.

DLLs easier to protect, hm, dunno. Perhaps because a whole bunch of people can fire up some generic tool like procdump and dump an EXE, while a fair amount less can do the 5min job of writing an app doing LoadLibrary that breakpoints on DLL entry... if your app is ever targetted by "the scene", this won't save your ass in any way, though.

DLLs always have (well, should have) relocations, and this could be used in a more advanced crypter for various tricks...
Posted on 2004-03-29 00:31:35 by f0dder