Copy protection for a .NET application

Massimo <ba****@mclink.it> wrote:

I'm planning to develop a .NET application using C#, in order to sell it as
a shareware and/or as a full package, so I'll need a good way to protect it
against piracy. I know some ways to protect it (activation, serial keys,
etc.), but my concern is: how can any copy protection mechanism work when
you can always disassemble it and read the source code? Even if I use a
native C++ DLL for my copy protection, the point where it's called from the
C# code can always be found.
Any good tips about this?

Yes - don't worry. Obfuscate your code if you particularly want to, but
I wouldn't bother going any further than that unless you're *really*
sure that:

a) There'll be lots of demand for pirate copies
b) There'll be technically competent people who are willing to spend
time decompiling your obfuscated code

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #3

Michael Giagnocavo [MVP]

You can check into obfuscating. But depending on the obfuscator, that might
not buy you much. Getting thru obfuscated code can be simple:
http://www.atrevido.net/blog/PermaLi...b-fcc15eb297c3

The real way is to use a tool that does a lot more than just simple naming
obfuscation (say, type obfuscation as well, call obfuscation), encrypts your
assembly, and then, write really messed up code for the critical part. For
instance, you might try some tricks to fake your stack trace, use multiple
threads, etc. in the "serial checking" part.

Also remember, if there's demand, people will get through and crack your
app. Even MS Window's activation has been cracked (and the Windows
programmers are extremely intelligent).

--
Michael Giagnocavo
MVP
www.atrevido.net

"Massimo" <ba****@mclink.it> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

I'm planning to develop a .NET application using C#, in order to sell it
as a shareware and/or as a full package, so I'll need a good way to
protect it against piracy. I know some ways to protect it (activation,
serial keys, etc.), but my concern is: how can any copy protection
mechanism work when you can always disassemble it and read the source
code? Even if I use a native C++ DLL for my copy protection, the point
where it's called from the C# code can always be found.
Any good tips about this?

Thanks
Massimo

Jul 21 '05 #4

Very true. Just some random thoughts. I got to the point where all the fancy
stuff is a waste of time if your protecting against code modification or
round-tripping. You can use threads, jumps, or Egyptian carrier pigeons to
confuse, but it normally all comes down to one single "if" statement to
continue. This is one way to even get around RSA...just walk around it.
You can obfuscate to help keep logic and secrets hidden so they ~can't
generate external key gens or repro your license stuff, but if they will mod
the code, then none of that really matters. So your really protecting again
those that don't/can't mod the code - the others you can't really stop (not
even with smartcards, strong names, etc.). Most of your protections will be
in a single constructor, so not too hard to drill in on that. In this case
obfuscation still helps a bit as it makes it harder to figure out where/what
to mod the code(hopefully). Some obfuscators also help prevent ildasm to
raise the bar even farther.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Michael Giagnocavo [MVP]" <mg*******@atrevido.net> wrote in message
news:er**************@tk2msftngp13.phx.gbl...

You can check into obfuscating. But depending on the obfuscator, that might not buy you much. Getting thru obfuscated code can be simple:
http://www.atrevido.net/blog/PermaLi...b-fcc15eb297c3
The real way is to use a tool that does a lot more than just simple naming
obfuscation (say, type obfuscation as well, call obfuscation), encrypts your assembly, and then, write really messed up code for the critical part. For
instance, you might try some tricks to fake your stack trace, use multiple
threads, etc. in the "serial checking" part.

Also remember, if there's demand, people will get through and crack your
app. Even MS Window's activation has been cracked (and the Windows
programmers are extremely intelligent).

--
Michael Giagnocavo
MVP
www.atrevido.net

"Massimo" <ba****@mclink.it> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I'm planning to develop a .NET application using C#, in order to sell it
as a shareware and/or as a full package, so I'll need a good way to
protect it against piracy. I know some ways to protect it (activation,
serial keys, etc.), but my concern is: how can any copy protection
mechanism work when you can always disassemble it and read the source
code? Even if I use a native C++ DLL for my copy protection, the point
where it's called from the C# code can always be found.
Any good tips about this?

Thanks
Massimo

Jul 21 '05 #5

Massimo

"William Stacey [MVP]" <st***********@mvps.org> ha scritto nel messaggio
news:em**************@TK2MSFTNGP14.phx.gbl...

Very true. Just some random thoughts. I got to the point where all the
fancy
stuff is a waste of time if your protecting against code modification or
round-tripping. You can use threads, jumps, or Egyptian carrier pigeons
to
confuse, but it normally all comes down to one single "if" statement to
continue.

That's exactly my point of view on the subject.
So, in a higly disassemblable environment such a .NET (or Java, for that
matter), isn't there any way to really protect applications against piracy?

Massimo

Jul 21 '05 #6

Massimo <ba****@mclink.it> wrote:

"William Stacey [MVP]" <st***********@mvps.org> ha scritto nel messaggio
news:em**************@TK2MSFTNGP14.phx.gbl...
Very true. Just some random thoughts. I got to the point where all the
fancy
stuff is a waste of time if your protecting against code modification or
round-tripping. You can use threads, jumps, or Egyptian carrier pigeons
to
confuse, but it normally all comes down to one single "if" statement to
continue.

That's exactly my point of view on the subject.
So, in a higly disassemblable environment such a .NET (or Java, for that
matter), isn't there any way to really protect applications against piracy?

Well, there's protection and there's protection. There's no foolproof
way of protecting software whether it's Java or native code. You can
make things harder by using an obfuscator, but if the code is going to
run on a user's box, that user can (with appropriate skill) work out
what it's doing.

Usually, however, the concept behind a piece of software (which is
plainly visible anyway) is more important than the implementation, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #7

Robby

You can skip MSIL and compile directly to machine code if you want. In
fact, you can obfuscate and then compile to machine code for double
protection. You don't have to release your program in MSIL. However, if
you do go straight to machine code then you will loose the cross platform
benefits of MSIL. That means you will have to complie separate assembiles
for PC, MAC and so on.

-Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Massimo <ba****@mclink.it> wrote:
"William Stacey [MVP]" <st***********@mvps.org> ha scritto nel messaggio
news:em**************@TK2MSFTNGP14.phx.gbl...
> Very true. Just some random thoughts. I got to the point where all the
> fancy
> stuff is a waste of time if your protecting against code modification
> or
> round-tripping. You can use threads, jumps, or Egyptian carrier
> pigeons
> to
> confuse, but it normally all comes down to one single "if" statement to
> continue.

That's exactly my point of view on the subject.
So, in a higly disassemblable environment such a .NET (or Java, for that
matter), isn't there any way to really protect applications against
piracy?

Well, there's protection and there's protection. There's no foolproof
way of protecting software whether it's Java or native code. You can
make things harder by using an obfuscator, but if the code is going to
run on a user's box, that user can (with appropriate skill) work out
what it's doing.

Usually, however, the concept behind a piece of software (which is
plainly visible anyway) is more important than the implementation, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #8

Massimo

"Robby" <ed****@not.my.email.com> ha scritto nel messaggio
news:Ot**************@TK2MSFTNGP12.phx.gbl...

You can skip MSIL and compile directly to machine code if you want. In
fact, you can obfuscate and then compile to machine code for double
protection. You don't have to release your program in MSIL. However, if
you do go straight to machine code then you will loose the cross platform
benefits of MSIL. That means you will have to complie separate assembiles
for PC, MAC and so on.

Didn't know about this; how can I generate machine code? I was talking about
a Windows application here.

Massimo

Jul 21 '05 #9

Massimo

"Jon Skeet [C# MVP]" <sk***@pobox.com> ha scritto nel messaggio
news:MP************************@msnews.microsoft.c om...

Usually, however, the concept behind a piece of software (which is
plainly visible anyway) is more important than the implementation, IMO.

I agree on this, but I'm not talking about protecting intellectual rights
(i.e. algorithms), but the software itself, which can be easily copied.

Massimo

Jul 21 '05 #10

Robby

Use the NGEN utility that comes with the .Net Framework.

Robby

"Massimo" <ba****@mclink.it> wrote in message
news:co***********@newsreader1.mclink.it...

"Robby" <ed****@not.my.email.com> ha scritto nel messaggio
news:Ot**************@TK2MSFTNGP12.phx.gbl...
You can skip MSIL and compile directly to machine code if you want. In
fact, you can obfuscate and then compile to machine code for double
protection. You don't have to release your program in MSIL. However, if
you do go straight to machine code then you will loose the cross platform
benefits of MSIL. That means you will have to complie separate
assembiles for PC, MAC and so on.

Didn't know about this; how can I generate machine code? I was talking
about a Windows application here.

Massimo

Jul 21 '05 #11

Massimo <ba****@mclink.it> wrote:

Usually, however, the concept behind a piece of software (which is
plainly visible anyway) is more important than the implementation, IMO.

I agree on this, but I'm not talking about protecting intellectual rights
(i.e. algorithms), but the software itself, which can be easily copied.

And native code can fairly easily be copied too - look how much effort
the games industry is constantly putting into making games as hard to
crack as possible.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #12

Massimo <ba****@mclink.it> wrote:

You can skip MSIL and compile directly to machine code if you want. In
fact, you can obfuscate and then compile to machine code for double
protection. You don't have to release your program in MSIL. However, if
you do go straight to machine code then you will loose the cross platform
benefits of MSIL. That means you will have to complie separate assembiles
for PC, MAC and so on.

Didn't know about this; how can I generate machine code? I was talking about
a Windows application here.

See http://www.pobox.com/~skeet/csharp/f...ework.required

I can't say I'd recommend going that route though - while I haven't
used the products in question, the .NET framework will clearly have
gone through a lot more testing (especially if you include the
"testing" which all of us are doing every time we run some .NET code)
than the linkers. I'd certainly recommend that if you take that route,
you do it early on and do as much of your development and testing using
the product as possible, largely ignoring the normal framework. That
may well end up costing a lot in terms of ease of development, of
course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #13

Robby

Using the NGEN utility is not ignoring the .Net Framework. It is a part of
the .Net Framework. Machine code compiled assembiles still need the .Net
Framework installed to run. You should not make grossly incorrect
statements like that.

Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Massimo <ba****@mclink.it> wrote:
> You can skip MSIL and compile directly to machine code if you want. In
> fact, you can obfuscate and then compile to machine code for double
> protection. You don't have to release your program in MSIL. However,
> if
> you do go straight to machine code then you will loose the cross
> platform
> benefits of MSIL. That means you will have to complie separate
> assembiles
> for PC, MAC and so on.

Didn't know about this; how can I generate machine code? I was talking
about
a Windows application here.

See http://www.pobox.com/~skeet/csharp/f...ework.required

I can't say I'd recommend going that route though - while I haven't
used the products in question, the .NET framework will clearly have
gone through a lot more testing (especially if you include the
"testing" which all of us are doing every time we run some .NET code)
than the linkers. I'd certainly recommend that if you take that route,
you do it early on and do as much of your development and testing using
the product as possible, largely ignoring the normal framework. That
may well end up costing a lot in terms of ease of development, of
course...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #14

Massimo

"Jon Skeet [C# MVP]" <sk***@pobox.com> ha scritto nel messaggio
news:MP************************@msnews.microsoft.c om...

> Usually, however, the concept behind a piece of software (which is
> plainly visible anyway) is more important than the implementation, IMO.

I agree on this, but I'm not talking about protecting intellectual rights
(i.e. algorithms), but the software itself, which can be easily copied.

And native code can fairly easily be copied too - look how much effort
the games industry is constantly putting into making games as hard to
crack as possible.

Yes, I know this, and in fact I'm quite unsure about native code safety,
too. But IL is definitely *a lot* simpler to understand, when disassembled.

Massimo

Jul 21 '05 #15

Robby <ed****@not.my.email.com> wrote:

Use the NGEN utility that comes with the .Net Framework.

The IL is still present in NGENed code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #16

Massimo <ba****@mclink.it> wrote:

And native code can fairly easily be copied too - look how much effort
the games industry is constantly putting into making games as hard to
crack as possible.

Yes, I know this, and in fact I'm quite unsure about native code safety,
too. But IL is definitely *a lot* simpler to understand, when disassembled.

Have you tried decompiling a real application of significant size,
after it's been obfuscated? It takes a fair amount of skill and
patience to understand it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #17

Robby <ed****@not.my.email.com> wrote:

Using the NGEN utility is not ignoring the .Net Framework. It is a part of
the .Net Framework. Machine code compiled assembiles still need the .Net
Framework installed to run. You should not make grossly incorrect
statements like that.

I think you should be careful about the fact before accusing others of
making grossly incorrect statements:

1) NGENed assemblies still require the original IL, so don't help in
the slightest.
2) If you'd followed the link I provided, you'd see that the products I
was referring to *don't* require the .NET framework to be installed
- they include everything that's required. I wasn't talking about
NGEN, as it doesn't accomplish the desired goal.

Of course, if you don't believe me about the first point, you'd
presumably be happy to send me an NGENed executable which you believe
doesn't contain any IL. If you can do so, *then* I'll apologise for
making a grossly incorrect statement.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #18

Robby

Well, I was talking about NGEN so your statements are incorrect. NGEN
assemblies do not require you to distribute MSIL.

Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Robby <ed****@not.my.email.com> wrote:
Using the NGEN utility is not ignoring the .Net Framework. It is a part
of
the .Net Framework. Machine code compiled assembiles still need the .Net
Framework installed to run. You should not make grossly incorrect
statements like that.

I think you should be careful about the fact before accusing others of
making grossly incorrect statements:

1) NGENed assemblies still require the original IL, so don't help in
the slightest.
2) If you'd followed the link I provided, you'd see that the products I
was referring to *don't* require the .NET framework to be installed
- they include everything that's required. I wasn't talking about
NGEN, as it doesn't accomplish the desired goal.

Of course, if you don't believe me about the first point, you'd
presumably be happy to send me an NGENed executable which you believe
doesn't contain any IL. If you can do so, *then* I'll apologise for
making a grossly incorrect statement.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #19

Robby <ed****@not.my.email.com> wrote:

Well, I was talking about NGEN so your statements are incorrect.
You may have been talking about NGEN, but you didn't specify that. My
statements concerned the products I referred to, and were correct in
that context. I answered a question from Massimo, and all my statements
in that answer were correct.
NGEN assemblies do not require you to distribute MSIL.

So I should expect an executable (compiled from C# source) in my inbox
which doesn't have any IL in pretty soon, right? I'll be very surprised
if you can produce one (using ngen).

Just out of interest, I NGENed a small test executable, copied the
native file out of the GAC, and tried to run it directly. No dice. You
need the assembly containing the IL in order to get the framework to
use the native image in the GAC.

There *may* be ways of removing the IL from the original assembly after
NGENing it, but in a way that fools the framework into using the image
from GAC - but I haven't seen anyone writing about that, and you'd need
fairly deep knowledge of exactly how the GAC works to try it out. (If
the framework checks the hash of the assembly against the original, for
instance, you're in trouble unless you can also change the hash that's
stored in the native code file.)

I'm off to bed now, but I'll be fascinated to see that executable
(along with exact details of how you produced it) in the morning...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #20

Not sure if this product works well or not, but thought it looked
interesting. Salamander .NET protector takes your code to produce native
code like:
00000000 mov eax,dword ptr ds:[20004000h]
00000006 mov ecx,dword ptr [eax]
00000008 mov eax,dword ptr ds:[200046C0h]
0000000e call dword ptr [eax]
00000020 ret

From this:
IL_0000: ldstr "Hello World using C#!"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_00a: ret

Have not tried it, but sounds interesting. Anyone use it?

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Robby <ed****@not.my.email.com> wrote:
Well, I was talking about NGEN so your statements are incorrect.

You may have been talking about NGEN, but you didn't specify that. My
statements concerned the products I referred to, and were correct in
that context. I answered a question from Massimo, and all my statements
in that answer were correct.
NGEN assemblies do not require you to distribute MSIL.

So I should expect an executable (compiled from C# source) in my inbox
which doesn't have any IL in pretty soon, right? I'll be very surprised
if you can produce one (using ngen).

Just out of interest, I NGENed a small test executable, copied the
native file out of the GAC, and tried to run it directly. No dice. You
need the assembly containing the IL in order to get the framework to
use the native image in the GAC.

There *may* be ways of removing the IL from the original assembly after
NGENing it, but in a way that fools the framework into using the image
from GAC - but I haven't seen anyone writing about that, and you'd need
fairly deep knowledge of exactly how the GAC works to try it out. (If
the framework checks the hash of the assembly against the original, for
instance, you're in trouble unless you can also change the hash that's
stored in the native code file.)

I'm off to bed now, but I'll be fascinated to see that executable
(along with exact details of how you produced it) in the morning...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #21

Agreed. When using XenoCode with control flow obfus and IL cracking, I have
not been able to decomiple a clean enouph version to start really reading.
In some respect I guess, IL and obfuscation may be harder to crack then
native code without obfuscation - assuming one knows how to look at (and
change) both.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Massimo <ba****@mclink.it> wrote:
And native code can fairly easily be copied too - look how much effort
the games industry is constantly putting into making games as hard to
crack as possible.
Yes, I know this, and in fact I'm quite unsure about native code safety,
too. But IL is definitely *a lot* simpler to understand, when

disassembled.
Have you tried decompiling a real application of significant size,
after it's been obfuscated? It takes a fair amount of skill and
patience to understand it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #22

William Stacey [MVP] <st***********@mvps.org> wrote:

Not sure if this product works well or not, but thought it looked
interesting. Salamander .NET protector takes your code to produce native
code like:
00000000 mov eax,dword ptr ds:[20004000h]
00000006 mov ecx,dword ptr [eax]
00000008 mov eax,dword ptr ds:[200046C0h]
0000000e call dword ptr [eax]
00000020 ret

From this:
IL_0000: ldstr "Hello World using C#!"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_00a: ret

Have not tried it, but sounds interesting. Anyone use it?

Interesting - seems to be a variant on the linker, basically - except
using a "pseudo-native" code rather than real native code. I do wonder
to what extent it's security through obscurity though - just a
different format for what is still really MSIL. I'd need to know
exactly what it was doing to say for sure, of course, and I'm not about
to spend a huge heap of time or money on it...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #23

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

I'm off to bed now, but I'll be fascinated to see that executable
(along with exact details of how you produced it) in the morning...

Just for anyone following this thread - I haven't heard anything back.

I have, however, tried playing around with ngen just for kicks. I took
a normal, very simple C# application:

using System;

class Test
{
static void Main()
{
Console.WriteLine ("Hello");
}
}

I compiled and ran it, producing "Hello" as expected. With a binary hex
editor, I then changed the "Hello" to "Hallo" - ran it, and got the
obvious output. I then ran ngen on it, and edited the IL to "Hxllo"
afterwards. Ran it again, and "Hxllo" was produced, showing that the
normal assembly was still being used (as it couldn't have made it as
far as the native code). Whether that was due to the string table from
the normal assembly being used by the ngen code, or the framework
realising that there was a change, I don't know - but it doesn't really
matter, as it seems to disprove Robby's point, as far as I'm concerned.

Still, I suppose it's always fun to be told I've made grossly incorrect
statements ;)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #24

Roy Fine

Still, I suppose it's always fun to be told I've made grossly incorrect
statements ;)

only if it is within the context of a conversation with self... :))

Jul 21 '05 #25

Salih Goncu

Hi, all.

Well, reading all the thread, there's a really good way to make a copy
protection for a IL (or bytecode for Java) available. Besides obfuscation,
which is good for many of the cases, the approach I'll tell you is for *real*
paranoids.

In protecting some piece of code from analysis requires that it is
impossible to reach that piece of code from within the context of
application, that is, run that code somewhere else.

The best candidate, as far as I know, is smartcards with crypto
co-processors.

Have the smartcard generate a key pair for you and store the private key
inside itself, never telling it even you. Then, put a piece of code in the
smartcard and give it the access credidentals with only the public key that
the card delivered you. Use a secure communication protocol between the
smartcard and the computer, so that nobody will be able to intercept the data
transmitted.

When your program is running as shareware, it won't require the vital piece
of code that needs to execute in the smartcard. But when it is licensed, you
give your customer the card and the corresponding public key. So, when in
licensed mode, the card executes the vital code, and returns only the
required results meaningful only for that license or context. (The code
inside the smartcard may be dependent on some data or other code in your
application, but your application *must* be dependent on this code piece.)

I used this approach on some projects, and proved well. You can check out
possible cards supported by Windows CSP from Gemplus, Sclumberger and Orga.
The capacity of cards range from 8 to 128 Kbytes, which is sufficient for
many types of applications.

As this is the hardest nut to crack, this is also very hard to code, so you
decide if you want it or not...

Salih

"Massimo" wrote:

I'm planning to develop a .NET application using C#, in order to sell it as
a shareware and/or as a full package, so I'll need a good way to protect it
against piracy. I know some ways to protect it (activation, serial keys,
etc.), but my concern is: how can any copy protection mechanism work when
you can always disassemble it and read the source code? Even if I use a
native C++ DLL for my copy protection, the point where it's called from the
C# code can always be found.
Any good tips about this?

Thanks
Massimo

Jul 21 '05 #26

Michael Giagnocavo [MVP]

It all depends on what the objective is. If it's to understand the working
and architecture of an application, it should be exceedingly hard. If it's
to simply find a single branch instruction, well... perhaps it's much
easier.

--
Michael Giagnocavo
MVP
www.atrevido.net
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:OS**************@TK2MSFTNGP14.phx.gbl...

Agreed. When using XenoCode with control flow obfus and IL cracking, I
have
not been able to decomiple a clean enouph version to start really reading.
In some respect I guess, IL and obfuscation may be harder to crack then
native code without obfuscation - assuming one knows how to look at (and
change) both.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Massimo <ba****@mclink.it> wrote:
> > And native code can fairly easily be copied too - look how much
> > effort
> > the games industry is constantly putting into making games as hard to
> > crack as possible.
>
> Yes, I know this, and in fact I'm quite unsure about native code
> safety,
> too. But IL is definitely *a lot* simpler to understand, when

disassembled.

Have you tried decompiling a real application of significant size,
after it's been obfuscated? It takes a fair amount of skill and
patience to understand it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #27

True. But it is no harder to branch around this then anything else if your
talking patching (not simple keygens). If keeping secrets, then maybe a
good way to go but seems to have all the draw backs of a dongle which I
would never buy (again).

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Salih Goncu" <Salih Go***@discussions.microsoft.com> wrote in message
news:11**********************************@microsof t.com...

Hi, all.

Well, reading all the thread, there's a really good way to make a copy
protection for a IL (or bytecode for Java) available. Besides obfuscation,
which is good for many of the cases, the approach I'll tell you is for *real* paranoids.

In protecting some piece of code from analysis requires that it is
impossible to reach that piece of code from within the context of
application, that is, run that code somewhere else.

The best candidate, as far as I know, is smartcards with crypto
co-processors.

Have the smartcard generate a key pair for you and store the private key
inside itself, never telling it even you. Then, put a piece of code in the
smartcard and give it the access credidentals with only the public key that the card delivered you. Use a secure communication protocol between the
smartcard and the computer, so that nobody will be able to intercept the data transmitted.

When your program is running as shareware, it won't require the vital piece of code that needs to execute in the smartcard. But when it is licensed, you give your customer the card and the corresponding public key. So, when in
licensed mode, the card executes the vital code, and returns only the
required results meaningful only for that license or context. (The code
inside the smartcard may be dependent on some data or other code in your
application, but your application *must* be dependent on this code piece.)

I used this approach on some projects, and proved well. You can check out
possible cards supported by Windows CSP from Gemplus, Sclumberger and Orga. The capacity of cards range from 8 to 128 Kbytes, which is sufficient for
many types of applications.

As this is the hardest nut to crack, this is also very hard to code, so you decide if you want it or not...

Salih

"Massimo" wrote:
I'm planning to develop a .NET application using C#, in order to sell it as a shareware and/or as a full package, so I'll need a good way to protect it against piracy. I know some ways to protect it (activation, serial keys,
etc.), but my concern is: how can any copy protection mechanism work when you can always disassemble it and read the source code? Even if I use a
native C++ DLL for my copy protection, the point where it's called from the C# code can always be found.
Any good tips about this?

Thanks
Massimo

Jul 21 '05 #28

Robby

Did you compile for release or debug? Did you move the NGENed assembly to a
different folder or .Net installed computer?

--Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
I'm off to bed now, but I'll be fascinated to see that executable
(along with exact details of how you produced it) in the morning...

Just for anyone following this thread - I haven't heard anything back.

I have, however, tried playing around with ngen just for kicks. I took
a normal, very simple C# application:

using System;

class Test
{
static void Main()
{
Console.WriteLine ("Hello");
}
}

I compiled and ran it, producing "Hello" as expected. With a binary hex
editor, I then changed the "Hello" to "Hallo" - ran it, and got the
obvious output. I then ran ngen on it, and edited the IL to "Hxllo"
afterwards. Ran it again, and "Hxllo" was produced, showing that the
normal assembly was still being used (as it couldn't have made it as
far as the native code). Whether that was due to the string table from
the normal assembly being used by the ngen code, or the framework
realising that there was a change, I don't know - but it doesn't really
matter, as it seems to disprove Robby's point, as far as I'm concerned.

Still, I suppose it's always fun to be told I've made grossly incorrect
statements ;)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #29

Robby <ed****@not.my.email.com> wrote:

Did you compile for release or debug? Did you move the NGENed assembly to a
different folder or .Net installed computer?

I just compiled with the defaults from the command line.

Note that running NGEN doesn't change the assembly it's run on - it
just adds the native image to the GAC's native images section. I don't
see why moving the assembly itself around either within the same
computer or to a different one would make any difference. (I'd need to
run NGEN again on the other computer, of course.)

However, as you're the one suggesting that NGEN is the way to go, you
should be the one to tell us how we're supposed to get a program
running without the original assembly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #30

Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Robby <ed****@not.my.email.com> wrote:
Did you compile for release or debug? Did you move the NGENed assembly
to a
different folder or .Net installed computer?

I just compiled with the defaults from the command line.

Note that running NGEN doesn't change the assembly it's run on - it
just adds the native image to the GAC's native images section. I don't
see why moving the assembly itself around either within the same
computer or to a different one would make any difference. (I'd need to
run NGEN again on the other computer, of course.)

However, as you're the one suggesting that NGEN is the way to go, you
should be the one to tell us how we're supposed to get a program
running without the original assembly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

A NGENed assembly has a special non-accessible cache created where the
machine code in stored. When you modify the IL assembly and re-execute it
the .Net Framework stops pointing the the cache and uses the IL cache
instead. This is why you see the changes made to the IL assembly instead of
the cached machine code version.

--Robby

Jul 21 '05 #31

Robby <ed****@not.my.email.com> wrote:

A NGENed assembly has a special non-accessible cache created where the
machine code in stored.
I don't know why you think it's non-accessible - I found it very
easily.
When you modify the IL assembly and re-execute it
the .Net Framework stops pointing the the cache and uses the IL cache
instead. This is why you see the changes made to the IL assembly instead of
the cached machine code version.

Exactly. The whole point was to demonstrate that. What that means is
that you can't execute the native code without the original assembly,
contrary to your previous assertions.

You still haven't detailed exactly how you think you can use NGEN to
foil people who wish to decompile the assembly. Maybe if you gave step-
by-step instructions as to how you'd go about it, things would be
clearer.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #32

Massimo

"Salih Goncu" <Salih Go***@discussions.microsoft.com> ha scritto nel
messaggio news:11**********************************@microsof t.com...

your application *must* be dependent on this code piece.

That's the failure point of your solution. Even in this case, there will be
some point in the application where an IF statement will compare the value
returned from the smart card to something else, and decide if the program is
allowed to run. Find that statement, and you crack the program...

Massimo

Jul 21 '05 #33

> That's the failure point of your solution. Even in this case, there will
be

some point in the application where an IF statement will compare the value
returned from the smart card to something else, and decide if the program is allowed to run. Find that statement, and you crack the program...

Well said.

--
William Stacey, MVP
http://mvp.support.microsoft.com

Jul 21 '05 #34

Salih Goncu

Well,

I think I couldn't point out the case I was talking about. OK, for the sake
of bravity, I'll state these axiomes:

1. Anything locked by a human being can be opened or broken by another human
being.
2. Anything that runs on deterministic fashion (in a way that uses a limited
set of commands like that of a CPU or IL) can be backtracked and reverse
engineered.

We can't do anything about the 1st axiome, as all programmers I know are
human beings, so what we may try is, to make our code for copy protection
less deterministic. With the help of obfuscators, we try to reach this goal.

For further confusion to be put on intruder is, to put *some* other also
deterministic in nature, but indeterministic in vision, a piece of code that
is vital for the protected part of the program. I don't say, just do some
hashing etc. and return the result to the program and compare with something
else and unlock something or not.

What I say is, run some part of the application *outside* the application
context, Windows and CPU that the application is already running. Physically
seperate these two parts of application. For example, using RPC, we do just
this, have some code run on another computer. So that intruder can just trace
the encrypted traffic between these two parts.

Of course it is possible to analyse the main application and find out what
that vital code is doing in that black box and write some other piece of code
or just patch the application, so that it has the same piece of code running
in the same context. But, here is the point: How much will it cost to achieve
this goal?

If I need supercomputers to find out the key pair generated (And don't
forget, my suggestion states that private key is only known by the card
itself. Not even by the programmer or personalizer) and a class 1000 (that is
1000 particles in 1 cubic meters of air) clean room and an electron scanning
microscope to crack a program, well, it's better to buy it...

Of course, if you increase the cost for breaking a system you also increase
the cost for building that system...

That's what I think. I never asserted that the solution I offered was
impenetretable. It is just too expensive to impenetrate...

Salih
"William Stacey [MVP]" wrote:

That's the failure point of your solution. Even in this case, there will

be
some point in the application where an IF statement will compare the value
returned from the smart card to something else, and decide if the program

is
allowed to run. Find that statement, and you crack the program...

Well said.

--
William Stacey, MVP
http://mvp.support.microsoft.com

Jul 21 '05 #35

Thanks Salih. I think what we are saying is a bit different. You are 100%
correct from the protection stand point. Trying to break a hidden algo on a
card would be too hard. Good protect from that stand point. However, what
we are saying is you can easily find where your program calls your "Card"
method, returns, and does an IF test to see if we can continue. Now you can
patch that and just "JUMP" around it. The hacker does not need to break RSA
or hash or Smart card. All he has to do is set the Test to true and he
totally went around all your protections. This is easier then you may
think. You can't really protect against this kind of hack, but only make it
harder to read and figure out your code, etc. A very good discussion of
these methods are at:
http://www.atrevido.net/blog/Categor...?category=Code

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Salih Goncu" <Salih Go***@discussions.microsoft.com> wrote in message
news:78**********************************@microsof t.com...

Well,

I think I couldn't point out the case I was talking about. OK, for the sake of bravity, I'll state these axiomes:

1. Anything locked by a human being can be opened or broken by another human being.
2. Anything that runs on deterministic fashion (in a way that uses a limited set of commands like that of a CPU or IL) can be backtracked and reverse
engineered.

We can't do anything about the 1st axiome, as all programmers I know are
human beings, so what we may try is, to make our code for copy protection
less deterministic. With the help of obfuscators, we try to reach this goal.
For further confusion to be put on intruder is, to put *some* other also
deterministic in nature, but indeterministic in vision, a piece of code that is vital for the protected part of the program. I don't say, just do some
hashing etc. and return the result to the program and compare with something else and unlock something or not.

What I say is, run some part of the application *outside* the application
context, Windows and CPU that the application is already running. Physically seperate these two parts of application. For example, using RPC, we do just this, have some code run on another computer. So that intruder can just trace the encrypted traffic between these two parts.

Of course it is possible to analyse the main application and find out what
that vital code is doing in that black box and write some other piece of code or just patch the application, so that it has the same piece of code running in the same context. But, here is the point: How much will it cost to achieve this goal?

If I need supercomputers to find out the key pair generated (And don't
forget, my suggestion states that private key is only known by the card
itself. Not even by the programmer or personalizer) and a class 1000 (that is 1000 particles in 1 cubic meters of air) clean room and an electron scanning microscope to crack a program, well, it's better to buy it...

Of course, if you increase the cost for breaking a system you also increase the cost for building that system...

That's what I think. I never asserted that the solution I offered was
impenetretable. It is just too expensive to impenetrate...

Salih
"William Stacey [MVP]" wrote:
That's the failure point of your solution. Even in this case, there will
be
some point in the application where an IF statement will compare the
value returned from the smart card to something else, and decide if the

program is
allowed to run. Find that statement, and you crack the program...

Well said.

--
William Stacey, MVP
http://mvp.support.microsoft.com

Jul 21 '05 #36

William Stacey [MVP] wrote:

Thanks Salih. I think what we are saying is a bit different. You are 100%
correct from the protection stand point. Trying to break a hidden algo on a
card would be too hard. Good protect from that stand point. However, what
we are saying is you can easily find where your program calls your "Card"
method, returns, and does an IF test to see if we can continue. Now you can
patch that and just "JUMP" around it. The hacker does not need to break RSA
or hash or Smart card. All he has to do is set the Test to true and he
totally went around all your protections. This is easier then you may
think. You can't really protect against this kind of hack, but only make it
harder to read and figure out your code, etc. A very good discussion of
these methods are at:
http://www.atrevido.net/blog/Categor...?category=Code

Not all protection depends on an IF statement. You can use a smartcard
(hardlock) to crypt data, which can only be read by use of this crypto
device. If you make part of your code depend on this crypto process then
it's a very different from just making a bitflip in the exe to bypass an
IF statement. We use Hardlocks to crypt certain DLLs. They have to be
read through the hardlock, otherwise they're useless. There's a whole
lot of wizardry going on to prevent people from getting at the uncrypted
code.

I'm not saying this is uncrackable (anything that can be run can be
cracked), but it's a whole lot more difficult than replacing an IF
statement.

--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #37

With respect, it does not matter. It eventually has to come down to an if
test somewhere in your main code. Otherwise you could never test if the
hardlock method with valid or not. It does not matter what the "blackbox"
is doing - you still have to test the return of the blackbox somewhere. If
I am still in error, please post some code to review. Don't need the
blackbox code, just the parts where you call the blackbox, return some value
and not test it with an if. Would be interested to see that. tia

--
William Stacey, MVP
http://mvp.support.microsoft.com

"C-Services Holland b.v." <cs*@REMOVEcsh4u.nl> wrote in message
news:5_********************@zeelandnet.nl...

William Stacey [MVP] wrote:
Thanks Salih. I think what we are saying is a bit different. You are 100% correct from the protection stand point. Trying to break a hidden algo on a card would be too hard. Good protect from that stand point. However, what we are saying is you can easily find where your program calls your "Card" method, returns, and does an IF test to see if we can continue. Now you can patch that and just "JUMP" around it. The hacker does not need to break RSA or hash or Smart card. All he has to do is set the Test to true and he
totally went around all your protections. This is easier then you may
think. You can't really protect against this kind of hack, but only make it harder to read and figure out your code, etc. A very good discussion of
these methods are at:
http://www.atrevido.net/blog/Categor...?category=Code

Not all protection depends on an IF statement. You can use a smartcard
(hardlock) to crypt data, which can only be read by use of this crypto
device. If you make part of your code depend on this crypto process then
it's a very different from just making a bitflip in the exe to bypass an
IF statement. We use Hardlocks to crypt certain DLLs. They have to be
read through the hardlock, otherwise they're useless. There's a whole
lot of wizardry going on to prevent people from getting at the uncrypted
code.

I'm not saying this is uncrackable (anything that can be run can be
cracked), but it's a whole lot more difficult than replacing an IF
statement.

--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #38

William Stacey [MVP] wrote:

With respect, it does not matter. It eventually has to come down to an if
test somewhere in your main code. Otherwise you could never test if the
hardlock method with valid or not. It does not matter what the "blackbox"
is doing - you still have to test the return of the blackbox somewhere. If
I am still in error, please post some code to review. Don't need the
blackbox code, just the parts where you call the blackbox, return some value
and not test it with an if. Would be interested to see that. tia

With respect, it does matter. I see you don't understand the method. We
have functional code wrapped up in a DLL. This DLL is then crypted
through a hardlock (www.hardlock.com). You can also crypt the whole .exe
if you want. This DLL can only be used if the hardlock is attached to
the computer. It encrytion 'envelope' decrypts the parts it needs on the
fly using the hardlock. The communication between the hardlock and the
software is also scattered with random stuff to make it very difficult
to catch what's real and what's not.

All interaction with this hardlock is regulated by the encapsulating
encryption. No intervention on my part is nescesary. As such, I don't
need to check anything from a black box, since from my POV (code) there
is no black box, that's the whole beauty of this solution.

Check out the documentation on the site. This protection is very
different from checking if that hardlock is attached, because that would
be easy to circumvent in the way you're describing.
--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #39

Thanks Rinze. Was not trying to be flippant with response. I assume your
talking license management here. If something else, please expand. To have
context here, lets assume we are talking license check as that is what site
mainly talks about. And your right, we probably can't crack the device or
internal structures. However, I still don't need to. Pretend we call an
IsValid() method in the hardlock. It does and does its thing with checking
keys, decrypting, xyz, etc. That is fine and good. But now, my main code
at some point need to check some reply from the hardlock to see if that was
valid or license failure. So my code my look like this (could be anything)
:

private void MainForm_Load(object sender, System.EventArgs e)
{
bool valid = HardLock.IsValid(); // HardLock goes and does its
magic.
if ( ! valid )
MessageBox.Show("Thank you for using our software. Please
obtain a valid license at xyz.com.");
}

So I can still bypass your HardLock all together with a mod to the code. I
don't need to break the hardlock, I just need to change your code. The
return value my not be a bool but something else. You can still do the same
thing. Now if all your code is in the hardlock, then that is probably a
different issue - but not sure we are talking about that. Truly interested
in this, so please post some other example if I am in error. I did look at
the site. The idea is good, but in the end it is a fancy dongle that people
will not buy sw that requires a dongle/smartcard/smart usb device (at least
a lot of people will not.) A good obfuscator and PKI would probably work as
well to make it very difficult to crack your code without requiring the
dongle. Now if we could load the whole program in the dongle and run it
from there, that may be a little more interesting. Instead of distributing
CDs or exe, you send out USB device with sw on it. Still a dongle however,
and you still have the perception issue. Is your software that great that
people will carry around this dongle with them. What if everyone did this,
I would have 20 dongles sticking out of my machine (If I could even get that
many usb ports.) As a user, chances are a non-dongle SW alternative starts
looking more attractive as the dongle feels like one more thing to keep
track of that I don't need. That said, for some high security applications,
this may be the right choice.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"C-Services Holland b.v." <cs*@REMOVEcsh4u.nl> wrote in message
news:5o********************@zeelandnet.nl...

William Stacey [MVP] wrote:
With respect, it does not matter. It eventually has to come down to an if test somewhere in your main code. Otherwise you could never test if the
hardlock method with valid or not. It does not matter what the "blackbox" is doing - you still have to test the return of the blackbox somewhere. If I am still in error, please post some code to review. Don't need the
blackbox code, just the parts where you call the blackbox, return some value and not test it with an if. Would be interested to see that. tia

With respect, it does matter. I see you don't understand the method. We
have functional code wrapped up in a DLL. This DLL is then crypted
through a hardlock (www.hardlock.com). You can also crypt the whole .exe
if you want. This DLL can only be used if the hardlock is attached to
the computer. It encrytion 'envelope' decrypts the parts it needs on the
fly using the hardlock. The communication between the hardlock and the
software is also scattered with random stuff to make it very difficult
to catch what's real and what's not.

All interaction with this hardlock is regulated by the encapsulating
encryption. No intervention on my part is nescesary. As such, I don't
need to check anything from a black box, since from my POV (code) there
is no black box, that's the whole beauty of this solution.

Check out the documentation on the site. This protection is very
different from checking if that hardlock is attached, because that would
be easy to circumvent in the way you're describing.
--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #40

Massimo

"William Stacey [MVP]" <st***********@mvps.org> ha scritto nel messaggio
news:%2****************@TK2MSFTNGP12.phx.gbl...

Thanks Rinze. Was not trying to be flippant with response. I assume your
talking license management here. If something else, please expand. To
have
context here, lets assume we are talking license check as that is what
site
mainly talks about. And your right, we probably can't crack the device or
internal structures. However, I still don't need to. Pretend we call an
IsValid() method in the hardlock. It does and does its thing with
checking
keys, decrypting, xyz, etc. That is fine and good. But now, my main code
at some point need to check some reply from the hardlock to see if that
was
valid or license failure. So my code my look like this (could be
anything)
:

private void MainForm_Load(object sender, System.EventArgs e)
{
bool valid = HardLock.IsValid(); // HardLock goes and does its
magic.
if ( ! valid )
MessageBox.Show("Thank you for using our software. Please
obtain a valid license at xyz.com.");
}

So I can still bypass your HardLock all together with a mod to the code.

I think he was talking about encrypting a DLL using some key stored inside a
dongle/smart card/whatever. That way, nobody could even access the code
without the key, so no patching could actually crack this system.
Howewer, a lot of copy protections from games take exactly this approach
(enrypting the main executable using data stored in the CD-ROM subchannel),
and no one of them has been cracked, but the games are still being copied...
by distributing a copy of the decrypted executable along with them.

Massimo

Jul 21 '05 #41

You don't seem to understand the crypting process.

quote: "Pretend we call an IsValid() method in the hardlock."

That is where you go wrong, in my code I don't even have to check for
the presence of the hardlock. The entire executable/dll is crypted with
a 128bit encryption method. It needs the hardlock to first decrypt the
code then run it. Code similar to what you showed is nowhere to be found
in my software. I'll describe the process:

1. I create and compile program just like any other
2. attach the customers hardlock with a specific module address
3. attach our company specific crypt lock
4. run the compiled program through a crypt program that crypts the
executable with the customers hardlock
5. burn it on CD and ship it and the hardlock to the customer

Now the executable/dll has changed alot. Aside from the encryption, it
is encapsulated in a software envelope that will automatically decrypt
it when needed. The envelope doesn't simply check if the hardlock is
available, it NEEDS it to be there to even be able to decrypt the
machine code and run it.

Think of PGP. PGP encrypt your program. Can you run it? No. Can you go
in there, change 1 bit and have you then defeated the PGP encryption?
No. You need to decrypt the program first before you can use it. The
hardlock does this on the fly, but all the while it obfuscates it
behaviour making it very hard for anyone with special software (like
WinIce) to see what is going on.

You can use it like you described, but that would defeat the purpose of
having one simply because it can be broken like you showed. But proper
use of the hardlock makes it very very hard to break.

William Stacey [MVP] wrote:

Thanks Rinze. Was not trying to be flippant with response. I assume your
talking license management here. If something else, please expand. To have
context here, lets assume we are talking license check as that is what site
mainly talks about. And your right, we probably can't crack the device or
internal structures. However, I still don't need to. Pretend we call an
IsValid() method in the hardlock. It does and does its thing with checking
keys, decrypting, xyz, etc. That is fine and good. But now, my main code
at some point need to check some reply from the hardlock to see if that was
valid or license failure. So my code my look like this (could be anything)
:

private void MainForm_Load(object sender, System.EventArgs e)
{
bool valid = HardLock.IsValid(); // HardLock goes and does its
magic.
if ( ! valid )
MessageBox.Show("Thank you for using our software. Please
obtain a valid license at xyz.com.");
}

So I can still bypass your HardLock all together with a mod to the code. I
don't need to break the hardlock, I just need to change your code. The
return value my not be a bool but something else. You can still do the same
thing. Now if all your code is in the hardlock, then that is probably a
different issue - but not sure we are talking about that. Truly interested
in this, so please post some other example if I am in error. I did look at
the site. The idea is good, but in the end it is a fancy dongle that people
will not buy sw that requires a dongle/smartcard/smart usb device (at least
a lot of people will not.) A good obfuscator and PKI would probably work as
well to make it very difficult to crack your code without requiring the
dongle. Now if we could load the whole program in the dongle and run it
from there, that may be a little more interesting. Instead of distributing
CDs or exe, you send out USB device with sw on it. Still a dongle however,
and you still have the perception issue. Is your software that great that
people will carry around this dongle with them. What if everyone did this,
I would have 20 dongles sticking out of my machine (If I could even get that
many usb ports.) As a user, chances are a non-dongle SW alternative starts
looking more attractive as the dongle feels like one more thing to keep
track of that I don't need. That said, for some high security applications,
this may be the right choice.

--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #42

I gotta now. I see what they are doing. I would never spend time on it,
but from a discussion standpoint, I still wonder how much better that is
then encrypting the dll yourself and encrypting the key in the loader or
something. I think under both (hardlock and self encrypted dll) you have
some key used for decryption into memory and/or disk. Naturally, one could
use "corddb myapp.exe" to find the plain key passed to Rijndael (et al) for
decryption and just use that to manually decrypt the dlls. That is an
additional step that takes most folks out-of-the-game. But your not really
protecting from them. Your really protecting from the crackers that live
inside debuggers and read asm like the morning paper just to publish a crack
or keygen to their buddies on the INET.
Still sounds interesting, but don't think majority would ever buy sw that
requires dongles (as history shows us.) Also not sure how much better this
is (in reality) then decrypting and loading your own dll in a loader?

Just curious, now that we spent time on this, what kind of application are
your protecting? Thanks for your patience and helping me understand.
Cheers.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"C-Services Holland b.v." <cs*@REMOVEcsh4u.nl> wrote in message
news:dZ********************@zeelandnet.nl...

You don't seem to understand the crypting process.

quote: "Pretend we call an IsValid() method in the hardlock."

That is where you go wrong, in my code I don't even have to check for
the presence of the hardlock. The entire executable/dll is crypted with
a 128bit encryption method. It needs the hardlock to first decrypt the
code then run it. Code similar to what you showed is nowhere to be found
in my software. I'll describe the process:

1. I create and compile program just like any other
2. attach the customers hardlock with a specific module address
3. attach our company specific crypt lock
4. run the compiled program through a crypt program that crypts the
executable with the customers hardlock
5. burn it on CD and ship it and the hardlock to the customer

Now the executable/dll has changed alot. Aside from the encryption, it
is encapsulated in a software envelope that will automatically decrypt
it when needed. The envelope doesn't simply check if the hardlock is
available, it NEEDS it to be there to even be able to decrypt the
machine code and run it.

Think of PGP. PGP encrypt your program. Can you run it? No. Can you go
in there, change 1 bit and have you then defeated the PGP encryption?
No. You need to decrypt the program first before you can use it. The
hardlock does this on the fly, but all the while it obfuscates it
behaviour making it very hard for anyone with special software (like
WinIce) to see what is going on.

You can use it like you described, but that would defeat the purpose of
having one simply because it can be broken like you showed. But proper
use of the hardlock makes it very very hard to break.

William Stacey [MVP] wrote:
Thanks Rinze. Was not trying to be flippant with response. I assume your talking license management here. If something else, please expand. To have context here, lets assume we are talking license check as that is what site mainly talks about. And your right, we probably can't crack the device or internal structures. However, I still don't need to. Pretend we call an IsValid() method in the hardlock. It does and does its thing with checking keys, decrypting, xyz, etc. That is fine and good. But now, my main code at some point need to check some reply from the hardlock to see if that was valid or license failure. So my code my look like this (could be anything) :

private void MainForm_Load(object sender, System.EventArgs e)
{
bool valid = HardLock.IsValid(); // HardLock goes and does its
magic.
if ( ! valid )
MessageBox.Show("Thank you for using our software. Please
obtain a valid license at xyz.com.");
}

So I can still bypass your HardLock all together with a mod to the code. I don't need to break the hardlock, I just need to change your code. The
return value my not be a bool but something else. You can still do the same thing. Now if all your code is in the hardlock, then that is probably a
different issue - but not sure we are talking about that. Truly interested in this, so please post some other example if I am in error. I did look at the site. The idea is good, but in the end it is a fancy dongle that people will not buy sw that requires a dongle/smartcard/smart usb device (at least a lot of people will not.) A good obfuscator and PKI would probably work as well to make it very difficult to crack your code without requiring the
dongle. Now if we could load the whole program in the dongle and run it from there, that may be a little more interesting. Instead of distributing CDs or exe, you send out USB device with sw on it. Still a dongle however, and you still have the perception issue. Is your software that great that people will carry around this dongle with them. What if everyone did this, I would have 20 dongles sticking out of my machine (If I could even get that many usb ports.) As a user, chances are a non-dongle SW alternative starts looking more attractive as the dongle feels like one more thing to keep
track of that I don't need. That said, for some high security applications, this may be the right choice.

--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #43

mmarsh

Have you considered Protector from Remotesoft.com?
It "completely stops MSIL disassembly and decompilation"
Mike Marsh

"Robby" wrote:

Well, I was talking about NGEN so your statements are incorrect. NGEN
assemblies do not require you to distribute MSIL.

Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Robby <ed****@not.my.email.com> wrote:
Using the NGEN utility is not ignoring the .Net Framework. It is a part
of
the .Net Framework. Machine code compiled assembiles still need the .Net
Framework installed to run. You should not make grossly incorrect
statements like that.

I think you should be careful about the fact before accusing others of
making grossly incorrect statements:

1) NGENed assemblies still require the original IL, so don't help in
the slightest.
2) If you'd followed the link I provided, you'd see that the products I
was referring to *don't* require the .NET framework to be installed
- they include everything that's required. I wasn't talking about
NGEN, as it doesn't accomplish the desired goal.

Of course, if you don't believe me about the first point, you'd
presumably be happy to send me an NGENed executable which you believe
doesn't contain any IL. If you can do so, *then* I'll apologise for
making a grossly incorrect statement.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #44

William Stacey [MVP] wrote:

I gotta now. I see what they are doing. I would never spend time on it,
but from a discussion standpoint, I still wonder how much better that is
then encrypting the dll yourself and encrypting the key in the loader or
something. I think under both (hardlock and self encrypted dll) you have
some key used for decryption into memory and/or disk. Naturally, one could
use "corddb myapp.exe" to find the plain key passed to Rijndael (et al) for
decryption and just use that to manually decrypt the dlls. That is an
additional step that takes most folks out-of-the-game. But your not really
protecting from them. Your really protecting from the crackers that live
inside debuggers and read asm like the morning paper just to publish a crack
or keygen to their buddies on the INET.
Still sounds interesting, but don't think majority would ever buy sw that
requires dongles (as history shows us.) Also not sure how much better this
is (in reality) then decrypting and loading your own dll in a loader?

Just curious, now that we spent time on this, what kind of application are
your protecting? Thanks for your patience and helping me understand.
Cheers.

The problem with decrypting the code yourself is that you have a readily
accessable decryption module in your software to decrypt the DLL. That
would make it a breeze for any decent cracker to break your protection.

We have engineering software for factories and such where very simply
put they store every connection (power/signal lines etc) and instrument
and what not in a database. It's a very expensive piece of software.

One of our other leading products is software for calculating
powercables to conform to the Dutch NEN norm. That ranges from wiring in
your home to streetlighting. Our main concern in the early days was
decompilation protection (VB4, easily decompiled to vb source). So we
used the hardlock encryption to stop people getting at our math modules.
These days it's a bit harder, but we still use it for licencing purposes
so we can control how many copies can be started at one time,
serverlocks are available so they can just plug it onto a Novell or
Windows server for instance.

Now I agree with you that for most software packages this solution is
way to expensive. The hardlock itself costs about as much as the average
game. But the same company also provides a software solution
(http://www.ealaddin.com/HASPSL/default.asp) which may be much more
interesting to more developers since it doesn't require a piece of
hardware and this distribution via the web is so much easier. How secure
that is, I can't say. But I do know the hardlock encryption is very
tough to crack.

In the end, any protection can be broken. I think our software is too
specific to be interesting enough for any hacking group to spend it's
efforts on, so we (our company that is) are reasonably safe.
--
Rinze van Huizen
C-Services Holland b.v.

Jul 21 '05 #45

Marco van Nieuwenhoven

Hi,

I'm working with C# now for the last months and just discovered that
obfuscating is not enough. My sourcecode is not considered safe anymore
because it can now be easily decoded with products like Remotesoft's software.

How can I protect myself? An answer could be using the protector software
from Remotesoftware but how sure can I be that this is also not breakable.
What is the technique used by Protector and is it considered safe?

Is it possible in anyway to link my assemblies into native code without
having to include my IL code. Even obfuscating IL code is not really safe
because the algorithm is 'easily' breakable.

Anyone?

"mmarsh" wrote:

Have you considered Protector from Remotesoft.com?
It "completely stops MSIL disassembly and decompilation"
Mike Marsh

"Robby" wrote:

Well, I was talking about NGEN so your statements are incorrect. NGEN
assemblies do not require you to distribute MSIL.

Robby

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Robby <ed****@not.my.email.com> wrote:
> Using the NGEN utility is not ignoring the .Net Framework. It is a part
> of
> the .Net Framework. Machine code compiled assembiles still need the .Net
> Framework installed to run. You should not make grossly incorrect
> statements like that.

I think you should be careful about the fact before accusing others of
making grossly incorrect statements:

1) NGENed assemblies still require the original IL, so don't help in
the slightest.
2) If you'd followed the link I provided, you'd see that the products I
was referring to *don't* require the .NET framework to be installed
- they include everything that's required. I wasn't talking about
NGEN, as it doesn't accomplish the desired goal.

Of course, if you don't believe me about the first point, you'd
presumably be happy to send me an NGENed executable which you believe
doesn't contain any IL. If you can do so, *then* I'll apologise for
making a grossly incorrect statement.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #46

Christian Gudrian

Massimo schrieb:

Find that statement, and you crack the program...

But if the assembly is signed it will fail to load when patched. Or has
the framework already been hacked in a way that prevents signed
assemblies from getting verified?

Christian

Jul 21 '05 #47

Marco van Nieuwenhoven <Ma******************@discussions.microsoft.com>
wrote:

I'm working with C# now for the last months and just discovered that
obfuscating is not enough. My sourcecode is not considered safe anymore
because it can now be easily decoded with products like Remotesoft's software.
But can it actually be *understood*?
How can I protect myself? An answer could be using the protector software
from Remotesoftware but how sure can I be that this is also not breakable.
What is the technique used by Protector and is it considered safe?
You'd have to ask RemoteSoft.
Is it possible in anyway to link my assemblies into native code without
having to include my IL code. Even obfuscating IL code is not really safe
because the algorithm is 'easily' breakable.

Yes - follow the links I posted before. However, people will still be
able to decompile your code. It'll take a bit longer, but it's far from
impossible.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #48