By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,678 Members | 1,144 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,678 IT Pros & Developers. It's quick & easy.

security/obfuscation question

P: n/a
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
Jul 21 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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

Jul 21 '05 #2

P: n/a
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++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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


Jul 21 '05 #3

P: n/a
http://www.oreilly.com/catalog/dotne...chapter/ch02.p
df

I hope that would help a little bit.

IL is assembler for C# so NO, I hope I am not right
(you can pre-interpret-it though)

KK
-----Original Message-----
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 nativecode in C++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in messagenews:uA**************@tk2msftngp13.phx.gbl...
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 nowtake
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 (shipnative
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> Hello all,
> Our company is trying to write some code in C#/.NET that we don't wantan > 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 embeddedin > 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'twork? >
> Are we on the right track here? Is there possibly
another option
available > to us?
>
> Thanks in advance,
>
> -T
>
>


.

Jul 21 '05 #4

P: n/a
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

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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


Jul 21 '05 #5

P: n/a
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
-----Original Message-----
Hello all,
Our company is trying to write some code in C#/.NET that we don't want anend user to be able to see. The algorithms are not that complex, but aresensitive such that if a user could decompile them, they'd be able to bypassalot 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 theyhave 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 tellme i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that intoa .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file withsome 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 inC#) and access the functionality provided by it via normal means.
In addition to all this, we'll be signing all of our .NET assemblies usingnormal 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 alreadybuilt-in, will prevent a user from replacing the Managed C++ .dll with theirown .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded inthe Managed C++ dll, we're making it near impossible for someone todecompile 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 availableto us?

Thanks in advance,

-T
.

Jul 21 '05 #6

P: n/a
KrisK <kk@easylink.com> wrote:
IL is assembler for C# so NO, I hope I am not right


Just to correct this slightly: IL is an assembler for .NET. It's not C#
specific in any way.

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

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

HTH
Kieran

"Will Clark" <wi***@btopenworld.com> wrote in message
news:bj*********@sparta.btinternet.com...
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++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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



Jul 21 '05 #8

P: n/a
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

"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
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

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
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.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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



Jul 21 '05 #9

P: n/a
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#.

"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:#u**************@TK2MSFTNGP12.phx.gbl...
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

Jul 21 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.