[Lazarus] Detecting when decompiler is running

Marc Santhoff M.Santhoff at web.de
Fri Dec 4 15:57:41 CET 2015


On Fr, 2015-12-04 at 14:20 +0000, Mark Morgan Lloyd wrote:
> Marc Santhoff wrote:
> > On Fr, 2015-12-04 at 08:29 +0000, Richard Mace wrote:
> >> Hi All,
> >> I was wondering if there was a way where an application, written in
> >> Lazarus, could detect when a compiler is running, perhaps by it's mutex?
> >> My idea was, in my application, I could periodically check to see if a
> >> decompiler was running and then my app could perform an operation, such as
> >> maybe closing.
> > 
> > As others said, decompilers and disassemblers are not detectable. But
> > for protection there are other counter measures.
> > 
> > 1. Protect your program using checksums. Refuse to run if tampered.
> 
> The ld linker for ELF can embed a fingerprint, that can be read back 
> fairly easily but I've not attempted to verify an entire binary against 
> it. What I don't know is what part of a binary contribute to this, and 
> whether- as a specific example- stripping symbols changes it.

Not easy but possible ...

I will not publicly tell more about the nasty upper and the ghastly
lower layers in use ... ;)

> The real problem however is the ease with which an attacker can 
> substitute a hostile library, e.g. using (something like) 
> LD_LIBRARY_PATH on unix.

For hacking protection external functions are not used. External in the
sense of being located in some dynamically loaded lib.

Protection against other frauds is another topic.

> > 2. Use varying protection schemes randomly. I did sth. like that by
> > including protection code that is switched from the make process between
> > multiple versions. If some hacker really solves the riddle for one
> > executable, her hack will fail on most others. Same scheme as compiling
> > in a serial number, that is changed for each compilation.
> > 
> > 3. Check integrity of the program often, from many placces in the
> > program. If really paranoid, you can combine with randomly selected
> > checking routines. Using a code scanner/parser and injection code for
> > checks is relaitvely simple, e.g. at the start of a procedure insert a
> > check and exit code (or leave out, depending on the moons phase or so).
> 
> Making random choices can be unwise, because sooner or later you hit a 
> weak combination.

Never had that problem. In principle you're right, but If the goal is to
check some validation points and exit on fail it is meaningless for the
rest of the program. The other case is "do nothing if OK". If there are
some timing sensitive hardware function, those have to be taken out of
the code insertion run.

> Also as a general point I once had a colleague who spent his lunchtimes 
> methodically single stepping through AutoCAD with a view to finding out 
> how the security dongle worked, and he was broadly successful despite 
> professing to know no x86 assembler.
> 
> So you can obfuscate things as much as you want, but that's no 
> protection against somebody with patience.

That's why often and unexpected are the main guidelines for this scheme.
You need to hack each and every executable, which mostly isn't worth the
effort. And even if you try, it will take ages.

The other thing is, the hacker has to distribute the binary executable
of the program hacked, for all others it will not work. If the program
is worth a lot you'll have to fight against illegal copying in any case.

For the general case of software distribution the use of activation
codes bound to some checksums retrieved on the target computer are safe
(enough), me thinks.

> > If you have enough checks, enough randomness between varying mechanisms,
> > hackers will give up for sure. You are in trouble if those programm
> > sould be distributed on DVD from one master, though.
> 
> Yes, big trouble. And I assume that you've seen yesterday's news about 
> Raspbian being insecure because all copies start with the same (or no) 
> "entropy", so SSH is seeded the same.
> 
> There is no substitute for a piece of hardware or software being 
> uniquely serialised, and the user's contract (or license, or whatever 
> you want to call it) being tied to that.

What I did not mention is, that I used this scheme from the solid
position of being able to rely on some hardware serial numbers.

General software (only) distribution needs another source of checksum,
but that one will need to be checked, too.

> > I'd like to hear from others about their anti hacking tools ... ;)

Still so, how do you protect?

Marc

-- 
Marc Santhoff <M.Santhoff at web.de>





More information about the Lazarus mailing list