.NET and OpenSource....

  • Thread starter Thread starter HamorSth
  • Start date Start date
H

HamorSth

What does "open source" mean in the .NET platform while almost all
"non-obfuscated" codes are "Open-Source"? Just yesterday i got an add-in for
my ".NET Reflector" which saved the entire disassembled-to-C# "mscorlib"
library for me in .cs files, and i now have a project on my computer that
was one day the efforts of hundreds of people in MS!
I mean, we can't expect the library developers to obfuscate their code in
..NET if they are to expose their classes to others. Now, isn't this just the
unconscious mind of MS that has let him into releasing a powerful platform
like .NET in "open-source"?
Please help me on this issue!
 
HamorSth said:
What does "open source" mean in the .NET platform while almost all
"non-obfuscated" codes are "Open-Source"? Just yesterday i got an add-in for
my ".NET Reflector" which saved the entire disassembled-to-C# "mscorlib"
library for me in .cs files, and i now have a project on my computer that
was one day the efforts of hundreds of people in MS!
I mean, we can't expect the library developers to obfuscate their code in
.NET if they are to expose their classes to others. Now, isn't this just the
unconscious mind of MS that has let him into releasing a powerful platform
like .NET in "open-source"?
Please help me on this issue!
Click to expand...

OpenSource is a lot more than just *having* the source code. It's a
license, and furthermore an philosophy and a marketing method.

What issue do you want help with? Explaining why they did it?
 
HamorSth said:
What does "open source" mean in the .NET platform while almost all
"non-obfuscated" codes are "Open-Source"? Just yesterday i got an add-in for
my ".NET Reflector" which saved the entire disassembled-to-C# "mscorlib"
library for me in .cs files, and i now have a project on my computer that
was one day the efforts of hundreds of people in MS!
I mean, we can't expect the library developers to obfuscate their code in
.NET if they are to expose their classes to others. Now, isn't this just the
unconscious mind of MS that has let him into releasing a powerful platform
like .NET in "open-source"?
Please help me on this issue!
Click to expand...

The definition of "Open Source" means you have full access to the source
code to use and modify if required. Obfuscated code by definition can't
be classed as "Open Source".
 
Helge Jensen said:
There are decompilers for C/C++/Java/* as well.
Click to expand...

That's true. But trying to disassemble a native executable written in C++
back to its source code is a lot like trying to disassemble a cake back to
flour and water and eggs. You can get an idea of what it is made of but
you'll not know for sure exactly what and how much.

Regards,
Will
 
HamorSth said:
What does "open source" mean in the .NET platform while almost all
"non-obfuscated" codes are "Open-Source"?
Click to expand...

As Helge pointed out being able to decompile code does not make it Open
Source. I can take apart my Sony TV and reverse engineer it, but the design
for the TV still belongs to Sony, and if I tried to sell copies they would
be well within their rights to sue the hell out of me.
Just yesterday i got an add-in for
my ".NET Reflector" which saved the entire disassembled-to-C# "mscorlib"
library for me in .cs files, and i now have a project on my computer that
was one day the efforts of hundreds of people in MS!
Click to expand...

Just as a matter of interest, many EULA's prohibit reverse-engineering, so
doing that would technically be illegal. MS appear to have a sort of relaxed
attritude about this as far as the BCL goes, since they do not appear to
object to people peering into the internals using Reflector or similar tools
to find out whats going on under the hood. Release your own version of the
BCL using their code and I imagine you'd hear from their lawyers sharpish.
I mean, we can't expect the library developers to obfuscate their code in
.NET if they are to expose their classes to others.
Click to expand...

Why? Besides the legalities and licensing issues raised above having the
source code does not mean it is instantly understandable. Many projects are
difficult enough to understand even with documentation and comments. In
addition whilst it may be interesting to see how a competitor implements
something, generally you have your own ideas. When a company I worked for
merged with a competitor, I had access to their source and was horrified.
Without the documentation and the developers walking me through their <ahem>
interesting implementation I would have spent months figuring it out,
probably more time than it would have taken me to develop it from scratch.
Now, isn't this just the unconscious mind of MS that has let him into
releasing a powerful platform
like .NET in "open-source"?
Click to expand...

No, it's an emergent characteristic of verifiable systems. Since the CLR
needs to verify that the code doesn't do anything nasty, the code has to be
easy and quick for the CLR to inspect. Thus the code is also easily
decompiled.
 
William said:
That's true. But trying to disassemble a native executable written in C++
back to its source code is a lot like trying to disassemble a cake back to
flour and water and eggs. You can get an idea of what it is made of but
you'll not know for sure exactly what and how much.
Click to expand...

Have you tried it? decompilation works really works surprisingly well on
many applications. Structural analysis have moved the boundries a lot in
the last 10 years.

Some C++ decompilers still don't recreate templates, but the
C-equivalent code isn't too hard to read.

Have a look at
http://www.program-transformation.org/Transform/DeCompilation.
 
Helge Jensen said:
Have you tried it?
Click to expand...

Yes, though not lately.
decompilation works really works surprisingly well on many applications.
Structural analysis have moved the boundries a lot in the last 10 years.

Some C++ decompilers still don't recreate templates, but the C-equivalent
code isn't too hard to read.

Have a look at
http://www.program-transformation.org/Transform/DeCompilation.
Click to expand...

So I quickly followed the link. If I read it correctly, EXE2C goes back to
the early '90s. Since it wouldn't make it to your "last 10 years" period I
looked at REC where I found this quote

<quote>
Note also a serious problem: REC assumes that the stack pointer does not
change between the prologue and epilogue of a procedure. This is not valid
for programs using the "omit frame pointer" optimisation (or equivalent),
including many Windows programs compiled with MSVC. For more details, see
the paper Using a Decompiler for Real-World Source Recovery.
</quote>

It hardly seems worth the trouble to experiment with a C++ decompiler if it
doesn't understand FPO. :-)

Don't misunderstand, I'm not saying it is not possible. Just as a mass
spectrometer might be used to analyze the cake, decompiling C++ to source
code is a really hard problem that takes lots of time and money to solve.

Regards,
Will
 
Sean said:
No, it's an emergent characteristic of verifiable systems. Since the CLR
needs to verify that the code doesn't do anything nasty, the code has to be
easy and quick for the CLR to inspect. Thus the code is also easily
decompiled.
Click to expand...

Well said, Sean. I think people need to quit worrying about it and
develop some software.

Most software is no mystery, it's just a lot of hard work. Having the
source code is a tiny part of the overall picture that, in the end,
likely wouldn't get the pirates anything *really usable* anyway. I mean,
who really cares if they have something they can't ever use?
 
That's true. But trying to disassemble a native executable written in C++
back to its source code is a lot like trying to disassemble a cake back to
flour and water and eggs. You can get an idea of what it is made of but
you'll not know for sure exactly what and how much.
Click to expand...

the analogy made me smile.
 
A couple of points:

1. It is not "open source" it is "byte code". While this may be splitting
hairs, i use plenty of "open source" projects (nUnit, nAnt, etc. come to
mind).

2. Java is also released in byte code, so this is not a unique problem to
..NET. In fact, the earliest VB code was shipped as PCode, which can easily be
reverse engineered (version 5 is the first version that truly compiled to
native).

3. Byte code has the advantage of being compiled for a particular machine on
the fly (from byte code (MSIL in .NET) to native code). This allows you to
deploy to machines and have the JIT compiler compile in a way that is
understood by the particular processor without having to create multiple
builds. What this means is open code is not all bad.

4. Byte code is also decompilable (Reflector is just one tool). This is a
negative if you are shipping code.

5. There are free obfuscators included Dotfuscator community, which ships
with certain versions of VIsual Studio products (and is downloable even when
not). If you are shipping downloadware or shrinkwrapware, you should
obfuscate at least at this level, although buying a tool is a better option.

The focus of .NET was develop in any language and deploy to any platform
that supports .NET. Currently, you can ship code to Windows (via MS's
implementation), FreeBSD, Linux, Unix and Mac (via the BSD route). In order
to work under all of the processors, the code has to be byte code rather than
native code.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
I agree, to an extent, but the byte code is like handing your source code
over to the competition. WHile they still have to go through the code, it can
save a lot of R&D time, giving the competition an advantage. For shipped code
(rather than code on internal servers), source is very important, making
obfuscation important.

On the other hand, there are ways to make the source safer (obfuscation is
one), so I would not stop developing in .NET simply because it can be reverse
engineered (so can Java, BTW).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Cowboy said:
The focus of .NET was develop in any language and deploy to any platform
that supports .NET. Currently, you can ship code to Windows (via MS's
implementation), FreeBSD, Linux, Unix and Mac (via the BSD route). In order
to work under all of the processors, the code has to be byte code rather than
native code.
Click to expand...

Windows is the only platform that is *really* supported by Microsoft.
Sure the idea behind .NET is to have single compile cross platform code
but it really isn't a reality yet --- is it? I've heard of Mono and
such, but they hardly look like "production" systems..

Am I wrong? Has .NET already spread that far?
 
Cowboy (Gregory A. Beamer) - MVP said:
I agree, to an extent, but the byte code is like handing your source code
over to the competition. WHile they still have to go through the code, it
can
save a lot of R&D time, giving the competition an advantage. For shipped
code
(rather than code on internal servers), source is very important, making
obfuscation important.
Click to expand...

I disagree. Think how long it takes to get a new developer fully up to speed
on a complex product. Now imagine how much that time will increase by when
said developer doesn't have access to mentoring, documentation or comments.
Obfuscation removes another component of the overall documentation by
mangling the semantic names, and thus raises an already fairly high bar. I'm
not saying don't use obfuscation by any means, but just that we shouldn't
underestimate the difficulties in reverse engineering undocumented,
uncommented code.

This thread inspired me to write a little article on the why's wherefore's
and such of decompiling:
http://codingsanity.blogspot.com/2005/05/yawgan.html. It basically boils
down to the the argument above though.
 
Cowboy (Gregory A. Beamer) - MVP said:
I agree, to an extent, but the byte code is like handing your source code
over to the competition.
Click to expand...

Does your source code really not have any comments or meaningful local
variable names? Also, if I hand source code over to anyone, I usually
hand over design documents etc too. Without all of this, just the real
non-comment code is almost useless, IMO. It may well make it relatively
easy to remove licensing, for example, but actually reverse engineering
the code to understand what's going on is much, much harder. I reckon
that for most software systems the overall system design and
architecture is more important than the implementation code, and the
architecture usually has to be part of the documentation in order to
let users understand the product.

I think it's more of a risk for low-cost software vendors who may lose
sales due to licensing "patches" than competitors reverse engineering.
 
Back
Top