unsealing a class

[rs_tiin]

Hi

YEP!!!!!!!!!!!!!!! It works. Opened the dll in ILDASM,
dumped it to a IL file, removed the sealed keyword,
compiled it thru ILASM and IT WORKS!!!!!!

regards,

sr

 

[news.microsoft.com]

ok good, now inherit from String

Hi

YEP!!!!!!!!!!!!!!! It works. Opened the dll in ILDASM,
dumped it to a IL file, removed the sealed keyword,
compiled it thru ILASM and IT WORKS!!!!!!

regards,

sr

 

[news.microsoft.com]

How good is obscufation against this?

Hi

YEP!!!!!!!!!!!!!!! It works. Opened the dll in ILDASM,
dumped it to a IL file, removed the sealed keyword,
compiled it thru ILASM and IT WORKS!!!!!!

regards,

sr

 

[rs_tiin]

Hi

To Summarise

a) At a top level yes you can unseal
b) You can do i by modifying it at IL Level
c) If the Assembly is strong-named it will NOT work
d) If the Assembly is NOT strong-named it will work(can
send you a sample)
e) To do it on a Non-Strong Named Assembly,
i) Open the dll in ILDASm
ii) Dump the full contents(hoose all CheckBoxes that
you get on choosing the Dump Option from File Menu) to
a .IL FIle
iii) Open the IL File in Notepad and remove all
instances of sealed
iv) Compile the File using ILASM
v) Set Reference to this file
This will work on a Non-Strong named Assembly. if you try
to do it on a Strong-Named Assembly, at runtime you will
get the error
"A first chance exception of
type 'System.IO.FileLoadException' occurred in Unknown
Module.

Additional information: Strong name validation failed for
assembly 'ILServerApp'."

hth

regards,

sr

 

[Jon Skeet [C# MVP]]

c) If the Assembly is strong-named it will NOT work

Yes it will. You just take out the bit which makes it strongly named,
and you'll end up with a non-strongly-named assembly. It's pretty
simple to do. The harder (but not really hard) bit is then to get rid
of the bit of code in whatever's loading this library which requires it
to be strongly-named in the first place. It may be that there is no
such bit of code anyway, or that it's easy to remove.

I wouldn't approve of doing things like this anyway though.

 

[news.microsoft.com]

Well, you can limit youreself if you want just means the rest of us will
have more tools in our toolbox than you.

 

[Jon Skeet [C# MVP]]

Well, you can limit youreself if you want just means the rest of us will
have more tools in our toolbox than you.

If any employer ever requires me to break the law in order to do my
job, I'll leave. I don't believe that modifying someone else's assembly
falls under fair use.

 

[Guest]

If does as a workaround for a bug. Would you rather dilly dally and wait
around and twiddle youre thumbs or use workarounds?

"Workaround" is a common chant in the software world. Heard it too often,
some1 raises a bug, next thing you hear is "WORKAROUND".

Guess you go through many jobs if you cant workaround bugs.

 

[Pieter Philippaerts]

If does as a workaround for a bug. Would you rather dilly dally and wait
around and twiddle youre thumbs or use workarounds?

Infringing someones copyright to work around a bug is still copyright
infringement and your argument won't hold up in court.
If you need to work around a bug, either notify Microsoft about it and wait
until they fix it, or work around it without violating the law.

Also note that a sealed class is not a bug -- it's a design decision.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

 

[Guest]

Its still theyre copyright even if you workaround, you arnt claiming
ownership of theyre code.

 

[Gary van der Merwe]

Hi

Lets say I wanted to extend System.Data.SqlClient.SqlDatareader. I want to
optimize GetOrdinal - So that I can use the Indexer without performance
worries.

Lets say we edit the System.Data.dll to unseal the SqlDatareader so that we
can create a class that inherits SqlDatareader, override GetOrdinal.
Objective achieved??? Not quite yet.

How do you use your derived class. You can't call SqlCommand.ExecuteReader()
and box the result, because that is downward boxing, which you can't do!
What you would need to do, is override SqlCommand.ExecuteReader() with a
decompiled version, modified to use your derived SqlDataReader.

This is not a desirable solution! And this Is why I believe the MS Sealed
the class. Not for petty legal, but for a good technical reason

Maybe the class that you have unsealed was sealed for legal, or for
technical reasons. I am sure that it was for technical reasons, but I sujest
that you think about it a bit!


Gary

 

[Daniel O'Connell]

Its still theyre copyright even if you workaround, you arnt claiming
ownership of theyre code.

Well, to change it, you are likely creating a derived work without adding
significant value. By doing so and distributing it you may be violating
their copyright. Doing it on your local machine is probably not a big deal,
but any form of distribution is most likely illegal in most countries.
In such cases, your stealing the source of one product to create your own.
Even if your product is the same as the other one with a bit unset. Its on
the same legal level as a game or app crack, probably legal to write and
probably illegal to use.

 

[William Ryan]

You know, prevailing in court isn't really the issue most of the time. I
guess if you have an extra 10 grand sitting around with nothign better to
spend it on than attorney's fees just to prove you are 'right' and just so
you can unseal a class...knock yourself out. However, Sealed classes are
sealed for a reason. Most of the Framework classes are sealed for
performance optimizations, and if you start freestyling with IL, you are
going to break something - I'm not being negative and don't mean to put you
down or slight you, but there's a lot more to it than just changing IL. So
even if you succeed, you may have a class that's slow and unpredicatable,
and the only possible benefit is a shot at unsealing it. The math just
doesn't look right...

U think i care about EULAs they dont stand up in court.

 

[William Ryan]

A truer post I have not seen. Particularly considering developers earn
their livelihood by selling intellectual property, we should be especially
respectful and aware of such issues. I always like reading your posts b/c
you are techincally correct and communicate very succinctly - and this is
Greg at his finest!