security/obfuscation question

  • Thread starter Thread starter Tim Mulholland
  • Start date Start date
T

Tim Mulholland

Hello all,
Our company is trying to write some code in C#/.NET that we don't want an
end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more confusing,
they certainly don't make it impossible for someone to figure out if they
have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file with
some more functionality. (we've read that static linking only works for C++
into Managed C++)
Last, we'll reference that .dll file from the main application (written in
C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using
normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in
the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.


We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?

Are we on the right track here? Is there possibly another option available
to us?

Thanks in advance,

-T
 
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want
to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the
door and add a deadbolt (ship an obfuscated assembly) then it will now take
a more determined and more skilled thief to steal your laptop. Finally, if
you add a security system and hire someone to guard your laptop (ship native
x86 code) someone is going to have to REALLY want that laptop to go to the
trouble to try and steal it but it may still happen. It's just a matter of
how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.
 
As a slight aside, but also fairly related... is it possible to compile c#
code straight to native code (ie instead of having to develop the native
code in C++)?
 
We as a team have discussed this.
Some of us are more inclined to allow the signing to do its job and let that
be.
Others think we need to hide the algorithms more than an obfuscator will
(obfuscators mess with the function calls, but the code in the functions
themselves is pretty easy to decipher).
If this scenario works, we can run with it fairly easy (the code already
exists in both C++ and C#), we're just trying to see if this is
viable/possible.
Thanks for the input though,

Tim
 
As an option, you may want to take a look of our
Salamander .NET protector, it prevents .NET disassembly
and decompilation by replacing MSIL with x86 machine code.

http://www.remotesoft.com/salamander/protector.html
(the protected code still requires .NET framework,
strings and resources can also be protected)

We are also working on a native compiler that links and
converts .NET assemblies to native image, .NET framework
is not required.

more info on the first part, the linker and mini-
deployment tool, is available here:
http://www.remotesoft.com/linker/

This linker is also capable of constructing a bare
minimum set of .NET framework to ship with your product,
so the client machine does not have to install the whole
framework. A typical windows app usually results in a 5MB
zip file, which can be unzipped and run without further
installation. Samples are provided on the web.

Thanks,

Huihong
Remotesoft
 
Will,
This is a definite no-no I'm afraid. C# is 100% managed and HAS to be run
within the runtime.

HTH
Kieran
 
Tim,

If you really think that it is necessary, I dont really see why this wouldnt
work as long as signing works correctly (unfortunately I've never tried this
so I can't comment). The unmanaged C++ code will be in pure unmanaged
machine code so it will be about has hard to decompile as you can reasonably
get.

HTH
Kieran
 
The way that I would approach it is to write your sensative algorithms as
win32 dll's and just use P/Invoke to access them directly with C#.
 
Back
Top