Breaking .NET Compact Framework code - how easy is it

[Chris Tacke, eMVP]

I had problems with Dotfuscator and CF as well. Xenocode worked for me, and
was inexpensive.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate

Steve,

Yes I used Dotfuscator and this is definitely good enough for me, it
certainly makes it very difficult to break.

I tried using Dotfuscator but when deploying my EXE to my device it no
longer starts when I tap it. Any ideas or hvae you experienced this?

Cheers
Simon.

Simon,

Now take that same assembly, run it through obfuscation and then look
at it in Reflector. Even if you use the VS built-in obfuscactor
(Tools/Dotfuscator Community Edition) you should see that the code is
very difficult to understand as it replaces all method and variable
names with a, b, c, etc.

Try it out, and then you make the call whether this technique is good
enough for you.

--steve

Ginny,

Thanks for that link I managed to google it after I asked...

Wow, that Reflector is quite amazing and worring!! I am using the DES
encryption algorithm to generate licence numbers. What I did find though
interestingly, that nor ILDASM and Reflector can decompile my IV and Key
bytes values as I declare these static fields as :

public static byte[] key_byte = Encoding.ASCII.GetBytes("mykey");

public static byte[] IV_byte = Encoding.ASCII.GetBytes("abcdefgh");



I guess is a good thing as it makes my code a little bit more secure.

Cheers

Simon.

message
Simon,

Here's Reflector: http://www.aisto.com/roeder/dotnet/

--
Ginny Caughey
.NET Compact Framework MVP


I have been thinking about this further. I know strong naming
assemblies
should prevent a "hacked" version from running - strong nameing
assemblies
should be common practice anyway. But lets say you are using a tool
such
as Reflector (where can I get Reflector btw? - to test my own code)
you
are able to decompile the assembly to source code successfully. In
this
case it doesn't matter where you put the algorithm - whether its
managed/unmanged or embedded as a resource etc. All the cracker has to
do
is alter the condition on return from the algorithm call to always
pass
regardless of the result.

So it seems the most effective way to stop pirate copies of your
software
is to ensure it cannot be decompiled.

Cheers
Simon.

At the risk of sounding naive, is this even a valid concern? If the
assemblies have been strong named, should that alone prevent the
issue
of running a "tampered" assembly? I thought that was the whole
point
of strong naming....to prevent running "hacked" assemblies.

As far as running ILDASM to look at source code, yes you can do
that.
If viewing source code is a concern of yours, then use an obfuscator
to
scramble the code before you release the app to production. The
downside of obfuscation, is that you cannot log a "readable" stack
trace in any error logs that you create.

Curious what your thoughts are on the strong naming issue.

--steve

 

[Simon Hart]

Of course this will be the case, duh! it will need to be strong named after
obfuscated.

I have found if strong naming my assembly the obfuscated assembly will not
load. When removing the strong named key, it worked like a gem on the
device.

The exe is around 30k smaller too.

Cheers
Simon.

Steve,

Yes I used Dotfuscator and this is definitely good enough for me, it
certainly makes it very difficult to break.

I tried using Dotfuscator but when deploying my EXE to my device it no
longer starts when I tap it. Any ideas or hvae you experienced this?

Cheers
Simon.

Simon,

Now take that same assembly, run it through obfuscation and then look
at it in Reflector. Even if you use the VS built-in obfuscactor
(Tools/Dotfuscator Community Edition) you should see that the code is
very difficult to understand as it replaces all method and variable
names with a, b, c, etc.

Try it out, and then you make the call whether this technique is good
enough for you.

--steve

Simon Hart wrote:
Ginny,

Thanks for that link I managed to google it after I asked...

Wow, that Reflector is quite amazing and worring!! I am using the DES
encryption algorithm to generate licence numbers. What I did find
though
interestingly, that nor ILDASM and Reflector can decompile my IV and
Key
bytes values as I declare these static fields as :

public static byte[] key_byte = Encoding.ASCII.GetBytes("mykey");

public static byte[] IV_byte = Encoding.ASCII.GetBytes("abcdefgh");



I guess is a good thing as it makes my code a little bit more secure.

Cheers

Simon.

message
Simon,

Here's Reflector: http://www.aisto.com/roeder/dotnet/

--
Ginny Caughey
.NET Compact Framework MVP


I have been thinking about this further. I know strong naming
assemblies
should prevent a "hacked" version from running - strong nameing
assemblies
should be common practice anyway. But lets say you are using a tool
such
as Reflector (where can I get Reflector btw? - to test my own code)
you
are able to decompile the assembly to source code successfully. In
this
case it doesn't matter where you put the algorithm - whether its
managed/unmanged or embedded as a resource etc. All the cracker has
to do
is alter the condition on return from the algorithm call to always
pass
regardless of the result.

So it seems the most effective way to stop pirate copies of your
software
is to ensure it cannot be decompiled.

Cheers
Simon.

At the risk of sounding naive, is this even a valid concern? If
the
assemblies have been strong named, should that alone prevent the
issue
of running a "tampered" assembly? I thought that was the whole
point
of strong naming....to prevent running "hacked" assemblies.

As far as running ILDASM to look at source code, yes you can do
that.
If viewing source code is a concern of yours, then use an
obfuscator to
scramble the code before you release the app to production. The
downside of obfuscation, is that you cannot log a "readable" stack
trace in any error logs that you create.

Curious what your thoughts are on the strong naming issue.

--steve

 

[Markus Humm]

Hello,

could you please explain a bit what the term "strong named" means?

Greetings

Markus

 

[Simon Hart]

Markus,

Microsoft are probebly the best people to explain it, see here:
http://msdn2.microsoft.com/en-us/library/wd40t7ad.aspx

Cheers
Simon.

 

[Daniel Moth]

....also check this out on a strong name myth (links on "Giagnocavo cracks
code"):
http://www.danielmoth.com/Blog/2004/11/blog-link-of-week-48.html

Cheers
Daniel

 

[Simon Hart]

Very interesting Daniel, indeed. It makes you wonder whether it is possible
to protect your code at all doesn't it!

Cheers
Simon.