How to secure the Dotnet code

[Usman]

Hi

I'm working on an application that contains classes for licensing,
authentication etc, including all the algorithms of encryption/decryption
etc. I wanted to secure this code, but after compiling all the code, I just
thought of trying a decompiler on the output file. The decompiler generated
almost 99% of the exact code out of it, exposing all those algorithms that I
need to secure. Even if I try a dotfuscator tool, still it does'nt secure
the code perfectly. I was wondering if there's some mechanism of ensuring
that the output cannot be decompiled. Or is this a huge compromise that
every dotnet developer has to do to opt this tool for development.

Regards

Usman

 

[Cor Ligthert [MVP]]

Usman,

I was wondering if there's some mechanism of ensuring
that the output cannot be decompiled.

No there is not and there has never been something like that.
That it is in future is very much not likely.

Be aware that obfuscated code is a request for some developers trying to
decompile it.

With what I not am saying that you should not do it as good as you can.

Cor

 

[Usman]

So what do you suggest should we do with such a code, that needs security.
We cannot just ship the code without making sure that our security is not
being compromised. Usually what techniques dotnet developers use for this.
I've tried a few other obfuscator tools, some of them have proved usefull
but thier licensing and distribution policy makes it un affordable. So
simply speaking, there was no big a problem writing secure code that cannot
be decompiled in VC++6, but this is a huge problem with VC.Net.

Regards

Usman

 

[Cowboy \(Gregory A. Beamer\)]

The Dotfuscator that ships with Visual Studio is a lite version. You should
try the pro trial and see if it better suits or one of the other
obfuscators. There are some solutions that actually encrypt your source;
there is a slight overhead for this, of course.

Look at the obfuscators/code protectors on sharptoolbox.com and you should
find one that suits your needs.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************

 

[Cowboy \(Gregory A. Beamer\)]

Actually, there are solutions that can protect .NET code by wrapping it in
an encrypted scheme. Undestand, of course, that NO solution protects from
the professional thief who has time and a copy of SoftIce, but that is true
of C++ code, as well.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************

 

[Barry Kelly]

there was no big a problem writing secure code that cannot
be decompiled in VC++6, but this is a huge problem with VC.Net.

Any code that can be executed can be decompiled. Managed code makes the
barrier to entry lower, but it's not difficult to diassemble and make
sense of standard VC++ executables with the right tools. The biggest
problem is that individual methods (methods are easy to detect, they
start with an address that is the target of a CALL and end with a RET)
don't have names.

The most common headline obfuscation technique for .NET involves
renaming all identifiers.

There really isn't a huge difference. Tooling in the managed space is
more advanced because of extra info in assemblies - reflection etc.

-- Barry

 

[Barry Kelly]

The Dotfuscator that ships with Visual Studio is a lite version. You should
try the pro trial and see if it better suits or one of the other
obfuscators. There are some solutions that actually encrypt your source;
there is a slight overhead for this, of course.

The decryption key will need to be in the executable, so the encryption
is actually just more obfuscation - not that that isn't good.

-- Barry

 

[Jim]

If you are used to programming in VC++, you could implement some parts of
your code in VC++ .Net. The powerful thing about VC++ .Net is that you can
create a mixed assembly that contains both Managed and Native code. - You
can't do this with C# or VB etc.

If you use the mixed assembly with a decent obfuscator such as the Pro
version of Dotfuscator, you should be able to create something that seems to
trip up virtually all the decompilers out there.

Another alternative it to use one of the tools that turns the .net
instructions into native code. But this defeats some of the advantages of
..net. But nevertheless could be an option.

There are some encryption tools out there that also stir things up a bit.
But again you have to be careful to see how good the encryption is. Some of
these programs simply decrypt the whole program as it is loaded into memory,
with people like RemoteSoft offering free tools that can remove this
protection.

Jim

 

[Cor Ligthert [MVP]]

Usman,

I did not write you should not obfuscate, but you asked it there is a
mechanise that could "ensuring that the output cannot be decompiled"

On that my answer was "No".

I gave you a thing to think about (obfuscting is inviting to decompile) and
than did write that if you want and howfar you want to obfuscate is up to
you, however never it will be as you asked. .

Be aware that you can decompile a program (probably you can get for standard
obfuscaters software on Internet, as I said, that is a hobby from some
persons). However, as I forever write. A decompiled program is usefull to
see how a program works, but I would never use it. It is easier to see what
it does and than make it yourself. A decompiled program has never those
declaring words I need to write a program.

As it is a licencing program, than I (I dont say that *you* have to do that)
would have look more how I could protect the data that is used in it. The
routines can forever be decompiled however if that is telling that extreme
difficult extern gotten encryption parts are used with external data, than
it helps nothing if you have a decompiled program..

To say with less words, with obfuscating you loose nothing, however don't
think that is all you have to do.

Just my thought,

Cor

 

[Jon Skeet [C# MVP]]

I'm working on an application that contains classes for licensing,
authentication etc, including all the algorithms of encryption/decryption
etc. I wanted to secure this code, but after compiling all the code, I just
thought of trying a decompiler on the output file. The decompiler generated
almost 99% of the exact code out of it, exposing all those algorithms that I
need to secure. Even if I try a dotfuscator tool, still it does'nt secure
the code perfectly. I was wondering if there's some mechanism of ensuring
that the output cannot be decompiled. Or is this a huge compromise that
every dotnet developer has to do to opt this tool for development.

See http://www.pobox.com/~skeet/csharp/obfuscation.html

If you're relying on hiding your code for security, you aren't going to
be very secure. Do a google search for "security through obscurity".

 

[C-Services Holland b.v.]

Hi

I'm working on an application that contains classes for licensing,
authentication etc, including all the algorithms of encryption/decryption
etc. I wanted to secure this code, but after compiling all the code, I just
thought of trying a decompiler on the output file. The decompiler generated
almost 99% of the exact code out of it, exposing all those algorithms that I
need to secure. Even if I try a dotfuscator tool, still it does'nt secure
the code perfectly. I was wondering if there's some mechanism of ensuring
that the output cannot be decompiled. Or is this a huge compromise that
every dotnet developer has to do to opt this tool for development.

Regards

Usman

We're planning to use hardware protection from http://www.aladdin.com/.
We have experience with that for our older software. It wraps it up in
an envelope which needs the hardware key to work. Reflector can't do
anything with the protected file. SoftICE also seems to be at a loss.

Don't know if this is a viable solution for you, but it sure works for us.

 

[Jim]

The problem might be how secure that Hasp envelope is, ...many envelopes are
fairly straightforward to remove.

I've used aladdin product myself, and would warn potential users not to just
rely on the protection as it stands out the box. You'll be wise to add some
extra tricks yourself.

With Aladdin being one of the leaders in this field they are also one of the
key targets for crackers wanting to produce hasp key emulators and envelope
removers. After only a quick google, you'll be able to find utilities that
can reveal the passwords stored in a Hasp key

Jim

 

[C-Services Holland b.v.]

The problem might be how secure that Hasp envelope is, ...many envelopes are
fairly straightforward to remove.

I've used aladdin product myself, and would warn potential users not to just
rely on the protection as it stands out the box. You'll be wise to add some
extra tricks yourself.

With Aladdin being one of the leaders in this field they are also one of the
key targets for crackers wanting to produce hasp key emulators and envelope
removers. After only a quick google, you'll be able to find utilities that
can reveal the passwords stored in a Hasp key

Jim

Ofcourse just calling the API to see if the lock is there is pretty
weak. As with every protection, it's how hard you make it. I've got a
demo version of it here to play with. It obfuscates the code and then
wraps it up in an envelope with configurable security layers. Aside from
that it is advised to place calls from within the program to the lock.
The more calls the more difficult it becomes to catch them all.

We don't store passwords in a hasp key btw.

In the end, every protection can be broken. Some are just more difficult
than others. For us, the dongle with encryption is good enough since
it's not a product that's going to have a huge user base because it's
rahter specific for factories/plants.

It's always a struggle on how much energy and money you're willing to
spend to protect your product. In the end it's all about how high a wall
you're willing to build and how high the cracker is able or willing to jump.

 

[Jim]

Generic envelopes etc are normally striaghtforward for crackers to remove,
especially if it is a well known envelope.

As far as the HASP API is concerned, you will need to use your vendor ID and
Passwords to call the API functions. You may not store other passwords in
the key. But you are _having_ to use your HASP Passwords each time you
call. - If you look at the HASP API, you will see these are a requirement of
calling the API functions.

If these passwords are visible to people cracking the program, then their
life is made much easier. I was told by HASP that you should always try to
keep these secret.

Therefore, after being told this, I found it a bit concerning to see that
after a quick google for HASP HL Emulator, I could download a utility from a
russian site that would reveal the HASP API passwords! - It's not some
obscure command line utility either. It has a little GUI with step by step
guide to doing so.

I'm not saying this makes HASPs unusable, but if I was to continue using
them, I'de make sure I had a several other tricks up my sleeve with the
software, and not rely on the HASP out of the box solution.

You are of course right though. Nothing in uncrackable, and it is down to
how much time you _need_ spend on developing license protection, to raise
the bar against the majority of your customer base. It is, of course,
possible to spend too much time and money on license control, when that same
time could be spent making the software more attractive.

The original point I wanted to make though was, that there does seem to be
some issues with the HASP keys, that appears to make them less secure than
the documentation that ships with HASP would have you believe. And this is
referring to native code applications. .net code is easier still to reverse.
I don't have any experience of how good the free HASP .net obfuscator is, or
how it compares with the $1500 ones such as Dotfucator Pro etc.

If you think that your customers are unlikely to google for a HASP emulator,
then it's less of a problem. But if not, then I would look carefully at what
else you can do to secure things up too.

Jim

 

[C-Services Holland b.v.]

Generic envelopes etc are normally striaghtforward for crackers to remove,
especially if it is a well known envelope.

As far as the HASP API is concerned, you will need to use your vendor ID and
Passwords to call the API functions. You may not store other passwords in
the key. But you are _having_ to use your HASP Passwords each time you
call. - If you look at the HASP API, you will see these are a requirement of
calling the API functions.

We only have real world experience with the HARDLOCK dongle, not the
HASP. With the HARDLOCK you don't need passwords to access the device.
It used module addresses with onchip encoding. I requested a demo HASP
because that supported .NET.

I will keep your comments in mind though and see how far I get with
these emulators and dig into the API a bit further. I'll have to weight
the pro's and con's to convince my boss either way.