encrypt C++ code

hi guys, how can I encrypt the C++ code?

when I use olly dbg or a simple hex editor, the program has the strings displayed, how can I prevent this from happening?

thank you in advance

I am not sure why you would want to do that.

Yet, theoretically, I suppose that you could write an encryption/decryption algorithm. Before compiling, you'd run all your strings through it and get "encrypted strings". After that, you would need to decrypt all strings in order to use them. Yet, if it is a simple one, it will most likely easily be broken, since it isn't that hard to step through the decryption process in a debugger/disassembler.

So, just "hypothetically", assume that you have a string "Hello!" that turns into "ar11z#" after it's been encrypted. You'd have to run the decryption function at run-time and get the resulting string, "Hello!", but the string you'd effectively "write" in C(++) code would be "ar11z#", probably with a nice comment saying what it is -- But it really would be in memory, then.

Quote:

---

Originally Posted by Jorl17

I am not sure why you would want to do that.

Yet, theoretically, I suppose that you could write an encryption/decryption algorithm. Before compiling, you'd run all your strings through it and get "encrypted strings". After that, you would need to decrypt all strings in order to use them. Yet, if it is a simple one, it will most likely easily be broken, since it isn't that hard to step through the decryption process in a debugger/disassembler.

So, just "hypothetically", assume that you have a string "Hello!" that turns into "ar11z#" after it's been encrypted. You'd have to run the decryption function at run-time and get the resulting string, "Hello!", but the string you'd effectively "write" in C(++) code would be "ar11z#", probably with a nice comment saying what it is -- But really would be in memory, then.

---

thank you, I will be doing this

Even if you XOR or encrypt the strings in your executable, they'll have to be loaded into memory decrypted at some point during runtime and then they'll be visible again.

I have found that adding strings as resources to the exe often stores them in a different format. However, doing this hard-codes your strings into your app which isn't bad for localization and other such items so it depends on what you want to do. Not sure why you would care honestly. Just remember not to store passwords or other items in string format b/c someone can easily see these inside of a hex editor or especially inside of Olly when you search for all referenced text strings. The best way to store passwords is to let the user input it, hash it with some algorithm, and then store the hash. The same is true for login - allow the user to input the password, hash it, and check against all stored hashes.

Most obfuscators provide this feature. Unfortunately most of the obfuscators I'm familiar with are for C# or Java. I'm not wholly sure how this is done, but it's quite interesting to look into.

Quote:

---

Unfortunately most of the obfuscators I'm familiar with are for C# or Java.

---

Um...probably b/c C# code is compiled to MSIL which can then be reverse engineered back to C# byte for byte. C# code that is compiled to native machine code cannot be reverse engineered but also loses the benefits of the size reduction of the final EXE. Essentially all of .NET will need to be linked to by the EXE so the EXE will be huge. Normally linking in C# is done quite differently but the downside is that pretty much anyone can read your code. You would never release your assemblies in C# without somehow obfuscating them.

That statement was only pointing out that I have no familiarity with C/C++ obfuscators. I would assume most of the techniques for bytecode languages and native-binary compilation languages are similar.

Quote:

---

Originally Posted by Bubba

I have found that adding strings as resources to the exe often stores them in a different format. However, doing this hard-codes your strings into your app which isn't bad for localization and other such items so it depends on what you want to do. Not sure why you would care honestly. Just remember not to store passwords or other items in string format b/c someone can easily see these inside of a hex editor or especially inside of Olly when you search for all referenced text strings. The best way to store passwords is to let the user input it, hash it with some algorithm, and then store the hash. The same is true for login - allow the user to input the password, hash it, and check against all stored hashes.

---

thanks the app has something to do with passwords etc thats why i was asking

Quote:

---

Originally Posted by nik2

thanks the app has something to do with passwords etc thats why i was asking

---

As in you are trying to write say, a program for secure storage of the user's passwords? If so, you only need to encrypt the passwords, not the program. The user would supply the secret key (or a passphrase from which the secret key is derived) on demand to recover the passwords.

Quote:

---

Originally Posted by nik2

thanks the app has something to do with passwords etc thats why i was asking

---

You could use a secure hash function to reduce the passwords to "encrypted" chunks (and compare these chunks, bit for bit, to validate). The hash function must be chosen carefully, of course!

Who exactly are you trying to defend against?

"kid in a bedroom with basically no skills"
"No Such Agency with more time and money than you can imagine"

Sooner or later, the password will be revealed by running the program and watching what happens (either internally in memory, or externally through it's interfaces).
As soon as that happens, the jig is up.

are they credentials for logging into a database? i see this all the time in webapps.

in fact, except for a few other minor precautionary measures, i don't think there's a way around that