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.
-
-
Re: Dll
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.0 309061944.4ce85 1e7@posting.goo gle.com...[color=blue]
> Is it possible to compile a dll that only works on my machine? if
> someone steals it, it would not work on their machine.[/color]
-
Re: Dll
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.publi c.dotnet.securi ty.
O'Reilly have published an excellent book 'Programming .NET Security' ISBN
0-596-00442-7.
---
Steven Wood
"Stephany Young" <stephany@sysof t.co.nz> wrote in message
news:OHXbdUPdDH A.1580@tk2msftn gp13.phx.gbl...[color=blue]
> Yes.
>
> There are many mechanisms you could use, but one would be to get the[/color]
machine[color=blue]
> name at runtime and compare it to a hard-coded value.
>
> "Aaron" <kuya789@yahoo. com> wrote in message
> news:b4828959.0 309061944.4ce85 1e7@posting.goo gle.com...[color=green]
> > Is it possible to compile a dll that only works on my machine? if
> > someone steals it, it would not work on their machine.[/color]
>
>[/color]
Comment
-
Re: Dll
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.
(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.
(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.
(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,
Huihong
Remotesoft
"Steven Wood" <stevennwood@ho tmail.com> wrote in message
news:%23f3$6uRd DHA.2168@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> 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[/color]
our[color=blue]
> 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.[/color]
Note[color=blue]
> 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[/color]
registration[color=blue]
> via a web server, a record of authorized features in a digitally signed[/color]
XML[color=blue]
> 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.publi c.dotnet.securi ty.
>
> O'Reilly have published an excellent book 'Programming .NET Security' ISBN
> 0-596-00442-7.
>
> ---
> Steven Wood
>
> "Stephany Young" <stephany@sysof t.co.nz> wrote in message
> news:OHXbdUPdDH A.1580@tk2msftn gp13.phx.gbl...[color=green]
> > Yes.
> >
> > There are many mechanisms you could use, but one would be to get the[/color]
> machine[color=green]
> > name at runtime and compare it to a hard-coded value.
> >
> > "Aaron" <kuya789@yahoo. com> wrote in message
> > news:b4828959.0 309061944.4ce85 1e7@posting.goo gle.com...[color=darkred]
> > > Is it possible to compile a dll that only works on my machine? if
> > > someone steals it, it would not work on their machine.[/color]
> >
> >[/color]
>
>[/color]
Comment
-
Re: Dll
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@stanf ordalumni.org> wrote in message
news:%23k%23msF XdDHA.3232@TK2M SFTNGP10.phx.gb l...[color=blue]
> There are other means than obfuscation for code protection. Obfuscation is
> the very first step that makes decompilation a bit more difficult, but[/color]
does[color=blue]
> not prevent disassembly at all,. We offers a series of award winning
> products to secure your .NET code. We offer the best protection strategy[/color]
on[color=blue]
> 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[/color]
use.[color=blue]
> Next release will make obfuscation a truely painless, and totally[/color]
automated[color=blue]
> 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[/color]
a[color=blue]
> 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[/color]
can[color=blue]
> 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@ho tmail.com> wrote in message
> news:%23f3$6uRd DHA.2168@TK2MSF TNGP09.phx.gbl. ..[color=green]
> > 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[/color]
> our[color=green]
> > 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[/color][/color]
hacker[color=blue][color=green]
> > from attempting to modify our code that performs the licensing checks.[/color]
> Note[color=green]
> > I use the word 'deter'. From my research, I believe that obfuscation[/color][/color]
does[color=blue][color=green]
> > 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[/color]
> registration[color=green]
> > via a web server, a record of authorized features in a digitally signed[/color]
> XML[color=green]
> > file, a strongly named assembly in the Global Assembly Cache (GAC) with[/color][/color]
a[color=blue][color=green]
> > 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[/color][/color]
computer.[color=blue][color=green]
> >
> > There are plenty of discussions on this subject going on in
> > microsoft.publi c.dotnet.securi ty.
> >
> > O'Reilly have published an excellent book 'Programming .NET Security'[/color][/color]
ISBN[color=blue][color=green]
> > 0-596-00442-7.
> >
> > ---
> > Steven Wood
> >
> > "Stephany Young" <stephany@sysof t.co.nz> wrote in message
> > news:OHXbdUPdDH A.1580@tk2msftn gp13.phx.gbl...[color=darkred]
> > > Yes.
> > >
> > > There are many mechanisms you could use, but one would be to get the[/color]
> > machine[color=darkred]
> > > name at runtime and compare it to a hard-coded value.
> > >
> > > "Aaron" <kuya789@yahoo. com> wrote in message
> > > news:b4828959.0 309061944.4ce85 1e7@posting.goo gle.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.
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
Comment
-
Re: Dll
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
"Steven Wood" <stevennwood@ho tmail.com> wrote in message
news:eR61$lXdDH A.4020@tk2msftn gp13.phx.gbl...[color=blue]
> Which is exactly what I said; one needs a 'good enough' solution. I[/color]
believe[color=blue]
> 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[/color]
bound[color=blue]
> to different typed datasets. Maybe it was something I did.
>
> I shall be keen to see your next version, I am especially interested in[/color]
the[color=blue]
> direction you are taking with integration of obfuscation with the build
> process, either through the IDE or scripts. The last thing I need when[/color]
I'm[color=blue]
> shipping is problems in this area, especially when a client wants a CD
> yesterday.
>
> ---
> Steven Wood
>
> "Huihong Luo" <huisinro@stanf ordalumni.org> wrote in message
> news:%23k%23msF XdDHA.3232@TK2M SFTNGP10.phx.gb l...[color=green]
> > There are other means than obfuscation for code protection. Obfuscation[/color][/color]
is[color=blue][color=green]
> > the very first step that makes decompilation a bit more difficult, but[/color]
> does[color=green]
> > not prevent disassembly at all,. We offers a series of award winning
> > products to secure your .NET code. We offer the best protection strategy[/color]
> on[color=green]
> > 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[/color]
> use.[color=green]
> > Next release will make obfuscation a truely painless, and totally[/color]
> automated[color=green]
> > 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[/color][/color]
finds[color=blue][color=green]
> > all required methods/classes and link all dependent EXE or DLL files[/color][/color]
into[color=blue]
> a[color=green]
> > single assembly. Even the .NET framework libraries can be linked into[/color][/color]
your[color=blue][color=green]
> > own code, and thus make it easier to deploy and very hard to decompile.[/color][/color]
We[color=blue][color=green]
> > also offer tools to help you to deploy only the very minimum set of[/color][/color]
files[color=blue][color=green]
> > without installing the whole Microsoft .NET framework.
> > http://www.remotesoft.com/linker
> >
> > (4) native compiler, link and compile .NET executables to x86 native[/color][/color]
code,[color=blue][color=green]
> > run w/o .NET framework, coming soon.
> > This would be very useful for WinForms applications as the compiled code[/color]
> can[color=green]
> > be deployed to more machines, and make it secure.
> >
> > (5) salamander .NET decompiler, show how easy to get source code from[/color][/color]
the[color=blue][color=green]
> > .NET assemblies,
> > http://www.remotesoft.com/salamander/index.html
> >
> > Huihong
> > Remotesoft
> >
> > "Steven Wood" <stevennwood@ho tmail.com> wrote in message
> > news:%23f3$6uRd DHA.2168@TK2MSF TNGP09.phx.gbl. ..[color=darkred]
> > > 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[/color][/color][/color]
protect[color=blue][color=green]
> > our[color=darkred]
> > > code from crackers and also competitors.
> > >
> > > Because the .NET Framework compiles your managed code into[/color][/color][/color]
Intermediate[color=blue][color=green][color=darkred]
> > > Language (IL) then we are looking at using an obfuscator to deter a[/color][/color]
> hacker[color=green][color=darkred]
> > > from attempting to modify our code that performs the licensing checks.[/color]
> > Note[color=darkred]
> > > I use the word 'deter'. From my research, I believe that obfuscation[/color][/color]
> does[color=green][color=darkred]
> > > 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[/color]
> > registration[color=darkred]
> > > via a web server, a record of authorized features in a digitally[/color][/color][/color]
signed[color=blue][color=green]
> > XML[color=darkred]
> > > file, a strongly named assembly in the Global Assembly Cache (GAC)[/color][/color][/color]
with[color=blue]
> a[color=green][color=darkred]
> > > 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,[/color][/color][/color]
at[color=blue][color=green][color=darkred]
> > > present, there is no way (AFAIK) of storing a secret on a user's[/color][/color]
> computer.[color=green][color=darkred]
> > >
> > > There are plenty of discussions on this subject going on in
> > > microsoft.publi c.dotnet.securi ty.
> > >
> > > O'Reilly have published an excellent book 'Programming .NET Security'[/color][/color]
> ISBN[color=green][color=darkred]
> > > 0-596-00442-7.
> > >
> > > ---
> > > Steven Wood
> > >
> > > "Stephany Young" <stephany@sysof t.co.nz> wrote in message
> > > news:OHXbdUPdDH A.1580@tk2msftn gp13.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.0 309061944.4ce85 1e7@posting.goo gle.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.
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
Comment
Comment