How to Perform a Static Analysis of Your Project Executables!

If you develop any software, you know that static code analysis has been trending for many years. Today, there are hints and warnings from compilers and IDEs, linters, and finally, feature-rich specialized solutions like ESLint, SonarQube, or Checkmarx. They help you write correct code, prevent bugs from slipping through, and harden program security. Is this enough to ensure the software is modern, reliable, and impossible to hack? Not quite.

\ Besides writing good code, a software engineer should remember many other things. Does the program have the correct icon? Is the version information filled in? Is there a valid digital signature? Does the program enable all available security mitigations? Does it correctly declare compatibility with the recent operating system versions? There are many bits to keep in mind, and static code analysis does not help with any of them. Fortunately, there is a solution: static analysis of the final compiled executable files.

\ The core of any desktop or mobile program is usually an executable file or an application package. First, there is the program code, which gets compiled into some computer-readable and executable representation, such as native assembly (which runs directly on a processor core) or an intermediate language (which is run in a virtual machine or further processed with a JIT compiler).

\ Static analysis tools cover the program code. However, the pure code can't execute without some extra information generated by the compiler and the linker.

\ Program resources, manifests, system directories, and digital signatures may be embedded into the executable file or package or supplied separately. Additional helpful data may be present, such as version information with the program description.

\ Let's look at the typical anatomy of a Windows executable file (which always has the Portable Executable format, 32 or 64-bit). It can be a program (exe), a library (dll), or a kernel driver (sys). Note that the picture below represents a native executable, and .NET ones are even more complex:

The green box's contents are processed by static code analysis. Boxes with no analysis performed (apart from rare linker warnings if you are lucky) are marked red. So, what kinds of issues can those red areas have? There are many worthy examples, such as:

• Incorrect digital signatures.

\

• Unsafe or deprecated imported DLL files and functions.

\

• Missing security hardening flags, such as ASLR, DEP, CF guard, CET Shadow Stack, and other protection mechanisms. These become especially important if your program interacts with the network or processes user-provided files, meaning the hackers might target your software. If your online game has a use-after-free bug in the network packet processing logic, or if your image editor has a buffer overflow issue when processing JPEG images, it would be much harder to actually exploit these vulnerabilities with all security mitigations enabled and configured correctly. In the worst case, the program will crash, but will not allow a hacker to silently gain access to your system.

\

• Version information issues, for example, inconsistent information across multiple executable files of the same product.

\

• Missing or wrongly configured compatibility flags. The operating system may apply OS-specific mitigations to the executables that do not declare compatibility with the current OS version. As a result, the program may run incorrectly or less efficiently than it could.

\

• Other security issues, such as writable sections that contain read-only data only or executable sections marked writable.

\ As you can see, you may miss a wide range of issues, and they will end up in the final production version of your application. Compilers usually set the best possible default generic options, but in many cases, they are not the most beneficial for your program. The same applies to executable files for other operating systems.

\ The solution is obvious: perform analysis of your production executables just as you do with the source code. Ideally, you should have such analysis built into your release pipeline. A more intricate question is the tools that would allow such analysis. Some of the available free and open-source tools are:

• BinSkim (GitHub): a console tool from Microsoft that supports Windows and *nix executable formats, mainly targeting security issues. The tool can create reports in the SARIF format.

\

• Binary Valentine (GitHub, website, documentation): a tool with both console interface and GUI, which supports Windows executables (including Electron apps) and provides the richest set of rules targeting security, configuration, format, optimization, and system compatibility issues. It also does combined executable analysis, meaning you can find problems spanning multiple executable files in the same project (such as inconsistent version information). Finally, it can create reports in different formats (plain text, SARIF, HTML).

\

• checksec (GitHub): a console tool to detect typical security issues in *nix executables.

\ Let's use Binary Valentine to check a few popular Windows applications. Will we be able to find anything that the developers could improve? The tool provides an easy-to-use UI: simply drag and drop an executable file or the whole folder and click the "Start executable analysis" button. I will first do this for the Firefox web browser:

As you can see, even Firefox has some non-critical issues. For example, different executable files in the directory have inconsistent version information: some of them specify “Mozilla Foundation” as the company name, while others use “Mozilla Corporation”. Firefox does enable most of the available security mitigations, and the analysis results show some minor suggestions for further improvements.

\ What about Wireguard? It is one of the most recent and popular VPN tunneling programs, with clients for many operating systems.

Here, we have several higher-priority issues. Wireguard could have done a better job enabling security mitigations. Security cookie buffer check and Control Flow guard mitigations are not enabled, and ASLR efficacy is limited because of the specific executable file settings. Clicking the links in the Binary Valentine UI, you get a detailed description of each issue and suggestions for mitigating them.

\ Let's finally look at the Telegram Desktop client, which is an extremely popular messenger application.

We can see a few insecure Windows API imports (marked as such by Microsoft with specific suggestions to mitigate). Control Flow Guard is disabled, too. Moreover, it turns out Telegram uses some quite old C++ libraries, which is hinted at by the following warning:

On top of that, there are a few less important findings, like the usage of functions marked deprecated by Microsoft and minor issues with the version information. Other than that, Telegram does a good job: it enables most security mitigations and properly configures system compatibility settings.

\ I checked many more Windows applications, and all of them could have some improvements. One executable had plain bugs in the version information structures, which prevented Windows from correctly displaying it. Another one had an incorrect checksum (possibly after some post-linking modifications), which might alert the anti-virus software.

\ The next one had the manifest which did not declare compatibility with the most recent Windows versions, meaning that Windows might apply some compatibility patches to the application, making it slower or limiting its functionality. I even found the one with the invalid digital signature!

\ To conclude, even well-established and tested applications have something to improve to be faster, more modern, and more secure. Remembering every option of the compiler, linker, resource, version, and manifest editor is challenging and unnecessary. It is much more reliable to let the static analyzer do the job.

\ When starting a new project, it is crucial to run the static executable analysis and fix the detected issues from the start. Finally, to maintain the high quality of your executables, consider introducing regular repeated checks for each production build.