-1

Is it possible to encrypt a .exe file such that users are only allowed to execute the file but are not allowed to read or open the file?

I know that C/C++ exe files are hard to decompile but for additional security I want to implement this.

Is this possible.

Please let me know if you need any more details about my requirements.

I would like to use C language to implement this.

share75
  • 69
  • 1
  • 10
  • 2
    To run the program, your computer would need to decrypt the file first; if your computer can decrypt it, so can any user. And "I know that C/C++ exe files are already encrypted" - they are not. – Amadan Apr 11 '16 at 04:52
  • 3
    C/C++ exe files are not encrypted. – Harry Apr 11 '16 at 04:53
  • Sorry for the confusion, I mean to say that they are already in unreadable form which is hard to decompile to get the source code. – share75 just now edit. Please correct me if I am wrong – share75 Apr 11 '16 at 05:23
  • They're readable enough for a machine to run then they're readable enough a caffeine-amped reverse-engineer to send through a disassembler and begin reconstruction. One can, however, make it more difficult. – WhozCraig Apr 11 '16 at 05:28
  • @WhozCraig so is it possible to encrypt in such a way that the user cannot read it but be able to execute it. – share75 Apr 11 '16 at 05:33
  • Not really, honestly you can only make it harder (sometimes very much so if you *really* know what you're doing). – WhozCraig Apr 11 '16 at 05:36
  • @WhozCraig Thanks for your quick response. Actually my ultimate goal is to hide the code from the user but allow hime to execute it. Instead of encryption is there any other technique which can applied to achieve this. – share75 Apr 11 '16 at 05:51

1 Answers1

3

Yes it is possible in the loosest sense.

In order to execute the code, the CPU needs to see the plain text. So you have to provide the key in the binary. The only remotely effective way of encrypting and packing code segments is if you encrypt and decrypt them at functional boundaries and only if the decryption happens upon function entry and then re-encryption happens when leaving the function. This will provide a small barrier against dumping your binary as it is running but is must be coupled with strong obfuscation, this is a very common technique and frankly tricks a lot of novice reversers who are used to the standard scheme of packed executable or "stub" encryption schemes.

When you hide information it is important that the information is well hidden at runtime as well. A competent reverse engineer will examine the state of your program as it is running. So using static variables that decrypt when loaded or by using packing which is completely unpacked upon loading will lead to a quick find. Be careful about what you allocate on the heap. All heap operations go via API calls and can be easily logged to a file and reasoned about. Stack operations are generally harder to keep track of just because of how frequent they are. Dynamic analysis is just as important as static. You need to be aware of what your program state is at all times and what information lies where.

It sounds like your goal is to protect your executable and to that end your more immediate goal should be to ensure that it is virtually impossible for the reverse engineer to find a steady mental footing. The less information you leak and the more changing the environment is, the harder it will be to study. If you're not an experienced reverse engineer, designing something hard to reverse engineer is almost impossible.

zetavolt
  • 2,989
  • 1
  • 23
  • 33