A
Aaron
Is it possible to compile a dll that only works on my machine? if
someone steals it, it would not work on their machine.
someone steals it, it would not work on their machine.
S
Stephany Young
Yes.
There are many mechanisms you could use, but one would be to get the machine
name at runtime and compare it to a hard-coded value.
There are many mechanisms you could use, but one would be to get the machine
name at runtime and compare it to a hard-coded value.
S
Steven Wood
This is a tricky subject, however. I am looking at it presently for a
client for some commercial software I am developing. We want to protect our
code from crackers and also competitors.
Because the .NET Framework compiles your managed code into Intermediate
Language (IL) then we are looking at using an obfuscator to deter a hacker
from attempting to modify our code that performs the licensing checks. Note
I use the word 'deter'. From my research, I believe that obfuscation does
not provide 100% protection - I await any counter arguments from the
obfuscation vendors
Therefore I am looking at a mix-and-match combination of techniques to
achieve a level of security that is 'good enough', e.g. online registration
via a web server, a record of authorized features in a digitally signed XML
file, a strongly named assembly in the Global Assembly Cache (GAC) with a
security certificate registered in the client's company name, and
obfuscation of the IL.
Ultimately, the whole security system is built on the obfuscation as, at
present, there is no way (AFAIK) of storing a secret on a user's computer.
There are plenty of discussions on this subject going on in
microsoft.public.dotnet.security.
O'Reilly have published an excellent book 'Programming .NET Security' ISBN
0-596-00442-7.
client for some commercial software I am developing. We want to protect our
code from crackers and also competitors.
Because the .NET Framework compiles your managed code into Intermediate
Language (IL) then we are looking at using an obfuscator to deter a hacker
from attempting to modify our code that performs the licensing checks. Note
I use the word 'deter'. From my research, I believe that obfuscation does
not provide 100% protection - I await any counter arguments from the
obfuscation vendors
Therefore I am looking at a mix-and-match combination of techniques to
achieve a level of security that is 'good enough', e.g. online registration
via a web server, a record of authorized features in a digitally signed XML
file, a strongly named assembly in the Global Assembly Cache (GAC) with a
security certificate registered in the client's company name, and
obfuscation of the IL.
Ultimately, the whole security system is built on the obfuscation as, at
present, there is no way (AFAIK) of storing a secret on a user's computer.
There are plenty of discussions on this subject going on in
microsoft.public.dotnet.security.
O'Reilly have published an excellent book 'Programming .NET Security' ISBN
0-596-00442-7.
H
Huihong Luo
There are other means than obfuscation for code protection. Obfuscation is
the very first step that makes decompilation a bit more difficult, but does
not prevent disassembly at all,. We offers a series of award winning
products to secure your .NET code. We offer the best protection strategy on
the market with a breadth of product offering.
(1) protector, completely prevents disassembly (no more ildasm) and
decompilation, also offers string and resource protection. MSIL code is
replaced with x86 machine code.
http://www.remotesoft.com/salamander/protector.html
(2) obfuscator, make reverse engineering more difficult, the easiest to use.
Next release will make obfuscation a truely painless, and totally automated
process. support C#, VB.NET, J#, MC++, etc.
http://www.remotesoft.com/salamander/obfuscator.html
(3) Linker and mini-deployment tool. The linker tool automatically finds
all required methods/classes and link all dependent EXE or DLL files into a
single assembly. Even the .NET framework libraries can be linked into your
own code, and thus make it easier to deploy and very hard to decompile. We
also offer tools to help you to deploy only the very minimum set of files
without installing the whole Microsoft .NET framework.
http://www.remotesoft.com/linker
(4) native compiler, link and compile .NET executables to x86 native code,
run w/o .NET framework, coming soon.
This would be very useful for WinForms applications as the compiled code can
be deployed to more machines, and make it secure.
(5) salamander .NET decompiler, show how easy to get source code from the
..NET assemblies,
http://www.remotesoft.com/salamander/index.html
Huihong
Remotesoft
the very first step that makes decompilation a bit more difficult, but does
not prevent disassembly at all,. We offers a series of award winning
products to secure your .NET code. We offer the best protection strategy on
the market with a breadth of product offering.
(1) protector, completely prevents disassembly (no more ildasm) and
decompilation, also offers string and resource protection. MSIL code is
replaced with x86 machine code.
http://www.remotesoft.com/salamander/protector.html
(2) obfuscator, make reverse engineering more difficult, the easiest to use.
Next release will make obfuscation a truely painless, and totally automated
process. support C#, VB.NET, J#, MC++, etc.
http://www.remotesoft.com/salamander/obfuscator.html
(3) Linker and mini-deployment tool. The linker tool automatically finds
all required methods/classes and link all dependent EXE or DLL files into a
single assembly. Even the .NET framework libraries can be linked into your
own code, and thus make it easier to deploy and very hard to decompile. We
also offer tools to help you to deploy only the very minimum set of files
without installing the whole Microsoft .NET framework.
http://www.remotesoft.com/linker
(4) native compiler, link and compile .NET executables to x86 native code,
run w/o .NET framework, coming soon.
This would be very useful for WinForms applications as the compiled code can
be deployed to more machines, and make it secure.
(5) salamander .NET decompiler, show how easy to get source code from the
..NET assemblies,
http://www.remotesoft.com/salamander/index.html
Huihong
Remotesoft
S
Steven Wood
Which is exactly what I said; one needs a 'good enough' solution. I believe
that native code can be put through a debugger to look for critical values
such as encryption keys.
I tried a trial of your obfuscator and had it do the full works on some
assemblies, but all my drop down list boxes stopped working; they were bound
to different typed datasets. Maybe it was something I did.
I shall be keen to see your next version, I am especially interested in the
direction you are taking with integration of obfuscation with the build
process, either through the IDE or scripts. The last thing I need when I'm
shipping is problems in this area, especially when a client wants a CD
yesterday.
that native code can be put through a debugger to look for critical values
such as encryption keys.
I tried a trial of your obfuscator and had it do the full works on some
assemblies, but all my drop down list boxes stopped working; they were bound
to different typed datasets. Maybe it was something I did.
I shall be keen to see your next version, I am especially interested in the
direction you are taking with integration of obfuscation with the build
process, either through the IDE or scripts. The last thing I need when I'm
shipping is problems in this area, especially when a client wants a CD
yesterday.
H
Huihong Luo
I agree with you. Spending precious development time on things like
obfuscation is ridiculous, it kills me. However, there is one unsolvable
reflection-related problem that any obfuscators are facing, that is, a
developer must manually exclude certain symbols from obfuscation, otherwise
the obfuscated code won't work. This problem prevents any true integration.
Wizard-driven obfuscation can not be done. In fact, >80% work of an
obfuscator is dealing with this painful configuration process.
We will deliver a new solution that makes obfuscation an enjoyable
experience.
Ideally, one should just click a few buttons, and then ship the processed
product.
The bug you get with the drop down list seems to do with some custom
attributes, we fixed a few bugs on that front. Will post a new build during
next week.
Huihong
http://www.remotesoft.com/salamander/obfuscator.html
obfuscation is ridiculous, it kills me. However, there is one unsolvable
reflection-related problem that any obfuscators are facing, that is, a
developer must manually exclude certain symbols from obfuscation, otherwise
the obfuscated code won't work. This problem prevents any true integration.
Wizard-driven obfuscation can not be done. In fact, >80% work of an
obfuscator is dealing with this painful configuration process.
We will deliver a new solution that makes obfuscation an enjoyable
experience.
Ideally, one should just click a few buttons, and then ship the processed
product.
The bug you get with the drop down list seems to do with some custom
attributes, we fixed a few bugs on that front. Will post a new build during
next week.
Huihong
http://www.remotesoft.com/salamander/obfuscator.html