You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CLR supports exporting managed methods as unmanaged functions that can be referenced by other native binaries or being P/Invoked. Currently, there is no way in AsmResolver.DotNet to specify that a MethodDefinition should be exported.
Proposal
Add a property to MethodDefinition that indicates the method should be exported or not. The ManagedPEImageBuilder would then add the appropriate VTable fixup and export directory entries to the image.
This could look something like the following:
MethodDefinitionmethod= ...// Indicate method should be exported by name.method.ExportInfo=newUnmanagedExportInfo{Name="MyExportedFunctionName",};// Indicate method should be exported by ordinal.method.ExportInfo=newUnmanagedExportInfo{Ordinal=1234,};
Alternatives
Users of AsmResolver could first transform the ModuleDefinition they are working with to a PEImage first, to then manually create and add the appropriate VTable fixup and export directory entries before writing it to the disk. This adds a lot of noise to the code, which is something we want to solve with this proposal.
Problem Description
The CLR supports exporting managed methods as unmanaged functions that can be referenced by other native binaries or being P/Invoked. Currently, there is no way in
AsmResolver.DotNet
to specify that aMethodDefinition
should be exported.Proposal
Add a property to
MethodDefinition
that indicates the method should be exported or not. TheManagedPEImageBuilder
would then add the appropriate VTable fixup and export directory entries to the image.This could look something like the following:
Alternatives
Users of AsmResolver could first transform the
ModuleDefinition
they are working with to aPEImage
first, to then manually create and add the appropriate VTable fixup and export directory entries before writing it to the disk. This adds a lot of noise to the code, which is something we want to solve with this proposal.Additional context
Requires #63, #179
The text was updated successfully, but these errors were encountered: