Re: Decompiler.NET reverse engineers your CLS compliant code

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Sriram Krishnan (ksriram_at_NOSPAMgmx.net)
Date: 10/02/04 

Date: Sat, 2 Oct 2004 15:06:24 +0530

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