Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70084 > unrolled thread

Obfuscate Assembler (Remove Function Calls, Unroll Loops)

Back to article view | Back to comp.lang.c++

Contents

  Obfuscate Assembler (Remove Function Calls, Unroll Loops) Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-28 07:58 -0800
    Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-28 19:47 +0100
    Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) Öö Tiib <ootiib@hot.ee> - 2019-11-28 11:19 -0800
      Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-28 13:10 -0800
    Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) David Brown <david.brown@hesbynett.no> - 2019-11-29 11:21 +0100
      Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) scott@slp53.sl.home (Scott Lurndal) - 2019-11-29 17:18 +0000
        Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) David Brown <david.brown@hesbynett.no> - 2019-11-30 12:00 +0100
          Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) scott@slp53.sl.home (Scott Lurndal) - 2019-11-30 19:03 +0000
      Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-29 10:58 -0800
        Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) Vir Campestris <vir.campestris@invalid.invalid> - 2019-11-29 21:19 +0000
    Re: Obfuscate Assembler (Remove Function Calls, Unroll Loops) Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-29 16:43 +0000

#70084 — Obfuscate Assembler (Remove Function Calls, Unroll Loops)

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

[toc] | [next] | [standalone]

#70085

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

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


- Alf

[toc] | [prev] | [next] | [standalone]

#70086

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.

[toc] | [prev] | [next] | [standalone]

#70093

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

[toc] | [prev] | [next] | [standalone]

#70146

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

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.

[toc] | [prev] | [next] | [standalone]

#70152

David Brown <david.brown@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.

[toc] | [prev] | [next] | [standalone]

#70169

On 29/11/2019 18:18, Scott Lurndal wrote:
> David Brown <david.brown@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.

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.

[toc] | [prev] | [next] | [standalone]

#70181

David Brown <david.brown@hesbynett.no> writes:
>On 29/11/2019 18:18, Scott Lurndal wrote:
>> David Brown <david.brown@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.

[toc] | [prev] | [next] | [standalone]

#70154

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

[toc] | [prev] | [next] | [standalone]

#70157

On 29/11/2019 18:58, Frederick Gotham wrote:
> "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.
> 

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

[toc] | [prev] | [next] | [standalone]

#70151

On 28/11/2019 15: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".

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web