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:
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.)