Ground rules

Work on software you are allowed to analyze, keep samples in an isolated directory or VM, hash the original files before touching them, and prefer static inspection before running unknown executables.

Quick workflow

  1. Identify the binary

    Check whether the executable is a managed .NET assembly. On Linux, file, strings, and PE metadata are usually enough. Useful hints include mscoree.dll, _CorExeMain, .NET Framework, or obvious namespace/class names in strings.

  2. Record hashes and metadata

    Save SHA-256, file size, timestamp, product metadata, target framework, platform target, and any embedded PDB path. These details make later notes reproducible.

  3. Open it in ILSpy

    Use ILSpy or ilspycmd to inspect the assembly. For a command-line export, install the tool in your analysis environment and write the recovered project to a separate folder. 

    dotnet tool install --global ilspycmd
ilspycmd -p -o decompiled VendorTool.exe

  4. Start from the entry point

    In WinForms tools, read Program.cs first, then the main form. Event handlers such as button clicks, timers, and serial DataReceived callbacks usually reveal the real state machine faster than reading every class top to bottom.

  5. Follow resources and constants

    Check .resx files, embedded strings, byte arrays, and large literals. Firmware updaters often hide Intel HEX, raw firmware blocks, command frames, checksums, and UI instructions directly in the decompiled C#.

  6. Separate facts from decompiler noise

    Decompiled projects are analysis artifacts, not clean source releases. Expect odd names, dead helper classes, broken designer code, and control flow that needs manual cleanup before it can be rebuilt.

What to extract from updater tools

Protocol shape

Port settings, handshake bytes, ACK/error handling, block size, checksum calculation, timeouts, and retry behavior.

Firmware payload

Embedded HEX or binary data, padding rules, transfer length, hashes, load address, vector table, and version strings.

Safety signals

Whether the host verifies signatures, validates checksums, checks device identity, or blindly trusts the bootloader.

Operational notes

Vendor warnings, required companion tools, resource loaders, CPS compatibility, and assumptions baked into the UI.

UV-4R example

In the UV-4R update bundle, the .NET decompile was enough to recover the high-level flashing flow, find the embedded Intel HEX firmware string, identify the serial state machine, and explain why the updater behaves like a fixed-image flasher rather than a general update manager.

After extraction, the firmware itself becomes a separate embedded-analysis task: reconstruct the binary image, load it at the correct Cortex-M base address, seed the vector table, and then move into disassembly or Ghidra.