Nauz File Detector names the toolchain behind a binary in one pass

Identification as a first triage step

Nauz File Detector is described as a portable linker, compiler, packer identifier utility, and the program works on macOS, Linux and Windows.

The problem it addresses is the first five minutes of meeting an unknown binary. A file arrives, and before you can decide whether to run it in a sandbox, unpack it or read it statically, you want to know what produced it. Was it built with Visual Studio, and which version? Is it packed, and by which protector? Is it a.NET assembly, a Go binary, a PyInstaller bundle, something signed with a certificate you recognise?

Those answers change your workflow. A packed file needs unpacking before anything else is useful, and knowing the packer tells you which unpacker to reach for. A file with a known protector signature may be a commercial protector used for licensing, which is a completely different investigation from a malware loader. A compiler fingerprint narrows the search for artefacts and known tooling output.

The repository topics make the intent clear: malware-analysis, malware-detection, malware-research, reverse-engineering, signature and detect. So the tool is aimed at people who look at binaries for a living, whether they are triage analysts, reverse engineers or malware researchers.

The primary language is C++, the licence is MIT, the default branch is master, and the last push was on 2026-10-22.

Portability is the design constraint

The word portable in the description is doing more work than it looks. A triage tool has to run on whatever machine is in front of you, and that machine is rarely the one you would choose. A Windows analyst has a Windows workstation, a Linux malware lab has Linux servers, and a macOS engineer has a Mac. If the detector only ran on one of those, it would be useless in two of the three cases.

That constraint explains the rest of the repository. The build is driven by CMake through a CMakeLists.txt at the root, and the source lives in src/ with a dep/ directory for dependencies, which are pulled in as Git submodules given the .gitmodules file at the root. res/ holds resources, translations/ holds the localisation files, and packaging/ holds the platform packaging.

The download itself is a release asset rather than a package manager entry, and the README lists it plainly:

* Download: https://github.com/horsicq/Nauz-File-Detector/releases

The documentation is organised the same way, with the three documents a user actually needs each in its own file in doc/: RUN.md for how to run it, BUILD.md for how to build it, and a changelog.txt at the repository root alongside the release notes. A separate release_version.txt at the root holds the version string, which is a common pattern for a project that has to stamp the version into several places, the Windows resource and the about box for instance.

The localisation is handled through the XTranslation project, which the README points at for people who want to help with translation. That is a sensible arrangement for a tool whose users are distributed across three operating systems and many locales, and it keeps the translation strings out of the main repository.

There is a THANKS.md file and a special thanks entry for PELock Software Protection and Reverse Engineering, which is a hint about where the packer and protector knowledge in the signature set comes from.

A beta release channel alongside numbered releases

The release tags in the repository record show a specific pattern, and it matters for how you pick a build.

There is a tag named Beta, published on 2024-07-27, and the README puts a link to it at the top under the name Beta Release, above the project description. Alongside it are numbered releases: 0.09 from 2022-10-26 and 0.08 from 2022-05-03.

So the project has two channels, a moving beta tag and a slow numbered series, and the numbered series has not moved since October 2022. For a tool whose value depends on recognising current protectors and compilers, a signature set that has not seen a numbered release since 2022 is a real limitation, and it is the reason to look at the beta channel rather than the last numbered release.

That is also why the changelog lives in the repository as a plain text file rather than only in the release notes. For a tool where the interesting change is the addition of a new signature, a text changelog you can read without a browser is a practical choice, and it makes it obvious when the last meaningful update was.

Note also what the tags say about the project's maturity. A 0.09 release is an early version, and a project with a beta channel and a multi-year gap between numbered releases is best understood as a working tool maintained by one person, in the same way the signature sets of most such tools are.

For a user, the practical consequence is that you should record which build you used alongside your analysis, because a detection result is only meaningful relative to the signature set that produced it.

Identification is not analysis, and the limits follow from that

The most common misunderstanding about tools in this category is what their output means. A packer detection is not a malware detection. Knowing that a file was processed by a commercial protector tells you nothing about whether the file is malicious, and a file with no known packer signature is not thereby clean, because most malware is not packed at all.

The second limit is coverage. A signature database only knows the tools whose signatures it contains, and it will always lag behind the tools being used, particularly for the less common or more recent ones. An unknown result is the most common outcome for an unusual binary, and the tool cannot distinguish between a genuinely novel packer and a known one with a slightly modified header.

The third is that identification is shallow by design. It reads headers, sections and signatures. It does not disassemble, it does not trace behaviour, and it does not tell you what the program does once it is running. If your question is what the binary does, you need a different tool and a different amount of time.

The fourth is that the detection is only as good as the sample set. A detector built by a reverse engineer is strongest on the protection schemes that reverse engineer sees, which is a useful heuristic for choosing where to point your attention, and a poor one for certifying the absence of a protector.

The reasonable way to use a tool like this is as a triage filter. You run it over a directory of samples, it sorts them into groups by what produced them, and each group gets an appropriate next step. Unpack the packed ones, statically read the compiler-identified ones with a matching toolchain in mind, and send the unknown ones to a sandbox. The output is a work queue, not a verdict.

Where a detector sits against a full reversing setup

The realistic alternative to a dedicated detector is not another detector, it is doing the identification yourself with a general purpose reversing tool, or not doing it at all.

Doing it yourself means opening the file in a disassembler or a hex editor and reading the section table, the import table and the overlay by hand. That is the approach that gives you full control and complete knowledge, because you are looking at the actual structures rather than a classification of them. It is also slow, and it does not scale to the case where a triage queue contains hundreds of files.

The detector approach inverts the trade. You give up the reasoning and get the answer immediately, at the cost of trusting a signature database. For a single file that you are going to spend an hour on anyway, the manual route may be better, because you are going to open it in a reversing tool regardless. For a queue of files where you only want to know which ones deserve that hour, the detector is clearly the right tool.

The middle path is a general purpose platform that includes identification alongside analysis, where the same tool reports the packer and then lets you look at the code. That saves the round trip of finding the information and then finding a tool that can act on it, at the price of a much heavier install for a triage step.

The other axis is coverage. A dedicated detector with a maintained signature set will recognise more packers than you will find by eye, because the recognition rules are already written. A general purpose reversing platform will recognise the popular ones because their maintainers care about them. Neither dominates, and the practical answer is to use the detector first and the reversing tool second, with the detector telling you which reversing tool to open.

Editorial conclusion

Adopt Nauz File Detector if you triage unknown executables and need to know what produced them, a protector signature, a compiler fingerprint or a packer stub, before you commit time to deeper analysis. Do not adopt it as a malware verdict, since identifying the toolchain says nothing about whether a file is malicious, and do not expect it to replace a disassembler, because it identifies rather than analyses. Before you rely on it, read the RUN.md and BUILD.md documents in the doc directory, check whether the beta release is the one you want, and confirm that its signature set covers the packers and compilers you actually encounter.

Frequently asked questions

Official sources

1. horsicq/Nauz-File-Detector on GitHub
2. Issues
3. License: MIT
4. README
5. Releases