AsmResolver reads and rewrites PE files from managed code

A PE object model instead of a hex editor

AsmResolver exists to remove the part of binary work that lives in a hex editor. Its stated purpose is a library for reading, modifying and reconstructing Portable Executable files, and it handles PE images that run natively on Windows as well as images that carry managed .NET metadata. The project description calls it a library for creating, reading and editing PE files and .NET modules, and the topic tags it carries name the same territory: portable executable, il, cil, msil, parser, writer, disassembler, assembler, reverse engineering and malware analysis.

The audience is a developer writing tools rather than a person at a terminal. That means a modding pipeline, a packer or unpacker, a build step that needs to patch an assembly, a static analysis tool, or malware research where a sample has to be taken apart and put back together. The project lists malware analysis among its topics, which is a fair signal about the intended use.

The implementation is C#, the licence is MIT, and the library is documented on a dedicated documentation site with guides, an API reference and a migration page for v5 to v6. The last push was on 2026-10-03, and the release line is v6, with 6.0.0 tagged on 2026-05-16 after a release candidate in March, and 6.0.1 on 2026-07-25.

The .NET metadata API borrows its shape from System.Reflection

The managed side of the library is the part with the most interesting design decision, and the project states it plainly: the .NET metadata support comes with an intuitive API similar to System.Reflection. If you have written reflection code, the object model reads as familiar. Type, method and field lookups feel like the framework's own metadata model rather than like a raw table parser.

Underneath, the feature list is broad. Method bodies are supported in managed, native and dynamic form, which covers the different ways a .NET method can hold its code. Metadata importing and cloning are called out as easy, meaning you can take a type from one module and place it in another without hand-assembling the tables. Managed resource file serializers and deserializers are included, so embedded resources can be read and rewritten. AppHost and SingleFileHost bundles are supported, which matters for anyone touching .NET single-file publishing, and ReadyToRun binaries are handled too, where the precompiled native code in the image has to be understood rather than discarded.

The result is a library that can load a module, treat it as a graph of types and methods, modify that graph, and write the result back out. The reconstruction step is where most of the work lives, and the feature list makes the ambition explicit: full control over the layout of the final PE file output.

Native images: sections, data directories and a rebuilt import table

The native half of the library is where the hard PE work is, and the feature list names it: full access to sections, data directories and their interpretations, plus Import Address Table reconstruction and trampolining. Reading a data directory is straightforward, interpreting one is not, and the library treats the interpretations as part of its surface rather than leaving them to you.

The import table is the interesting case. When a binary is modified, the import table often has to be rebuilt, and the reconstruction and trampolining support covers that. Trampolining in particular is the kind of thing that only matters if you intend the result to run, and its presence tells you the library is aimed at producing working output rather than only at parsing.

Win32 resources are covered as well, with support for resource types such as icons and VersionInfo, so a tool that rewrites a file can also update the version block and the icon in the same pass. Sections, data directories, resources and imports are all first-class objects in the model, and the final layout of the written file is something you control.

Getting the package and building the solution

The library ships on NuGet, and there are two feeds. Stable builds come from the public NuGet feed and from GitHub releases, and nightly builds come from a separate NuGet feed hosted by the project, whose service index is listed in the project documentation. The distinction matters in practice: if you want the newest commit behaviour for a tool you build yourself, the nightly feed is where it is, and if you want a pinned stable version, the public feed is the one to use.

Building from source needs the .NET SDK, or an IDE that works with it, and the project names Visual Studio and JetBrains Rider as examples. The main packages target long-term support versions of several runtimes, which the documentation lists as .NET Framework 3.5, .NET Standard 2.0, .NET Standard 2.1, .NET Core 3.1, .NET 6.0, .NET 8.0, .NET 9.0 and .NET 10.0. The command line build is a single step:

dotnet build

The solution file is AsmResolver.slnx, and the tree is split into src, test, tools and docs, with shared build settings in Directory.Build.props. Running the tests is the second command:

dotnet test

The test suite has a specific appetite. Because the unit tests verify reading binaries that target various .NET runtimes, you need additional runtime versions installed, including support and end-of-life versions, and on macOS and Linux the documentation expects mono and wine to be present as well. That is a heavy local setup for a contributor, and it is worth knowing before you plan to run the suite in continuous integration.

Reading symbols without DIA

Symbol reading gets its own bullet in the feature list, and the detail attached to it is the part that matters. The library offers rich read support for PDB and PortablePdb symbols through a fully managed cross-platform API, and the project states that no DIA or similar dependencies are required. DIA is the Windows debug interface access SDK, and by removing the dependency the library keeps its symbol reading available on Linux and macOS as well as Windows.

That is a design choice with consequences. A managed implementation of the PDB format can be read and analysed anywhere the library itself runs, which makes cross-platform analysis and CI-based inspection practical, and it removes a native component that would otherwise need to be provisioned per machine. The trade is that a from-scratch implementation of a debug information format is a large surface to keep current, and the project is explicit that this is read support rather than a full debugging scenario.

The library is also built to survive hostile input, which the feature list describes as being built to be resilient against malformed or obfuscated binaries. For an analysis tool that is a primary requirement, because a packed or corrupted sample is a normal input rather than an exception. The project lists unit testing among its guarantees.

Where a hex editor or a scripting approach fits better

The alternative is not a competing library but a different level of intervention. A general purpose binary editor changes bytes at offsets you chose yourself, and for a single field, a version string or a patched branch, that is faster than learning an object model. The cost of the manual approach is that every offset is a guess you have to confirm by hand, and the edit is not re-derivable after the file changes.

AsmResolver trades that for structure. A resource is a resource object, an import is an import, a managed type is a type with methods and fields, and the write step rebuilds a consistent file from the model. The difference in approach is manual offsets versus a typed graph, and the second one pays off when the edit involves more than a couple of bytes, when the file must still run afterwards, or when the same tool has to work on many samples with varying layouts.

There is a third path for smaller jobs. If the goal is to read a few values out of a .NET assembly, reflection over the loaded assembly, or the framework's own metadata readers, will answer the question without a PE parser at all. AsmResolver is for the cases reflection cannot reach: files on disk that are not loadable, malformed inputs, resources, and images whose layout you intend to change.

Version 6 and the cost of an API break

The upgrade path is the main practical risk. The documentation publishes a dedicated guide for migrating from v5.x to v6.0, which is what a project publishes when the public API changed in a way that touches callers. For a library whose users tend to hold long-lived tooling, a major version means reading the migration guide before touching the version number in a project file.

The release record shows how deliberate the process was. A release candidate for 6.0.0 appeared on 2026-03-06, the stable 6.0.0 followed on 2026-05-16, and 6.0.1 on 2026-07-25 fixed something in the new line. The last push on 2026-10-03 is later than the tagged release, which is consistent with a project that keeps working on master and publishes nightly packages from it.

On licensing, the project is MIT with the text in LICENSE.md, so a commercial tool built on it can be closed source and shipped. The repository also carries a CONTRIBUTING.md, and the acknowledgements credit the people at MonoMod for the .NET Framework 3.5 compatibility work, which is the kind of help that matters when a library still supports a runtime from that era. The project describes itself as having started as a hobby project and grown into a community project, and it runs a Discord alongside the issue tracker and discussion board.

Editorial conclusion

AsmResolver fits reverse engineering, packaging and tooling work where a binary has to be inspected or rebuilt programmatically and a text editor will not do, especially for .NET assemblies with managed metadata. It is the wrong tool when you need to execute untrusted code safely, when the target is not a PE image at all, or when a one-off byte patch would be faster by hand. Verify first that your target runtime is covered by the library's object model, that the v5 to v6 migration guide matches the API you depend on, and that the symbol reading path you need works without DIA on the platform you build for.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Washi1337/AsmResolver on GitHub