Re: obfuscatorS & decompilers

For someone who is just getting into this side of things and has a small
budget what is the best way to protect my exe and dll's at this time?

Thanks for the information

"Valery Pryamikov" wrote:

> Hi Dominick,
> from what I've read about demeanor .net - it's just doing metadata
> obfuscation plus simple context flow graph obfuscation (like simple loops
> unrolling and similar). However it is possible to achieve protection even
> against determined attackers (in a different way than in cryptography) by
> using more advanced techniques of obfuscation such as Wang's control flow
> flattening, several advanced techniques due to Collberg's/Thomborson such as
> opaque predicates and my call tree flattening scheme. Here I first of all
> talk about very strong protection against automatic deobfuscation tools +
> making it very difficult for manual and semiautomatic analyze. Main is to
> remove economic initiative of breaking the scheme. If attacker would need to
> spend 10 times as much time breaking obfuscation scheme as the same attacker
> would need for independent development of functional equivalent - then any
> initiative of breaking the scheme is gone.
>
> If you check my sample that I mentioned in my previous post - you'll see
> that application of call tree flattening technique only (without any
> obfuscation of variable names whatsoever) makes it very difficult to analyze
> even a most trivial program (even if you are the wizard of the debugging).
> Check calltree.cpp (you can compile it with Visual C++) and try debugging
> it. After that you can compare it to source.cpp (you can compile it with
> Visual C++) and see the difference. Note that is the most trivial
> demonstration of a simpliest aspect of call tree transformation technique.
> Complete implementation will make it even more (incomparably more)
> difficult.
>
> -Valery.
> http://www.harper.no/valery
>
> "Dominick Baier [DevelopMentor]" <dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> wrote in message news:4580be6316d7d88c7d11b67a57a67@xxxxxxxxxxxxxxxxxxxxx
> > Hello Valery,
> >
> > i heard that people like demeanor .net
> > http://www.wiseowl.com/products/products.aspx
> >
> > reflector is obfuscated with this one...
> >
> > but in general i agree - obfuscation may buy you some time - but if
> > someone really wants your IP then that's no problem.
> >
> > ---------------------------------------
> > Dominick Baier - DevelopMentor
> > http://www.leastprivilege.com
> >
> >> Hi,
> >> Unfortunately, commercially available obfuscators that I've seen
> >> doesn't
> >> seem to provide any value for money they are charging. Their licensed
> >> tecnologoies (like name-induction and similar) is more like a joke or
> >> totally unreasonable hype, but nothing like a real protection. They
> >> are
> >> mostly doing metadata obfuscation and simpliest known types of Control
> >> Flow
> >> Graph obfuscation. None of these would help against a decompiler that
> >> will
> >> also include program profiling techniquies.
> >> There are known types of obfuscation due to Wang, Collberg,
> >> Thomborthon and
> >> others that does provide real protection. There are some techniques
> >> that
> >> provide strong resistance to static and dynamic code analyze. You can
> >> see
> >> most of them in Chritian Collberg's Sandmark, but the latter is only
> >> research product and is only for Java.
> >> A bit more than a month ago I've presented a new obfuscating and copy
> >> protection transformation at the first international converence on
> >> Digital
> >> Rights Management in Sydney.
> >> My paper describing that transformation will be published in
> >> Springer-Verlag's
> >> Lecture Notes on Computer Science series soon. For supporting the
> >> paper, I
> >> hand coded simple demonstration of the principle that could be found
> >> here:
> >> http://www.harper.no/valery/CallTreeTransformation
> >> Note that the only obfuscating transformation applied to the
> >> transformed program is call tree transformation described in the
> >> paper, while as the rest of the code was not obfuscated in any way
> >> (even all the variables are still keeping very descriptive names) and
> >> neither copy protection nor watermarking (that I also suggested in my
> >> paper) was demonstrated by the test program ...
> >>
> >> However even application of minimal obfuscation approach of call tree
> >> shows very strong obfuscation properties. Using a debugger for
> >> learning the program logic would not help much to the attacker even
> >> with minimally transformed program (I'd encourage you to try and see
> >> it yourself).
> >>
> >> Applying the rest of transformations described in the paper together
> >> with other previously known methods of program and data obfuscation
> >> will only enforce resilience and potency of program obfuscation.
> >>
> >> Unlike cryptography that strives for achieving undistinguishability,
> >> obfuscation schemes (that could never achieve undistinguishability in
> >> general) should rely on different measurement of their effectiveness.
> >> I think that ideal obfuscating and copy protection transformation
> >> should ensure that breaking them will be at least as difficult and as
> >> expensive as independent development of a functional equivalent. If we
> >> manage to achieve that - it effectively removes economical initiative
> >> for breaking such schemes.
> >>
> >> Valery.
> >> http://www.harper.no/valery
> >> "Sean" <Sean@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:248431AC-32B3-406A-9F89-FCAAE85B839C@xxxxxxxxxxxxxxxx
> >>
> >>> My concern on about decompilers. I am newly educated about
> >>> obfuscation but
> >>> I
> >>> am curious how common place .Net decompilers are.
> >>> Given that one product I looked as was both I would assume fairly
> >>> common.
> >>>
> >>> Just trying to secure my dll files without spending a ton of money.
> >>>
> >>> Thanks
> >>>
> >
> >
>
>
.

Relevant Pages

  • Re: About jobfuscate
    ... Obfuscators (and also copy protection) are ... Obfuscation is, essentially, weak encryption. ... encryption but leaves a decryption key in the hands of every would-be ... asymmetric ciphers used to encode symmetric session keys for things ...
    (comp.lang.java.programmer)
  • Re: make entire exe private
    ... to reverse engineer IP and the need to put important IP on a server. ... Your IP already has legal protection in the form of copyright and, if you play your cards right, patent protection as well. ... At the very least, you are setting yourself up for a lot of extra work, as _all_ of your testing will need to be done on the obfuscated release of the program, and any anomalous behavior that occurs will require that you not only debug your own code, but that of the obfuscation system you're using. ... And of course, no matter what you do, there's always a chance that some serious bug will be induced by the obfuscation system that isn't noted until the program's been released and is in use by the customer. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.framework)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.general)
  • Re: Copy protection for a .NET application
    ... cracking is just as simple on x86 code as it is with IL. ... obfuscation which is a big problem with the idea in general. ... > across .NET Framework Service packs. ... > environments protection is not strongly needed. ...
    (microsoft.public.dotnet.languages.csharp)