URGENT: How can I avoid my SOURCE CODE from DECOMPILERS like Anakrino9??

  • Thread starter Thread starter chang cocho
  • Start date Start date
C

chang cocho

I'm scare because using Anakrino9 I was able to DECOMPILE my PROJECT. I have
been working on it for a year now and it's too unfair that anybody out threr
will be able to DECOMPILE my APP

what can I do???

Thanks
 
I'm scare because using Anakrino9 I was able to DECOMPILE my PROJECT. I
have
been working on it for a year now and it's too unfair that anybody out threr
will be able to DECOMPILE my APP

what can I do???


Do you know what also is unfair? Crossposting is.

Obfuscation tools cannot fully protect your App since they only rename
private members, nothing more. The sources still can be fully reproduced by
Decompilers. Additionally there can be lots of problems arising from
Obfuscation: if you are using Reflection or Invoking a class/method by its
name it doesn't work. Also for example I've head of scenarios where VS.NET
is unable to load an obfuscated dll.
 
I'm scare because using Anakrino9 I was able to DECOMPILE my PROJECT. I
have


Do you know what also is unfair? Crossposting is.

Obfuscation tools cannot fully protect your App since they only rename
private members, nothing more. The sources still can be fully reproduced
by
Decompilers. Additionally there can be lots of problems arising from
Obfuscation: if you are using Reflection or Invoking a class/method by its
name it doesn't work. Also for example I've head of scenarios where VS.NET
is unable to load an obfuscated dll.

Sure, weak obfuscators still allow decompilation into C# or so. Better ones
will have the option to change code around so that it's not possible to
decompile it.

-mike
MVP
 
Obfuscation tools cannot fully protect your App since they only rename
Sure, weak obfuscators still allow decompilation into C# or so. Better ones
will have the option to change code around so that it's not possible to
decompile it.


How will you "change code around" so that is doesn't recompile? The clr
still need to be able to execute it so it can also be decompiled.
Sure you can rely on the inability of certain decompiler not to recognize
some patterns that aren't commonly used by compilers but they will be able
to recognize it in their next version maybe.
 
IL code doesn't necessary translate to legal C# source code.

This is no article it is just an advertisement which tries to stress the
advantages of obfuscating while trying to hide the disadvantages.
Also I didn't found anything in the "article" which says about decompilers
producing illegal code from an obfuscated assembly.
Substituting a loop which a number of goto's is no illegal code, it is a bit
harder to understand but a lot easier than plain assembly code.

And I don't know what the point of encrypting string literals is, since you
can easily attach a debugger and see where the control flow goes if you
press the register button and the license key is yours.

"Obfuscators remove debug information and non-essential metadata from a file
as they process it. "

I shuddered on this sentence. How can they know what is non-essential for my
app?

"Obfuscation puts the reverse engineering bar back to or above where it was
before the days of intermediate language "

Plain stupid claim. Even reading obfuscated plain msil is a lot easier than
reading assember code. You can see all variables in the decompiled code,
in assembly you see just register.

Obfuscating cannot rename public or protected members since they are part of
the api, additionally renaming fields destroys you app if you using relying
in any part of your app.

<humour>
However, if somebody is really interested in obfuscating his code see
www.ioccc.org. Some of the techniques valid in C may be also useful in C#..
</humour>
 
Back
Top