Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

Re: Dll Security

Subject: Re: Dll Security
Date: Sun, 08 May 2005 19:34:37 -0400
On Fri, 06 May 2005 16:17:30 -0300, VP said:
Hi, i have a dll and i want to encrypt it to hide (obfuscate ??) an
important algorithm used here.

Good luck.  You're probably better off making the customer sign an NDA
or other document that has some teeth in it, so that you can sue them if
they rip your code off.  I have more faith in a good lawyer being able
to bulletproof the problem than a good programmer...

I'm encrypting the dll with a program, then when i want to loadlibrary() it,
i decrypt it to a plain-text file, then i loadlibrary the plain-text file.
So i have my encrypted dll and i have a plain-text version either. To
mitigate this vulnerability, i'm using EFS to protect my plain-text dll.

So far so good, except....

I'm wondering if using the PE format i can do some kind of "on-the-fly
encrypt and decrypt". Is it possible ? There is any example ? Is it a good
solution ?

The first guy who comes along with a debugger will have little to no problem
getting your code extracted.  Note that even loading the encrypted form, then
checking if you're being debugged, then decrypting and calling the code won't
work, because there's a race condition - they can attach the debugger after
your test.  And they can make the timing hole arbitrarily large - a bunch
of 'for(;;)' loops will slow things down.  You can't even raise your priority
by a notch, as the attacker can raise the priority of their cycle-suckers by
2 notches and the debugger by 3.

This is *really* a "You can't win this one" game.  You *might* be able
to if there's proper hardware support - but note that even the now-emerging
"trusted computing" chipsets probably can be subverted....

Attachment: pgpv44p03vx20.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>