sigmaker 1.9.2

Sigmaker is an IDA Pro 9.0+ cross-platform signature maker plugin that works on MacOS/Linux/Windows. It creates unique binary pattern signatures to identify specific functions or addresses within binaries, even after updates. It helps reverse engineers preserve their analysis work by generating resilient signatures that can quickly relocate important code locations in new binary versions.

Signature Maker Plugin for IDA Pro 9.0+

An IDA Pro 9.0+ zero-dependency cross-platform signature maker plugin with optional SIMD (e.g. AVX2/NEON/SSE2) speedups that works on MacOS/Linux/Windows. The primary goal of this plugin is to work with future versions of IDA without needing to compile against the IDA SDK as well as to allow for easier community contributions.

Background reading on mahmoudimus.com:

• IDA Pro and Cython: super-charging the work-horse of reverse engineering: how the optional SIMD speedups were built.
• Growing a unique function signature without rescanning the binary: the search algorithm, with interactive visualizations.
• How do you know your Cython hot loop is fast enough?: how I confirmed those kernels are already optimal (memory-bound, not compute-bound).

Table of contents

• Installation
  • Quick Install
  • From Releases
  • Install with hcli
  • Need to find your plugin directory?
  • Where and what is my default user directory?
• SIMD Speedups
• Requirements
• What is a "sigmaker"?
• Usage
  • Finding XREFs
  • Signature searching
  • Signature Configuration
• Performance
  • Benchmarks
  • How it works
• Using SigMaker as a library
  • Stability contract
  • Used by
• Acknowledgements
• Development & Releases
  • Contributing
• Contact

Installation

sigmaker's main value proposition is its cross-platform (Windows, macOS, Linux) Python 3 support. It uses zero third party dependencies, making the code both portable and easy to install.

Quick Install

• Copy src/sigmaker/__init__.py into the /plugins/ folder to the plugin directory!
• Rename it to sigmaker.py
• OPTIONALLY, if you would like SIMD speedups, just pip install sigmaker
• Restart IDA Pro.

From Releases

• Download the latest conveniently renamed sigmaker.py release from the Releases page
• Copy it to your IDA Pro plugins directory
• OPTIONALLY, if you would like SIMD speedups, just pip install sigmaker
• Restart IDA Pro

That's it!

Install with hcli

hcli is Hex-Rays' command-line tool, and it can install sigmaker from the IDA Plugin Repository. Install hcli once:

curl -LsSf https://hcli.docs.hex-rays.com/install | sh        # macOS/Linux
iwr -useb https://hcli.docs.hex-rays.com/install.ps1 | iex    # Windows (PowerShell)

Then authenticate (see the hcli docs) and install the plugin:

hcli plugin search sigmaker
hcli plugin install SigMaker

hcli downloads the plugin and places it in $IDAUSR/plugins (~/.idapro/plugins on macOS/Linux), where IDA loads it on the next launch. Requires IDA 9.0+. For SIMD speedups, also run pip install sigmaker as above.

Need to find your plugin directory?

From IDA's Python console run the following command to find its plugin directory:

import idaapi, os; print(os.path.join(idaapi.get_user_idadir(), "plugins"))

Where and what is my default user directory?

The user directory is a location where IDA stores some of the global settings and which can be used for some additional customization. Default location:

• On Windows: %APPDATA%/Hex-Rays/IDA Pro
• On Linux and Mac: $HOME/.idapro

SIMD Speedups

If you just followed the installation above and ran pip install sigmaker, then based on your system and architecture (i.e. Windows (x64), Linux (x64), Mac (x64), Mac (ARM/Silicon)), the plugin will install the appropriate wheel and will automatically use them if they're available. You do not have to do anything else. The plugin is designed to display the status of whether or not SIMD speedups are installed. They are shown in the top right menu bar of the plugin:

SIMD Enabled

No SIMD Speedups

Requirements

• IDA Pro 9.0+
• IDA Python
• Python 3.10+

What is a "sigmaker"?

Sigmaker stands for "signature maker." It enables users to create unique binary pattern signatures that can identify specific addresses or routines within a binary, even after the binary has been updated.

In malware analysis or binary reverse engineering, a common challenge is pinpointing an important address, such as a function or global variable. However, when the binary is updated, all the effort spent identifying these locations can be lost if their addresses change.

To preserve this work, reverse engineers take advantage of the fact that most programs do not change drastically between updates. While some functions or data may be modified, much of the binary remains the same. Most often, previously identified addresses are simply relocated. This is where sigmaker comes in.

Sigmaker lets you create unique patterns to track important parts of a program, making your analysis more resilient to updates. By generating signatures for specific functions, data references, or other critical locations, you can quickly relocate these points in a new version of the binary, saving time and effort in future reverse engineering tasks.

Usage

In disassembly view, select a line you want to generate a signature for, and press CTRL+ALT+S:

OR Right-Click and select SigMaker:

The generated signature will be printed to the output console, as well as copied to the clipboard:

---

Signature type	Example preview
IDA Signature	E8 ? ? ? ? 45 33 F6 66 44 89 34 33
x64Dbg Signature	E8 ?? ?? ?? ?? 45 33 F6 66 44 89 34 33
C Byte Array Signature + String mask	\xE8\x00\x00\x00\x00\x45\x33\xF6\x66\x44\x89\x34\x33 x????xxxxxxxx
C Raw Bytes Signature + Bitmask	0xE8, 0x00, 0x00, 0x00, 0x00, 0x45, 0x33, 0xF6, 0x66, 0x44, 0x89, 0x34, 0x33 0b1111111100001

---

Finding XREFs

Generating code Signatures by data or code xrefs and finding the shortest ones is also supported:

---

Signature searching

Searching for Signatures works for supported formats:

It also supports wildcard nibble search support:

Just enter any string containing your Signature, it will automatically try to figure out what kind of Signature format is being used:

Currently, all output formats you can generate are supported.

Match(es) of your signature will be printed to console alongside the containing function name:

If the matched address is not a function name or has no function name, it falls back to just printing the address:

Signature Configuration

sigmaker also supports configurable wildcardable operands for unique signature creation:

There are also various options that be configured via the Other options button:

Performance

SigMaker's "find the shortest unique signature for the current function" search has been heavily optimized. On a real 16 MB module, a single worst-case function search once took 462 seconds (7.7 minutes). A stack of four optimizations brought the heaviest searches down to the tens-of-seconds range and typical ones to near-instant. One user reported the progress wait-box now "barely show[s] up for a 26 byte signature."

The full derivation, including the match-set math, the counting-sort index, the selectivity proof, and what is novel about the approach, is written up in ALGORITHM.md.

Benchmarks

Measured on the largest function (8486 bytes) of a 16 MB module via native idalib on Apple Silicon. The effects are cumulative across the four phases:

Optimization	Effect	PR
Phase 1: seed-then-refine candidate refinement	~13x faster function search	#33
Phase 2: 2-byte bucket position index	additional ~2.48x on large databases, widening as the database grows	#35
Phase 3: dynamic seed selection (1- or 2-byte)	per-anchor seed scans cut from 206 to 2	#36
Phase 4: Cython in-place refinement	per-byte refinement ~14 s to ~0.28 s (~50x); function total ~24 s to ~15.6 s	#36

Signature output is byte-identical before and after every optimization. The test suite cross-checks each fast path against a brute-force oracle and diffs the generated signatures across the entire test binary.

How it works

A short tour (see ALGORITHM.md for the math):

• Seed, then refine. The set of database matches can only shrink as a signature grows, so instead of rescanning the whole database for every candidate length, SigMaker scans once to seed a candidate set and then filters that set in place as each byte is appended.
• Index the database once. A counting-sort index over every adjacent byte pair lets the seed be drawn from the rarest exact run in the pattern, in time proportional to that run's frequency rather than to the database size. The same index serves both 1-byte and 2-byte runs for free, so the most selective anchor is always chosen.
• Push the hot loops into C. With the optional pip install sigmaker SIMD wheel, the index build and the per-byte refinement run as nogil C over typed buffers with zero per-call allocation, and the raw byte scan uses AVX2/NEON/SSE2. Without the wheel, pure-Python fallbacks produce identical results.

Using SigMaker as a library

Beyond the IDA plugin, sigmaker is imported directly as a Python library by other tools (for example, batch signature-generation pipelines). The core types are usable from any IDAPython or idalib context:

import sigmaker

cfg = sigmaker.SigMakerConfig(
    output_format=sigmaker.SignatureType.IDA,
    wildcard_operands=True,
    continue_outside_of_function=False,
    wildcard_optimized=True,
    ask_longer_signature=False,
)
result = sigmaker.SignatureMaker().make_signature(ea, cfg)
print(f"{result.signature:ida}")   # IDA-style string
print(len(result.signature))       # byte length

# Cross-references:
xrefs = sigmaker.XrefFinder().find_xrefs(ea, cfg)
for gen in xrefs.signatures:
    print(str(gen.address), f"{gen.signature:ida}")

Stability contract

If you embed sigmaker, you can rely on the following. These are treated as a contract and are checked before any change to the public surface:

1. Append-only config. SigMakerConfig fields are never reordered or removed. New behavior arrives as new fields with safe defaults, so existing constructions keep working.
2. Stable public names. These names and their documented attributes are not renamed or removed: SignatureMaker, SigMakerConfig, SignatureType (IDA, x64Dbg, Mask, BitMask), XrefFinder, GeneratedSignature (signature, address, status, match_count), XrefGeneratedSignature (signatures), Match (__str__ returns the hex address), Signature (__len__, __format__), GenerationPolicy, GenerationStatus.
3. Stable method signatures. SignatureMaker.make_signature(ea, cfg, end=None, *, progress_reporter=None, policy=GenerationPolicy.strict()), XrefFinder.find_xrefs(ea, cfg), XrefFinder.count_code_xrefs_to(ea), and XrefFinder.iter_code_xrefs_to(ea).
4. Stable format specs. f"{sig:ida}", f"{sig:x64dbg}", f"{sig:mask}", and f"{sig:bitmask}" keep producing their current output exactly.
5. Byte-identical defaults. Production defaults are unchanged across optimizations: a script that does not opt into a new flag gets byte-identical signatures to previous versions.

Used by

Projects that build on or embed the sigmaker library:

• mrexodia/ida-pro-mcp, an AI reverse-engineering MCP server (8.9k+ stars), vendors a stripped, engine-only copy of sigmaker and exposes signature tools through SigMakerConfig, SignatureType, SignatureMaker().make_signature, and XrefFinder().find_xrefs.
• koyzdev/sigdrift is a batch signature-generation script that imports the library and calls SignatureMaker().make_signature(ea, SigMakerConfig(...)) and XrefFinder(), formatting results via f"{sig:ida}" and f"{sig:mask}".

Building something on top of sigmaker? Open a PR or an issue and I will add it here.

Acknowledgements

Thank you to @A200K's IDA-Pro-SigMaker plugin, which served as inspiration and the basis for the initial port of this plugin. I would also like to acknowledge @kweatherman's sigmakerex as independent prior work within the SigMaker ecosystem. While the initial port did not draw from sigmakerex, members of the community later requested compatibility and feature parity with parts of its functionality (for example, see issue #17). As documented in sigmakerex's README credits, there is a long history of SigMaker authors and contributors, and I would like to thank and acknowledge them as well:

thanks to the previous creators of the original SigMaker tool back from the gamedeception.net days up to the current C/C++ and Python iteration authors: P4TR!CK, bobbysing, xero|hawk, ajkhoury, and zoomgod et al.

Thanks to Wojciech Mula for his SIMD programming resources.

Development & Releases

Contributing

1. Fork the repository
2. Create a feature branch
3. Make your changes
4. Test thoroughly
5. Submit a pull request

The version lives in one place, __version__ in src/sigmaker/__init__.py. To keep ida-plugin.json in step with it automatically, enable the repo's git hook once per clone:

git config core.hooksPath .githooks

The pre-commit hook (.githooks/pre-commit) runs tools/sync_plugin_version.py, which copies __version__ into ida-plugin.json and stages it, so the manifest the IDA Plugin Repository reads can never drift behind a version bump. CI runs the same check (TestPluginManifestVersion) as a backstop for commits that skip the hook.

Contact

ping me on x @mahmoudimus or you may contact me from any one of the addresses on mahmoudimus.com.

MIT License

Copyright (c) 2024 Mahmoud Abdelkader (@mahmoudimus)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.