I use a number of mountaineering references here on Summit Route, much to everyone’s confusion. Mountaineering, like information security, involves risk management and the application of best practices to reduce the inherent risks.
Rock climbing is one aspect of mountaineering, and it requires you to secure your ropes to an anchor (ex. a tree, crack, or rock feature). The acronym SERENE is used as a checklist to review your anchor. The anchor needs to be Solid, Equalized, Redundant, Efficient, and No Extension (SERENE). This doesn’t check the quality of the rope, your harness, the weather, your current physical state, or many other things that will affect your safety, but it’s a simple series of checks for one thing that ensures you’re applying best practices.
Similarly, I built a tool call that I call Serene to perform a couple of best practice checks on executable binaries. It’s not an acronym, because there is nothing for you to remember, as it does the work for you. When a Windows executable, such as a .exe or .dll (a PE file), or an Apple mach-o file is compiled, there are a few settings that can improve its security. These include:
- DEP/NX: Denies execution on the stack.
- ASLR/PIE: Loads the binary into a random place in memory.
- CFG (Windows only): Restricts what execution paths can be taken.
- x64: Allows a 64-bit memory space to be used for ASLR/PIE.
Serene is a simple static web app (meaning no backend server, it’s just a javascript file that runs locally). You can drag and drop files or folders to it and it will identify the executable binaries, perform its checks, and display the results.
My primary use case for making Serene is when I evaluate products at the company I work at. I want to get an idea of the software development practices, so this tool gives me some quick insight into that.
Examples
Windows Defender
Microsoft’s Windows Defender, the default AV for Windows, can be dragged and dropped to Serene by using the folder C:\Program Files\Windows Defender\
, resulting in:
As you can see it follows all the best practices that Serene checks for. This also shows how Serene tells you that DEP is not applicable (N/A) to these files because all 64-bit processes have DEP applied by default. Furthermore, Windows Defender includes a number of MUI files which do not include code and therefore don’t play into the security of the applications, so they are ignored.
Google Chrome on macOS
Google Chrome on macOS can be analyzed by dragging and dropping the Google Chrome icon in the Applications directory, which ends up being a .app
file containing the executables.
As you can see this time I show NX and PIE which are the equivalents of DEP and ASLR on Windows, and don’t show CFG, which has no relevance to macOS. Only some install files are missing PIE and 32-bit, so it’s not too worrying.
Checking files without Serene
Serene makes it easy to check files, but you might want to to this via the command-line. You may also just want to double-check my work. To perform the same checks as Serene, using the official tools, do one of the following:
Windows executables
Windows executables are PE files and can be checked using the Visual Studio tool dumpbin
. Run dumpbin /headers yourfile.exe
First look at FILE HEADER VALUES
for the machine
to determine if it is 64-bit or 32-bit. Next, look in the OPTIONAL HEADER VALUES
for the Dll Characteristics
section for the phrases Dynamic base
(ASLR), NX compatible
(DEP), and Guard
(CFG).
macOS executables
To manually check macOS mach-o files, use the XCode tool otool
. Run otool -hv yourfile
. First look at the cputype to see if it is X86_64
to determine if it is 64-bit. Next check the flags
to see if it contains PIE
. Determining if it has NX
is identified by the lack of MH_ALLOW_STACK_EXECUTION
(probably called something else, as I just check for that bit in the binary and don’t know what the tool calls it).
Known limitations
On macOS, I don’t currently handle mach-o files containing multiple architectures, which is an admittedly large limitation. I also do not yet support ELF files, which I hope to one day handle.
It only works with x86 and x86-64 executables, not ARM.
Anything compiled with Golang will not have ASLR/PIE. This is a decision by the language creators as Golang is a secure language, but if the process imports a C library, it exposes itself to possible issues. As such, I didn’t want to skip Golang binaries.
On Windows, an executable can enable DEP without it being compiled into the binary.
If you don’t have permissions to read a file, Serene may lock up and you’ll need to refresh the page.
Finally, there are all sorts of ways an application can be insecure or more secure than Serene shows. This is only identifying one set of features.
Other comments
This is really just some improvements to a project of mine from 2012 called SlopFinder.