Security Checks

Security Checks

The Mitigations view (CLI: -m) reports what is provable from static bytes. Every check shows its evidence, and three-valued checks can answer Unknown rather than guess.

Check	Values	How it is decided
RELRO	Full / Partial / None / Unknown	PT_GNU_RELRO segment present → Partial; plus immediate binding (DT_BIND_NOW / DF_BIND_NOW) → Full. No program headers at all → Unknown.
NX (stack)	Enabled / Disabled / Unknown	PT_GNU_STACK without the execute flag (PF_X) → Enabled; with PF_X → Disabled; segment absent (kernel default governs) → Unknown.
PIE	PIE / No PIE / DSO / Unknown	ET_EXEC → No PIE. ET_DYN with an interpreter, a DT_DEBUG entry, or DF_1_PIE in DT_FLAGS_1 → PIE (this also distinguishes static-PIE from a shared object). ET_DYN with none of those → plain DSO.
Stack canary	Enabled / Disabled / Unknown	Looks for __stack_chk_fail, __stack_chk_fail_local, or __stack_chk_guard in the symbol tables. No symbols (stripped) → Unknown.
Fortify	Enabled / Disabled / Unknown	Counts undefined imports whose name ends in _chk (e.g. __printf_chk); the deduplicated list is shown. No symbols → Unknown.
RWX segments	count	Segments carrying both the write and execute permission bits. Anything above 0 deserves a look.
Insecure RPATH/RUNPATH	yes / no	A path containing an empty component, ., or a ./-prefixed component can hijack library resolution from the binary's own directory.

Interpreting results

• Unknown is a statement about knowledge, not about the binary. A stripped file cannot prove canary absence; the report says Unknown instead of Disabled.
• Detection is segment- and symbol-based, matching what readelf-based checksec tooling can prove. It is not a malware score — disassembly and malware scoring are out of scope.
• Typical hard desktop binary: Full RELRO, NX enabled, PIE, canary enabled, fortify enabled, 0 RWX segments.

JSON

All values serialize under mitigations — see JSON-Schema: relro, nx, pie, stack_canary, fortify, fortified_functions, rwx_segments, has_insecure_rpath.