Consider ignoring SuppressIldasmAttribute in ILDASM

[vcsjones]

The SuppressIldasmAttribute instructs the ildasm tool to prevent working on assemblies or modules that have this attribute over here.

I'd like to ask re-considering if this is necessary still and if the check can be removed, and documenting the attribute as obsolete.

Some motivation:

The attribute is, as many know, trivial to bypass. Practically every other disassembly tool ignores this attribute. As for why "Well why not keep using that tool" is because ildasm offers some benefits over other tools, such as quickly dumping the IL-text to disk and re-assembling.

The attribute conveys as sense of protection that is really not existent. If the desired outcome is to protect intellectual property, then they should be steered toward 3rd party solutions like a commercial obfuscator.

[Symbai]

The attribute conveys as sense of protection that is really not existent. If the desired outcome is to protect intellectual property, then they should be steered toward 3rd party solutions like a commercial obfuscator.

Which can also bypassed easily so the protection is not really existent as well. Instead .NET should offer a way to generative native assemblies and this wouldn't be a problem at all. On top of that, it would also provide performance improvements.

[mgravell]

Instead .NET should offer a way to generative native assemblies and this wouldn't be a problem at all.

...because as we all know, native assemblies can't be disassembled, decompiled, etc! 🤦‍♂️ (my point: that also just gives a false sense of security)

[dotMorten]

The attribute is, as many know, trivial to bypass. Practically every other disassembly tool ignores this attribute. As for why "Well why not keep using that tool" is because ildasm offers some benefits over other tools, such as quickly dumping the IL-text to disk and re-assembling.

I think this is the wrong argument. The attribute is not about security or completely preventing people from decompiling. It's about helping to keep the honest people honest. A lot of commercial software (if not all of it), has a license that explicitly forbids your to decompile their code - regardless of whether it's possible or not. This attribute is useful for those products as it's another indicator that acts in support of this paper license. This especially becomes true with Visual Studio now offering users to decompile libraries when navigating to a definition. This attribute is there to prevent that from happening, as clicking yes to decompile instantly makes you violate that license agreement.

If producers of class libraries wants to make it easy for users to decompile their stuff, all they have to do is not set this attribute on their assembly. Easy peasy. But don't obsolete this attribute, or have ildasm ignore it, or have VS's go-to-definition bypass it.

I could perhaps see an argument for letting ildasm ignore this attribute (or a dialog to allow you to override it), but the Visual Studio scenario is still very much valid.

[mletterle]

The attribute is, as many know, trivial to bypass. Practically every other disassembly tool ignores this attribute. As for why "Well why not keep using that tool" is because ildasm offers some benefits over other tools, such as quickly dumping the IL-text to disk and re-assembling.

I think this is the wrong argument. The attribute is not about security or completely preventing people from decompiling. It's about helping to keep the honest people honest.

It may be better to define a standardized AssemblyMetadataAttribute for this scenario, something like [AssemblyMetadata("PlsNoDecompile")] :P

[dotMorten]

@mletterle Aren't we then just replacing one attribute with another to cover the exact same scenario?

[mletterle]

@mletterle Aren't we then just replacing one attribute with another to cover the exact same scenario?

Yes, but it would not be ildasm specific so it would not seem wrong for ildasm to ignore it ;)

[GrabYourPitchforks]

FWIW, I believe ildasm and VS don't look for this specific attribute (as it exists in System.Private.CoreLib). I think you can define your own attribute with the same namespace & name in your own assembly, and the behavior today is that those tools will honor the attribute.

In practice, what this means is that if the only change we made was to remove this attribute from the reference assemblies, with no other functional changes, the tooling would continue to work as it does today.

[mletterle]

On a relevant note, maybe a good compromise is to add an opt-out argument to ildasm and have it match just on the attribute's simplename (ignoring namespace) and remove the attribute from CorLib. Users and protection tools could then inject their own versions of SuppressIldasmAttribute and "honest" developers could simply never use the opt-out argument.