ASP.NET 2005 hack-proof?

[Edwin Knoppert]

I know ASP.NET 1.x generated dll's which decompilable to plain c or vb
(afaik, i never used 2003)

Is this problem solved in 2005?
We ever want to distribute 2005 compiled code.
And it seems all like ordinary dll's at first.
Is the code i wrote retrievable?

Thanks!

PS, this is not a discussion about decompiling to win32 assembly code.

 

[Jon]

It works the same. You should use an obfuscator on .Net 2 exes and dlls,
just like on 1.x.

 

[Edwin Knoppert]

Anyone having such a tool?
The tools i found on internet are extremely expensive!

That dodo from Xenocode must be insane $2000 USD.
Their trial also connects through internet.
Wonder if this is not so when i purchase such a tool.
(Maybe the $99 version)

 

[John]

How much difference does that make? Is source still retrievable? I mean are
we getting a false sense of security?

Thanks

Regards

 

[Mark Rae]

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able to steal
your car no matter how carefully you lock it...

 

[Juan T. Llibre]

You could also try the Obfuscator included with VS 2005.

 

[Edwin Knoppert]

Comparing of apples and oranges..?

It will deter the casual decompiler, nothing more.


Yes, given enough time and resource...


It largely depends. A skilled and determined car thief will be able to
steal your car no matter how carefully you lock it...

 

[Kevin Spencer]

Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact, nothing is.
Decompilation is always possible. If the computer can read the DLL, so can a
decompiler.

Earlier, John asked if "we [are] all getting a false sense of security." I
would argue that we are all getting a false sense of INsecurity. In fact,
obfuscation should not be necessary at all. If anyone other than the author
can get to the DLLs on the server file system, there is already a huge hole
in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the illegal
acquisition of another person's property. And just as in "real-life"
thievery, there are levels of expertise in the thievery realm. There are
shoplifters, and there are safe-crackers. And software should be protected
in the same way that "real-life" property should be protected, according to
its value, because the higher the level of protection you wish to employ,
the more it will cost you. Nobody has yet robbed Fort Knox. but in 1936 it
cost over a half-million dollars to build the gold depository vault, and the
Fort has an annual budget of over 12 million dollars. Obviously, you don't
want to spend that much money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And again, if
a hacker can break into the file system of the web server, obfuscation isn't
any solution at all. Fixing the security hole in the web server is the
solution.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

 

[Not Me]

Comparing of apples and oranges..?

Why not? It's all fruit D

 

[Juan T. Llibre]

re:

Why not? It's all fruit D

It's easy to tell it's, finally, Friday!

 

[Edwin Knoppert]

If we post our dll's on another compagny's server or even distribute simple
apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to get
a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a useful
language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??

Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact, nothing
is. Decompilation is always possible. If the computer can read the DLL, so
can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of security." I
would argue that we are all getting a false sense of INsecurity. In fact,
obfuscation should not be necessary at all. If anyone other than the
author can get to the DLLs on the server file system, there is already a
huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the illegal
acquisition of another person's property. And just as in "real-life"
thievery, there are levels of expertise in the thievery realm. There are
shoplifters, and there are safe-crackers. And software should be protected
in the same way that "real-life" property should be protected, according
to its value, because the higher the level of protection you wish to
employ, the more it will cost you. Nobody has yet robbed Fort Knox. but in
1936 it cost over a half-million dollars to build the gold depository
vault, and the Fort has an annual budget of over 12 million dollars.
Obviously, you don't want to spend that much money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And again,
if a hacker can break into the file system of the web server, obfuscation
isn't any solution at all. Fixing the security hole in the web server is
the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?

 

[Scott Allen]

I know ASP.NET 1.x generated dll's which decompilable to plain c or vb
(afaik, i never used 2003)

Is this problem solved in 2005?
No.

We ever want to distribute 2005 compiled code.
And it seems all like ordinary dll's at first.
Is the code i wrote retrievable?

Always.

Another tip I have - never give your application a user interface -
someone might see it and steal that too

 

[Kevin Spencer]

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can decompile
..Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to
get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??

Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact, nothing
is. Decompilation is always possible. If the computer can read the DLL,
so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of security."
I would argue that we are all getting a false sense of INsecurity. In
fact, obfuscation should not be necessary at all. If anyone other than
the author can get to the DLLs on the server file system, there is
already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the illegal
acquisition of another person's property. And just as in "real-life"
thievery, there are levels of expertise in the thievery realm. There are
shoplifters, and there are safe-crackers. And software should be
protected in the same way that "real-life" property should be protected,
according to its value, because the higher the level of protection you
wish to employ, the more it will cost you. Nobody has yet robbed Fort
Knox. but in 1936 it cost over a half-million dollars to build the gold
depository vault, and the Fort has an annual budget of over 12 million
dollars. Obviously, you don't want to spend that much money to protect
your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And again,
if a hacker can break into the file system of the web server, obfuscation
isn't any solution at all. Fixing the security hole in the web server is
the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able to
steal your car no matter how carefully you lock it...

 

[John]

No. Which one is it?

Regards

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can
decompile .Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to
get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??

Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact, nothing
is. Decompilation is always possible. If the computer can read the DLL,
so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of security."
I would argue that we are all getting a false sense of INsecurity. In
fact, obfuscation should not be necessary at all. If anyone other than
the author can get to the DLLs on the server file system, there is
already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the
illegal acquisition of another person's property. And just as in
"real-life" thievery, there are levels of expertise in the thievery
realm. There are shoplifters, and there are safe-crackers. And software
should be protected in the same way that "real-life" property should be
protected, according to its value, because the higher the level of
protection you wish to employ, the more it will cost you. Nobody has yet
robbed Fort Knox. but in 1936 it cost over a half-million dollars to
build the gold depository vault, and the Fort has an annual budget of
over 12 million dollars. Obviously, you don't want to spend that much
money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And again,
if a hacker can break into the file system of the web server,
obfuscation isn't any solution at all. Fixing the security hole in the
web server is the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able to
steal your car no matter how carefully you lock it...

 

[Edwin Knoppert]

I don't really care much, i take your word on that, fine.

*What i need is a solid way to prevent that.*

'Happily' a few parts in our ASP.NET apps use plain win32 dll's we create
ourselves.
Stuff we haven't coded in ASP.NET yet and might be to difficult to do so
anyway.
(+ same code is used in our stand-alone apps as well, not using dotnet)

So that might reduce the joy of decompiling somewhat

Also discussions how i should think about these matters.. well i made up my
mind already.
Iow, i don't want decompilation.
During the VB3 times i was also able to rewrite some stuff in the VB exe's
and that decompiler gasp'd, that's good for me.

Is there someone who can show me some decompiled code?
I want to know if it's worth using at all.
Thanks,

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can
decompile .Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to
get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??

Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact, nothing
is. Decompilation is always possible. If the computer can read the DLL,
so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of security."
I would argue that we are all getting a false sense of INsecurity. In
fact, obfuscation should not be necessary at all. If anyone other than
the author can get to the DLLs on the server file system, there is
already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the
illegal acquisition of another person's property. And just as in
"real-life" thievery, there are levels of expertise in the thievery
realm. There are shoplifters, and there are safe-crackers. And software
should be protected in the same way that "real-life" property should be
protected, according to its value, because the higher the level of
protection you wish to employ, the more it will cost you. Nobody has yet
robbed Fort Knox. but in 1936 it cost over a half-million dollars to
build the gold depository vault, and the Fort has an annual budget of
over 12 million dollars. Obviously, you don't want to spend that much
money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And again,
if a hacker can break into the file system of the web server,
obfuscation isn't any solution at all. Fixing the security hole in the
web server is the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able to
steal your car no matter how carefully you lock it...

 

[Jeff]

Okay, if you *really* want to understand the whole obfuscation issue, here
is a great e-book:
http://www.desaware.com/products/books/net/obfuscating/index.aspx

It includes before/after decompilation code and gives the whole topic a
thorough and readable treatment.

If you don't want to thoroughly understand the topic and you're just after
a bottom line answer, then here's a bottom line answer on how to make your
source code as safe as possible (given that the MVPs here apparently take
the tact of "don't worry about it, there's more important things to worry
about". NO FLAME intended!!! - that's literally what you guys are saying...
a valid point with which I totally agree; but that's not helpful to the OP
who I gather is wondering what it takes to make his source as safe as
possible and if VS2005 helps, which it obviously doesn't...).

To make your source as safe as possible (keeping in mind that nothing you do
will make it 100%), you do at least these 3 things:
1. Obfuscate your code using a strong obfuscator (like the one from
http://www.preemptive.com/ not the freebie in VS.NET and not the freebie
offered by Desaware)

2. Implement licensing in your software using an industrial-strength
licencing system - like the one from Desaware.com

3. Have all of your assemblies strong-named. Then have each server component
verify the caller via its strong name... if it's being called by an
unrecognized client, then discontinue processing the request...

So, is it worth it to you to do *at least all* of the 3 steps above? It can
be easily argued that doing anything less than ALL of the 3 steps I is
completely pointless and a waste of your time (might as well do nothing).

Remember it's not about getting "completely safe" - it's all about raising
the bar high enough to kill the economics for your would-be hacker. It's all
about economics at the end of the day. Kevin Spencer's post nailed it pretty
well with the Ft. Knox example.


-HTH

-Jeff

I don't really care much, i take your word on that, fine.

*What i need is a solid way to prevent that.*

'Happily' a few parts in our ASP.NET apps use plain win32 dll's we create
ourselves.
Stuff we haven't coded in ASP.NET yet and might be to difficult to do so
anyway.
(+ same code is used in our stand-alone apps as well, not using dotnet)

So that might reduce the joy of decompiling somewhat

Also discussions how i should think about these matters.. well i made up
my mind already.
Iow, i don't want decompilation.
During the VB3 times i was also able to rewrite some stuff in the VB exe's
and that decompiler gasp'd, that's good for me.

Is there someone who can show me some decompiled code?
I want to know if it's worth using at all.
Thanks,

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can
decompile .Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to
get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??



"Kevin Spencer" <[email protected]> schreef in bericht
Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact,
nothing is. Decompilation is always possible. If the computer can read
the DLL, so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of
security." I would argue that we are all getting a false sense of
INsecurity. In fact, obfuscation should not be necessary at all. If
anyone other than the author can get to the DLLs on the server file
system, there is already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the
illegal acquisition of another person's property. And just as in
"real-life" thievery, there are levels of expertise in the thievery
realm. There are shoplifters, and there are safe-crackers. And software
should be protected in the same way that "real-life" property should be
protected, according to its value, because the higher the level of
protection you wish to employ, the more it will cost you. Nobody has
yet robbed Fort Knox. but in 1936 it cost over a half-million dollars
to build the gold depository vault, and the Fort has an annual budget
of over 12 million dollars. Obviously, you don't want to spend that
much money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And
again, if a hacker can break into the file system of the web server,
obfuscation isn't any solution at all. Fixing the security hole in the
web server is the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able
to steal your car no matter how carefully you lock it...

 

[Edwin Knoppert]

it's all about raising the bar high enough to kill the economics for your

would-be hacker.

That's my goal.
I'm not talking about the A-H 18-year old i-can-hack-anything, he would not
have any interest.

I'll reread your post tomorrow, if anyone has more on this, i would like
that.

Thanks so far,

Okay, if you *really* want to understand the whole obfuscation issue, here
is a great e-book:
http://www.desaware.com/products/books/net/obfuscating/index.aspx

It includes before/after decompilation code and gives the whole topic a
thorough and readable treatment.

If you don't want to thoroughly understand the topic and you're just
after a bottom line answer, then here's a bottom line answer on how to
make your source code as safe as possible (given that the MVPs here
apparently take the tact of "don't worry about it, there's more important
things to worry about". NO FLAME intended!!! - that's literally what you
guys are saying... a valid point with which I totally agree; but that's
not helpful to the OP who I gather is wondering what it takes to make his
source as safe as possible and if VS2005 helps, which it obviously
doesn't...).

To make your source as safe as possible (keeping in mind that nothing you
do will make it 100%), you do at least these 3 things:
1. Obfuscate your code using a strong obfuscator (like the one from
http://www.preemptive.com/ not the freebie in VS.NET and not the freebie
offered by Desaware)

2. Implement licensing in your software using an industrial-strength
licencing system - like the one from Desaware.com

3. Have all of your assemblies strong-named. Then have each server
component verify the caller via its strong name... if it's being called by
an unrecognized client, then discontinue processing the request...

So, is it worth it to you to do *at least all* of the 3 steps above? It
can be easily argued that doing anything less than ALL of the 3 steps I is
completely pointless and a waste of your time (might as well do nothing).

Remember it's not about getting "completely safe" - it's all about raising
the bar high enough to kill the economics for your would-be hacker. It's
all about economics at the end of the day. Kevin Spencer's post nailed it
pretty well with the Ft. Knox example.


-HTH

-Jeff

I don't really care much, i take your word on that, fine.

*What i need is a solid way to prevent that.*

'Happily' a few parts in our ASP.NET apps use plain win32 dll's we create
ourselves.
Stuff we haven't coded in ASP.NET yet and might be to difficult to do so
anyway.
(+ same code is used in our stand-alone apps as well, not using dotnet)

So that might reduce the joy of decompiling somewhat

Also discussions how i should think about these matters.. well i made up
my mind already.
Iow, i don't want decompilation.
During the VB3 times i was also able to rewrite some stuff in the VB
exe's and that decompiler gasp'd, that's good for me.

Is there someone who can show me some decompiled code?
I want to know if it's worth using at all.
Thanks,

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can
decompile .Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly
to get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??



"Kevin Spencer" <[email protected]> schreef in bericht
Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact,
nothing is. Decompilation is always possible. If the computer can read
the DLL, so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of
security." I would argue that we are all getting a false sense of
INsecurity. In fact, obfuscation should not be necessary at all. If
anyone other than the author can get to the DLLs on the server file
system, there is already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the
illegal acquisition of another person's property. And just as in
"real-life" thievery, there are levels of expertise in the thievery
realm. There are shoplifters, and there are safe-crackers. And
software should be protected in the same way that "real-life" property
should be protected, according to its value, because the higher the
level of protection you wish to employ, the more it will cost you.
Nobody has yet robbed Fort Knox. but in 1936 it cost over a
half-million dollars to build the gold depository vault, and the Fort
has an annual budget of over 12 million dollars. Obviously, you don't
want to spend that much money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And
again, if a hacker can break into the file system of the web server,
obfuscation isn't any solution at all. Fixing the security hole in the
web server is the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able
to steal your car no matter how carefully you lock it...

 

[Kevin Spencer]

No. Which one is it?

http://www.junglecreatures.com/DesktopDefault.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

No. Which one is it?

Regards

Hi Edwin,

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.

Would you be surprised if I told you I have a decompiler that can
decompile .Net assemblies, obfuscated or not, into C#, and that it is a
commercially-available product?

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

If we post our dll's on another compagny's server or even distribute
simple apps for the consumer market.
We don't want to give away our programming skills.

And as i said, let's not strand into discussions about decompiling to a
level of win32 assembly code.
There will be no one interested to decompile ASP.NET code to assembly to
get a hint of how our code works.

But as i see it, the current stuff seems easy to be decompiled into a
useful language.
I don't know exactly since i never seen decompiled code.
Maybe someone can post a not to complex procedure, before and after..

??



"Kevin Spencer" <[email protected]> schreef in bericht
Comparing of apples and oranges..?

Not at all.

Obfuscation is not fool-proof once the DLL is obtained. In fact,
nothing is. Decompilation is always possible. If the computer can read
the DLL, so can a decompiler.

Earlier, John asked if "we [are] all getting a false sense of
security." I would argue that we are all getting a false sense of
INsecurity. In fact, obfuscation should not be necessary at all. If
anyone other than the author can get to the DLLs on the server file
system, there is already a huge hole in the security for that system.

Software thievery is exactly like "real-life" thievery. It is the
illegal acquisition of another person's property. And just as in
"real-life" thievery, there are levels of expertise in the thievery
realm. There are shoplifters, and there are safe-crackers. And software
should be protected in the same way that "real-life" property should be
protected, according to its value, because the higher the level of
protection you wish to employ, the more it will cost you. Nobody has
yet robbed Fort Knox. but in 1936 it cost over a half-million dollars
to build the gold depository vault, and the Fort has an annual budget
of over 12 million dollars. Obviously, you don't want to spend that
much money to protect your wallet.

So, the amount of trouble, time, and expense to protect intellectual
property should be proportional to the value of the property. And
again, if a hacker can break into the file system of the web server,
obfuscation isn't any solution at all. Fixing the security hole in the
web server is the solution.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.

Comparing of apples and oranges..?


"Mark Rae" <[email protected]> schreef in bericht

How much difference does that make?

It will deter the casual decompiler, nothing more.

Is source still retrievable?

Yes, given enough time and resource...

I mean are we getting a false sense of security?

It largely depends. A skilled and determined car thief will be able
to steal your car no matter how carefully you lock it...