[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EXE/COM encryptions

This is a message I received for an excellent idea on the run-time encryptions.
Once I finish my current project(s), I may start on it, but in the mean time...
any of you out there want to try this one?  BTW - the program I mentioned
in the post at the beginning of this thread has been uploaded to 
soda.berkeley.edu - when (if) it gets posted, anyone who's interested can
FTP it... it contains full source code and is titled BWFPU21S.ZIP.  As
of yet, It has rather poor encryption techniques, but after all the suggestions
I've been receiving, I hope to change that ASAP.  Thanks Everyone!
				Michael Ellison  [email protected]

Forwarded Message:

From:	IN%"[email protected]"  "A1 ray arachelian"  8-AUG-1993 13:18:00.86
To:	IN%"[email protected]"
Subj:	RE: EXE/COM encryptions....

Return-path: <[email protected]>
Received: from ishara.poly.edu by vaxb.acs.unt.edu (PMDF #3644 ) id
 <[email protected]>; Sun, 8 Aug 1993 13:17:49 CDT
Received: by ishara.poly.edu (5.59a/25-eef) id AA05059; Sun,
 8 Aug 93 10:16:57 EDT
Date: 08 Aug 1993 10:16:55 -0400 (EDT)
From: A1 ray arachelian <[email protected]> (library)
Subject: RE: EXE/COM encryptions....
In-reply-to: <[email protected]>; from
 "[email protected]" at Aug 7, 93 7:42 pm
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT

>         That sounds like an excellent idea - I may start experiment with
> that soon if I get time, if not, you might want to send the idea to the
> cypherpunks list as a whole as it would be really cool to see implemented.  
> The program I've written attaches to already compiled .EXE and .COM files 
> after compiling, so it would be of little use in that application (and
> it is in .ASM), but writing another one at some point would be interesting...
> haveta find someone with some _really_ technical docs on a good commercial
> compiler.....

I hope I'm right about this, but when you do a reply to a message coming
from the cypherpunks newsgroup (from my mailbox as I subscribed to it)
doesn't the reply go through toad.com rather than just as a reply to the
person to whom I'm responding? 

(If not, then I've been needlessly posting private messages!)

Anyhow, you could always go for a compiler whose sources are readily
available such as GCC.  Commercial grade compilers will generally not
provide a way to patch the back end.  >HOWEVER< you can get around this
by writing your own linker, and if the linker is smart enough to know
where a function call is made, you can add in your own code to do the
decryption to some free memory area off the disk, execute that area, 
and when the code returs back out, you free that memory area.  It would
be a somewhat disk intesive execution, but hey, it could be done from
RAM as well. :-)

There are several excellent third party linkers out there such as RTLINK
and Blinker in the DOS world that do all sorts of nifty things such as
overlays and dynamic memory management for compilers that don't give
these features.

Another possiblility is to write your own assembler as for instance Borland
C will produce assembly output if told to do so rather than obj code.
Then the assembler does the encryption handlink and I suppose a regular
linker would work too.

However, with most compilers, you should be able to write an engine
in C code which will open up a datbase or some other file which is encrypted
then grab portions of that file, decrypt them to memory, and do a
call to them as if they were functions.  Then when the call is done,
you free that memory block, and continue to do the same..  This
would deal with the ability to load up functions in overlays or
just execute functions via a pointer than a direct call to a function.

So the main code of your program is a decryption engine which loads up
modules from an encrypted overlay file (or from the end of the EXE file,)
decrypts them in RAM, calls them, and frees the memory they took up.
(This may fail with STATIC variable declarations within functions!)

It would work very nicely, but instead of doing direct function calls
your program's source would need to be modifyied to do a whole song
and dance before it can call a protected function.

With a linker or compiler that does this automatically it makes it
much easier to just recompile existing code, and much much easier
to write such code from the programmer's point of view.

Now an interesting situation is to be found on Macs which have
individual code resources which can be compressed.  There is no
built in decompression/compression scheme in the system software.
Rather it makes use of a special code resource labeled as DCMP for
decompress which of course you could replace with a decrypt
code resource, though the system would think the code resources
are compressed. :-)

This would not require any modifications to a compiler or linker.
Just encrypting resources and adding in a decryption code resource
which would pop up a dialog box asking for a key the first time it

(IF this winds up being private just to you, please post it as public
for me by forwarding it to the cypherpunks newsgroup.)