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.

[Ray Cassick \(Home\)]

1. Use an Obfuscator. That is not 100% but then again NOTHING is 100% if
there is someone out there that REALLY wants to use your stuff without your
permission.

2. Consider signing your stuff so at least then others will know that their
stuff is not your stuff. Also consider maybe writing most of your stuff in
managed code but then keeping the proprietary things in non-managed DLLs if
you are really worried.

The bottom line is that NOTHING is 100%, not even unmanaged code. The trick
is keeping 99% of the honest people honest.
"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]

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

yeah, ok.. my bad.. was WEP cracked due a bad algorithm?

on a side note, I'd like to point out that in the movie SWORDFISH, Hugh
Jackman was able to break 512 bit encryption in his head. Hugh is very smart
that way.

[Niki Estner]

"David Sworder" <ds******@cts.c om> wrote in
news:eB******** ******@TK2MSFTN GP09.phx.gbl...

...
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 didn't say I'm a signal processing genius - but it does take time to find
good algorithms; Time spent testing, reading books, optimizing; Or spent
decompiling.
To stick to your example: if I spent a month on an algorithm, those "signal
programming gurus" would probably need a week or so to do the same; Or a
day, using a decompiler.

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.

What's your point?
Do you think Doom wasn't disassembled?
Or do you think it wouldn't have been, if it would have been 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.
Ok, maybe this example wasn't that good.
...

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.
Did you spend a moment thinking whether this task is possible? Whether it
can be done by a computer?
Well, for charachter, speech or face recognition you usually do have to
spend a lot of time thinking about what's possible and what isn't.

Again, I don't claim I ever developed any "impressive " algorithms of that
kind - merely ones that work more-or-less.
But then again, look at the OCR, speech or face processing market, and you
won't find too many "impressive " products - only ones that work
more-or-less...
...
I'm not claiming that my situation applies to everyone. If your
signal/image processing logic is truly awesome and warrants protection,
Awesome? Probably not.
But it's surely more work developing it than copying it...
... 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.

Well you said in your first post you didn't understand the scare of
decompilation - I hope I could clarify that scare a little bit, because I do
share it.

And, take my word for it - there probably are some Oracle programmers out
there disassembling some SQL server code right now as we speak ;-)

Niki

[David Sworder]

> I didn't say I'm a signal processing genius - but it does take time to
find

good algorithms; Time spent testing, reading books, optimizing; Or spent
decompiling.
To stick to your example: if I spent a month on an algorithm, those "signal programming gurus" would probably need a week or so to do the same; Or a
day, using a decompiler.
Ok, if that's truly the case, then you certainly have a right to be
concerned... but for me and the developers I've encountered, the reverse is
true: It would take competitors much longer to design something comparable
by decompiling/understanding/recompiling an app than it would to just design
it on their own.
What's your point?
Do you think Doom wasn't disassembled?
You mean did people try decompiling the unmanaged EXE to figure out ID's
graphics engine? Geez, I hope not! I guess anything's possible, but I don't
remember seeing a lot of Doom clones springing up until after a) ID released
the source code and b) there were a fair number of public articles published
on the topic. Even if some guy was smart enough to reverse engineer the raw
assembler code for a graphics engine, wouldn't he be taking an *enormous*
legal risk putting that very same code into his own product and reselling it
as an alternative to Doom? In other words, even if it were technically
possible, would it be practical?
Or do you think it wouldn't have been, if it would have been managed code???

Yes, it WOULD have been if it were managed code... which is my point: If
you (not you personally) have a revolutionary idea for a 3D graphics engine,
then I'll agree with you -- .NET isn't for you.
Again, I don't claim I ever developed any "impressive " algorithms of that
kind - merely ones that work more-or-less.
But then again, look at the OCR, speech or face processing market, and you
won't find too many "impressive " products - only ones that work
more-or-less...
Yeah, but face processing is cutting edge stuff! You've produced some
excellent examples that illustrate how the possibility of decompilation
could be a threat. I just don't think that most app developers fit into that
category.
Awesome? Probably not.
But it's surely more work developing it than copying it...
I guess that's really the crux of the issue. It sounds like you're doing
a lot of work with cutting edge algorithms. For me, most of the code I write
is based upon knowledge and formulas that are public domain. The UI code is
just standard stuff: creating new windows, validation of forms, etc... the
idea that someone would try to reverse engineer this stuff is silly. but for
the stuff you're working on, ok, I guess I understand your point.
And, take my word for it - there probably are some Oracle programmers out
there disassembling some SQL server code right now as we speak ;-)

Has anyone tried to reverse engineer Microsoft Bob? If not, they should.

[Daniel O'Connell [C# MVP]]

"David Sworder" <ds******@cts.c om> wrote in message
news:Ol******** ******@TK2MSFTN GP10.phx.gbl...

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.

yeah, ok.. my bad.. was WEP cracked due a bad algorithm?

There is some info at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
that covers why wep didn't work. I'm no security or cryptography expert so I
won't try to explain it here.

on a side note, I'd like to point out that in the movie SWORDFISH, Hugh
Jackman was able to break 512 bit encryption in his head. Hugh is very
smart
that way.

I wish I could be a movie computer expert...everyt hing is so easy in that
world, I'd be a billionare by now I'm sure.

Have you ever read userfriendly(us erfriendly.org) ? Somewhere deep back in
the archives one of the characters creates "Hollywood OS 1.0"(or something
like that) which can be hacked with two key presses, everything only takes
one click, etc.

[David Sworder]

> I wish I could be a movie computer expert...everyt hing is so easy in that

world, I'd be a billionare by now I'm sure.

Have you ever read userfriendly(us erfriendly.org) ? Somewhere deep back in
the archives one of the characters creates "Hollywood OS 1.0"(or something like that) which can be hacked with two key presses, everything only takes
one click, etc.

Ha! Yeah, I like the way computers are used in the movies. People have
weird IP addresses like "271.4653.0 .41" and the cops can instantly trace
anyone's physical address and phone number using these IP addresses.

[Steve McLellan]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.

True, but it IS the bit that you're selling - anyone can slap a UI on
something. The only IP we have is the algorithm, and unless it's patented,
nothing stops someone decompiling it and incorporating it into their
product. With an algorithm it's relatively easy (once you understand it) to
rewrite it, so copyright doesn't apply. Of course, given an expert in any
algorithmic field, you can generally work out the methods used in a given
piece of software through experimentation and a feel for how different
methods work. A sort of mental decompilation, if you will.

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

For some applications that's true. But commercially that stuff isn't
important to any company producing any cutting edge scientific
applications - the blood and guts (and the bit you pay your people for) is
the algorithm. As it happens at the moment, using managed code for any
number crunching isn't really practical in terms of performance (not to
mention cross platform compatibility) but it will become more of a problem.

Just, sa they say, my two.

Steve

[Jon Skeet [C# MVP]]

<"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>> wrote:

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.

True, but it IS the bit that you're selling - anyone can slap a UI on
something. The only IP we have is the algorithm, and unless it's patented,
nothing stops someone decompiling it and incorporating it into their
product. With an algorithm it's relatively easy (once you understand it) to
rewrite it, so copyright doesn't apply. Of course, given an expert in any
algorithmic field, you can generally work out the methods used in a given
piece of software through experimentation and a feel for how different
methods work. A sort of mental decompilation, if you will.

That may well be what *you're* selling, but it's not what most people
are selling. The general design isn't something you can easily get from
decompilation, and the mixture of general design and the work involved
in implementation is what most apps are sold for, really.

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.

For some applications that's true. But commercially that stuff isn't
important to any company producing any cutting edge scientific
applications - the blood and guts (and the bit you pay your people for) is
the algorithm. As it happens at the moment, using managed code for any
number crunching isn't really practical in terms of performance (not to
mention cross platform compatibility) but it will become more of a problem.

And sure, for number crunchers that may be a significant problem - but
I don't believe *most* developers are in that situation. I know I've
never written anything which has been particularly impressive in terms
of algorithm. By the time someone has decompiled the code, *understood*
it (without comments or local variable names, and in the case of
obfuscated code, without useful class or method names either for the
most part) they could easily have come up with the same algorithm - if
they'd had the same design to start with.

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