encrypted executables

[Bert JW Regeer]

On Feb 20, 2008, at 20:18 , Joerg Sonnenberger wrote:

> On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote:
>> Mind you, it's true that disabling core dumps with a resource limit
>> doesn't keep one from creating a core image using gcore, but since  
>> gcore
>> generally must either attach to a process using ptrace() or access
>> mapped code segments in the original binary (depending on the
>> implementation), it won't help in such a case, either.
>
> What prevents me from patching the kernel (!) to just ignore the
> resource limit? Nothing.
>
> Joerg

Or for that matter ignoring the first ptrace() so that on the second  
ptrace call we make we can attach without a problem?

On an open system like FreeBSD or Linux it is practically impossible  
to guarantee that the binary that is encrypted can't be tampered with  
in such a way, or have it's un-encrypted code dumped.

Even on Windows this is hard, since the kernel is open for so many  
attack vectors, including but not limited to writing new kernel  
modules that hook certain kernel functions to do what I just  
mentioned. The openness of an Open Source system that allows an  
attacker to easily modify the OS the executables are running on is the  
biggest problem. There is no guaranteed code execution path, no  
guarantee that syscall's will do what you ask them to do.

Bert JW Regeer