From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 03:05:44 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09AA16A402 for ; Thu, 21 Feb 2008 03:05:44 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: from episec.com (episec.com [69.55.237.141]) by mx1.freebsd.org (Postfix) with SMTP id 9070613C4CC for ; Thu, 21 Feb 2008 03:05:44 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 65970 invoked by uid 1024); 21 Feb 2008 02:39:03 -0000 Date: Wed, 20 Feb 2008 21:39:03 -0500 From: ari edelkind To: freebsd-hackers@freebsd.org Message-ID: <20080221023902.GI79355@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@freebsd.org References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BCD34F.7010309@freebsd.org> Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:05:45 -0000 > >#!/usr/local/bin/mysecyritywrapper > ><...encryted code goes where...> > > > > In this way. it'll be hard to use truss, ktrace, strace etc... > > No, not really. All of those tools can trace through > to sub-processes, so whenever the code gets decrypted and > starts executing (whether it's in the main process or > in a sub-process), they'll be able to follow the system > calls it makes. Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is already being traced. As for core files, a process can use setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory pages may be encrypted or unloaded, to be decrypted or loaded on demand. An approach that handles all of the above, with the possible exception of setrlimit(RLIMIT_CORE,...), is "shiva", though it's available only for linux and distributed as an executable. http://www.securiteam.com/tools/5XP041FA0U.html Even then, the developers explicitly state that this can only slow the determined attacker in his endeavors, but the solutions everyone seems to be proposing here won't help. 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. That said, here's a set of slides from a talk on attacking shiva-encrypted binaries: http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-eagle/bh-fed-03-eagle.pdf ari