I need some advice on protecting an .exe file. Programs like Armidillo are basically crap and i would like to keep my application private for at least a little while. any advice would be greatly appreciated. thanx
Posted on 2001-11-11 18:14:58 by hexman

There have been many schemes for protecting programs depending on what they do and how they need to be protected but there are probably as many schemes around for breaking the protection so its not as easy as it looks.

The old cracking scene used to have a lot of very smart info on protection scheme design but once it was made illegal, you are not allowed to place protection design info on a web site any longer.

If you could give us some idea on what you are trying to do, there would be a few people around this forum who know something about program protection design who may be able to help you.

If you can find any of ther old stuff, you may be able to learn what ideas to avoid as many can be routinely broken and if you wish to have any chance of succeding, you will need to do something original and different to protect a program from hacking or professional crackers.


Posted on 2001-11-11 21:46:09 by hutch--
I dont know much about this neck of the woods, but what i do know is the bottom line is to keep it confusing for the "hacker"...

The hacker will *always* figure it out... so dont kid yourself.. but the trick is to keep them running in circles long enought to where they dont find worth in *wasting* anymore of their time.

Another kinda asset is that fact that once compiled into ml, there is no more labels for jumps, so this can get a bit tiresome after a while, where all the jumps have no "names"...

Good Luck...

PS: Another Canadian i see, where are you from?
Posted on 2001-11-12 00:14:00 by NaN
I did a little work on some macros which worked to convolute all API code. The produced code is faster is some cases, compresses better, and is hard as hell to follow - no debugger I know of can recognize the API calls. ;) It requires a pretty twisted mind to code using them though, and the macros are very incomplete.
Posted on 2001-11-12 00:39:10 by bitRAKE
Nan: ML assembles, it doesn't compile... and it's called a cracker, not a hacker.

Well, as NaN said, obfuscation is one of the most important things.
Call call call call. Lots of procs with lots of subprocs doing nothing
(but making it seem like a lot of stuff is goign on). Runtime code decryption
is also good, but you'll have to make it "spiffy", like not storing the
decryption key in your executable, but making your app bruteforce itself
(with the help of a CRC). Playing around with SEH and int3 (using int3
to trigger a SEH that does vital stuff) is also very good, and will foil all
ring3 debuggers I know of. And make debugging annoying, even in ring0 debuggers.

Other tricks? Pagefault+seh used to do JIT decryption. SEH is in general
pretty neat.

Make a compression wrapper that also implements an API which your app uses.
This way, as soon as the cracker (easily) removes the compression wrapper
and has an analyzable executable, it just wont work because the wrapper API is gone.

Also, import APIs yourself. Keep one import from each DLL you use. That imported
function can be used to scan back and locate the PE header of the DLL, and from
there you can do any importing yourself. Of course instead of using the function
name, you should use a hash of the function name, so it's not obvious which function
is being imported. Note that you must handle nt/2k redirected exports...

Note that I'm too busy to help you implement any of this. And if you
want to stand ANY chance against cracking, you must be able to
implement these schemes from my (rather vague) descriptions...
otherwise you might as well give up :).
Posted on 2001-11-12 08:31:06 by f0dder
You can also pop the return address off the stack, and push something else on in its place, it makes deadlisting much more difficult to trace, and in an interactive debug, the would be cracker has to step through each call (most debuggers will place a break point on the instruction after the call, then run, obviously this is never reached, so stepping through each call can be a REAL pain! ).


P.S. f0dder, if you use a .IF statement then ML has to compile it, so technically it is a compiler (even if it's comilation functionality isn't always used).
Posted on 2001-11-12 08:50:08 by Mirno
Masm does a few "compiler-like" things. But compilers usually do
a lot more... like optimization and such.

Now, you might argue that since masm does compiler-like stuff (struct
handling, macros, etc) that it should be called a compiler. But it
handles assembler code, not highlevel code. If you were to be a purist,
what would you call an assembler? Debug.exe?

I say call masm, tasm, nasm and all such tools assemblers. It avoids
Posted on 2001-11-12 09:05:34 by f0dder
Wow! Thank you for the help. Basically what I am trying to do is obtain some kind of add on s/w based wrapper that will, in the least, buy me some time. The nature of the business I am involved in requires constant change and modification to code... In short 10 days of security is worth alot! I simply do not have the time to stay on top of the code changes required and the security measures to fend off the hackers. As I mentioned earlier programs such as Armidillo that exist for this purpose basically all have freeware solutions to defeat thier intentions. Is there any reliable s/w application that I can run my .exe through without modifing the source to render it somewhat secure from the average hacker? Again, your help and opinions are greatly appreciated. -hexman

Winnipeg, Canada!
Posted on 2001-11-12 10:40:33 by hexman
You can use asprotect. It's not too difficult to unwrap, BUT... if you
use the AsProtect API (which you have to do if you want ANY kind
of security), the job suddenly gets a lot tougher. If you have a name/serial
type of scheme, change it to use asprotect api, and you'll know that
it will NOT be keygenned... asprotect offers RSA1024 ;). Your app
will still be unpacked and patched though, but this is not as prestigious
as writing a keygen. And not all crackers have the knowledge required
to unpack the later asprotect versions (though this knowledge is
becoming more and more common).

Also, know that generic unpackers exist for older aspr versions, and
will surely be written for newer versions. So all you buy is a little
time, plus making it impossible to keygen the app.
Posted on 2001-11-12 10:59:34 by f0dder
If you want to protect then lock the room with a couple of huge locks and a some security guards at the door.
If you are going to spread your app it'll get cracked sooner or later.
This is history repeating.
Anyway, if you cannot develop your own protection, go for the Russian ones which are always the toughest ones :)
Posted on 2001-11-13 08:40:49 by latigo
Can anyone point me in the direction where I might find a copy of VB 6 disassembler? thanks -hexman

I think I have an idea... will share results with group!
Posted on 2001-11-13 10:36:46 by hexman