experchange > cpp

Frederick Gotham (11-28-19, 05:58 PM)
I have two programs that I need to obfuscate.

The first one is just two source files and doesn't link with any 3rd party libraries, so I just went through the code line by line and tagged each function with "__attribute__((always_inline))". This worked fine.

The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.

If I take the assembler for my second program, or even the binary executable file in ELF format, then I could manipulate the assembler (or machine code) in order to remove all function calls (and also unroll all loops if possible). Is there a tool for doing this?

I suppose another thing I could do is compile the 3rd party library with some sort of global setting that every function has the attribute "always_inline".
Alf P. Steinbach (11-28-19, 08:47 PM)
On 28.11.2019 16:58, Frederick Gotham wrote:
> I have two programs that I need to obfuscate.
> The first one is just two source files and doesn't link with any 3rd party libraries, so I just went through the code line by line and tagged each function with "__attribute__((always_inline))". This worked fine.
> The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.
> If I take the assembler for my second program, or even the binary executable file in ELF format, then I could manipulate the assembler (or machine code) in order to remove all function calls (and also unroll all loops if possible). Is there a tool for doing this?
> I suppose another thing I could do is compile the 3rd party library with some sort of global setting that every function has the attribute "always_inline".




- Alf
Öö Tiib (11-28-19, 09:19 PM)
On Thursday, 28 November 2019 17:59:10 UTC+2, Frederick Gotham wrote:
> The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.


Obfuscation won't hide that you use General Public License
library in your closed source product. If anyone cares then
they wait a bit and then suggest the copyright holders to sue you
with license agreement violation.
Frederick Gotham (11-28-19, 11:10 PM)
"Obfuscation won't hide that you use General Public License library in your closed source product. If anyone cares then they wait a bit and then suggest the copyright holders to sue you with license agreement violation."

I'm not.
David Brown (11-29-19, 12:21 PM)
On 28/11/2019 16:58, Frederick Gotham wrote:
[..]
> I suppose another thing I could do is compile the 3rd party library
> with some sort of global setting that every function has the
> attribute "always_inline".


Obfustication like this does not work. If people have enough reason to
want to know what your program does, they will find out. It will take
them more time and effort, but they will manage it if they want.

But if you simply want to make it harder for casual hackers to know what
is going on in the code, don't mess around manually like this. Use
link-time optimisation, and -O3 optimisation. You might also like to
play with some of the parameters to encourage more inlining, cloning,
merging, etc. There are also a few more experimental code optimisation
options, or ones that change the language semantics, which can be
enabled explicitly (see the gcc documentation for details). And some,
like the "align" options, you might want to explicitly disable to make
code harder to follow.

The compiler can do a far better job of inlining, code-reordering,
unrolling, etc., than you can hope to manage.

Once your LTO-optimised binary is stripped of all extra symbols, it will
be very difficult to follow by examination of the object code.
Similar Threads