Mark Morgan Lloyd wrote 18 lines
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.
Show quoted text 14 lines
> 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.
Show quoted text 7 lines
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.
Show quoted text 11 lines
> 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
