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. |

| 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....
pgpv44p03vx20.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Announcement: The Web Security Mailing List, contact |
|---|---|
| Next by Date: | RE: Dll Security, Slavisa Dojcinovic |
| Previous by Thread: | RE: Dll Security, Chris Matthews |
| Next by Thread: | RE: Dll Security, Slavisa Dojcinovic |
| Indexes: | [Date] [Thread] [Top] [All Lists] |