Is that a crime to use Reflection on System classes?

  • Thread starter Thread starter Vladimir Kouznetsov
  • Start date Start date
V

Vladimir Kouznetsov

Hello everybody,

I've already tried this group a month ago, but didn't get any opinion on the
matter.

The question basically is: if that is a kind of reverse engineering and if
reverse engineering is legal in the US, Canada, Europe? Let's say I run into
a bug in the MS's implementation and I'm trying to come up with a
workaround. Sometimes one can figure out internal implementation details
only by looking at non-public members' declarations and probably even fix
that by using Reflection. And of course one could solve the problem in more
cases if one had a right to look at the IL function representation. The
second way is
definitely a reverse engineering. What about the first one? If it's illegal
we probably cannot even expand objects of System classes in debugger. On the
other hand there are ways to hide those details from debugger and if they
are not hidden may be it's not illegal? I couldn't find a statement in the
EULA that it's not allowed to reverse engineer .Net Framework. There is such
a statement in .Net Framework SDK though. May be the reverse engineering is
disallowed by default? I know that in some countries copyright laws allow to
use reverse engineering to achieve integration with other company's
products.
Let's say I found a solution based on using reflection. What can I do with
it? Can I use it? Can I sell it? Can I tell everybody about the way of
fixing the problem just to become famous? Or I shouldn't even think about
it?
I'm not asking for a legal advise and I'm pretty sure that the solution is
not going to be supported by MS in any way.

thank you for your time,
v
 
For instance, I don't think there is any way for me to find out the timeout
for Forms Authentication without parsing the web.config. So, I could use
reflection to check their internal field.

As far as legality, I don't think you'll have too much a problem, unless
you're doing something against Microsoft (for instance, hacking their
libraries to contribute to Mono would probably off limits :))

The real problem is that things internally will change without notice. You
could go sell something that uses reflection to read some system value, only
to find out that in a new framework, it's been changed.

You'll need a lawyer to sort thru things correctly, but I don't see any
inherent problem using Reflection to do stuff to private members.

-mike
MVP
 
Thank you Michael,

What I'd really like to know is if reverse engineering is legal and if using
reflection is a kind of reverse engineering.

The reliance on implementation details is just a deployment strategy and in
this particular case might even work pretty well - thanks to side-by-side
execution.

I would be extremely surprised if Microsoft pressed charges against all
developers using the Framework just because they can see the details in
debugger, but you never know :).

It's not a matter of business for me, I'm not going to sell anything like
that so I don't feel like getting a lawyer. It's more just my curiosity.

Any way thanks for you reply,
v
 
If .net framework team did not want you to look at the inside of the system
assemblies, they could very well run some obfuscator to make the IL code
unreadable. They did not do that. That itself tells something.

For your side by side luck, well, maybe once you installed a SP, your stuff
breaks. Who knows. And if your product depends on modifying system
assemblies, how do you make sure the machine your product installs with have
the correct modified bits? If you say you are going to change it, how do you
make sure you will not screw other applications? Your best bet is to work
with Microsoft to fix the bug if you really think it is important.

For you worry on Microsoft charge, if you are that paranoid, you better not
use any commercial product.
 
inline:

Conrad Zhang said:
If .net framework team did not want you to look at the inside of the system
assemblies, they could very well run some obfuscator to make the IL code
unreadable. They did not do that. That itself tells something.
Click to expand...
This may ar may not tell something. I know how it works: development
department has one vision, marketing has another one and legal department
has no idea what's going on for the time being.
For your side by side luck, well, maybe once you installed a SP, your stuff
breaks. Who knows. And if your product depends on modifying system
Click to expand...
As I said that is a matter of the deployment strategy. My only deployment
target can be my own workstation so you can stop to worry about that.
assemblies, how do you make sure the machine your product installs with have
the correct modified bits? If you say you are going to change it, how do
Click to expand...
you
Think about that once more. I don't have to change system assemblies to fix
the problem. I was talking about Reflection that meant I was going to make
run-time changes. In fact in some cases the changes required can be quite
hygienic, affecting only certain inctances my application has total control
over anyway.
make sure you will not screw other applications? Your best bet is to work
with Microsoft to fix the bug if you really think it is important.
Click to expand...
Yeah, in the best case they will fix that in the next release which will
happen in a year.
For you worry on Microsoft charge, if you are that paranoid, you better not
use any commercial product.
Click to expand...
Probably not even open source ones - look what SCO is doing. ;)
 
Reverse engineering is normally not allowed via a license, and the Digital
Millenium Copyright Act (DMCA), which is almost always abused, can easily
say no. If I write a program that moves one byte from the beginning of a
file to the end of it, and you "crack" it, the DMCA can be used against you.
In the states, depending on who sues you, you can either fight it and maybe
win after wasting tons of money, or get arrested by the FBI or whoever and
put in jail for the rest of your life. New laws against "terrorism" + the
DMCA + wide definition of hacking makes it pretty dire, at least
technically.

On the other side, there's very little chance MSFT would move against you
unless you were doing something that was hurting them or their partners.

-mike
MVP
 
Thanks again Michael!

So it looks like:
- Reverse engineering of system classes is probably not prohibited by the
license, as there is no mention of that in there;
- Reverse engineering of system classes is most probably prohibited by the
DMCA;
- If using reflection on system classes is a reverse engineering is not
clear;
- If you used to inspect instances of system classes in debugger you are
most probably not going to have any troubles if you are not hurting MS or
its partners and don't have personal enemies in its legal department.

We are done if we define troubles, hurting, partners and enemies ;).
 
I've heard of customers doing two things:

1) Looking at the shared-source cli source code, which has a lot in common
with the shipping .Net version
2) Running a decompiler over the system assemblies

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the response Eric,

I know about Rotor and ildasm, that doesn't answer my questions :( Using of
ildasm to decompile code definitely is a reverse engineering. As to
Reflection - visibility of internal details in debugger could tell that it's
considered legal by MS if there were no chances that that was unintentional.
I'm not trying to make a big deal out of that. If using Reflection was not a
reverse engineering that would open a lot of possibilities of fixing bugs by
third parties. I'm not saying if that's good or bad, that definitely adds
compatibility and maintenance problems. But that might be fun :).

thanks,
v
 
Back
Top