Hello World!
I wrote a c++ program but for security reasons I need to make sure that no one can read my codes by my ".out" files. I did everything I could. But everyone can see it by "strings Alpha.cpp".
I heard that g++ has some options to do so.
Please if anyone can help me hide my contents, reply.

Then don't distribute Alpha.cpp with your a.out file! People don't need access to your source code to run your executables.

If you're asking how to prevent people from reverse-engineering your executables, you're out of luck. The binary code can always be disassembled; the disassembled code can always be analyzed with a debugger. If what you intend to protect is worth protecting, then it's worth someone's time to reverse engineer. That's why you can find keygens for all shareware programs that use registration keys. It's also how the "undocumented" Windows API was discovered.

You definitely want to get a copy of this book, to understand the angles of attack:

http://www.amazon.com/Reversing-Secr...dp/0764574817/

2 members found this post helpful.

I'm writing an encryption system, I need to hide my key, So it's stupid to have my key to spare by my encryptor. Do you have any idea how do I keep a hidden library for my key?

Thanks for answering

It is not that simple. I.e. there are measures making running under a debugger quite problematic, though technically, of course, one can run code through a debugger. The question is how much misleading the debug traces become.

More powerful "guns" than just a debugger might be needed.

I still have no idea what to do, It may be difficult but still it's not impossible. Is there a way to hide my encryption key in another way, other than hard-coding it?

Have a program to generate a key and place it in a text file (that only you have permission read) and use it from there. If your key is symmetric (i.e. you use the same key for both encryption and decryption), you'll need to find a secure way of getting it to whoever you want to be able to encrypt/decrypt data - otherwise, both of you can just use the program to generate your own private+public key pairs and then send the public ones to each other.

1 members found this post helpful.

That's actually a good idea; BTW how do iterate a text file in C++?
Sorry I keep asking questions, I'm a newbie

Yes, you can "hide" it in many ways[*], but it is still easily discovered: Just run your program in a debugger or emulator, stop it just before it starts the encryption, and read the key from the key buffer. The encryption routines are quite easy to find even from disassembly, since they look nothing like ordinary code, so this is not at all that difficult one might think.

You can rewrite the encryption algorithm to not hold the key in a buffer, but that is at least an order of magnitude more difficult -- and even then, the entire encryption code and all data it refers to can be lifted as-is, and used by somebody else.

I don't know if this is feasible for you, since I don't know what you actually do with the key, but I'd recommend a fundamentally different approach: use a public key encryption algorithm. That way encryption and decryption use different keys.

For example, if you wanted to store an unique serial number in your application, you would store two copies of it, encrypted using a public key algorithm, within the code as constants, and use two totally different keys. The decryption keys for the serial numbers would be stored in plain view also. Your program would use the decryption keys to decrypt and verify the serial numbers match. A nefarious user can copy a serial number to another copy of the application, but that would be exactly the same as copying the entire application. They cannot create a fake one, without first obtaining the other halves of the keys -- which are not included in the applications, and are in your possession only. Still, users can just modify the application binary to skip the checks, so even this is not absolutely secure. Nothing is.

Similarly, if you communicate with an another party -- either via the network, or via files, or some other means --, use a different public key in each direction, with each party knowing only half of each key. If you yourself are the other party, and you keep your halves of the keys secure, with each application having their own key pairs, you can easily authenticate each application. (Or, in the case of files, either authenticate the application used to create the files, or note that the authentication bits were removed after saving the file by other means.)

In the end, you'll find out that you must trust the user to a degree. I'd recommend picking the degree such that you don't hinder the users' activities, or they will either break the security, or use another application. Consider what would be acceptable to you yourself, if you were the user of your application.

[*] In the early nineties, I hid a copy of the applications serial number into the relocation data, overwriting another copy of the serial number when the application is loaded into memory. (This was with old-type EXE files that contained their own relocation code; I replaced that with a home-grown one.) Even changing the serial number in the file would not change it, since it was regenerated when the program was loaded into memory. All copies of the application were different at the binary level, so comparing the memory image to the file would be a tedious job.
In short, the trick was to make it more work to disable or hide the serial number, than to rewrite the application from scratch. Normal users were totally unaware of this feature, since it did not hinder their actions in any way.

2 members found this post helpful.