From: IE63@vaxb.acs.unt.edu
To: cypherpunks@toad.com
Message Hash: c0a0dccc8ec613d98427249deb4181abf5b04490cbc5684d113314df6b76067f
Message ID: <01H1IIPJ64TE001JWH@vaxb.acs.unt.edu>
Reply To: N/A
UTC Datetime: 1993-08-09 00:36:26 UTC
Raw Date: Sun, 8 Aug 93 17:36:26 PDT
From: IE63@vaxb.acs.unt.edu
Date: Sun, 8 Aug 93 17:36:26 PDT
To: cypherpunks@toad.com
Subject: EXE/COM encryptions
Message-ID: <01H1IIPJ64TE001JWH@vaxb.acs.unt.edu>
MIME-Version: 1.0
Content-Type: text/plain
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 ie63@vaxb.acs.unt.edu
Forwarded Message:
From: IN%"rarachel@ishara.poly.edu" "A1 ray arachelian" 8-AUG-1993 13:18:00.86
To: IN%"IE63@vaxb.acs.unt.edu"
CC:
Subj: RE: EXE/COM encryptions....
Return-path: <rarachel@ishara.poly.edu>
Received: from ishara.poly.edu by vaxb.acs.unt.edu (PMDF #3644 ) id
<01H1I5P1HL3K001KB3@vaxb.acs.unt.edu>; 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 <rarachel@ishara.poly.edu> (library)
Subject: RE: EXE/COM encryptions....
In-reply-to: <01H1H4U3WNYQ001JGI@vaxb.acs.unt.edu>; from
"IE63@vaxb.acs.unt.edu" at Aug 7, 93 7:42 pm
To: IE63@vaxb.acs.unt.edu
Message-id: <9308081416.AA05059@ishara.poly.edu>
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
runs.
(IF this winds up being private just to you, please post it as public
for me by forwarding it to the cypherpunks newsgroup.)
Return to August 1993
Return to “IE63@vaxb.acs.unt.edu”
1993-08-09 (Sun, 8 Aug 93 17:36:26 PDT) - EXE/COM encryptions - IE63@vaxb.acs.unt.edu