unsealing a class

  • Thread starter Thread starter Guest
  • Start date Start date
Is this possible by modifying the IL?
Click to expand...

Arguably *anything* is possible by modifying the IL - but depending on
which class it is (i.e. where it comes from) you're probably violating
the EULA.
 
Of course, anything can be done by smacking around the IL, but you will
likely fail either way. Changing IL is only half of the story. The second
half is the CLR and the strongly named key. The CLR should recognize your
hack and refuse to use your new version, sending you back to the install CD
to straighten out your mess. If the assembly is ngen'ed, you are in even
more of a pickle, as you end up hacking with binary code.

Then again, you can hack the binary code itself, which leads to a deeper
level. This is much more time consuming, but might yield results. If you
have a very good hack mentality, you might even succeed here.

Another avenue is a decompiler, as I do not think the Framework is
obfuscated. Decompile and create a new class or classes that you can ship.
This is the avenue that is most likely to succeed of the EULA violations.
But, you have already stated that the ability to be successfully sued is the
issue, not whether you are breaking an agreement, right? ;->

Another avenue is to make your case to the .NET team for unsealing the
class. You would be surprised how receptive the team is to good arguments.
Of course, you will not be likely to see a lasting change until version 2.0
(Whidbey), but your quest would benefit all of humanity, which could be far
more rewarding.

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

**********************************************************************
Think Outside the Box!
**********************************************************************
 
Umm, ok. Just cause a few were shot down for silly clauses doesn't mean
that any EULA is going to be invalid. But hey, not *our* problem but I
wouldn't plan on releasing commercial or production software based on it.

Now, writing your own class based on the ECMA specs is another story...

-mike
MVP

U think i care about EULAs :D they dont stand up in court.
Click to expand...
 
In the EU the copy right directive PERMITS reverse engineering to allow
interop and discovering how it works as to not stiffle competition.

anyway, EULAs = jack in the legal world.
 
EU Copyright directive, nuff said. EULAs preventing reverse engineering are
automatically INVALID in europe as they breach a directive.

So yes, they would be.


Michael Giagnocavo said:
Umm, ok. Just cause a few were shot down for silly clauses doesn't mean
that any EULA is going to be invalid. But hey, not *our* problem but I
wouldn't plan on releasing commercial or production software based on it.

Now, writing your own class based on the ECMA specs is another story...

-mike
MVP
Click to expand...
 
In the EU the copy right directive PERMITS reverse engineering to allow
interop and discovering how it works as to not stiffle competition.

anyway, EULAs = jack in the legal world.
Click to expand...


To me, this is the same as:
As long as there are no cops around, speed limits = jack in the legal world.

Ethically, one should ask whether something is right or wrong, not whether
there will be punishment, legal or otherwise. If society was based solely on
getting caught, or not, the system created is an anarchy. Ultimately, chaos
ensues.

In a society whose "higher power" is the government, the main question is
whether or not one will get caught, rather than right or wrong. As the
government has limited reach, new laws are consistently passed for items
that should have been caught by ethics or decency. Unfortunately, when
government is the "higher power," competing desires are the main issue,
which means screw before you are screwed. Not exactly the golden rule.

As far as reverse engineering goes, Salamander is the best tool on the
market (albeit pricey if you do not hork it). If you have time, Reflector is
rather nice (http://www.aisto.com/roeder/dotnet/) -- Anakrino
(http://www.saurik.com/net/exemplar/) is also fairly decent, although it has
not been updated in a long time.

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

**********************************************************************
Think Outside the Box!
**********************************************************************
 
Nothing wrong with reverse engineering, its tottaly ethical for interop,
otherwise you are stifling other products. Thats more unethicsl. EU
directives recognise this.
 
I did not state that the process of reverse engineering was unethical, only
the thought process "if I cannot successfully get sued, I am allowed to do
what I want".

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

**********************************************************************
Think Outside the Box!
**********************************************************************
 
EU Copyright directive, nuff said. EULAs preventing reverse engineering are
automatically INVALID in europe as they breach a directive.
Click to expand...

That's not true. According to the Legal Protection of Computer Programs
Directive [1993] you're only allowed to reverse engineer or decompile a
program for interoperability reasons in Europe. For instance, you'd be
allowed to reverse engineer a DLL if and only if it contains an undocumented
API. Since .NET is documented, decompiling the .NET class library would be a
violation of European law.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl
 
"for interoperability reasons" doesnt mean documented only, I can do this
also to confirm behaviours, this part is open to intrepertation, not just
APIs, I can also do this for any I/O sources, sockets, the lot.





Pieter Philippaerts said:
EU Copyright directive, nuff said. EULAs preventing reverse engineering are
automatically INVALID in europe as they breach a directive.
Click to expand...

That's not true. According to the Legal Protection of Computer Programs
Directive [1993] you're only allowed to reverse engineer or decompile a
program for interoperability reasons in Europe. For instance, you'd be
allowed to reverse engineer a DLL if and only if it contains an undocumented
API. Since .NET is documented, decompiling the .NET class library would be a
violation of European law.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl
Click to expand...
 
Broad prevention of reverse engineering and benchmarking is a standard EULA
FUD template. So alot is not publically documented on software so yes it
would be automatically invalid in alot of cases with those clauses.


Pieter Philippaerts said:
EU Copyright directive, nuff said. EULAs preventing reverse engineering are
automatically INVALID in europe as they breach a directive.
Click to expand...

That's not true. According to the Legal Protection of Computer Programs
Directive [1993] you're only allowed to reverse engineer or decompile a
program for interoperability reasons in Europe. For instance, you'd be
allowed to reverse engineer a DLL if and only if it contains an undocumented
API. Since .NET is documented, decompiling the .NET class library would be a
violation of European law.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl
Click to expand...
 
Why would one think of violating eula... and why do u want to unseal the
class.. anythign is possible by manipulating the MSIL....


Keyur Shah
Verizon Communications
732-423-0745
 
"for interoperability reasons" doesnt mean documented only, I can do this
also to confirm behaviours, this part is open to intrepertation, not just
APIs, I can also do this for any I/O sources, sockets, the lot.
Click to expand...

In your case, you're obviously not decompiling to "confirm behavior". The
behavior is well documented in the documentation -- the class is sealed or
not sealed. Besides you can easily confirm the sealed behavior by writing a
small application in C# that tries to inherit the class. If the compilation
fails, you'll have verified the sealed behavior with a means other than
decompilation.

Your case has absolutely nothing to do with interoperability. Besides, if
you decompile a DLL, modify the IL a bit and then recompile it, you're not
only violating the decompilation laws but also the copyright laws.

Notice that your case is explicitly included in the law:
"2. The provisions of paragraph 1 shall not permit the information obtained
through its application:
[..]
(c) to be used for the development, production or marketing of a computer
program substantially similar in its expression, or for any other act which
infringes copyright."

Oh, and by the way: this law applies to any computer program -- with or
without EULA [unless the author clearly allows decompilation, which is
obviously not the case if we're talking about Microsoft].

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl
 
If the assembly is ngen'ed, you are in even
more of a pickle, as you end up hacking with binary code.
Click to expand...

Why would the presence of a NGENed copy pickle the process more? NGENed
assemblies have a module version identifier (MVID) that has a dependency on
the hash of the original assemblies physical file, so the runtime will be
able to detect that the NGENed assembly is invalid, and silently fall back
to JIT compilation.

I agree with your overall opinion that IL modification of other parties
assemblies is generally not the best idea, and lobbying the vendor for a
worthwhile change is the best course of action.

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org
 
hi

Should be possible for a non-strong-named assembly.
However, if the assembly is strong named and u modify the
IL and reassemble it, then you will be trouble, as you
will not be able to use it again
 
Back
Top