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.
[color=blue]
>-----Original Message-----
>This thread is intended to be more of a discussion[/color]
thread - because i value[color=blue]
>the opinions of the posters in this newsgroup, and[/color]
especially the MVPs like[color=blue]
>Nicholas Paladino and Jon Skeet (thanks to all of you for[/color]
your help over the[color=blue]
>years).
>
>My company has been toying with moving alot of our[/color]
applications to .NET/C#[color=blue]
>(which makes me _very_ happy). I've successfully gotten[/color]
them to start new[color=blue]
>projects using C# and we have been very happy with the[/color]
results so far.[color=blue]
>
>However, the one primary concern i am running up against[/color]
in this pro-.NET[color=blue]
>push is that my boss, as well as some of the people that[/color]
wrote the "old" C++[color=blue]
>code, doesn't want some of the more important algorithms[/color]
they use in our[color=blue]
>more critical applications to be easily read via a[/color]
disassembler (even[color=blue]
>ILDASM) or even turned back into C# code by some of the[/color]
applications out[color=blue]
>there that are available for that.
>
>I'm kind of at a loss for an answer to them on this, so[/color]
as of now, i haven't[color=blue]
>gained much ground. The possible solutions (and reasons[/color]
why i don't like[color=blue]
>them) that i've come up with so far, are as follows:
>
>1) Obfuscation: Although this makes it more difficult to[/color]
read, it doens't[color=blue]
>completely hide the algorithms/theory of the[/color]
classes/functions in the[color=blue]
>assembly. I've also heard that it has caused people some[/color]
issues where[color=blue]
>assemblies wouldn't execute after being obfuscated.
>2) Using Managed C++ and including native C++ lib files:[/color]
I can't remember if[color=blue]
>i ever got this working when i tried it myself, but i do[/color]
remember it being[color=blue]
>quite a pain. part of that came from the fact that i[/color]
don't like the .NET[color=blue]
>implementation in C++ (compared to the C# one) - it seems[/color]
very kludgy. If[color=blue]
>this does actually work, then its a possibility, though[/color]
not a very clean[color=blue]
>one.
>3) Creating native C++ DLLs and using interop to get to[/color]
them from C#: This[color=blue]
>was the method i was most successful with, but, partially[/color]
because of the[color=blue]
>complexity of some of the functions/classes our old[/color]
applications were using[color=blue]
>and partially because i'm not all too familiar with[/color]
marshalling/interop, i[color=blue]
>ended up with some not very nice looking code to allow C#[/color]
to work well with[color=blue]
>the functions.
>
>#2 and #3 also just didn't seem like very good options[/color]
for some of the[color=blue]
>thigns i was converting because the algorithms i was[/color]
trying to hide were[color=blue]
>fairly closely tied in with the main operation of the[/color]
applications (the[color=blue]
>parts that would be in .NET).
>
>Basically, i'm curious to find out what others think[/color]
about all this, and[color=blue]
>what others are doing in their own workplaces. I'm big on[/color]
C#/.NET and i'd[color=blue]
>love to get the company moving to as much of this as[/color]
possible, but i don't[color=blue]
>know where to go from here.
>
>Thanks in advance for any comments/suggestions!
>
>
>.
>[/color]
