Closed siegfriedpammer closed 6 years ago
By design SRM does not accept assemblies that do not comply with ECMA335 spec.
Reading obfuscated assemblies doesn't seem like an important scenario for ILSpy to me. Customers using obfuscators certainly don't want their code to be disassembled.
For ILSpy this is not much of a problem, because if ILSpy fails you can still use a deobfuscator like de4dot, but if SRM fails, how do you process these in Visual Studio, given that Roslyn uses SRM as well?
Note that this exception occurs simply when trying to open the assembly, not reading any method bodies, so retrieving public types and members would also fail -> no intellisense.
The output of an obfuscator is still required to adhere to the specifications for the underlying VM. If it fails to do so, downstream tools are expected to fail randomly.
Before determining how how SRM should handle this, we need to determine if this is a bug in SRM (obfuscated code adheres to the specification), or if this is an intended behavior of the obfuscator (does not adhere to the specification).
@siegfriedpammer your example produces a CS0009 compilation error if you try and compile against the assembly. IntelliSense fails as well. For all practical purposes, this is an unusable assembly from a developer's perspective.
OK, then it is completely worthless and I think we can live with an exception in this case. Thank you for looking into this!
While doing some testing of the new disassembler on the srm branch, I came across this exception:
MetadataReader is not very resilient. Feeding it the obfuscated
Lidgren.Network.dll
Lidgren.Network.dll.zip makes it fail completely.@sharwell @nguerrera @tmat Do you have any plans on improving SRM in this regard?