> For the complete documentation index, see [llms.txt](https://docs.hex-rays.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hex-rays.com/core/flirt/concepts/flirt-2.0.md). # FLIRT 2.0: Reference-Driven Naming FLIRT 2.0, shipping with IDA 9.5, introduces signature format version 11. Beyond recognizing a library function from its own bytes, a v11 signature also records the references that function makes, so IDA can name the code and data they point to as well. ## Why references matter Library code calls many small helpers that are hard to recognize by their bytes alone: they are only a few bytes long, or identical to dozens of other tiny functions. Before FLIRT 2.0, such helpers often stayed unnamed. The functions that call them are usually long enough to match. A v11 signature records, for every call and data reference in a library function, which symbol it refers to, taken from the relocations in the library's object files. After auto-analysis, IDA follows these references from every matched function and names their targets. For example, in a stripped sqlite3 shell statically linked with the MSVC 14.41 runtime (x64), IDA 9.4 recognizes `__scrt_initialize_default_local_stdio_options`, but not the two 8-byte functions it calls: ``` __scrt_initialize_default_local_stdio_options: sub rsp, 28h call sub_1400DB2F0 or qword ptr [rax], 24h call sub_1400DB300 or qword ptr [rax], 2 add rsp, 28h retn ``` IDA 9.5 names both from the references of the matched caller: ``` __scrt_initialize_default_local_stdio_options: sub rsp, 28h call __local_stdio_printf_options or qword ptr [rax], 24h call __local_stdio_scanf_options or qword ptr [rax], 2 add rsp, 28h retn ``` Data is named the same way: globals, tables and string literals that library code refers to get their library names. On the same stripped sqlite3 shell, built for each architecture, the number of correctly named library symbols: | MSVC 14.41 static runtime (/MT) | IDA 9.4 functions | IDA 9.5 functions | IDA 9.4 data | IDA 9.5 data | | ------------------------------- | ----------------: | ----------------: | -----------: | -----------: | | x64 | 596 | 732 | 0 | 1353 | | x86 | 855 | 1038 | 0 | 222 | | ARM64 | 0 | 790 | 0 | 405 | | ARM | 38 | 660 | 0 | 248 | IDA 9.4 has no ARM64 MSVC signatures and covers only VC11 on ARM, so those two rows mostly show the new signatures. ## Picking the right MSVC runtime IDA detects whether a Windows binary links the MSVC runtime statically (`/MT`) or dynamically (`/MD`), and applies signatures built for that linkage. Before, dynamically linked binaries were matched against the static runtime signatures. Twin functions that the narrow and wide runtimes compile to identical bytes (`main`/`wmain`, `WinMain`/`wWinMain`, the argv accessors, the environment helpers) are told apart from evidence in the binary itself. MSVC coverage is also wider: * **ARM64**: VC 14.11-14.52, the first ARM64 MSVC signatures * **ARM**: VC 14.0-14.44, in addition to the existing VC11 signatures * **x86 and x64**: VC 14.39-14.52 added The 9.4 versions of the x86 and x64 MSVC signatures ship unchanged alongside the new ones, named `.v1.sig` (for example `vc64_14.v1.sig`). IDA applies them right after the new signature, and they only name functions the new one left unrecognized. They appear as separate rows in the [Signatures window](/core/user-interface/concepts/subviews.md#signatures-window), each with its own count of recognized functions. ## Other new signatures * **glibc**: statically linked glibc on x86, x64, ARM, ARM64, MIPS64 (little-endian), RISC-V 64 and s390x * **ARC millicode helpers**: the out-of-line prolog/epilog save/restore routines the MetaWare compiler emits, applied automatically to every new ARC database * **Go runtime**: functions get their original Go names, such as `runtime.(*mheap).alloc`, covering Go binaries through go1.26. Databases that [restrict name characters](/core/user-interface/concepts/configuration-files/legacy-name-character-restrictions.md) automatically get the previous signatures instead, which already carry the restricted names. These ship as `*_legacy.sig`. ## The v11 signature format A v11 signature adds several things a v10 signature could not express: | Addition | What it's for | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bit-level relocation discriminators | Keeps opcode and register bits that a fully-wildcarded byte used to discard. Matters most on RISC targets, where a single instruction word mixes opcode bits with an addressable offset (AArch64 `ADRP`/`BL`, ARM32, MIPS, RISC-V). | | Reference tables | Every reference a matched module makes is stored, and followed once the pattern matches -- this is what makes reference-driven naming possible. | | Alternative fixup tables | Byte-identical builds sometimes call the same functions in a different order; IDA scores each stored table against the binary and keeps the best match. | | zstd compression | Replaces the older zlib-based compression. | Format v11 **can't be read by older IDA versions**: IDA 9.5 reads v10 and older signatures without issue, but a v11 file cannot be read by an IDA version older than 9.5. The FLAIR tool `zipsig` always writes the current version, so running it against an old `.sig` file upgrades it in place; `sigmake` writes v11 by default from 9.5 onward. An upgraded file still holds only what the old signature recorded: to get reference-driven naming, run the FLAIR parser on the library again and rebuild the signature with `sigmake`. {% hint style="warning" %} If you build or upgrade a signature with the FLAIR tools of IDA 9.5 or later, it will not load in IDA 9.4 or earlier. Keep the original `.sig` file if you also need it in older versions. {% endhint %} ## For signature authors * **`makesig`** can build a pattern from a selected byte range instead of a whole function, for patterns that don't cover a whole function, such as millicode helpers or entry-point tables. * Signatures can be installed as a directory carrying an `ida-sig.json` manifest, the same way plugins are, instead of being copied into `sig/` by hand. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.hex-rays.com/core/flirt/concepts/flirt-2.0.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.