From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjXaX-000215-EB for qemu-devel@nongnu.org; Fri, 04 Sep 2009 08:08:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjXaR-00020F-QL for qemu-devel@nongnu.org; Fri, 04 Sep 2009 08:08:19 -0400 Received: from [199.232.76.173] (port=58558 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjXaQ-0001zu-2Z for qemu-devel@nongnu.org; Fri, 04 Sep 2009 08:08:14 -0400 Received: from mx20.gnu.org ([199.232.41.8]:37749) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MjXaP-0001Rg-OI for qemu-devel@nongnu.org; Fri, 04 Sep 2009 08:08:13 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjXaO-0005dX-NZ for qemu-devel@nongnu.org; Fri, 04 Sep 2009 08:08:13 -0400 From: Paul Brook Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"? Date: Fri, 4 Sep 2009 13:08:08 +0100 References: <20090831180825.6ed2ea55@bud-laptop> <20090903170931.1e7d5772@bud-laptop> In-Reply-To: <20090903170931.1e7d5772@bud-laptop> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200909041308.09485.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , "Bud P. Bruegger" , John@mail.uk2.net, Forrester > Assume that I wanted to protect a secret algorithm in some C program. You're never going to be able to do this. At best you're going to add a few levels of obfuscation. At worst you're going to give yourself a false sense of security, while actually making it easier to defeat. The reason the Windows DRM stuff works is because it's protected by the lowest level of the OS/hardware, and that protection extends up the whole software stack. As soon as you loose this link (e.g. by running inside a virtual machine, or as a userspace application without host kernel magic) then you're vulnerable to anyone with a copy of gdb. The whole point of a smartcard is that it's a black box where you can't observe its operation at all, only its output. > Normally this is compiled into the machine code of a certain processor > and there are standard tools (disassembler, debugger) that can be used > to figure out what the secret algorithm does. > A virtual machine has a virtual processor. Assume now that I was to > shuffle around machine instructions both in the processor of the > virtual machine and in the back-end of my c-compiler. I imagine that > it would be possible to automate this process (some refactoring tool?) > and to do some random shuffling. This is no different from a simple bytecoded execution engine, and fairly straightforward to reverse-engineer. An experienced hacker will have no problem writing their own reverse engineering tools to strip away your obfuscation. Remember that your "encryption" is still native host code, with any keys plainly visible. Paul