Can use execute a binary from memory opposed to from a disk?

[DeepT]

I would like to have one executable 'execute' another executable from a memory buffer / ram disk (do these even exist under windows?).

Basically I want to have my main executable encrypted, and then have a loader which loads it to ram, decrypts it and then executes it. I do *not* want to write the decrypted thing out to a temporary file and then run that.

If I did, it would kind of defeat the purpose of encrypting the file to begin with unless there is a safe place, an invisible place, I can put this temporary file that is decrypted when I run it.

I just do not want a clever end user getting ahold of a decrypted version of an executable file.

Does anyone have any idea how to do this?

[kuphryn]

you will need reference for this topic

dll injection

Kuphryn

[Krishnaa]

I think you have previously asked same question, the answer is no, it's almost(*) impossible to do that. The main reason is resolving references on your own, thats not possible.

Why not extract your encrypted file into temp. file and execute it from there ?

[John E]

Is there the possibility of an encrypted folder? I've never used them but I believe that there are products available which can encrypt certain folders under Windows. Could this help you? For example, if a particular folder was encrypted and its decryption key was only known to your loader program, you could possibly decrypt your main program into a temporary file (within the encrypted folder) and run it from there. In theory, nothing outside of your program could see the contents of the temporary file. Of course, that in itself might prevent Windows from being able to run it...!

What are you trying to avoid? The possibility of reverse-engineering or what?

[DeepT]

you will need reference for this topic

dll injection

Kuphryn

Yes I asked about DLLs. This time I am asking about EXEs.

Why do I need a reference? What do you mean?

[DeepT]

I think you have previously asked same question, the answer is no, it's almost(*) impossible to do that. The main reason is resolving references on your own, thats not possible.

Yes, I asked about DLLs, not EXEs. Are they treated the same?

Why not extract your encrypted file into temp. file and execute it from there ?

What would be the point of ecryption then? All someone would have to do is take the extra, tiny step, of locating the temp file and then reading it all decrypted.

[DeepT]

What are you trying to avoid? The possibility of reverse-engineering or what?

Yes that is the main thrust of it, although I realize you can't actually stop reverse engineering. You can only make it very difficult.

Part of the problem is that there are lots and lots and lots of logging strings the the application as well as xml tags.

If you were to take the Linux app, "strings" and run it on our program, you would get a bonanza of information.

Furthermore, I use encrypted communication with our server (blowfish) and a clever hacker might be able to find the encryption key. If our binary was encrypted with a different key, it would make it harder to find.

If somehow I could "load" our exe into ram and THEN run it, it would make doing updates very easy since I could easily replace the encrypted exe file because it isn't actually running.

Lastly, the newer AV software, notably Norton and McAfee are super paranoid and every time we update our app (which is frequently due to its evolving technology) they throw up lots of warning boxes about how our product's exe has changed. Then the users need to re-authorize it which usually involves several click boxes from these AV products. If our main EXE was really a data file, then our frequent updates would not cause such a hassle.

[wildfrog]

What would be the point of ecryption then? All someone would have to do is take the extra, tiny step, of locating the temp file and then reading it all decrypted.

Well, they can always just break your application by attaching a debugger and then check out what it's doing.

Anyway, I believe I've seen a way to load an executable from a resource or the internet etc., and then execute it without saving it to disk. I just cant remember where . I also believe I've read somewhere that this (or atleast that technique) doesn't work on XP and newer... I'll see if I can dig up the code.

- petter

[Siddhartha]

What would be the point of ecryption then?

Encryption is used to protect data. Data unlike machine code contained by an executable is something that never gets executed. This is why your requirement to execute an encrypted file is not the norm.

(If I may I ask - why do you wish to do this?)

All someone would have to do is take the extra, tiny step, of locating the temp file and then reading it all decrypted.

That's right.

Which makes my question all the more important - what is in an executable that demands the same to be encrypted?

[DeepT]

Does it matter? Lets say it has classified information in it.

Let me put it this way, the application I am writing is a security application. The more difficult it is for a hacker to understand the application the more secure the entire system is.

Is there, or is there not a way, to run an executable that does *not* exist on a disk?

[Siddhartha]

Let me put it this way, the application I am writing is a security application. The more difficult it is for a hacker to understand the application the more secure the entire system is.

Are you convinced that a hacker of the capability to understand your executable's machine code and figure your algorithms out will not be competent enough to see what the decrypting application is doing?

Additionally, optimizing compilers like VS 2005 produce binary output that does not have one-to-one correlation with the source. i.e. Even for a hacker who can read an unfriendly binary and figure algorithms out, it isn't that straightforward. Add to that, you can make use of code obfuscators.

Is there, or is there not a way, to run an executable that does *not* exist on a disk?

Assume there is one (viruses do this all the time) - it is possible to peek into a Process' Memory - so, what seems to be a safe haven isn't really that safe.

______________

A possible solution is this - should you choose to decrypt your executible and run it from the disk, the executed file should first open itself with OF_SHARE_DENY_READ effectively blocking the ability of any process to access it's content.

OF_SHARE_DENY_READ-

Opens a file and denies read access to other processes.

On closure, the executible can signal another to delete it.

This isn't foolproof (and nothing is), but quite achievable.

[DeepT]

Are you convinced that a hacker of the capability to understand your executable's machine code and figure your algorithms out will not be competent enough to see what the decrypting application is doing?

It is not so much as the algorithms, they have been recently patented.

There is a lot of "clear text" in our app, which would be easy to see. Some of our cypher keys are also in our app, although they are not "clear text".

The concern is the end users, who in many cases are not 'willing'. Our application is a network management tool that does such things as make sure someone has AV software installed, running, and up to date with definitions. There are dozens and dozens of things it does.

As a network admin, you may want your users to have AV software otherwise they can not use your network. As an end user, you may not be happy about this and may resent this fact and try and bypass our app. You will quickly find out that simply removing our app will quickly result in your network connection going away.

The only option is to try and "spoof" the system. The first step I would do, as a hacker, is examine the EXE and see what I could find. Right now you would find a lot from it. As it is, you would still be stuck, but a really, really clever hacker might figure out a way.

Anyway, there are alot of benefits to be gained on many fronts if I could load our exe as a data file and just "execute" it without it having a physical presence on a disk.

In general, this idea itself could do a lot for software copy protection. I know if I was making a video game, I could use something like this to make a nearly uncrackable game, although it would also require that each copy of the game to be somehow unique.

[Vanaj]

Have you considered something like this ???

Stongbit

If you use this then password protect the program at startup there is not much else you can do...if "they" want into your program they will get into it UNLESS it is on a protected/secure/trusted network.

[John E]

In any case, if someone was determined enough, it wouldn't be too difficult to write a program that dumps the entire contents of memory into a file. Using such an app, they could dump the current RAM contents immediately after boot-up, then load your program, then do another dump. Comparing the two would tell them whereabouts your program was located and they could probably reverse engineer it from there (if they were determined enough).

The best you can ever hope for is to deter casual hackers. You can never protect yourself from a determined hacker.

[Vanaj]

I did read somewhere that about 90% of crackers give up after 30 minutes and move on to something else.