Am I the only one with doubts about .NET for commercial apps?

[Rich S.]

Hello

Just like everyone else, I am excited about how easily one can create Windows applications with the .NET platform, but for shareware, I have some serious reservations

1. Your code can be easily decompiled. This would make it very difficult to implement any sort of license restrictions on your app, because anything you write can be easily viewed and cracked. This also removes any privacy for your intellectual property

2. Jim Hubbard, in a previous post, informs me that there is really no way to prevent someone from reusing one of your private assemblies in their own application! I imagine that someone could simply remove your trade marks and names, and slap on their own

So far, I have found only these two weaknesses, but these are BIG weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial software development? Or can someone point out something that I haven't yet come across that mediates these weaknesses

.NET is all the rage, but I have yet to see these points seriously discussed

Sincerely
Rich.

[Daniel O'Connell [C# MVP]]

"Rich S." <an*******@disc ussions.microso ft.com> wrote in message
news:ED******** *************** ***********@mic rosoft.com...

Hello,

Just like everyone else, I am excited about how easily one can create
Windows applications with the .NET platform, but for shareware, I have
some serious reservations.

1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app,
because anything you write can be easily viewed and cracked. This also
removes any privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really no
way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG
weaknesses.

Am I alone in thinking that .NET just isn't ready for commercial
software development? Or can someone point out something that I haven't
yet come across that mediates these weaknesses?

The problem is that both of these are pretty much not new. While its a touch
harder to do in unmanaged code, no licensing restrictions you add there are
going to stand up any better(thousand s upon thousands of cracks for
unmanaged apps come out every year, every major game gets cracked). The most
effective protection scheme I've heard of was from...autodesk I think, which
used a dongle that the program used as a lookup table. It took some doing
but even that was eventually emulated, IIRC. Intellectual property is
mostly a matter of legality, not security. When you ship your application,
in any format, if someone wants it they will take it. While I personally
can't read x86 assembly worth a damn, I've known people who could read it
better than they ould English. .NET just takes away that particular false
sense of security by making it clearer how easy it is to do.

Often times, all that stops someone from using your dll's is that they don't
have the call signatures...gi ven time they will figure them out if they want
them(and possibly publish them). Now, what about COM objects? The user
pretty much has access to them as well...where is the security there?

Again, its something that is apparent in .NET, but certainly not new or
unique.

You can make reusing your assemblies a bit harder by using identity demands,
it'll raise the bar a litlte but it won't make a difference, IMHO.
.NET is all the rage, but I have yet to see these points seriously
discussed. You should go to google groups and start looking up obfustication and
diassembly. This topic has actually been discussed quite throughly, I've
participated in atleast 3 or 4 myself.

Sincerely,
Rich.

[Jim Hubbard]

Keep in mind that Microsoft has publicly stated its goals of "software
as a service" including the goal of making the Microsoft Office suite a
service by the year 2010.

Make no mistake about it, although .Net has tremendous advantages over
the old Visual Studio products, .Net was written by Microsoft for Microsoft.
The fact that they can push it on their customers at a profit is just icing
on the cake.

No need crying over spilled development tools. The thing to do now is
to learn how to use the new tools in a productive and profitable manner. As
I see things, copying the "software as a service" model that Microsoft is
implementing is the only way to go. And, not just because we have no other
choice...

As a shareware authors will attest, shareware (and even retail software)
is easily ripped off. (Just check www.keygen.us or www.cracks.am or
www.astalavista.com. If a software title is remotely popular, you can find
a crack for it on one of these sites.)

Although I disagree with Microsoft's handling of VB.Net, placing part of
your software on an inaccessible server is the only way to guarantee that
you get paid. Microsoft recently made $9 billion in sales for a single
year's software sales, which is admittedly a lot of money. But, it lost $3
billion to software thieves - which is also a lot of money.

This is what is driving Microsoft's (and savy shareware/retail
developers) to the "software as a service model".

See the news lately that Bush is pushing for all homes in the US to have
broadband access by 2007? Don't think that Microsoft had a little hand in
that, or that the globalization of the software workforce pushed it a
little?

If you study .Net a little, you'll see that it is very simple to deliver
zero deployment applications (yes, actual Windows forms-type applications -
NOT the limited web pages we are used to) via a web server and web services
that allow you to actually get paid for your hard work.

Currently, the lack of broadband access limits the number of potential
customers, but that will soon change. Are you ready?

Jim Hubbard
"Rich S." <an*******@disc ussions.microso ft.com> wrote in message
news:ED******** *************** ***********@mic rosoft.com...

Hello,

Just like everyone else, I am excited about how easily one can create Windows applications with the .NET platform, but for shareware, I have some
serious reservations.
1. Your code can be easily decompiled. This would make it very difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.
2. Jim Hubbard, in a previous post, informs me that there is really no way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.
So far, I have found only these two weaknesses, but these are BIG weaknesses.
Am I alone in thinking that .NET just isn't ready for commercial software development? Or can someone point out something that I haven't yet
come across that mediates these weaknesses?
.NET is all the rage, but I have yet to see these points seriously discussed.
Sincerely,
Rich.

[Jon Skeet [C# MVP]]

Rich S. <an*******@disc ussions.microso ft.com> wrote:

Just like everyone else, I am excited about how easily one can create
Windows applications with the .NET platform, but for shareware, I
have some serious reservations.

1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app,
because anything you write can be easily viewed and cracked. This
also removes any privacy for your intellectual property.

2. Jim Hubbard, in a previous post, informs me that there is really
no way to prevent someone from reusing one of your private assemblies
in their own application! I imagine that someone could simply remove
your trade marks and names, and slap on their own.

So far, I have found only these two weaknesses, but these are BIG
weaknesses.
I don't believe they really are.

See http://www.pobox.com/~skeet/csharp/faq/#obfuscation
Am I alone in thinking that .NET just isn't ready for commercial
software development? Or can someone point out something that I
haven't yet come across that mediates these weaknesses?

.NET is all the rage, but I have yet to see these points seriously
discussed.

A good counterexample is Java. It's got exactly the same "problem", but
it seems to be pretty commercially popular, doesn't it?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike McIntyre [MVP]]

Hello Rich,

For your point 1, use an obfuscator.

http://www.vbdotnetheaven.com/Code/Sept2003/2171.asp

http://www.ftponline.com/reports/vslivesf/2004/torok/

For examples see Salamander at
http://www.remotesoft.com/salamander/obfuscator.html and Dofuscator at
http://preemptive.com/products/dotfuscator/index.html.

----------------------------
For point 2, there are built in capabilities in the .NET Framework for
controlling/security access to an assembly. If implemented correctly some of
the capabilties provide a great deal of protection.

http://www.ftponline.com/wss/2002_10...umns/security/

Sophisticated .NET hackers are finding ways past some of the built in
capabilities. Dan Appleman wrote an inexpensive eBook that provides
excellent advice on how to project against them:

Hijacking .Net Vol 2: Protecting Your Code
by Dan Appleman

---------------------------

Securing your applications is a process of 'hardening' your application by
using layers of projection. Obfuscation is one layer. Using the .NET
Framework's capabilities provide more layers. Ideas such as those provided
by Dan Applemen add more.

You can add your own layer(s) too. For example, some of your class
contructors and/or methods can be written to accept one or more encrypted
parameters that only your application can generate.

--
Mike

Mike McIntyre
Visual Basic MVP
www.getdotnetcode.com
"Rich S." <an*******@disc ussions.microso ft.com> wrote in message
news:ED******** *************** ***********@mic rosoft.com...

Hello,

Just like everyone else, I am excited about how easily one can create Windows applications with the .NET platform, but for shareware, I have some
serious reservations.
1. Your code can be easily decompiled. This would make it very difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.
2. Jim Hubbard, in a previous post, informs me that there is really no way to prevent someone from reusing one of your private assemblies in
their own application! I imagine that someone could simply remove your
trade marks and names, and slap on their own.
So far, I have found only these two weaknesses, but these are BIG weaknesses.
Am I alone in thinking that .NET just isn't ready for commercial software development? Or can someone point out something that I haven't yet
come across that mediates these weaknesses?
.NET is all the rage, but I have yet to see these points seriously discussed.
Sincerely,
Rich.

[David Sworder]

>>>>>>>>
1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app, because
anything you write can be easily viewed and cracked. This also removes any
privacy for your intellectual property.
<<<<<<<<

I'm not saying that your argument doesn't have merit, but I guess I've
never really understood the big scare about people decompiling .NET apps.
It's very unusual that a piece of logic in a WinForms app is so incredibly
revolutionary that "hackers" are going to want to reverse engineer it. There
may be a few exceptions to this like if you've developed some fantastic data
compression algorithm -- and in such cases, you can move such code to
unmanaged C++ if you want (even then, your algorithm wouldn't be fully
protected).

Even if someone DID decide to decompile your obfuscated .NET code, what
would he do with it? Would he copy the code into his own project, recompile
it, and then try to compete with you by selling it? Selling stolen code is
just too risky. It's almost ALWAYS easier for a competitor to just redesign
your app on his own without trying to reverse engineer your code. For
example, if I wanted to design my own peer-to-peer file swapping app, I
wouldn't attempt to decompile Kazza and try to reverse engineer the code --
I'd just look at the Kazza *functionality* via the UI and design my own app
from scratch.

>>>>>>

2. Jim Hubbard, in a previous post, informs me that there is really no
way to prevent someone from reusing one of your private assemblies in their
own application! I imagine that someone could simply remove your trade
marks and names, and slap on their own.
<<<<<<<<<<

I don't think that this is true. I've seen discussions in this newsgroup
that indicate contrary. There is a way to sign your assemblies in such a way
that they can only be called by other assemblies that have a particular
signature. Scan this newsgroup for more info on this topic...

David

[Niki Estner]

What kind of applications do YOU write???
I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think. But getting good hints e.g. from
un-obfuscated mathod names (like "Fourier" or "Median") can really make this
too easy.
I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code) or
proprietary communication standards or high-speed-databases... - virtually
every piece of code that required thought when it was written.

Niki

"David Sworder" <ds******@cts.c om> wrote in
news:OI******** ********@TK2MSF TNGP09.phx.gbl. ..

>>>>> 1. Your code can be easily decompiled. This would make it very
difficult to implement any sort of license restrictions on your app, because anything you write can be easily viewed and cracked. This also removes any privacy for your intellectual property.
<<<<<<<<

I'm not saying that your argument doesn't have merit, but I guess I've
never really understood the big scare about people decompiling .NET apps.
It's very unusual that a piece of logic in a WinForms app is so incredibly
revolutionary that "hackers" are going to want to reverse engineer it. There may be a few exceptions to this like if you've developed some fantastic data compression algorithm -- and in such cases, you can move such code to
unmanaged C++ if you want (even then, your algorithm wouldn't be fully
protected).

Even if someone DID decide to decompile your obfuscated .NET code, what would he do with it? Would he copy the code into his own project, recompile it, and then try to compete with you by selling it? Selling stolen code is
just too risky. It's almost ALWAYS easier for a competitor to just redesign your app on his own without trying to reverse engineer your code. For
example, if I wanted to design my own peer-to-peer file swapping app, I
wouldn't attempt to decompile Kazza and try to reverse engineer the code -- I'd just look at the Kazza *functionality* via the UI and design my own app from scratch.
>>>>>

2. Jim Hubbard, in a previous post, informs me that there is really

no way to prevent someone from reusing one of your private assemblies in their own application! I imagine that someone could simply remove your trade
marks and names, and slap on their own.
<<<<<<<<<<

I don't think that this is true. I've seen discussions in this newsgroup that indicate contrary. There is a way to sign your assemblies in such a way that they can only be called by other assemblies that have a particular
signature. Scan this newsgroup for more info on this topic...

David

[David Sworder]

What kind of applications do YOU write???
Financial apps... essentially every piece of analytical logic I use has
been around for decades or can be copied out of an article or book.
I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think.
Probably true... but then again, I know nothing about signal
processing/image processing. Do you think that if you gathered a bunch of
signal processing experts together in a room and showed them your app,
they'd be SO impressed with your algorithm that they'd say to themselves
"wow, I've never seen anything like that! Instead of creating our own
similar algorithm, let's reverse engineer her code, recompile it into our
own app, and SELL it!"
Please don't misinterpret my tone here. I'm not being sarcastic. If this
actually applies to you, then hey, congratulations ! ... and you're right,
you'd better look for a sophisticated way to protect your algorithm.
I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code)
I'll buy that argument. For example, I remember when ID Software
released "Doom." Other developers were genuinely amazed. I remember them
asking "how did ID Software do that?"... but that was written in C/C++,
*not* managed code.
proprietary communication standards
I don't know... It seems like the hacks against com standards have been
done by using a sniffer to examine network traffic, not by reverse
engineering code. I suspect that the spammer that figured out how the
"proprietar y" Windows messenger service worked did so by examining network
traffic, not by trying to decompile the messenger service EXE.
or high-speed-databases...
...but these aren't written in .NET managed code (but they presumably
will be at some point). I assume you're talking about databases like SQL
Server and Oracle? If I were writing my own high speed database, I'd turn to
books, articles, and classes on database theory. I educate myself the same
way the designers of SQL Server did. This would be vastly more effective
than trying to decompile the .EXEs of a competitor's product.
virtually
every piece of code that required thought when it was written.

This is a gross exaggeration! Yesterday I wrote a helper app that waits
for a file to arrive, reads it, does some analysis, and uploads the results
to a database. This app "required thought," but should I worry about someone
reverse engineering my code and discovering:
a) I used a FileSystemWatch er to wait for the file
b) I used an SqlConnection object to connect to the database and called
some methods against an IDbCommand object to upload the data
c) I used some well-known algorithms (well known in financial analyst
circles) to perform the analysis that can be looked up on Google and read in
*plain English* (as opposed to reading them in unobfuscated decompiled
cryptic C# code.)

My app required thought, but any competitor who wanted to duplicate my
efforts would be better off reading some financial analysis articles and the
documentation for ADO.NET and FileSystemWatch er than he would trying to
decompile my app, unobfuscate it, etc.

I'm not claiming that my situation applies to everyone. If your
signal/image processing logic is truly awesome and warrants protection, so
be it. If you're designing encryption logic for the dept of defense, don't
use .NET. Same would be true if you're designing a revolutionary 3D game
engine that is so frigging' unique that it isn't just a derivative of the
techniques taught in any of the "Teach Yourself 3D Game Programming" books
at Barnes and Noble... what I *am* saying is that a very large fraction of
the apps out there don't fall into this category and the authors of some of
these apps have decided to use C++ instead of C# simply because they're
worried about someone reverse engineering their precious code -- and I think
that's a shame.

David

[Jon Skeet [C# MVP]]

Niki Estner <ni*********@cu be.net> wrote:

What kind of applications do YOU write???
I spent a few years developing signal processing/image processing
applications, and I can tell you: finding out how an algorithm works isn't
half as easy as you seem to think. But getting good hints e.g. from
un-obfuscated mathod names (like "Fourier" or "Median") can really make this
too easy.
I guess the same would apply to highly optimized graphics engines as they
are found in computer games (if they were written in managed code) or
proprietary communication standards or high-speed-databases...
There are certainly a *few* cases where the algorithm itself is most of
the work. I don't think it covers what most developers write, however.
- virtually every piece of code that required thought when it was written.

I spend relatively little time thinking about coding. Coding is
relatively easy. Designing the system in the first place - what object
should have what responsibility, etc - is the more demanding part, in
my experience.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

David Sworder <ds******@cts.c om> wrote:

If you're designing encryption logic for the dept of defense, don't
use .NET.

I certainly *hope* that very few governments are using encryption
algorithms which are only secure because the algorithm isn't known.
That way, trouble lies. Encryption schemes should rely on the secrecy
of some other piece of information (the key, essentially) - *not* the
obscurity of the algorithm.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too