Effortless security feature detection with Winchecksec

We’re proud to announce the release of Winchecksec , a new open-source tool that detects security features in Windows binaries. Developed to satisfy our analysis and research needs, Winchecksec aims to surpass current open-source security feature detection tools in depth, accuracy, and performance without sacrificing simplicity.

Feature detection, made simple

Winchecksec takes a Windows PE binary as input, and outputs a report of the security features baked into it at build time. Common features include:

• Address-space layout randomization (ASLR) and 64-bit-aware high-entropy ASLR (HEASLR)
• Authenticity/integrity protections (Authenticode, Forced Integrity)
• Data Execution Prevention (DEP), better known as W^X or No eXecute (NX)
• Manifest isolation
• Structured Exception Handling (SEH) and SafeSEH
• Control Flow Guard (CFG) and Return Flow Guard (RFG)
• Guard Stack (GS), better known as stack cookies or canaries

Winchecksec’s two output modes are controlled by one flag ( -j ): the default plain-text tabular mode for humans, and a JSON mode for machine consumption. In action:

Did you notice that Winchecksec distinguishes between “Dynamic Base” and ASLR above? This is because setting /DYNAMICBASE at build-time does not guarantee address-space randomization. Windows cannot perform ASLR without a relocation table , so binaries that explicitly request ASLR but lack relocation entries (indicated by IMAGE_FILE_RELOCS_STRIPPED in the image header’s flags) are silently loaded without randomized address spaces. This edge case was directly responsible for turning an otherwise moderate use-after-free in VLC 2.2.8 into a gaping hole ( CVE-2017-17670 ). The underlying toolchain error in mingw-w64 remains unfixed .

Similarly, applications that run under the CLR are guaranteed to use ASLR and DEP, regardless of the state of the Dynamic Base/NX compatibility flags or the presence of a relocation table. As such, Winchecksec will report ASLR and DEP as enabled on any binary that indicates that it runs under the CLR. The CLR also provides safe exception handling but not via SafeSEH, so SafeSEH is not indicated unless enabled.

How do other tools compare?

Not well:

• Microsoft released BinScope in 2014, only to let it wither on the vine. BinScope performs several security feature checks and provides XML and HTML outputs, but relies on .pdb files for its analysis on binaries. As such, it’s impractical for any use case outside of the Microsoft Secure Development Lifecycle . BinSkim appears to be the spiritual successor to BinScope and is actively maintained, but uses an obtuse overengineered format for machine consumption. Like BinScope, it also appears to depend on the availability of debugging information.
• The Visual Studio toolchain provides dumpbin.exe , which can be used to dump some of the security attributes present in the given binary. But dumpbin.exe doesn’t provide a machine-consumable output, so developers are forced to write ad-hoc parsers . To make matters worse, dumpbin.exe provides a dump, not an analysis, of the given file. It won’t, for example, explain that a program with stripped relocation entries and Dynamic Base enabled isn’t ASLR-compatible. It’s up to the user to put two and two together.
• NetSPI maintains PESecurity , a PowerShell script for testing many common PE security features. While it provides a CSV output option for programmatic consumption, it lags in performance compared to dumpbin.exe (and other compiled tools listed below), much less Winchecksec.
• There are a few small feature detectors floating around the world of plugins and gists, like this one , this one , and this one (for x64dbg!). These are generally incomplete (in terms of checks), difficult to interact with programmatically, sporadically maintained, and/or perform ad-hoc PE parsing. Winchecksec aims for completeness in the domain of static checks, is maintained, and uses official Windows APIs for PE parsing.

Try it!

Winchecksec was developed as part ofSienna Locomotive, our integrated fuzzing and triaging system. As one of several triaging components, Winchecksec informs our exploitability scoring system (reducing the exploitability of a buffer overflow, for example, if both DEP and ASLR are enabled) and allows us to give users immediate advice on improving the baseline security of their applications. We expect that others will develop additional use cases, such as:

• CI/CD integration to make a base set of security features mandatory for all builds.
• Auditing entire production servers for deployed applications that lack key security features.
• Evaluating the efficacy of security features in applications (e.g., whether stack cookies are effective in a C++ application with a large number of buffers in objects that contain vtables).

Get Winchecksec on GitHub now. If you’re interested in helping us develop it, try out this crop of first issues .