I've also been toying with generating hash codes from call stack data and using those hash codes as private keys ... This works with considerable success, avoids storing the private key anywhere in the code, and incorporates something of a defense against code injection attacks where API hooking, dynamic library replacement, and other techniques useful for scraping keys out of memory at run-time are automatically defeated because the call stack changes and thus the authentic private key disappears, never to be computed at runtime. The resulting DoS event also signals an attack in progress. Of course, you have to profile your call stacks carefully and rekey everything if you ever fix bugs or make other changes to the code that may result in changes to your call stacks. Sincerely, Jason Coombs jasoncat_private -----Original Message----- From: Peter Jeremy [mailto:peterjeremyat_private] Sent: Saturday, January 11, 2003 12:32 PM To: lsi Cc: secprogat_private Subject: Re: PGP scripting... On Wed, Jan 08, 2003 at 12:38:42AM -0000, lsi wrote: >My best theory to date is to embed an encrypted password in sourcecode >(please don't shoot me). The prog must decrypt before use. Requires >encryption of pw prior to compilation. Requires decryption algorithm >in code. If the system was comprised the attacker would still need to >reverse the decryption. > >The prog would not be vulnerable to NOP-style cracking (binary >patching of executable to skip instructions) as the pw does actually >need to be decrypted. But a disassembler would have the algorithm in >plain sight soon enough. If you are considering this approach, you should probably consider obfuscating the pw decryption code: - subdivide it into small pieces and scatter them throughout the rest of the code. Burying parts of the code in trap handlers can make it hard to find. This will make the decryption algorithm harder to determine. - consider using self-modifying code - which will make static disassembly less useful. - map the code and data in multiple locations and use them interchangeably (eg have the same buffer appear at 3 different addresses and have different parts of the algorithm use different buffer addresses). Beware of cache effects with this. - If this is running on known, dedicated hardware, write the code to depend on CPU and hardware quirks. (Remember to document this so that your successor doesn't try to "upgrade" the system). Peter
This archive was generated by hypermail 2b30 : Mon Jan 13 2003 - 07:50:41 PST