Re: Obfuscation and Salamander
From: Richard Grimes [MVP] (read)
Date: 04/30/04
- Next message: Richard Grimes [MVP]: "Re: passing a delegate to a C function."
- Previous message: Mike: "no dotnet 1.1 service pack?!"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 30 Apr 2004 14:18:01 +0100
Matt wrote:
> Is my only choice to use managed C++? If so what level of source is
> exposed in its assemblies/builds?
Managed C++ generates IL, just as do all the other .NET compilers. You could
compile your secret algorithms as native code (so that the module contains
x86 for the algorithm) and managed C++ does help here because you can tell
the compiler that a function should be compiled as x86 rather than IL, this
x86 code is stored in the assembly.
Of course, any cracker worth his salt will be able to read x86 and will be
able to work out your algorithm. The problem with .NET is that (as you
imply) the metadata in the assembly contains readable class and member
names, this level of information is not normally available with x86 code
unless a symbol file (.pdb or .dbg) is supplied. However, ...
> what's more, for those that don't get Salamander, what is the point
> of using obfuscation (the main use being its obscure class
> overloading and variable renaming) when your own application
> 'ildasm.exe' will give anyone all the original friking names, types
> and variables??
Not true, unless the obfuscator is really lame (in which case don't use it).
In your assembly classes and class members are referred to through tokens,
the compiler will add metadata to the file that gives the full (string) name
of the item that the token refers to. However, for private classes or
private members these string names are not required because the tokens are
sufficient. An obfuscator will replace the string names of such private
members with some unrelated string, so you don't get to see the original
name (friking or not).
This does not work with public classes because the string names are required
by compilers when they compile a class that use them.
Some obfuscators do additional work: they change the code flow to make the
IL less readable.
> My question is simple, why should I, as a freelance developer, spend
> good time producing client/server software and libraries in .net when
> any stupid monkey can extract all of my source using Salamander? And
You say you are a client-server developer. Well, if your server code is
installed on a secure server and is accessed through remoting or a web
service then the person running the client won't have access to the
IL/metadata. (They only need access to the metadata - but not IL - of public
classes and members)
Another suggestion is to ngen the code, however, this has to be done on the
client machine because the ngen'd assembly must be stored into a special
part of the GAC. This is no help to you.
> I'm p**sed and want some good answers or delphi might well become my
> language of choice
That's your choice of course.
It comes down to this: if you have some secret algorithm that is worth
millions of dollars then a cracker will find a way of cracking it whether
the code is compiled to IL, obfuscated IL or x86 - its worth their time and
effort to do so. In this case the algorithm should be run as a web service
on a machine that you trust.
If you are trying to protect your IP then obfuscate the code, or even
compile it to x86 with managed C++. You won't prevent a determined cracker
from getting your algorithm, but you will prevent the casual snooper. Its a
case of making the cost of the effort worth less than the actual information
that they will gain. Some obfuscators are better than others, I can't
recommend one over another because I've not tested them all.
If you compile to x86 then there may be a performance issue - first you have
the issue of thunking between the native and managed worlds (small, but its
still there), and second, after JIT compilation is taken into account JITted
managed C++ IL can have better performance than native C++ x86 (it depends
on the compiler switches you use).
Richard
-- my email evpuneqt@zicf.bet is encrypted with ROT13 (www.rot13.org) sign up for my free .NET newsletter at http://www.wd-mag.com/newsletters/
- Next message: Richard Grimes [MVP]: "Re: passing a delegate to a C function."
- Previous message: Mike: "no dotnet 1.1 service pack?!"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
