Verify a Mono Assembly with pedump

You will finish with a repeatable check for a managed PE file: inspect its headers, run Mono's IL verifier, and distinguish a clean result from a file that pedump cannot open. This guide uses the pedump shipped by Debian's mono-utils package, version 6.8.0.105+dfsg-3.6ubuntu2 on the system tested.

Allow about fifteen minutes. You need a shell, mono-utils, and an .exe or managed .dll to examine. The examples only read their input files. They do not repair, rewrite, sign or execute an assembly, so no elevated privileges are normally needed.

1. Confirm the local command

The installed manpage is deliberately sparse. It says that the program has no manpage and directs you to its help switch. Treat the binary on your machine as the contract, because pedump's interface is not a general-purpose .NET standard.

$ command -v pedump
/usr/bin/pedump
$ dpkg-query -W -f='${Package} ${Version}\n' mono-utils
mono-utils 6.8.0.105+dfsg-3.6ubuntu2
$ pedump --help
Usage is: pedump [--verify error,warn,cls,all,code,fail-on-verifiable,non-strict,valid-only,metadata] file.exe

The help command exits with status 1 on this installation after printing its usage line. That is an awkward but reproducible detail: do not use the exit status of --help as a health check for the utility. The useful information is the accepted command shape and verify modes.

2. Inspect the PE and CLI headers

Run pedump with a known assembly path. A normal invocation prints the file's COFF, PE and managed metadata details. Use a quoted shell variable when the path is not a fixed literal.

$ ASSEMBLY='/path/to/application.exe'
$ pedump "$ASSEMBLY" | sed -n '1,35p'

COFF Header:
                Machine: 0x014c
               Sections: 0x0003
...

PE Header:
         Magic (0x010b): 0x010b
             Entry Point RVA: 0x000022fe

The exact numbers depend on the input and the compiler. The useful first question is whether pedump can parse the image at all. A file extension is not proof that a file is a managed assembly, and a native Windows PE file is not automatically a suitable input.

Capture the status separately if this is going into a script:

if pedump "$ASSEMBLY" >/tmp/pedump-report.txt 2>/tmp/pedump-error.txt; then
    printf '%s\n' 'pedump opened the image'
else
    status=$?
    printf 'pedump could not inspect the image, status %s\n' "$status" >&2
    exit "$status"
fi

3. Run verification on a copy or build output

Use --verify to ask Mono to check the assembly's verifiable structure and IL. The argument is a comma-separated selection from the modes shown by --help. Start with all when you want the broadest check exposed by this installed tool.

$ pedump --verify all "$ASSEMBLY"
$ status=$?
$ printf 'verification status: %s\n' "$status"
verification status: 0

For a clean, ordinary assembly, this command may print nothing and return 0. Silence is therefore expected output, not evidence that the command was skipped. Redirect output to a log when a build or audit needs a record:

report='/tmp/pedump-verify.txt'
if pedump --verify all "$ASSEMBLY" >"$report" 2>&1; then
    printf 'verification passed: %s\n' "$report"
else
    status=$?
    printf 'verification failed or could not inspect the image, status %s\n' "$status" >&2
    sed -n '1,80p' "$report" >&2
    exit "$status"
fi

Do not overwrite the original assembly while investigating it. This command is read-only, but a later repair or signing step may not be. Keep the report and the original file together until you have decided what should happen next.

4. Choose a narrower verification mode when the question is specific

The local help lists these selectors: error, warn, cls, all, code, fail-on-verifiable, non-strict, valid-only and metadata. They are not interchangeable labels for a generic lint command.

• metadata is useful when you are checking the metadata side of an image.
• code focuses the request on code verification.
• valid-only and non-strict change how verification treats accepted or strict cases; use them only when your build or compatibility policy calls for that distinction.
• fail-on-verifiable changes failure handling, so read the exit status rather than relying on displayed text.

For example, this records a metadata-only check without claiming that the method bodies were fully tested:

$ pedump --verify metadata "$ASSEMBLY"
$ printf 'metadata check status: %s\n' "$?"
metadata check status: 0

Use one mode at a time while diagnosing a failure. Once you know which category matters, combine selectors only if the output and status still have a clear meaning for your pipeline.

5. Separate input errors from verification findings

A path can fail before verification starts. Here is the safe distinction using a deliberately invalid temporary file:

$ printf '%s\n' 'not an assembly' >/tmp/not-an-assembly.bin
$ pedump /tmp/not-an-assembly.bin
Cannot open image /tmp/not-an-assembly.bin
$ printf 'status: %s\n' "$?"
status: 1

That result means pedump could not open the image. It does not prove that the file contains invalid IL, and it does not mean that running verification again with a different selector will repair it. Check the path, permissions and file type first. If the input is copied from an untrusted source, preserve it for analysis and do not execute it with Mono or another runtime.

A non-zero result from a file that does open needs the diagnostic output as well as the status. Save both streams, identify the failing assembly and method if reported, then compare the build artefact with a freshly produced copy. Do not suppress warnings in a release gate until you have documented why that mode is acceptable.

6. Keep the boundary clear

pedump is an inspection and verification utility. It does not run the program, load it into a service, change its metadata or apply a signature. It also does not establish that an assembly is trustworthy: a file can be structurally valid and still be malicious, inappropriate or built from the wrong source.

Use elevated privileges only if the input is readable exclusively by another account and your normal access-control process permits inspection. Do not make the assembly world-readable as a shortcut. If you copied a report or test file into /tmp, remove only that known temporary file after review:

$ rm -- /tmp/pedump-verify.txt /tmp/not-an-assembly.bin

This cleanup is optional and affects only the named temporary files. There is nothing to undo in the assembly itself because the pedump commands above did not modify it.