Re: Copy protection for a .NET application

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 12/02/04 

Date: Thu, 2 Dec 2004 09:50:24 -0500

Are you talking hacking/cracking or getting the code posted at the code
project? They are different.
Actually, cracking is just as simple on x86 code as it is with IL. That is
because crackers live in debuggers and asm anyway. From that perspective
obfuscated IL is harder for them as you add obfuscation and is different
then what they are used to. So you will be able hack any app that lives on
a w/r medium. But can you understand it is the other another problem and
the one you want to control as well as possible. I really like Xeno code.
Is a fair price and works really well. With conservitive settings and
control flow obfus, and ILDasm breaking turned on is great. Can not use std
ILdasm to round trip, can not understand from Reflector or others and can
not reverse it. Saying "can not" is misleading. As everything is
possible - right? I mean you would eventually find your RSA private key
with a brute force attack too. So how hard is it is the key. Even with a
good obfuscator you have to balance protection level as if you do to much
you start breaking things. You still need to test whole app again after
obfuscation which is a big problem with the idea in general. 

-- 
William Stacey, MVP
http://mvp.support.microsoft.com
"Marco van Nieuwenhoven" <MarcovanNieuwenhoven@discussions.microsoft.com>
wrote in message news:020300AF-B4CA-4696-95D3-F453D9AFFC39@microsoft.com...
> "Jon Skeet [C# MVP]" wrote:
> > Marco van Nieuwenhoven <MarcovanNieuwenhoven@discussions.microsoft.com>
> > wrote:
> > > I'm working with C# now for the last months and just discovered that
> > > obfuscating is not enough. My sourcecode is not considered safe
anymore
> > > because it can now be easily decoded with products like Remotesoft's
software.
> >
> > But can it actually be *understood*?
>
> I think the code can still be understood because the calls to the .net
> framework are still understood and there you can fiddle out the function
of a
> function :-) When getting a message of a customer that a crash has
occurred
> this will also cause you a problem as well. You will then not be able to
> understand what went wrong.
>
> > > How can I protect myself? An answer could be using the protector
software
> > > from Remotesoftware but how sure can I be that this is also not
breakable.
> > > What is the technique used by Protector and is it considered safe?
> >
> > You'd have to ask RemoteSoft.
>
> I don't think I will get a clean answer from them because this will give
> away a big hint on how to hack their tool. A disadvantage of their
solution
> is also that the solution is: *BeginQuote* This method is not compatible
> across .NET Framework Service packs. For example EXE files created using
.NET
> Framework Service Initial Release do not work with installations of
Service
> Pack 2. Because many users may
> have different installations of the framework installed, this solution
> becomes useful only in very controlled environments - but usually in these
> environments protection is not strongly needed. *EndQuote*
> This is why I am looking for a solution which does not include the IL code
> inside an executable. This will make it more difficult to hack. x86 code
is
> more difficult to read than IL (obfuscated or not)
>
> > > Is it possible in anyway to link my assemblies into native code
without
> > > having to include my IL code. Even obfuscating IL code is not really
safe
> > > because the algorithm is 'easily' breakable.
> >
> > Yes - follow the links I posted before. However, people will still be
> > able to decompile your code. It'll take a bit longer, but it's far from
> > impossible.
>
> I may be a fool but I could not find the reference you told me of.  I
could
> only find the qoute from below. This does confuse me.
> > There *may* be ways of removing the IL from the original assembly after
> > NGENing it, but in a way that fools the framework into using the image
> > from GAC - but I haven't seen anyone writing about that, and you'd need
> > fairly deep knowledge of exactly how the GAC works to try it out. (If
> > the framework checks the hash of the assembly against the original, for
> > instance, you're in trouble unless you can also change the hash that's
> > stored in the native code file.)
>

Relevant Pages

  • 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.framework)
  • 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: copyright issues...help needed...
    ... "intellectual property" is not hugely significant ... is precisely the overarching framework of copyright. ... technical restrictions including a lock to my front door. ... in practice copyright protection and the assorted technical ...
    (uk.religion.christian)