From: Jason Coombs [jasonc@science.org]
Sent: Monday, January 13, 2003 1:43 AM
To: Peter Jeremy; lsi
Cc: secprog@securityfocus.com
Subject: RE: PGP scripting...

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
jasonc@science.org

-----Original Message-----
From: Peter Jeremy [mailto:peterjeremy@optushome.com.au]
Sent: Saturday, January 11, 2003 12:32 PM
To: lsi
Cc: secprog@securityfocus.com
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