C++ code obfuscation for static LIB

Question

Basically I have this…

I have created a WPF application. It references a C++/CLI wrapper to a native static LIB.

Now the static LIB has commercially sensitive algorithms.

The code for the static LIB is small and simple.

As it stands someone could decompile the LIB with Ada Pro / Hex-Rays and work out the algorithms easily. What I was wondering was if I could obfuscate the source code then the decompiled LIB would have additional complexity.

What I would like is some way of making what is a fairly small and straight-forward code base obfuscated enough to make it difficult to work out the algorithm from the de-compilation.

Two things. Firstly, I understand that this will not prevent someone from discovering the algorithm. I just want to increase the costs of doing so in terms of time and money. Secondly, I am not actually worried too much about the code itself, it is just the algorithm I want to hide.

I ask here because, a google search gives a lot about obfuscation but says little for this particular case when the codebase is small and simple. Is there are alternative approach that I have overlooked?

Additionally. I am not concerned with obfuscating the managed code.

"small and simple" and "commercially sensitive algorithms" at the same time? — , Jul 14 '17 at 23:09
The code is small and simple...the algorithm is non-obvious. — user3079907, Jul 14 '17 at 23:10
Probably not. You still have to do the same things in more-or-less the same order. An optimizing compiler is going to take your obfuscated code strip off all of the markers and bizzarro naming you use and run it through a through a blender on it's way to producing the fastest/smallest/ whatever you're optimizing for executable code it can. In theory, by the time it's done the screwball monkey wrenches you threw into readability are going to be mostly gone. — user4581301, Jul 14 '17 at 23:11
Yes, I see your point. I was wondering if there is any tool that would increase the complexity of the code e.g. scrambled the code, broke functions up, introduced loops, function calls etc...just to confuse things. — user3079907, Jul 14 '17 at 23:16
You may find some good suggestions in this question: https://stackoverflow.com/questions/6481668/protecting-executable-from-reverse-engineering And some of the answers. — user4581301, Jul 14 '17 at 23:26
Thanks...With a quick read of the link, one thing jumps out. Someone says that obfuscation by adding padding code can be easily stripped e.g. it is easy to identify meaningless code. He says that the only way padding code will be effective if somehow the original code is dependent upon the padding code. I suspect this would be tricky for a commercial obfuscator but I may be wrong....it would be possible to do manually but this would be a real pain to maintain and debug. — user3079907, Jul 14 '17 at 23:44
I may be wrong. But I don't want to obfuscate the managed code. The static LIB is written in C++ and is not CLR dependent. — user3079907, Jul 14 '17 at 23:45
The source language of an executable is of no concern, once the code is converted to an executable, the source code information is lost. An executable could be written in FORTRAN or compiled BASIC. The method for reverse engineering your library is to figure out what the assembly language is performing, then rewrite in a high level language. — Thomas Matthews, Jul 15 '17 at 00:40
One idea is to encrypt the library. Before you use a function in the library, decrypt the library (or function) into memory, then execute, then clear the memory. You could also develop an interpreter that will decrypt your functions then execute them (or decrypt processor instructions then execute them). — Thomas Matthews, Jul 15 '17 at 00:42
@Thomas Mathews, I think some obfuscators work on the compiled executable. I am not clear how this works though. However, what I was really thinking was that if you could increase the complexity of the source code e.g. the logical complexity with dummy code insertions, splitting existing functions, jumping back and forth through source code that had a horrible spaghetti structure, the complied binary would be horribly complex too. This would increase the workload once the binary was decompiled. Essentially, spaghetti C++ source code, compiled then decompiled will be spaghetti assembler. — user3079907, Jul 15 '17 at 01:05
@Thomas Mathews. I found this link. https://breakdev.org/obfusion-c-x86-code-obfuscation-library/ it works on X86 machine code in order to increase it complexity. Not sure if it can work on 64 bit builds. — user3079907, Jul 15 '17 at 01:24
Spaghetti code does not obfuscate the compiled code (executable); it only makes your code harder to debug, write and get working. If I want to reverse engineer your code, I will disassemble it, then develop flow charts and probably rewrite it in a high level language. Encryption will delay people from reverse engineering your code longer than spaghetti code. — Thomas Matthews, Jul 15 '17 at 17:59
@ThomasMatthews When you encrypt the lib, you need to have a decryption key. And that decryption key must be resident in memory while the lib is being loaded. Thus, cracking becomes as simple as identifying the decryption key within the running process's memory. Any cracker will quickly recognize the code structures of common encryption algorithms, and start searching for the key. And it's really hard to hide a well-defined 32 bytes that needs to be fed into a well-defined function so that people won't find them. — cmaster - reinstate monica, Aug 01 '18 at 18:59
@user3079907 You are looking for executable obfuscation, not for source code obfuscation. The source code language is irrelevant for this. — cmaster - reinstate monica, Aug 01 '18 at 19:01

score 1 · Answer 1 · answered Aug 01 '18 at 18:26

Here are several things you can do which may decrease the chances of a 3rd party to find out what your library does, how it works, sensitive strings and so on.