Re: Decompiler.NET reverse engineers your CLS compliant code

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: CJ Taylor (cege)
Date: 10/02/04 

Date: Sat, 2 Oct 2004 11:13:37 -0500

That was kinda the point dude. Hence the *very expensive* part...

I have said it before, how much do you think people *actually* care about
your source code...

"Sriram Krishnan" <ksriram@NOSPAMgmx.net> wrote in message
news:OkZrdRHqEHA.2052@TK2MSFTNGP10.phx.gbl...
> Since everyone is in the mood for impractical ideas here,I have one.
>
> For every client that you have,generate a public key and a private key.
Use
> the public key to encrypt the assembly. Now, here comes the really wacky
> idea. Take the Rotor souce code (or pay Microsoft a lot of money to do
this
> for you)..and build your own mscoree/mscorwks/mscorsvr dlls which have the
> private key embedded in them. If you're really paranoid, you can do
> something like Windows Activation and make sure that the CLR works
properly
> only on some hardware hashes.
>
> Now, these runtimes will work normally with normal applications - but
will
> recognize your specially encrypted assembly and decrypt it using the
private
> key. This way, we make sure that every assembly runs *only* in its very
own
> version of the CLR. So when you send customers the assemblies, you send
them
> your custom CLR as well. Yes - this would inflict all sorts of versioning
> conflicts on them - but you can sleep assuredly at night with the
knowledge
> that no one else can get at your code.
>
> You know what the scary part is? That some paranoid person reading this
post
> might actually take this seriously and try it out. And even worse,
somebody
> somewhere will always find a way to get the public key out of our custom
CLR
> and crack your assembly.
>
> --
> Sriram Krishnan
>
> http://www.dotnetjunkies.com/weblog/sriram
>
>
> "CJ Taylor" <cege [ahh ttt] tavayn wooohooo hooo ohhh com> wrote in
message
> news:efyPlv2pEHA.868@TK2MSFTNGP10.phx.gbl...
> > That's not how public keys work. PKI uses a Public Key and Private Key
> > combination. A Public key can encrypt data, while a private key can
> > encrypt
> > and decrypt.
> >
> > It's all done through prime numbers, really really really really really
> > big
> > prime numbers that are added together to make the key pair. Hence the
> > conundrum of PKI that you have half of what you need to crack it,
however,
> > trying to do so is either pure luck or brute force.
> >
> > I mean REALLY big prime numbers.
> >
> > ----
> >
> > Responding to Williams comments. I have actually thought about this as
> > well. And true microsoft would have to have a single key using asymm
> > enc...
> > Or you could do something how RSA does it's SecureID's using a Half Life
> > Formula of some material (I don't know what they use or how they seed
it).
> > And that would prevent using the same key over and over. However...
that
> > could be really expensive...
> >
> > Just my thoughts.
> >
> > -CJ
> >
> >
> >
> > "Robert Jordan" <robertj@gmx.net> wrote in message
> > news:cji9gp$njk$03$1@news.t-online.com...
> >> Hi Richard,
> >>
> >> > If you could send the assembly to MSFT to get signed with their
private
> > key then only the public key woul dneed to ship with the CLR. I thought
> > thats what you suggested with hte Microsoft Remoting encrytping service.
> >>
> >> Supposing the MSFT public key is really "public",
> >> then everybody would be able to unencrypt the assembly, isn't it?
> >> I thought we wanted to prevent that.
> >>
> >> bye
> >> Rob
> >>
> >> >
> >> > Regards
> >> >
> >> > Richard Blewett - DevelopMentor
> >> > http://staff.develop.com/richardb/weblog
> >> >
> >> >
> >
nntp://news.microsoft.com/microsoft.public.dotnet.framework/>
> >> >
> >> > Hi Richard,
> >> >
> >> > > if it used an asymetric algorithm (encryption key <> decryption
key)
> > then the CLR would only need the decryption key so it wouldn't be a
> > problem
> > as that is how PPK encryption works now (or one flavour of it) everyone
> > has
> > the decryption key only one party can encrypt. However, with this prize
a
> > cherry on offer it would be brute forced very quickly I would assume
(you
> > could get loads of samples to base your brute force on my submitting
loads
> > of assemblies to be signed)
> >> >
> >> > I *thought* about asymetric encryption but did't wrote it ;-)
> >> >
> >> > - the assembly gets encrypted with my private key and with MS public
> > key
> >> > - my public key gets attached to the assembly
> >> > - the CLR unencrypts the assembly using my public key and
> >> > the MS private key, which has to be deployed with every
> >> > CLR, right?
> >> >
> >> > I was talking about that MS private key. No way to secure it.
> >> >
> >> > thanks
> >> >
> >> > bye
> >> > Rob
> >> >
> >> > >
> >> > > Regards
> >> > >
> >> > > Richard Blewett - DevelopMentor
> >> > > http://staff.develop.com/richardb/weblog
> >> > >
> >> > >
> >
nntp://news.microsoft.com/microsoft.public.dotnet.framework/>
> >> > >
> >> > > Hi William,
> >> > >
> >> > > > Just a random thought...
> >> > > > Forget about obfuscators for one minute. What are some other
ideas
> > on
> >> > > > protecting code that would work with the CLR (or not) to protect
> > your code
> >> > > > so it could not be decompiled? I had thought at one time that
some
> > kind of
> >> > > > encryption may work with the clr the only thing that could
> > unencrypt it.
> >> > >
> >> > > This shouldn't be a big problem, but since all assemblies will be
> >> > > encrypted with the same key(s) (otherwise the CLR wouldn't be able
> >> > > to unencrypt them), I bet the key(s) will be cracked within days.
> >> > >
> >> > > Even when those assemblies were encrypted by MS (using some
> >> > > fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
> >> > > contain the decryption keys somewhere.
> >> > >
> >> > > It's not worthwhile.
> >> > >
> >> > > bye
> >> > > Rob
> >> > >
> >> > > ---
> >> > > Incoming mail is certified Virus Free.
> >> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> >> > > Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004
> >> > >
> >> > >
> >> > >
> >> > > [microsoft.public.dotnet.framework]
> >> >
> >> > ---
> >> > Incoming mail is certified Virus Free.
> >> > Checked by AVG anti-virus system (http://www.grisoft.com).
> >> > Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004
> >> >
> >> >
> >> >
> >> > [microsoft.public.dotnet.framework]
> >
> >
>
>

Relevant Pages