Is there an obfuscator for D that at least renames identifiers? This is because sometimes they leak from various processes and could be potential sources of attack.

It would be a tool that probably just replaces their values with, say their hash + something else and done pre release build. Ideally it would be able to compile with dmd and all in memory or use temp storage without file issues. It can't modify the code directly because then that would be permanent.

On 14/06/18 03:01, DigitalDesigns wrote:
> Is there an obfuscator for D that at least renames identifiers? This is because sometimes they leak from various processes and could be potential sources of attack.
> 
> It would be a tool that probably just replaces their values with, say their hash + something else and done pre release build. Ideally it would be able to compile with dmd and all in memory or use temp storage without file issues. It can't modify the code directly because then that would be permanent.
> 

I highly doubt it.

You see, with introspection and run-time execution, writing such a tool is equivalent to solving the halting problem. You simply do not know what you're affecting.

There are some cases where you might know at x% certainty that it's okay to rename. Someone might do a best-effort based tool. I'm not aware of one.


With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form.

Shachar

1- One notable exception is complex algorithmic code. I will point out that those are difficult to figure out from source code too, and it usually takes very good documentation to be able to do so, so even there I'm not sure my original statement doesn't hold.

On Thursday, 14 June 2018 at 00:01:31 UTC, DigitalDesigns wrote:
> Is there an obfuscator for D that at least renames identifiers? This is because sometimes they leak from various processes and could be potential sources of attack.

Yes, DustMite has an obfuscation mode.

You will need to give it a test command which checks if the file is still a working D program. Building the program and running its unit tests is generally sufficient for this purpose.

On Thursday, 14 June 2018 at 00:01:31 UTC, DigitalDesigns wrote:
> Is there an obfuscator for D that at least renames identifiers? This is because sometimes they leak from various processes and could be potential sources of attack.
>
> It would be a tool that probably just replaces their values with, say their hash + something else and done pre release build. Ideally it would be able to compile with dmd and all in memory or use temp storage without file issues. It can't modify the code directly because then that would be permanent.

I don't know any specifically for D but these C/C++ tools might help as a starting point.

https://github.com/obfuscator-llvm/obfuscator/wiki
https://github.com/obfuscator-llvm/obfuscator/tree/llvm-4.0

https://sourceforge.net/projects/cshroud/

On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote:
> On 14/06/18 03:01, DigitalDesigns wrote:
>> Is there an obfuscator for D that at least renames identifiers? This is because sometimes they leak from various processes and could be potential sources of attack.
>> 
>> It would be a tool that probably just replaces their values with, say their hash + something else and done pre release build. Ideally it would be able to compile with dmd and all in memory or use temp storage without file issues. It can't modify the code directly because then that would be permanent.
>> 
>
> I highly doubt it.
>
> You see, with introspection and run-time execution, writing such a tool is equivalent to solving the halting problem. You simply do not know what you're affecting.
>
> There are some cases where you might know at x% certainty that it's okay to rename. Someone might do a best-effort based tool. I'm not aware of one.
>
>
> With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form.
>
> Shachar
>
> 1- One notable exception is complex algorithmic code. I will point out that those are difficult to figure out from source code too, and it usually takes very good documentation to be able to do so, so even there I'm not sure my original statement doesn't hold.


Just one question! Are you kidding me?

On Thursday, 14 June 2018 at 05:21:03 UTC, DigitalDesigns wrote:
>
> Just one question! Are you kidding me?

He most certainly is not.

Infact I prefer size-optimized machinecode over source sometimes.

Because
it is a trustworthy representation of what the program does.

Rather then being a half-truth about what it should do.

On 14/06/18 08:21, DigitalDesigns wrote:
> On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote:
>> With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form.
>>
>> Shachar
> 
> 
> Just one question! Are you kidding me?

First of all, run your program under strace. For a surprising percentage of the programs that should give you a fairly good idea of what the program is doing. ltrace goes further, but it can be easily defeated by statically linking, so probably irrelevant for our current discussion.

Next, try loading your program in Ida Pro (https://www.hex-rays.com/products/ida/index.shtml). You will notice that program flow practically jumps out at you with no further work on your part.

Other tricks require a little more knowledge, but are still exceedingly effective.

In a demonstration I saw in 2002, Halvar Flake showed how he uses Ida to graph the branches, and then use a tool he built to place breakpoints on the branch points. Next he started feeding inputs to the program, and colored the graph where the input sent the code. He used that to find the correct input that would bring the code path to the line he thought might be vulnerable.

If I had to do this trick today for *my own* programs, I'd still use Ida and the compiled code.

So, no, I was not kidding. Not even close.

Shachar

On Thursday, 14 June 2018 at 08:54:16 UTC, Shachar Shemesh wrote:
> On 14/06/18 08:21, DigitalDesigns wrote:
>> On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote:
>>> With that said, what you're trying to achieve is probably not a good idea anyways. With very few exceptions(1), reverse-engineering code to figure out what it does is not considerably more difficult than using the source, even when none of the identifiers leak at all. Certain aspects of creating attacks are even easier with good rev-eng tools than in source form.
>>>
>>> Shachar
>> 
>> 
>> Just one question! Are you kidding me?
>
> First of all, run your program under strace. For a surprising percentage of the programs that should give you a fairly good idea of what the program is doing. ltrace goes further, but it can be easily defeated by statically linking, so probably irrelevant for our current discussion.
>
> Next, try loading your program in Ida Pro (https://www.hex-rays.com/products/ida/index.shtml). You will notice that program flow practically jumps out at you with no further work on your part.
>
> Other tricks require a little more knowledge, but are still exceedingly effective.
>
> In a demonstration I saw in 2002, Halvar Flake showed how he uses Ida to graph the branches, and then use a tool he built to place breakpoints on the branch points. Next he started feeding inputs to the program, and colored the graph where the input sent the code. He used that to find the correct input that would bring the code path to the line he thought might be vulnerable.
>
> If I had to do this trick today for *my own* programs, I'd still use Ida and the compiled code.
>
> So, no, I was not kidding. Not even close.
>
> Shachar

Wait? Are you sure you are not kidding? Do you want another shot?

On 14/06/18 13:39, DigitalDesigns wrote:
> 
> Wait? Are you sure you are not kidding? Do you want another shot?

No, I'm fine. Thank you. I am not out here to convert anyone. If you want to believe the magic of obfuscation, go right ahead.

You can probably even leverage D's CTFE to do it inside the compiler while not making your program too much uglier. Something like replacing definitions with:

mixin Obfuscate!(int, "variableName");

and use with:

Deobfuscate!"variableName";

Shouldn't be too difficult to create.

Shachar

On Thursday, 14 June 2018 at 11:07:17 UTC, Shachar Shemesh wrote:
> On 14/06/18 13:39, DigitalDesigns wrote:
>> 
>> Wait? Are you sure you are not kidding? Do you want another shot?
>
> No, I'm fine. Thank you. I am not out here to convert anyone. If you want to believe the magic of obfuscation, go right ahead.

Dude, don't be an idiot! Please! Of course, here we go...

> You can probably even leverage D's CTFE to do it inside the compiler while not making your program too much uglier. Something like replacing definitions with:
>
> mixin Obfuscate!(int, "variableName");
>
> and use with:
>
> Deobfuscate!"variableName";
>
> Shouldn't be too difficult to create.
>

That's the best you can do? Do you really expect me to go and manually obfuscate an entire program? Do you want to try again? 3 strikes and your out!