1

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).

Angelo
  • 907
  • 3
  • 16
  • 33
  • Do you want to make it difficult for someone with Wireshark at their disposal? That's a tough ask. – Marcelo Cantos Oct 01 '13 at 11:02
  • 1
    A simple way is to convert your string to hex, [C++ convert string to hexadecimal and vice versa](http://stackoverflow.com/questions/3381614/c-convert-string-to-hexadecimal-and-vice-versa) – cpp Oct 01 '13 at 11:04
  • 1
    Your proposed scheme is pretty weak no matter what encryption scheme you use. The url won't show if someone scans the binary for strings, but anyone who's doing "reverse engineering" worthy of the name will be able to breakpoint at `URLDownloadToFile` and examine its parameters. That being the case, it really doesn't matter what "encryption" you use, you just need to stop the data in the binary catching the eye as a URL. base64 encode it or something. – Steve Jessop Oct 01 '13 at 11:05
  • Maybe explain what your app is going to do, then maybe someone will help you secure it better. – marcinj Oct 01 '13 at 11:09
  • What vector of attach are you trying to cover? In the worst case he can redirect all traffic and watch for DNS requests. This way he can easily catch the URL. – RedX Oct 01 '13 at 11:17
  • Thank you all for your comments, and you're right about the weakness of my idea. as @marcin_j said, I'll explain what my application does in an edit. – Angelo Oct 01 '13 at 11:57
  • @MarceloCantos Your answer is very useful but, if you want, read my edit for more informations! I don't know, effectively, if I'm asking for the impossible. – Angelo Oct 01 '13 at 12:07
  • I was reading about [DGA](http://en.wikipedia.org/wiki/Domain_generation_algorithm). It is far from my capabilites! – Angelo Oct 01 '13 at 14:36

2 Answers2

5

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?
Marcelo Cantos
  • 181,030
  • 38
  • 327
  • 365
  • 1
    Don't know about panacea, but there are upcoming solutions that could allow a pretty decent in-app security - http://theinvisiblethings.blogspot.co.il/2013/08/thoughts-on-intels-upcoming-software.html – Leeor Oct 01 '13 at 11:35
  • I don't know exactly what kind of scenarios Intel is targeting with SGX, but absolutely anything can be emulated, so I don't see how it can possibly solve the hide-my-url problem. – Marcelo Cantos Oct 01 '13 at 11:40
  • 1
    @MarceloCantos: hiding a URL from the person running the code is isomorphic to DRM, at least until the point where you send the URL out over the network. So SGX (and for that matter TPM, which already exists) presumably could help, *if* you decoded the URL via an existing DRM framework based on SGX. Emulation would not break that (since the emulator couldn't get into the DRM), but you'd still have some work to do to actually use the URL without leaking it. And of course the question is about having the URL in the binary... – Steve Jessop Oct 01 '13 at 14:27
  • @SteveJessop: Good point; I hadn't thought of the DRM semantic. – Marcelo Cantos Oct 02 '13 at 11:46
0

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.

djgandy
  • 1,125
  • 6
  • 15