# JITScanner: Just-in-Time Executable Page Check in the Linux Operating System +
## 1 Introduction  
The importance of services running on contemporary computing systems is growing significantly. There is an increasing demand for solutions that extend beyond simply analyzing code statically. These solutions should offer the capability to actively control actions that might be executed by potentially harmful programs, rather than relying solely on static analysis. This approach is highlighted in several literature studies [1, 2, 3]. Dynamic analysis, surpassing its static counterpart in various aspects, concentrates on observing the actual behavior of malware. It focuses on activities such as network connections, file system access, and system calls. This method simplifies the identification of obfuscated or encrypted code, which is commonly employed by malware programs. Nevertheless, dynamic analysis utilizing sandboxing brings about a considerable overhead and has been proven to be detectable in specific configurations [4, 5, 6, 7]. In this article, we take a different approach and introduce JITScanner (Just-in-Time Scanner), a Linux-based solution. This solution is based on identifying, along wall-clock-time, appropriate moments for conducting actual checks on the content of a specific executable page. The primary aim is to circumvent the necessity of checking pages that,although associated with a program or an external library used by the program, are not actively present in RAM. We use the term \"materialized\" to denote a virtual page that currently resides in a page frame within the RAM, accessible by the application in its address space. Pages that are not materialized will prompt a fault to be managed by the operating system if accessed. For instance, pages that are mmap-ed in a Posix operating system at a certain point in time might materialize later during the application's execution. By focusing on pages that are actively accessed for instruction fetching, we aim to bypass the expense of checking pages that the application does not utilize for storing machine instructions needed for execution. From a technical perspective, JITScanner encounters a significant challenge with pages that are allocated for Write-Execute (WX) usage. Simply checking these pages at the time their content materializes and upon their initial use for executing machine instructions is inadequate for confirming that they will not harbor exploitable malicious signatures accessible to attackers. At the same time, it is crucial to note that WX pages hold substantial relevance in legitimate scenarios, particularly in supporting Just-in-Time (JIT) compiling within language-specific virtual machines [8]. To address this issue, our solution incorporates support for a security-focused state machine, managed at the kernel level. This \"shadow\" state machine operates in a way that the actual actions an application can perform on any WX (Write-Execute) page--such as writing or fetching instructions--are entirely logical. In particular, at any given moment, only one of the two possibilities (W or X) is allowed to happen without being traced by the operating system kernel. This approach enables us to identify instances where an executable page is revisited by the CPU to fetch machine instructions after its content has been updated. Consequently, this allows us to recheck for the potential presence of malicious signatures following the modification of the page's content, i.e., the re-materialization of its content. Importantly, this solution also addresses scenarios where an attacker exploits encrypted code that is later decrypted over time into an executable page. This particular scenario is critical and cannot be effectively handled by traditional static analysis techniques and tools and it presents a potential loophole for evading antivirus software that conducts dynamic analysis of active programs [9]. In our solution, we also provide the support for checking the page content upon an instruction fetch if a previously materialized non-executable page is requested to become executable via specific system calls.