rea-reverse

.NET assembly metadata and IL viewer

Open a .NET DLL or EXE to see its identity, target framework, references, every namespace, type and member, P/Invoke imports and resources. Click a method to disassemble its IL. Nothing is executed.

Your assembly never leaves your browser. Metadata and IL are read locally in a Web Worker that has no network access. Nothing is uploaded. How to verify this yourself

Drop a .dll or .exe here

or

Managed .NET assemblies (.NET Framework, .NET Core / 5+, .NET Standard, Mono). Up to 256 MiB.

A .NET assembly is a PE file, the same container format as any Windows .exe or .dll, but it carries much more structure than a native binary. Inside is a metadata database that names every type, method and field, records which other assemblies and native libraries the code depends on, and stores each method body as CIL (Common Intermediate Language) instructions that still refer to those names. That is why so much of a managed assembly can be understood without running it and without a decompiler.

This tool reads that structure inside your browser. Choose a .dll or .exe and you get the assembly’s identity, its references, a browsable type tree, its P/Invoke declarations and its resources. Click a method and the page disassembles its IL. The file is never uploaded.

What it does

Input. A .NET assembly (.dll or .exe) up to 256 MiB, for .NET Framework, .NET Core, .NET 5 and later, or .NET Standard. Each request (the report, or one method’s IL) has a 60-second time limit.

Report. The page shows:

  • Assembly identity: name, version, culture and public key token, computed from the public key the way the runtime does it. The target framework comes from the assembly-level TargetFrameworkAttribute, for example .NETCoreApp,Version=v8.0. The module name and MVID are listed too.
  • References: every referenced assembly with its version, culture and public key token, plus the native modules named by ModuleRef rows.
  • Type tree: namespaces, then types, with nested types under their enclosing type. Each type shows its kind (class, interface, struct, enum, delegate or static class), visibility, abstract and sealed, and its base type. Each field shows its type, visibility and whether it is static, const or readonly. Each method shows a C#-style signature such as int Parse(string text, ref int position), its visibility, whether it is static, virtual, abstract or P/Invoke, its metadata token and its RVA.
  • P/Invoke: every DllImport declaration with the managed method, the native DLL, the entry point name, the character set, the calling convention and SetLastError. This is the boundary between managed and native code, and often the most interesting list in the report.
  • Resources: manifest resources with their visibility. Embedded resources show their size and file offset, and the page marks those that start with the .resources signature 0xBEEFCACE. Linked resources show the file or assembly that holds them.
  • PE and CLI headers: machine (x86, x64, ARM64 and others, including the OS-specific values used by ReadyToRun images for Linux or macOS), PE32 or PE32+, DLL or executable, the section table, the CLI runtime version, the CLI flags (ILONLY, 32BITREQUIRED, STRONGNAMESIGNED and so on) and the entry point token.
  • Metadata layout: the metadata version string (such as v4.0.30319), the streams and the row count of each metadata table.
  • Image markers: a ReadyToRun marker when the image contains precompiled native code next to its IL, and a mixed-mode marker when the ILONLY flag is clear, as in C++/CLI assemblies that contain native code.
  • Warnings: a row or signature that cannot be decoded becomes a warning (up to 200) instead of stopping the whole analysis.

IL on demand. Clicking a method disassembles its body. You get the header format (tiny or fat), maxStack, whether locals are zero-initialized, the code size, the types of the local variables, and the instruction listing with IL_xxxx offsets. Operands are resolved: calls and field accesses show the member name, ldstr shows the string literal, branches and switch show their target labels. The exception-handling clauses (catch with the caught type, filter, finally, fault) are listed with their try and handler ranges. Methods without IL say why: abstract, P/Invoke, runtime-implemented or native.

How it works

The parser follows the ECMA-335 standard that defines .NET metadata. It reads the PE headers, finds the CLI header in data directory 14, maps RVAs to file offsets through the section table, and opens the metadata root (the BSJB signature). From there it reads the table stream (#~ or the uncompressed #-) and the heaps: #Strings for names, #US for string literals, #GUID and #Blob for signatures and attribute values. Type names and signatures are rendered as C#-like text, with generic parameters under their declared names.

The PE reader, metadata layout, signature grammar, opcode table and method body parsing are ported from REA 6.4.0, the open-source project by morluto (MIT). The port is tested against REA 6.4.0’s own output on the same sample assemblies.

For IL, the page reads the method header at the method’s RVA, decodes the instructions one by one with the full CIL opcode table, resolves each metadata token to a readable name, and parses the exception sections that follow fat method bodies. IL is decoded only for the method you click, so a large assembly does not have to be disassembled up front.

When there is no CLI header, the page checks for NativeAOT markers (a .managed or hydrated section, or the string DotNetRuntimeDebugHeader anywhere in the file) and tells you whether the file is a NativeAOT binary or simply a native PE.

How your file stays private

The assembly is not uploaded:

  • The analysis and each IL request run in a Web Worker on your device. The worker reads the file through the browser’s file APIs and sends back only the report or the listing.
  • Analytics events are coarse: success or an error code, a coarse range for the number of types found (such as 11-100), a file-size bucket and a duration bucket. They never contain the file name, type or method names, or any other content. The full list is on the privacy page.
  • The tool page shows no ads.

How to verify this yourself

  1. Open your browser’s developer tools and switch to the Network tab before you choose a file. Analyze an assembly and open some methods. The only requests are page assets and the worker script /_astro/dotnet-worker-*.js; none carries your file.
  2. Or load the page, go offline (turn off Wi-Fi, or tick Offline in the Network tab) and analyze a file. It still works.
  3. The worker runs under the Content Security Policy default-src 'none'; script-src 'self'; connect-src 'none', so the browser does not let it make any network request.

Limitations

  • No decompilation to C#. The tool shows metadata and IL. It does not reconstruct C# or any other source code. Signatures look like C# only to make them easy to read.
  • NativeAOT and native PE files have no IL. A NativeAOT build compiles everything to machine code and keeps no ECMA-335 metadata, so there is nothing for this tool to show. Use a native disassembler or decompiler such as Ghidra.
  • ReadyToRun code is not shown. For ReadyToRun images the page shows the IL and the metadata, not the precompiled native code beside them. Mixed-mode assemblies likewise show only their managed part.
  • Single-file bundles must be extracted first. A published single-file app starts with a native host, which has no CLI header. Analyze the assemblies inside the bundle instead.
  • Obfuscated names stay obfuscated. Names are shown exactly as stored, cut at 1,024 characters.
  • No signature verification. STRONGNAMESIGNED is a header flag. The page does not verify strong-name or Authenticode signatures.
  • Per-method limits. IL is decoded up to 1 MiB and 200,000 instructions per method. Decoding stops at the first unknown opcode or truncated operand and says so.
  • Static only. Nothing is executed, so reflection, dynamic loading and code generated at run time are invisible.

FAQ

Is this an online ILDasm?

It covers similar ground: metadata tables, type and member lists, and IL listings with resolved tokens. The output format is the page’s own and is not a round-trippable .il file.

The page says “NativeAOT”. What now?

The file contains only machine code. Open it in a native analysis tool. Our REA and Ghidra guide walks through that.

Why does a method show “no IL”?

It is abstract, a P/Invoke declaration, implemented by the runtime (as delegate Invoke methods are), or native code in a mixed-mode assembly.

Can I see string literals?

Yes, inside the IL listing: ldstr instructions show the literal, escaped and cut at 4,096 characters.

Why is the public key token empty?

The assembly or reference is not strong-named.

Compliance

Analyze assemblies you built, assemblies you are authorized to examine, or open-source assemblies. Respect the licenses of the software you inspect, including any terms that restrict reverse engineering, and the laws that apply to you. The tool gives no advice on bypassing licensing or other protections. See the disclaimer.