1994-07-10 - Re: Request: tamper-proofing executables

Header Data

From: rarachel@prism.poly.edu (Arsen Ray Arachelian)
To: grendel@netaxs.com (Michael Handler)
Message Hash: cb8a443d9d192fb995bc66eb0d239f4d2c23dfbacbeccc50602db075a7e87ae3
Message ID: <9407100718.AA21416@prism.poly.edu>
Reply To: <Pine.3.89.9407081353.B13677-0100000@unix2.netaxs.com>
UTC Datetime: 1994-07-10 07:31:22 UTC
Raw Date: Sun, 10 Jul 94 00:31:22 PDT

Raw message

From: rarachel@prism.poly.edu (Arsen Ray Arachelian)
Date: Sun, 10 Jul 94 00:31:22 PDT
To: grendel@netaxs.com (Michael Handler)
Subject: Re: Request: tamper-proofing executables
In-Reply-To: <Pine.3.89.9407081353.B13677-0100000@unix2.netaxs.com>
Message-ID: <9407100718.AA21416@prism.poly.edu>
MIME-Version: 1.0
Content-Type: text


> 	I have yet to devise or find a foolproof [ ;) ] or unbreakable 
> protection scheme. I'mm starting to think there's no such animal. What 
> you CAN do is protect your executables against file corruption, viruses, 
> and lame-0 hacker dudez. But, getting any secure PGP-level security is 
> very difficult.
> 	OTOH, if anyone else has come up with a scheme that is hard to 
> break / unbreakable, *please* come formward and correct me. I have a few 
> applications that I'd like to apply this to. :)

There isn't any foolproof way.  The reason is that if you protect a program
through software, the hacker, if determined and of exceptionally high caliber
will turn to hardware.

I have a friend of mine who was in Russia a few years back while they were
trying to clone their own PC's.  One great method of debugging such home
made Russian brand machines was to use one computer to debug another computer.
How?  Somple.  You shut down the clock on one machine, let it execute one
instruction, then use the other computer to look at the memory of the
machine being debugged.  The debugger can modify memory or read memory.  It
would then execute one or many instructions on the debugged CPU by strobing
the clock.  I believe they even had a way of grabbing the current registers
on the target CPU via interrupts.  (ie: a hardware interrupt that points to
a ROM routine which then stores the current registers to some memory which is
not normally available to the program running on the debugged CPU except
when it is activated by the debugger CPU.)

Simpler schemes if I may point them out include the ISEPIK cartrige and its
ilk on Commodore 64 machines.  Infact I may point out that the Commodore128
which could emulate a C64 had a built in debugger which when the machine was
reset would let you look at most of the memory from a running C64 program! Now
some memory would be lost, granted, but a determined hacker could find a way
to get at it and create an image which could be restored later.

(Infact the C128 debugger was so good that GEOS 1.2 could be hacked with it!)
A lot of the earlier Activision games could be restarted by a simple SYS
call to one of the usual locations.  Usually restarting the computer and loading
a debugger did the trick.  With the C128, this was even easier.


Some UPS cards have the feature of saving the RAM of the currently running
machine to the drive because of a power failure.  This is evident in
notebook computers though they keep it in RAM.
(Infact the C128 debugger was so good that GEOS 1.2 could be hacked with it!)





Thread