IL Code Security

[Tim Mulholland]

This thread is intended to be more of a discussion thread - because i value
the opinions of the posters in this newsgroup, and especially the MVPs like
Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the
years).

My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I've successfully gotten them to start new
projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++
code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i haven't
gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens't
completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if
i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using
and partially because i'm not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with
the functions.

#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.

Thanks in advance for any comments/suggestions!

[Tim Mulholland]

I forgot one other part of what i was going to say.

I'm sort of surprised that Microsoft hasn't provided something (better than
the dotfuscator community edition) to prevent this issue. With the strong
..NET push they've had, and their intentions of having a very fast and strong
uptake on .NET applications over the first couple years - it would seem that
this issue would be one of the major stumbling blocks for them.

Because it is possible for the assembly code to not show up when
disassembled (see the use of __asm in Managed C++ applications), it would
seem that there must be a way to "hide" this information, or even to allow
developers to choose (possibly with an Attribute) which functions are
pre-compiled, while the rest are turned to IL like normal. This could
obviously be optional - so all the tremendous benefits of a pure-IL .NET
application would be there, but if a developer needed that extra bit of code
security, they'd have it.

I'm sure this has been discussed before, and i'm sure there are good
reasons - i just haven't seen these discussions or the reasons.

Thanks again!

[gabriel]

Tim Mulholland wrote:

Basically, i'm curious to find out what others think about all this,

Let your boss know that it is rather straightforward to disassemble a C/C++
application and if you are looking for an algorithm in particular, it is
even easier to get from the generated assembler.

Likewise, you can reverse engineer .NET IL. I use Thinstall to obfuscate
and prevent memory-peeking which is a way to get aroung obfuscation of .NET
assemblies.

There is no perfect solution for either .NET or older stuff.

--
gabriel

[gabriel]

Tim Mulholland wrote:

I'm sort of surprised that Microsoft hasn't provided something (better
than the dotfuscator community edition) to prevent this issue. With

That's because you can't really prevent a truly determined hacker from
reverse engineering anything. The instructions eventually have to be on a
memory location so the CPU can follow them. No matter what encryption,
obfuscation, encoding or whtever, the instructions will eventually be there
and reverse-engineerable. All you can hope for is to make it hard enough
for them to reverse engineer.

If you have truly secret algorithms, then set up a web service where the
key algorithm runs on your company's server away from the client at the
customer site. This is pretty much the best you can do.

--
gabriel

[Tim Mulholland]

I agree that its not too hard to find out the workings of a normal C/C++
application - though from my personal experience i would say that doing it
with .NET is alot easier. I would wager that someone with little experience
in this type of thing could more easily do it with a .NET assembly than with
a native-compiled executable/dll.
The boss knows this, and just doesn't want to make it any easier i guess
(bosses and 'workers' too often have differing viewpoints, don't they? :) )

I'll look into the Thinstall application you mentioned.

Tim

"gabriel" <[e-mail]> wrote in message
news:33***************************@msgid.meganewss ervers.com...

Tim Mulholland wrote:

Basically, i'm curious to find out what others think about all this,
Let your boss know that it is rather straightforward to disassemble a

C/C++ application and if you are looking for an algorithm in particular, it is
even easier to get from the generated assembler.

Likewise, you can reverse engineer .NET IL. I use Thinstall to obfuscate
and prevent memory-peeking which is a way to get aroung obfuscation of ..NET assemblies.

There is no perfect solution for either .NET or older stuff.

--
gabriel

[Philip Rieck]

On 1)

Just because native-compiled C++ doesn't use IL doesn't mean that you can't
disassemble it... it just turns to x86 assembly instead of IL assembly. In
fact, there have been decompilers (turns assembly back to C) for many
years -- and disassemblers since the dawn of assemblers.

Now, taking a compiled c# assembly and decompiling is MUCH easier and gives
better results than decompiling compiled C/C++ libraries. Also, the .net
decompilers are very easy to get and easy to use, so they take a lot less
effort to apply to code.

However, obfuscators like dotfuscator or demeanor make it much, much harder.
I'd say that decompiling obfuscated c# is harder than decompiling
non-obfuscated c++. --By decompiling, I mean turning the compiled product
into useful / readable / navigable code. That may be disassembling or
decompiling or both

If using obfuscated .net code isn't an option because of concerns about
these methods, then native unprotected c++ probably isn't either. My quick
and dirty rule of thumb has been to say if a company didn't think of this as
a risk when distributing native code, then obfuscated IL is just fine.
There have been obfuscators on the market for a long time due to just this
concern - .net is no exception.

I can't really address your concerns of non-executable obfuscated
assemblies, as I haven't had this issue. However, I will be researching it
as it could be quite a concern.
"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

This thread is intended to be more of a discussion thread - because i value the opinions of the posters in this newsgroup, and especially the MVPs like Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the years).

My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I've successfully gotten them to start new
projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++ code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i haven't gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens't
completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using and partially because i'm not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with the functions.

#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.

Thanks in advance for any comments/suggestions!

[Tim Mulholland]

I agree with you here, just like with your other post...
but "hard enough" for me seems to be different from "hard enough" for my
boss. He seems to consider the current native exe/dll files to be the
standard, and anything even remotely less than that isn't good enough.

I've been exploring the use of web services for some of our applications. It
is viable in some cases - but we have other cases where we can guarantee the
clients will not have internet access, so it wouldnt be at all feasible in
those cases - unfortunately.

Tim

"gabriel" <[e-mail]> wrote in message
news:27***************************@msgid.meganewss ervers.com...

Tim Mulholland wrote:

I'm sort of surprised that Microsoft hasn't provided something (better
than the dotfuscator community edition) to prevent this issue. With
That's because you can't really prevent a truly determined hacker from
reverse engineering anything. The instructions eventually have to be on a
memory location so the CPU can follow them. No matter what encryption,
obfuscation, encoding or whtever, the instructions will eventually be

there and reverse-engineerable. All you can hope for is to make it hard enough
for them to reverse engineer.

If you have truly secret algorithms, then set up a web service where the
key algorithm runs on your company's server away from the client at the
customer site. This is pretty much the best you can do.

--
gabriel

[Daniel O'Connell [C# MVP]]

"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

I forgot one other part of what i was going to say.

I'm sort of surprised that Microsoft hasn't provided something (better than the dotfuscator community edition) to prevent this issue. With the strong
.NET push they've had, and their intentions of having a very fast and strong uptake on .NET applications over the first couple years - it would seem that this issue would be one of the major stumbling blocks for them.

Because it is possible for the assembly code to not show up when
disassembled (see the use of __asm in Managed C++ applications), it would
seem that there must be a way to "hide" this information, or even to allow
developers to choose (possibly with an Attribute) which functions are
pre-compiled, while the rest are turned to IL like normal. This could
obviously be optional - so all the tremendous benefits of a pure-IL .NET
application would be there, but if a developer needed that extra bit of code security, they'd have it.

No, all they'd have is a false sense of security. As gabriel pointed out,
all code *is* reverse engineerable. IL may make it *easier* for the code to
be reverse engineered, but probably not significantly so. As I've stated
before, you may buy yourself two or three days(if your algorithm is complex
enough), is that enough time to matter? A complex algorithm in C# can be
fairly difficult to understand, especially if no meaningful variable names
are provided
int var001,var002, var003;

doesn't exactly tell you much. The time to understand it in IL would be a
little longer, a little longer still in x86. However it can be understood
and people *will* take the time to understand it if its valuable, no matter
what language you use. The question you need to ask is will .NET increase
your products value, increase sales, increase customer satisfaction.
Worrying about code protection is anti-productive at best. You will spend
time, possibly alot of time, doing things you can't measure and that won't
matter when you could be getting work done that is perceptable and increases
code value.

Anyway, using obfustication and some other minor tricks should be enough to
turn back most issues. If your code has to interop with other code(plugins,
its a library, whatever), there are still tricks you can use to make it a
*little* harder for a cracker to determine exactly what is going on, but at
a performance cost.
I'm sure this has been discussed before, and i'm sure there are good
reasons - i just haven't seen these discussions or the reasons.

Thanks again!

[Tim Mulholland]

> If using obfuscated .net code isn't an option because of concerns about

these methods, then native unprotected c++ probably isn't either. My quick and dirty rule of thumb has been to say if a company didn't think of this as a risk when distributing native code, then obfuscated IL is just fine.
There have been obfuscators on the market for a long time due to just this
concern - .net is no exception.
Between you and gabriel this seems to be the consensus. I more or less had
this opinion, but wasn't sure if it was just my opinion, or if it was shared
by others. Maybe if a few more people make the same comments on here, i can
point that out to the boss and see if that makes any difference.

I can't really address your concerns of non-executable obfuscated
assemblies, as I haven't had this issue. However, I will be researching it as it could be quite a concern.

I haven't experienced this personally, but when i started researching
obfuscators, i did run across several people stating there were sometimes
problems with the output (in reference to various obfuscators, not just a
single one). If i run across any examples of what i read before, i'll post
them.

[Tim Mulholland]

> The question you need to ask is will .NET increase

your products value, increase sales, increase customer satisfaction.
Worrying about code protection is anti-productive at best. You will spend
time, possibly alot of time, doing things you can't measure and that won't
matter when you could be getting work done that is perceptable and increases code value.

That sounds like the type of statement i can take to my boss. Like i said to
gabriel and Philip, i've been much less concerned with this issue than he
has been. I'd much rather be moving on to more parts of the code or to v2.0
of a product instead of finding a way to "hide" the company secrets. He has
alot more invested in this original code and thus finds it a bit more
important to hide it i suppose. Maybe reading what you all are saying will
change his mind a bit...

[Brian W]

If your boss is so convinced that the algorithms are more secure in C++
then just put them into a DLL (if they arent already) and use P/Invke to
call the functions.

That's what I would do, if disassembly was my concern.
My $.02

Good luck
Brian W

BTW, there is another (better?) version of the Dotfucator available
"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

This thread is intended to be more of a discussion thread - because i value the opinions of the posters in this newsgroup, and especially the MVPs like Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the years).

My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I've successfully gotten them to start new
projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++ code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i haven't gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens't
completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using and partially because i'm not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with the functions.

#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.

Thanks in advance for any comments/suggestions!

[Tim Mulholland]

That has been the most viable solution i've run across so far - though i ran
into some issues with some of the classes/functions that were closely tied
to how the application works. But those are more specific instances for
another thread on another day :)

"Brian W" <brianw@gold_death_2_spam_rush.com> wrote in message
news:uo**************@TK2MSFTNGP12.phx.gbl...

If your boss is so convinced that the algorithms are more secure in C++
then just put them into a DLL (if they arent already) and use P/Invke to
call the functions.

That's what I would do, if disassembly was my concern.
My $.02

Good luck
Brian W

BTW, there is another (better?) version of the Dotfucator available
"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

This thread is intended to be more of a discussion thread - because i value

the opinions of the posters in this newsgroup, and especially the MVPs

like

Nicholas Paladino and Jon Skeet (thanks to all of you for your help over

the

years).

My company has been toying with moving alot of our applications to ..NET/C# (which makes me _very_ happy). I've successfully gotten them to start new projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET push is that my boss, as well as some of the people that wrote the "old"

C++

code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i

haven't

gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens't completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if

i ever got this working when i tried it myself, but i do remember it

being quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were

using

and partially because i'm not all too familiar with marshalling/interop, i ended up with some not very nice looking code to allow C# to work well

with

the functions.

#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd love to get the company moving to as much of this as possible, but i don't know where to go from here.

Thanks in advance for any comments/suggestions!

[gabriel]

Tim Mulholland wrote:

I'll look into the Thinstall application you mentioned.

I guess I have it easier than you, my boos just took my word for it that
I could use the Thinstall thing and move on with life. We have some
patented business methods and hardware and we rely on the Thinstall for
protecting the .NET executables from reverse engineers. Given that our
devices run C++ applications, we simply assume the executables _will_ be
reverse enginneered and we have put other mechanisms in place to limit
damage.

Good luck though.

PS - Thinstall is a good product, they do update it a lot to prevent
rather nerdy reverse-engineering methods that I found the other
obfusctaors don't even address (such as the forementioned, "read the code
loaded in memory not in the assembly file" method). The only thing I
don't like is that Thinstall "calls home" when you install it. I hate
this practice. If you find something else that does the same thing and
does not call home, let me know please.

--
gabriel

[Tim Mulholland]

I think my boss would probably choke over the suggestion that i spend a
couple grand (we'd need at least the 2 user, probably the 5 user license) on
Thinstall to be able to use C# instead of just sticking with C++
applications.Obviously his opinion on securing the code is very different
from mine, and very different from yours as well... not to mention the fact
that i am several factors more productive with C#/.NET than i am with
C++/MFC/APIs...

I suppose i can always give it a shot :)

Thanks for your comments though. The program seems like quite an impressive
piece of work. I'm still looking into it at this moment...

Tim

"gabriel" <[e-mail]> wrote in message
news:90***************************@msgid.meganewss ervers.com...

Tim Mulholland wrote:

I'll look into the Thinstall application you mentioned.

I guess I have it easier than you, my boos just took my word for it that
I could use the Thinstall thing and move on with life. We have some
patented business methods and hardware and we rely on the Thinstall for
protecting the .NET executables from reverse engineers. Given that our
devices run C++ applications, we simply assume the executables _will_ be
reverse enginneered and we have put other mechanisms in place to limit
damage.

Good luck though.

PS - Thinstall is a good product, they do update it a lot to prevent
rather nerdy reverse-engineering methods that I found the other
obfusctaors don't even address (such as the forementioned, "read the code
loaded in memory not in the assembly file" method). The only thing I
don't like is that Thinstall "calls home" when you install it. I hate
this practice. If you find something else that does the same thing and
does not call home, let me know please.

--
gabriel

[Brian W]

I just wanted to add...

If your boss thinks the algorithms are so "unique" (which I doubt) perhaps
your company should apply for a patent, that way if they are reverse
engineered (regardless of the language used) you are protected legally.

Just another $.02

Regards
Brian W
"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message
news:O%****************@tk2msftngp13.phx.gbl...

That has been the most viable solution i've run across so far - though i ran into some issues with some of the classes/functions that were closely tied
to how the application works. But those are more specific instances for
another thread on another day :)

"Brian W" <brianw@gold_death_2_spam_rush.com> wrote in message
news:uo**************@TK2MSFTNGP12.phx.gbl...

If your boss is so convinced that the algorithms are more secure in C++
then just put them into a DLL (if they arent already) and use P/Invke to
call the functions.

That's what I would do, if disassembly was my concern.
My $.02

Good luck
Brian W

BTW, there is another (better?) version of the Dotfucator available
"Tim Mulholland" <Mu***************@alumni.virginia.edu> wrote in message

news:uP**************@TK2MSFTNGP12.phx.gbl...

This thread is intended to be more of a discussion thread - because i value

the opinions of the posters in this newsgroup, and especially the MVPs

like

Nicholas Paladino and Jon Skeet (thanks to all of you for your help over

the

years).

My company has been toying with moving alot of our applications to .NET/C# (which makes me _very_ happy). I've successfully gotten them to start new projects using C# and we have been very happy with the results so far.

However, the one primary concern i am running up against in this pro-.NET push is that my boss, as well as some of the people that wrote the

"old" C++

code, doesn't want some of the more important algorithms they use in

our more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out there that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i

haven't

gained much ground. The possible solutions (and reasons why i don't like them) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it

doens't completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember

if

i ever got this working when i tried it myself, but i do remember it

being quite a pain. part of that came from the fact that i don't like the ..NET implementation in C++ (compared to the C# one) - it seems very kludgy. If this does actually work, then its a possibility, though not a very clean one.
3) Creating native C++ DLLs and using interop to get to them from C#: This was the method i was most successful with, but, partially because of the complexity of some of the functions/classes our old applications were

using

and partially because i'm not all too familiar with marshalling/interop, i

ended up with some not very nice looking code to allow C# to work well

with

the functions.

#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide

were fairly closely tied in with the main operation of the applications (the parts that would be in .NET).

Basically, i'm curious to find out what others think about all this, and what others are doing in their own workplaces. I'm big on C#/.NET and

i'd love to get the company moving to as much of this as possible, but i don't know where to go from here.

Thanks in advance for any comments/suggestions!

[Huihong]

We offer a series of products addressing the problem.
(1) salamander .net protector
http://www.remotesot.com/salamander/protector.html
(2) salamander .net obfuscator,
http://www.remotesot.com/salamander/obfuscator.html
(3) salamander .net linker,
http://www.remotesot.com/linker/

To the best of my knowledge, if you using the above 3
products, your app will be secure as good as native C/C++
code, or even better.

Native C/C++ code is considered to be safe against reverse
engineering because, to my understanding,

(1) it turns all symbols into memory locations, this is
similiar to what a .NET obfuscator is doing
(2) it has much much fewer entry points, whereas .NET
assemblies expose all classes and methods to the public.
This is, on the other hand, the beauty of the java/.net
platforms, sincee the rich metadata provides many benefits
to developers.
(3) native code instructions are register transfer
languages, while .NET IL is strictly stack based. Stack
based instructions are easier to convert into expressions.

These are the main reasons why I think native code is
safe. If we could convert .NET assemblies into similar
format, then it has the same level of protection against
reverse engineering.

Now let me explain how our products try to achieve that,

(1) the obfuscator performs task (1) by converting symbols
to meaningless ones, similiar to memory locations

(2) the protector converts IL code into native code, so
the instructions can not be decompiled. I have yet to see
a good c/C++ decompiler. None really works.

(3) the linker can be used to link assemblies together,
and thus can be used to remove those public entrypoints.
This performs task (2). The fewer entry points, the better
against reverse engineering.

I believe, this gives the best protection as of today, and
you can relax with a guarantee that no one will be able to
decompile your code, same level of confidence as your old
c/c++ native code.

All other approches including whole assembly encryption
can be cracked, and original files can be recovered by
win32 API interceptions, etc.

Huihong
Remotesoft, Inc.

-----Original Message-----
This thread is intended to be more of a discussion thread - because i valuethe opinions of the posters in this newsgroup, and especially the MVPs likeNicholas Paladino and Jon Skeet (thanks to all of you for your help over theyears).

My company has been toying with moving alot of our applications to .NET/C#(which makes me _very_ happy). I've successfully gotten them to start newprojects using C# and we have been very happy with the results so far.
However, the one primary concern i am running up against in this pro-.NETpush is that my boss, as well as some of the people that wrote the "old" C++code, doesn't want some of the more important algorithms they use in ourmore critical applications to be easily read via a disassembler (evenILDASM) or even turned back into C# code by some of the applications outthere that are available for that.

I'm kind of at a loss for an answer to them on this, so as of now, i haven'tgained much ground. The possible solutions (and reasons why i don't likethem) that i've come up with so far, are as follows:

1) Obfuscation: Although this makes it more difficult to read, it doens'tcompletely hide the algorithms/theory of the classes/functions in theassembly. I've also heard that it has caused people some issues whereassemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember ifi ever got this working when i tried it myself, but i do remember it beingquite a pain. part of that came from the fact that i don't like the .NETimplementation in C++ (compared to the C# one) - it seems very kludgy. Ifthis does actually work, then its a possibility, though not a very cleanone.
3) Creating native C++ DLLs and using interop to get to them from C#: Thiswas the method i was most successful with, but, partially because of thecomplexity of some of the functions/classes our old applications were usingand partially because i'm not all too familiar with marshalling/interop, iended up with some not very nice looking code to allow C# to work well withthe functions.

#2 and #3 also just didn't seem like very good options for some of thethigns i was converting because the algorithms i was trying to hide werefairly closely tied in with the main operation of the applications (theparts that would be in .NET).

Basically, i'm curious to find out what others think about all this, andwhat others are doing in their own workplaces. I'm big on C#/.NET and i'dlove to get the company moving to as much of this as possible, but i don'tknow where to go from here.

Thanks in advance for any comments/suggestions!
.

[Jon Skeet [C# MVP]]

Tim Mulholland <Mu***************@alumni.virginia.edu> wrote:

<snip>

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.

Sorry to weigh in late on this issue - I've been away.

Like the others, I'd consider obfuscation "good enough". As a test, why
not obfuscate your app and then get someone with some .NET experience
to try to reverse engineer it to get the specific algorithm?

Frankly, most algorithms are going to be easier to recreate than to
reverse engineer - people aren't usually paying for algorithms these
days, they're paying for the design around them, and how they're
integrated and packaged together.

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

[Dmitriy Lapshin [C# / .NET MVP]]

Jon,

Frankly, most algorithms are going to be easier to recreate than to
reverse engineer - people aren't usually paying for algorithms these
days, they're paying for the design around them, and how they're
integrated and packaged together.
Given an average business application, I also hardly imagine anything that
would be worth of reverse engineering given the code has been obfuscated,
except for probably licensing/trial limitation code. From my experience I
can tell that any general purpose sophisticated algorithms are very rarely
used, as well as solutions to many pure technical problems can be easily
found on the Net.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

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

<snip>

Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd love to get the company moving to as much of this as possible, but i don't know where to go from here.

Sorry to weigh in late on this issue - I've been away.

Like the others, I'd consider obfuscation "good enough". As a test, why
not obfuscate your app and then get someone with some .NET experience
to try to reverse engineer it to get the specific algorithm?

Frankly, most algorithms are going to be easier to recreate than to
reverse engineer - people aren't usually paying for algorithms these
days, they're paying for the design around them, and how they're
integrated and packaged together.

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

[Tim Mulholland]

what about something, just as an example, like an activation program.
Something akin to the windows product activation stuff Microsoft uses.
That's something that someone wouldn't want to recreate for their own use,
instead they'd want to know exactly how it was done so they could circumvent
it. It would seem that something like this, written in a .NET language,
might be a little too easy to get into. Though perhaps obfuscation would be
enough to deter the majority of would-be crackers.

I just noticed that it seemed like the discusion was leaning towards hiding
business secrets, so i wanted to see if peoples opinions were differet on
something slightly different from patentable and business secrets.

Thanks for everyones input!

"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.com> wrote
in message news:e4**************@TK2MSFTNGP10.phx.gbl...

Jon,

Frankly, most algorithms are going to be easier to recreate than to
reverse engineer - people aren't usually paying for algorithms these
days, they're paying for the design around them, and how they're
integrated and packaged together.

Given an average business application, I also hardly imagine anything that
would be worth of reverse engineering given the code has been obfuscated,
except for probably licensing/trial limitation code. From my experience I
can tell that any general purpose sophisticated algorithms are very rarely
used, as well as solutions to many pure technical problems can be easily
found on the Net.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

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

Tim Mulholland <Mu***************@alumni.virginia.edu> wrote:

<snip>

Basically, i'm curious to find out what others think about all this, and what others are doing in their own workplaces. I'm big on C#/.NET and i'd love to get the company moving to as much of this as possible, but i don't know where to go from here.

Sorry to weigh in late on this issue - I've been away.

Like the others, I'd consider obfuscation "good enough". As a test, why
not obfuscate your app and then get someone with some .NET experience
to try to reverse engineer it to get the specific algorithm?

Frankly, most algorithms are going to be easier to recreate than to
reverse engineer - people aren't usually paying for algorithms these
days, they're paying for the design around them, and how they're
integrated and packaged together.

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

[Jon Skeet [C# MVP]]

Tim Mulholland <Ti***********@nospamaddress.com> wrote:

what about something, just as an example, like an activation program.
Something akin to the windows product activation stuff Microsoft uses.
That's something that someone wouldn't want to recreate for their own use,
instead they'd want to know exactly how it was done so they could circumvent
it. It would seem that something like this, written in a .NET language,
might be a little too easy to get into. Though perhaps obfuscation would be
enough to deter the majority of would-be crackers.

I just noticed that it seemed like the discusion was leaning towards hiding
business secrets, so i wanted to see if peoples opinions were differet on
something slightly different from patentable and business secrets.

Not particularly - because people are still fairly easily able to crack
that kind of thing. Real security doesn't come through the algorithm
being unknown.

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

[Tim Mulholland]

"Real security doesn't come through the algorithm being unknown."

very good point Jon, and thanks for the comments.