Protection Software

[Astro]

Hi,

Does anyone know of any software that can be used to protect MASM generated executables?

I tried UPX but the files are too small for it to work with it. I want something that just scrambles the EXE to make it harder to disassemble.

Does anyone know if VMProtect works with assembler files? I only had a demo which was limited so no way to test.

Best regards,
Robin.

[NervGaz]

I'd say anything that uses more than just simple compression of the file should do.
However I'll also point out that a fair few "protectors" are easily defeatable and
quite simply won't be worth your time. UPX as protection is a perfect example,
I can just download UPX and unpack it, and with a debugged and freely available
tools it is trivial to unpack and rebuild it to a working executable to analyze.

VMProtect or one of the other more advanced virtual machine based protectors
do make your would be reverser'/cracker's job a lot harder, one of the reasons
they are favoured by malware authors for instance.

I'll also point out that if you are using them to obscure a licensing scheme of some
description you are better off designing a god licensing scheme than relying on a
protector to keep a halfa***d one safe. There are plenty websites out there about
this however linking to them here might potentially break forum policy so my best
advice is that Google is your friend.

[BlackVortex]

1) UPX isn't a protector. End of story.

2) Heavy protectors leave your executable a mess, they reduce compatibility and sometimes speed and memory consumption.

If you are willing to pay that price, I recommend latest AsProtect 2.x. *IF* it's implemented correctly, automatic unpackers won't work on it and manual unpacking it is difficult. Many naive wannabe crackers think it's an easy protection because it's usually implemented lightly and there are a ton of tools and tutorials for it, but I guarantee that strong implementations are at the top of the food chain.   :U

[hutch--]

For those with no fear of using a hex editor, a couple of minor twiddles in the UPX compressed EXE header render it unable to be unpacked automatically but the authors don't like you doing that, the reason why I ditched UPX years ago. I agree with both BlackVortex and NervGaz that there is little chance of serious excryption of an executable without making a hell of a mess of it and they can still be broken if someone is serious. As apps get bigger you can increase the difficulty by some powers by doing ideosyncratic things, distributing data around an EXE in unusual ways, CRC checking things like the PE header and flagging an error that goes bang somewhere down the track but all of it can be broken over time.

The idea is to make it take a long time and keep changing the guts of each version so its different and you can slow them up some.

[Astro]

The idea is to make it take a long time and keep changing the guts of each version so its different and you can slow them up some.

I'm not looking for a panacea, just something that makes it harder.

Best regards,
Robin.

[NervGaz]

Astro, When you say making it harder are you talking about just the disassembling or are as I mentioned in my earlier
post trying to protect a licensing scheme or something to that effect? Cause there are some obvious differences in
the ways you can do the two. there are plenty of articles about on various anti disassembly and anto debugging
tricks out there that you can implement in your code to make it harder to analyze your code even after it has been
unpacked/unprotected. Admittedly these should be added to any decent licensing scheme but they will half the
time make it harder to keep your code readable as they tend to involve things like jumping into the middle of an
instruction that it pure garbage yet when the jump lands there it is the actual instruction you are using and various
other kinds tricks that will force you to write your code and the look at the opcodes and hardcode stuff around them.

Your goal will very much define your options.

[Farabi]

From my experience when my friend want me to test its security system. If your packed or encrypted software is running, your app software code is shown. I just put a breakpoint on the windows API function, and then run the app, the unencrypted data is then shown to you.

[Astro]

Basically - it is a waste of time? No probs!  :thumbu

Best regards,
Robin.

[NervGaz]

What Farabi says is essentially true depending on the protector I would
one that is based around virtually machines and resigning yourself to
the fact that if someone really wants to they will unprotect it.

Look into some anti debugging/disassembly tricks as well if you want
to, but in the end you'll never be completely safe.

[Astro]

I realize that given sufficient time and motivation anything can be cracked/broken/etc..

I know some software protection systems are easy to reverse - that is in part why I'm asking.

Best regards,
Robin.

[Farabi]

I realize that given sufficient time and motivation anything can be cracked/broken/etc..

I know some software protection systems are easy to reverse - that is in part why I'm asking.

Best regards,
Robin.

Well atleast by using UPX your software would not be able to be patched (Code removing), since no one know on which offset your code is.

[Ghandi]

Sorry Farabi but a quick Google search shows that UPX is no protection agains patching. It can be unpacked automatically with UPX.exe using the -d switch, it can be unpacked manually, it can also be patched in an inline fashion and it can have its process memory written to by a loader.

Essentially, there is no method which is 100% foolproof for protecting a 32 bit process. Encryption can be broken or reversed using a valid key, anti-debug measures keep out the less determined but eventually if the software is of interest and gains enough attention, it will be broken. An alternative approach for a software developer is to have the registration scheme in place, with protections of course, but to concentrate more on providing a reasonably priced package of software, support and updates. This should enable them to build a customer base with genuine users. Generally speaking, the average 'user' who will use a cracked version wouldnt use the software if they had to pay for it, so its not as if they're lost sales.

If its not for profits, then its a little harder to tie in legit users, but even so you can protect your code from the casual prying eyes simply by following Hutch's advice:

As apps get bigger you can increase the difficulty by some powers by doing ideosyncratic things, distributing data around an EXE in unusual ways, CRC checking things like the PE header and flagging an error that goes bang somewhere down the track but all of it can be broken over time.

The idea is to make it take a long time and keep changing the guts of each version so its different and you can slow them up some.

HR,
Ghandi

[sinsi]

I seem to remember that if you use UPX version 0.x to pack you can't unpack it with any version of UPX.