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
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
Comment