Dll

[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.

[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.

"Aaron" <ku*****@yahoo.com> wrote in message
news:b4**************************@posting.google.c om...

Is it possible to compile a dll that only works on my machine? if
someone steals it, it would not work on their machine.

[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.

---
Steven Wood

"Stephany Young" <st******@sysoft.co.nz> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...

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.

"Aaron" <ku*****@yahoo.com> wrote in message
news:b4**************************@posting.google.c om...

Is it possible to compile a dll that only works on my machine? if
someone steals it, it would not work on their machine.

[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

"Steven Wood" <st*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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.

---
Steven Wood

"Stephany Young" <st******@sysoft.co.nz> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...

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.

"Aaron" <ku*****@yahoo.com> wrote in message
news:b4**************************@posting.google.c om...

Is it possible to compile a dll that only works on my machine? if
someone steals it, it would not work on their machine.

[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.

---
Steven Wood

"Huihong Luo" <hu******@stanfordalumni.org> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

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

"Steven Wood" <st*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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.

---
Steven Wood

"Stephany Young" <st******@sysoft.co.nz> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...

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.

"Aaron" <ku*****@yahoo.com> wrote in message
news:b4**************************@posting.google.c om...
> Is it possible to compile a dll that only works on my machine? if
> someone steals it, it would not work on their machine.

[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

"Steven Wood" <st*********@hotmail.com> wrote in message
news:eR**************@tk2msftngp13.phx.gbl...

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.

---
Steven Wood

"Huihong Luo" <hu******@stanfordalumni.org> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

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

"Steven Wood" <st*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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.

---
Steven Wood

"Stephany Young" <st******@sysoft.co.nz> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...
> 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.
>
> "Aaron" <ku*****@yahoo.com> wrote in message
> news:b4**************************@posting.google.c om...
> > Is it possible to compile a dll that only works on my machine? if
> > someone steals it, it would not work on their machine.
>
>