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.

"Rich S." <(E-Mail Removed)> wrote in message
news:ED7635A2-B32A-448C-B627-(E-Mail Removed)...
> 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(thousands 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...given 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.

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." <(E-Mail Removed)> wrote in message
news:ED7635A2-B32A-448C-B627-(E-Mail Removed)...
> 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.

Rich S. <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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." <(E-Mail Removed)> wrote in message
news:ED7635A2-B32A-448C-B627-(E-Mail Removed)...
> 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.

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

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" <(E-Mail Removed)> wrote in
news:OIZ%(E-Mail Removed)...
> >>>>>>>>
> 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
>
>

> 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
"proprietary" 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 FileSystemWatcher 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 FileSystemWatcher 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

Niki Estner <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

David Sworder <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too