Decompiler.NET reverse engineers your CLS compliant code

[Sriram Krishnan]

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

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

Hi Richard,

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

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

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]

 

[Robert Jordan]

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.

*Really* scary are discussions about cryptography carried out
by clueless people. This includes myself! )) But I really
enjoy it! LOL!

bye
Rob

 

[CJ Taylor]

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...

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

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

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

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

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]