CODEWITHSUNDEEP
c++stringurlencryption
Angelo
Angelo

Reputation: 937

What is the best way to encrypt hardcoded strings in C++?

Warning: C++ noob

I've read multiple posts on StackOverflow about string encryption. By the way, they don't answer my doubts. I must insert one or two hardcoded strings in my code but I would like to make it difficult to read in plain text when debugging/reverse engineering. That's not all: my strings are URLs, so a simple packet analyzer (Wireshark) can read it. I've said difficult because I know that, when the code runs, the string is somewhere (in RAM?) decrypted as plain text and somebody can read it. So, assuming that is not possible to completely secure my string, what is the best way of encrypting/decrypting it in C++? I was thinking of something like this:

//I've omitted all the #include and main stuff of course...
string encryptedUrl = "Ajdu67gGHhbh34590Hb6vfu6gu" //Encrypted url with some known algorithm
URLDownloadToFile(NULL, encryptedUrl.decrypt(), C:\temp.txt, 0, NULL);

What about packet analyzing? I'm sure there's no way to hide the URL but maybe I'm missing something? Thank you and sorry for my worst english!

Edit 1: What my application does?

It's a simple login script. My application downloads a text file from an URL. This file contains an encrypted string that is read using fstream library. The string is then decrypted and used to login on another site. It is very weak, because there's no database, no salt, no hashing. My achievement is to ensure that neither the url nor the login string are "easy" to read from a static analisys of the binary, and possibly as hard as possible with a dynamic analysis (debugging, revers engineering, etc).

Upvotes: 1

Views: 3899

Answers (2)

djgandy
djgandy

Reputation: 1135

Try XorSTR [1, 2]. It's what I used to use when trying to hamper static analysis. Most results will come from game cheat forums, there is an html generator too.

However as others have mentioned, getting the strings is still easy for anyone who puts a breakpoint on URLDownloadToFile. However, you will have made their life a bit harder if they are trying to do static analysis.

I am not sure what your URL's do, and what your goal is in all this, but XorStr + anti-debug + packing the binary will stop most amateurs from reverse engineering your application.

Upvotes: 0

Marcelo Cantos
Marcelo Cantos

Reputation: 185852

If you want to stymie packet inspectors, the bare minimum requirement is to use https with a hard-coded server certificate baked into your app.

There is no panacea for encrypting in-app content. A determined hacker with the right skills will get at the plain url, no matter what you do. The best you can hope for is to make it difficult enough that most people will just give up. The way to achieve this is to implement multiple diverse obfuscation and tripwire techniques. Including, but not limited to:

  1. Store parts of the encrypted url and the password (preferably a one-time key) in different locations and bring them together in code.
  2. Hide the encrypted parts in large strings of randomness that looks indistinguishable from the parts.
  3. Bring the parts together piecemeal. E.g., Concatenate the first and second third of the encrypted url into a single buffer from one initialisation function, concatenate this buffer with the last third in a different unrelated init function, and use the final concatenation in yet another function, all called from different random places in your code.
  4. Detect when the app is running under a debugger and have different functions trash the encrypted contents at different times.
    • Detection should be done at various call sites using different techniques, not by calling a single "DetectDebug" function or testing a global bool, both of which create a single point of attack.
  5. Don't use obvious names, like, "DecryptUrl" for the relevant functions.
  6. Harvest parts of the key from seemingly unrelated, but consistent sources. E.g., read the clock and only use a few of the high bits (high enough that that they won't change for the foreseeable future, but low enough that they're not all zero), or use a random sampling of non-volatile results from initialisation code.

This is just the tip of the iceberg and will only throw novices off the scent. None of it is going to stop, or even significantly slow down, a skillful attacker, who will simply intercept calls to the SSL library using a stealth debugger. You therefore have to ask yourself:

  1. How much is it worth to me to protect this url, and from what kind of attacker?
  2. Can I somehow change the system design so that I don't need to secure the url?

Upvotes: 5

Related Questions