0

I have seen this question and ADVobfuscator git repository. The closest thing I've found is something akin to this repository.

But my problem is that I have a rather large code that uses several system calls and prints lots of messages based on string literals and concatenations thereof. Because of this, many commands get written in the object code, where I'd like them to remain readable with minimal clutter.

Unlike a single password that can be locally encrypted with a OBFUSCATE macro, I'd like to have a global solution, such that every string is obfuscated, without having to place this macro each time, so that my code remains readable for developers and reviewers, while the executable has these strings somewhat obfuscated.

This is not a matter of security, but rather of protection of intellectual property, I just want to avoid having curious end-users reverse engineering my executable in their spare time. I'm not trying to prevent any elaborate attack.

Mefitico
  • 816
  • 1
  • 12
  • 41
  • 2
    *"This is not a matter of security, but rather of protection of intellectual property"* Confidentiality is a branch of security. Protecting intellectual property is a matter of security. – François Andrieux Feb 14 '20 at 20:40
  • 1
    Feels odd seeing "convenient" and "obfuscation" being used together. – user4581301 Feb 14 '20 at 20:50
  • @FrançoisAndrieux : Fair point, but I'm not sure how to reword then. What I mean is that I'm not storing passwords in the code, but rather plain commands. If a few strings were decrypted, I wouldn't care, the problem would be if any user would gather all the strings form the executable and guess-work his way into replacing significant parts of my application, thus rendering the application borderline useless for that user. That, over time, would also help him reverse engineer a lot of stuff. – Mefitico Feb 14 '20 at 20:50
  • "_the problem would be if any user would gather all the strings form the executable and guess-work his way into replacing significant parts of my application_" - If that is a real concern, you are going about solving it the wrong way. Pretend that your obsufcation algorithm is known to the public. It will be in no-time even if you don't want it anyway. You could hash the commands and only store hashes in your executeable to obfuscate it a little, but how do you verify that a user (with ample time to depickle your program) is entitled to use it? – Ted Lyngmo Feb 15 '20 at 00:33
  • @TedLyngmo The software is meant for very limited distribution with perpetual license + yearly support + pay for new/custom features monetization scheme. Because the amount of end-users is small, and they're expected to be busy people, I simply assume there will be none who happens to have the free time and minimal documentation to start a reverse engineering project. What I do want to avoid is having a user with little free time guesswork his way into a lot of important stuff in a manner that is just way too easy to do. – Mefitico Feb 16 '20 at 19:01
  • In this way, I'd expect the end user to have no ideia that there would be encrypted strings in the object code. So I'd be very unlucky if he both found out about this, and found the hashing method and only then started reverse engineering for fun. – Mefitico Feb 16 '20 at 19:03
  • Well, you could use a `constexpr` hash function so that all that is stored in your object files are numbers. `if( hashfunc(user_command) == hashfunc("secret_command") ) ...` "secret_command"` would then be hashed when compiling and no trace of the real command would be found in the object file. – Ted Lyngmo Feb 16 '20 at 19:09
  • @TedLyngmo That would be good for passwords, but what I have is actually a lot of system call commands. Because I do lots of `system("string I don't want in executable");` or `printf("Error message the user might see, but doesn't need to find in the executable");` I can't just use if-else logic based on hash functions. – Mefitico Feb 16 '20 at 19:45
  • Ok, in that case you need encryption, not a one-way hash. – Ted Lyngmo Feb 16 '20 at 20:48
  • Perhaps the easier solution is just to run the executable through one of the .exe-compressor type programs before distributing it. – Jeremy Friesner Feb 21 '20 at 14:09
  • A portable solution is going to be hard. Do you have a specific OS in mind? – MSalters Feb 21 '20 at 14:27
  • I don't think you can get any convenient way unless you use a preprocessing tool to process the strings before every build – phuclv Feb 21 '20 at 15:21
  • @JeremyFriesner: While not perfect, I think UPX did a pretty good job. If you want to add an answer explaining about executable compressors, I'd surely upvote it and probably accept it. – Mefitico Feb 21 '20 at 16:20

1 Answers1

1

One easy(ish) solution is to run your executable file through an executable-compression program like UPX before distributing it. The file-compression should serve to obfuscate any string literals in the resulting executable file.

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
  • you can add UPX as an example to your reply. – Afshin Feb 21 '20 at 19:58
  • i am not familiar with these, but if they are compressing wouldn't it be trivial to decompress ie extract? – bolov Feb 21 '20 at 21:55
  • Yes, fairly trivial -- but the questioner wasn't asking for anything "secure", just for some way to obfuscate plain-text strings enough to discourage amateurs. – Jeremy Friesner Feb 21 '20 at 22:04