Obfuscate Assembler (Remove Function Calls, Unroll Loops)

[Frederick Gotham]

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]

https://en.wikipedia.org/wiki/AARD_code


- Alf

[Öö Tiib]

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]

"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]

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.

[Mr Flibble]

If you look up the word "obfuscation" in a thesaurus will you find that it is a synonym for the word "futile". You. Are. Doing. It. Wrong.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[Scott Lurndal]

Until you run it under QEMU and get a full instruction/register trace.

[Frederick Gotham]

"Obfustication like this does not work"

I have been reading articles about binary obfuscation, e.g. presentations at Defcon. My own form of obfuscation goes way further than anything else I've ever seen.

If the Iranian government were to pay four hackers $120,000 each per year to figure out what my program is doing, I think they'd take about 5 or 6 weeks.

Even if you were to give me the output of my own program, and then ask me to determine the state my program was in when it give that output, I think I would spend maybe 4-8 hours writing the program to do so.

I think it would take the very best programmers-cum-hackers a few weeks to figure my program out.

[Vir Campestris]

Well, if it works ask yourself who is your competition?

It's not a new idea. If it works, someone must be doing it.

Andy

[David Brown]

It will still be difficult to follow there. LTO generally results in a
lot of inlining, including partial inlining - code from all over the
project can get merged together into huge blocks of assembly with no
clear structure. With -O3 you get unrolling, re-arrangement of loops,
function cloning, and more.

Certainly QEMU or similar tools are a big aid to tracing the
functionality of code (and they pretty much neutralise things like code
encryption), but they won't make it an easy job here. Even for more
complex obfuscation techniques, like self-modifying code, extra jumps
added all over, extra dummy code, etc., there are tools available for
picking out the real code flow - though they may be hard to find and
expensive to get.

That is why complex obfuscation is pointless here, but LTO is a simple
and easy way to get block casual inspection of the code.

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 29/11/2019 18:18, Scott Lurndal wrote:
>> David Brown <david...@hesbynett.no> writes:
>>> On 28/11/2019 16:58, Frederick Gotham wrote:
>>>>
>>
>>> Once your LTO-optimised binary is stripped of all extra symbols, it will
>>> be very difficult to follow by examination of the object code.
>>
>> Until you run it under QEMU and get a full instruction/register trace.
>>
>
>It will still be difficult to follow there. LTO generally results in a
>lot of inlining, including partial inlining - code from all over the
>project can get merged together into huge blocks of assembly with no
>clear structure. With -O3 you get unrolling, re-arrangement of loops,
>function cloning, and more.

I spend every day debugging processors that run such code; for which
it is necessary to understand what the code is trying to accomplish,
often without source. Simulation tools and in-circuit emulation can
be quite powerful.