Open xXTurnerLP opened 2 weeks ago
This is an interesting edge-case that can be reduced to preserving StandAloneSignature
s with local variable signatures referencing the removed type.
Removing a type results in this type becoming "unimported" because it is no longer present in the module. However, preserving a standalone signature that still references this type will therefore mean preserving a signature with an invalid reference to a non-existing metadata member:
This issue highlights the asymmetry that exists within what it means to "preserve indices" for different metadata tables. Preserving TypeDef indices preserves RIDs by replacing removed types with inaccessible empty dummy types. Preserving standalone signatures does not replace removed signatures with dummy metadata, but preserves the unreferenced signature as a whole including its contents. This was a conscious decision to make it easier to add "floating" signatures to modules that are not directly referenced by metadata but by code (e.g., using Module::ResolveSignature).
Since we are preserving invalid signatures, should we consider this an error? If so, how should a user deal with this (other than simply ignoring the error)? We also want the user to create invalid .NET modules. Should there be an extra builder flag for this? Should the signature keep referencing the original metadata token (and thus reference the new placeholder type), even if the target type is removed?
Open to suggestions.
AsmResolver Version
6.0.0-beta.1
.NET Version
.NET 8.0
Operating System
Windows
Describe the Bug
When removing a typedef from this particular assembly and using the PreserveAll flags it will throw a bunch of
MemberNotImportedException
exceptions but if that flag is not used it will work as expected and the modified assembly will have the typedef removedHow To Reproduce
To reproduce it, I've managed to create this minimal example for .NET 8.0 console project on windows
After building the app drag & drop this provided dll onto the .exe or pass it as the first argument if invoking from a console or a debugger.
For completeness sake, I will provide a working compiled example: CompiledExample.zip (needs .NET 8.0 runtime to run)
Expected Behavior
Save the module without issues
Actual Behavior
Throws:
Additional Context
No response