"Stephany Young" <stephany@sysoft.co.nz> wrote in message
news:OHXbdUPdDHA.1580@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" <kuya789@yahoo.com> wrote in message
> news:b4828959.0309061944.4ce851e7@posting.google.com...
> > 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" <stevennwood@hotmail.com> wrote in message
news:%23f3$6uRdDHA.2168@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" <stephany@sysoft.co.nz> wrote in message
> news:OHXbdUPdDHA.1580@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" <kuya789@yahoo.com> wrote in message
> > news:b4828959.0309061944.4ce851e7@posting.google.com...
> > > Is it possible to compile a dll that only works on my machine? if
> > > someone steals it, it would not work on their machine.
> >
> >
>
>

"Aaron" <kuya789@yahoo.com> wrote in message
news:b4828959.0309061944.4ce851e7@posting.google.com...
> 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" <stevennwood@hotmail.com> wrote in message
news:eR61$lXdDHA.4020@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" <huisinro@stanfordalumni.org> wrote in message
> news:%23k%23msFXdDHA.3232@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" <stevennwood@hotmail.com> wrote in message
> > news:%23f3$6uRdDHA.2168@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" <stephany@sysoft.co.nz> wrote in message
> > > news:OHXbdUPdDHA.1580@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" <kuya789@yahoo.com> wrote in message
> > > > news:b4828959.0309061944.4ce851e7@posting.google.com...
> > > > > 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" <huisinro@stanfordalumni.org> wrote in message
news:%23k%23msFXdDHA.3232@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" <stevennwood@hotmail.com> wrote in message
> news:%23f3$6uRdDHA.2168@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" <stephany@sysoft.co.nz> wrote in message
> > news:OHXbdUPdDHA.1580@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" <kuya789@yahoo.com> wrote in message
> > > news:b4828959.0309061944.4ce851e7@posting.google.com...
> > > > Is it possible to compile a dll that only works on my machine? if
> > > > someone steals it, it would not work on their machine.
> > >
> > >
> >
> >
>
>