Suspicious Program Detection via Memory Location Comparison
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current malware detection methods face difficulties in identifying polymorphic malware and rootkits that use hooks to obscure their behavior, making it hard for anti-malware applications to detect and remove them effectively.
Innovation Solution
A method that calculates estimated absolute memory locations for functions or helper programs in executable files before loading, compares these with actual memory locations, and detects mismatches to identify potential malware, with additional corroboration steps to confirm the presence of malicious code, such as looking for new thread instantiation instructions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Object-affected harmful factors
If malware uses polymorphism to encrypt code with different encryption forms for each copy, then the malware becomes harder to detect by signature-based anti-virus applications, but the detection complexity and resource requirements increase
Solution Approach 1:
The patent performs preliminary actions by calculating expected absolute memory locations for all functions and helper programs before the executable is loaded into memory. This pre-calculation creates a baseline that can be compared against actual runtime values to detect malware-induced discrepancies without requiring complex real-time analysis of encrypted code variations.
Solution Approach 2:
The patent introduces an intermediary comparison mechanism that checks absolute memory locations of functions and helper programs as a mediator between the executable code and the detection system. This intermediary layer detects malware behavior indirectly through memory location discrepancies rather than directly analyzing encrypted or obscured malware code.
2Object-affected harmful factors
If root kits use hooks to redirect calls from legitimate functions to malicious code, then the malicious behavior is obscured from anti-malware applications, but the system reliability and security are compromised
Solution Approach 1:
The patent performs preliminary analysis of the executable file before loading to calculate expected memory locations of all functions and helper programs. This pre-established baseline enables detection of hook-induced redirects by comparing expected versus actual memory locations during runtime, exposing malicious behavior that would otherwise be obscured.
Solution Approach 2:
The patent implements a feedback mechanism by continuously comparing actual memory locations of functions and helper programs against pre-calculated expected values. When discrepancies are detected, the system can identify potential hooking activity and trigger appropriate responses, creating a closed-loop security system that adapts to detected threats.
3Object-affected harmful factors
If malware modifies helper functions in DLL files without registering as separate processes, then the malicious activity becomes harder to detect, but the ability to perform restorative actions is reduced
Solution Approach 1:
The patent performs preliminary calculation of expected memory locations for all helper programs and functions within DLL files before the executable loads. This pre-established reference data enables post-detection restorative actions by providing a baseline for comparing against actual runtime states, facilitating identification and correction of malicious modifications.
Solution Approach 2:
The patent uses absolute memory location comparison as an intermediary detection mechanism that works independently of process registration status. By monitoring memory locations of helper functions rather than relying on process information, the system can detect malware modifications in DLL files and maintain the capability to perform restorative actions even when malware operates without separate process registration.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A processing device (10) includes a processor (12), an interface (14) and a memory (100). The memory (100) is formed from system Random Access Memory (RAM) and one or more other storage devices. The memory (100) can be considered as comprising working memory (110) and persistent storage (120). The working memory includes the system RAM but may also use memory from one or more other storage devices and when certain suspicious program detection modules are operating also stores a comparison table (112) discussed below. Contained within the persistent storage are several executable program files as follows: an Absolute Memory Address Calculator executable program (121) which is responsible for causing the system (10) to inspect a copy of a persistently stored (and compiled) executable program (e.g. an executable program (125, 126, 127,... as stored in the persistent storage 120) and to calculate expected absolute memory locations for the various functions or helper programs that it makes calls to and to store these in a table (112) that it creates in the working memory (110) for this purpose; a Loaded Program Accessor executable program (122) which is responsible for causing the system (10) to inspect a copy of an executable program as loaded in the working memory (110) of the system after loading and linking of the program have been completed, to determine the actual memory locations stored in the Import Address Table (IAT) of the loaded program, and to store these actual memory locations in the comparison table (112); a Memory Location Comparator executable program (123) which is responsible for causing the system (10) during execution of this program to compare the calculated expected absolute memory locations with their respective actual accessed memory locations as stored in the comparison table of memory locations (112); and a Corroborator executable program (124) which is responsible for causing the system (10) during execution of this program to perform a corroboration of any mismatches of memory locations detected in the memory location pairs stored in the table (112) of memory locations, by, in the present embodiment, inspecting the contents of any executable instructions contained at the actually accessed memory location to look for the presence of an instruction causing a new thread of execution to be instantiated.