PREVENTING EXECUTION OF MALICIOUS INSTRUCTIONS BASED ON ADDRESS SPECIFIED IN A BRANCH INSTRUCTION
In one aspect of the embodiments, malicious instructions executed or to be executed by a processor in a computing device are identified and preventive action is taken in response to that detection, thereby preventing harm to the computing device and the user's data by the malicious instructions. In another aspect of the embodiments, a thread context monitor determines which thread are active within an operating system at any given time, which further enhances the ability to determine which thread contains malicious instructions.
This application is a divisional application of U.S. patent application Ser. No. 15/099,494, filed on Apr. 14, 2016, and titled “PREVENTING EXECUTION OF MALICIOUS INSTRUCTIONS BASED ON ADDRESS SPECIFIED IN A BRANCH INSTRUCTION,” which issued on Sep. 24, 2019, as U.S. Pat. No. 10,423,777, which is incorporated by reference herein.
FIELD OF THE DISCLOSUREThe present disclosure relates to a system and method for detecting malicious instructions executed or to be executed by a processor in a computing device and to take preventive action in response to that detection. These embodiments can prevent harm to the computing device and the user's data by viruses and malware.
BACKGROUNDAs computing devices become increasingly complex, viruses and malware also are becoming increasingly complex and difficult to detect and prevent. While the prior art includes many approaches for scanning non-volatile storage such as a hard disk drive for such threats, the prior art includes few satisfactory solutions for detecting malicious code loaded into memory or the processor itself. The prior art also is lacking in the ability to detect malicious instructions before they are executed, particularly in situations where the malicious instructions are “new” or are known instructions used in a new way and are not part of a well-known virus or malware.
In
What is needed is a mechanism for detecting suspicious BRANCH instructions and to prevent the system from performing the BRANCH if the associated address is likely to contain malicious instructions.
Another aspect of the prior art is shown in
What is further needed is a mechanism to allow code outside of operating system 210 to identify when each thread starts and stops so that it can better target suspicious instructions.
BRIEF SUMMARY OF THE INVENTIONIn one aspect of the invention, a whitelist of known valid branch addresses is generated. Then whenever a new or existing thread is executing, all BRANCH instructions are checked against the whitelist before they are executed. If a BRANCH instruction refers to an address that is not on the whitelist, the system can take preventive action, as the code contained at that address is likely to be malicious.
In another aspect of the invention, a thread context monitor determines which threads are active within an operating system at any given time, which enables the system to turn the malware detection logic off for threads that are relatively innocuous, which decreases the performance overhead of the software.
Thus in the example of
Additional detail regarding branch analysis 510 is now provided. Branch analysis module 510 parses software code stored in memory 120, which comprise binary executable files, and separates the code into its appropriate sections. Relocation information in the form of an absolute address is retrieved from data sections of each executable image, such as a BRANCH instruction. Each absolute address that is found that falls within the address range of the binaries code section is considered to be a legitimate BRANCH destination and added to whitelist 520.
Branch analysis module 510 then scans the code section of each binary image in search of specific byte sequences that indicate CPU instructions that are loading an address into a register. Each address identified after the target byte sequence is treated as a relative instruction pointer (IP) address, and analysis is performed to determine whether the relative address falls into the code section of the binary image. Those that pass this criteria are considered legitimate BRANCH destinations.
Next, the algorithm scans for jump tables (switch statements) in code, and the code section for each loaded image is searched for an instruction byte sequence that indicates loading IP relative addresses into a register. If the relative address falls within a read-only data section of the binary, further analysis to identify jump tables is done as follows:
-
- a. The first and second DWORD/QWORD at the data section offset is treated as an IP relative address. If both relative addresses when added to the offset of the load instruction points into the code section AND the two offsets within the code section are within a specific threshold of one another, then the structure in read-only data is treated as a jump table.
- b. The first pass completes with the identification of all jump table locations in memory. Next, the algorithm traverses each potential entry in each jump table and treats each relative address as a jump destination (when added to the offset of the load instruction) until it encounters a relative address that does not point into the code section. Each branch destination found in each jump table is added to the whitelist.
Prior to being added to the whitelist, each branch location address that is identified in binary code is added to its appropriate base address of the binaries executable code page in virtual memory based on the memory map of the target thread of execution.
If processor 110 follows an instruction set architecture (ISA) where instructions are both larger than 8-bits and aligned on memory boundaries equal to a power of 2, then a further heuristic can be applied to ensure a candidate BRANCH destination lies on a 2, 4, 8, 16, 32, etc. byte aligned boundary depending on the instruction size and discarding those addresses that do not fall on that byte boundary.
Each function entry point or legitimate branch location address is stored in a data structure that allows for fast lookup. Additionally, the data structure ensures a reduced memory footprint for the storage of the branch location list. In one embodiment, the data structure is a simple sorted list upon which a binary search is performed. In another embodiment, the data structure is a hashtable data structure. In another embodiment, the data structure is a bloom filter data structure. One of ordinary skill in the art will appreciate that other types of data structures can be used.
Another aspect of the invention is shown in
In the example of
At a later time, scheduler 1110 stops thread 1130 (step 1202) and starts thread 1140 (step 1203), which causes a set of code in APC queue 1240 to execute, which in turn creates an APC event that is detected by thread context monitor 1210, which then concludes that thread 1140 is active and consequently determines that thread 1130 is now inactive.
At a later time, scheduler 1110 stops thread 1140 (step 1204) and starts thread 1130 (step 1205) and later stops thread 1130 (step 1205). The starting of thread 1130 generates an APC event in the manner described above.
Thread context monitor 1210 can store data that indicates the state of the thread context. Under one approach, thread context monitor 1210 stores identification data for each thread that is currently active (e.g., after step 1201, it would store an ID for Thread 1130).
Under another approach shown in
Under a similar approach shown in
Under the embodiments of
The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures which, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various different exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art. In addition, certain terms used in the present disclosure, including the specification, drawings and claims thereof, can be used synonymously in certain instances, including, but not limited to, for example, data and information. It should be understood that, while these words, and/or other words that can be synonymous to one another, can be used synonymously herein, that there can be instances when such words can be intended to not be used synonymously. Further, to the extent that the prior art knowledge has not been explicitly incorporated by reference herein above, it is explicitly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entireties.
Claims
1. A method of identifying valid addresses in a memory device that are referenced in BRANCH instructions to be executed by a processor coupled to the memory device, the method comprising:
- identifying an address referenced by a BRANCH instruction stored in a memory device;
- adding the address to a data structure containing a list of valid addresses in the memory device if the address is assigned to a known software module; and
- refraining from adding the address to the data structure if the address is not assigned to a known software module.
2. The method of claim 1, wherein an address not assigned to a known software module is an unassigned address.
3. The method of claim 1, wherein the address is determined to be assigned to a known software module if the address is located with an address range for binary executable files.
4. The method of claim 1, wherein the data structure is a bloom filter data structure.
5. The method of claim 1, wherein the data structure is a sorted list.
6. The method of claim 1, wherein the data structure is a hashtable data structure.
7. A method of maintaining a thread context within an operating system running on a computer system and controlling a malware prevention module, the computer system comprising a processor coupled to a memory device and the operating system comprising an asynchronous procedure call (APC) module and a thread context monitor, the method comprising:
- running one or more threads within the operating system;
- maintaining, for each of the one or more threads, information within the APC module that indicates one or more start events for each thread;
- deducing stop events for each thread based on start events of other threads;
- maintaining a data structure, by the thread context monitor, comprising start event information and stop event information for each thread; and
- turning a malware prevention module on or off based on the start event information and the stop event information in the data structure.
8. The method of claim 7, wherein the data structure comprises a table that indicates the status for each of the one or more threads.
9. A computer system comprising:
- a processor;
- a memory device coupled to the processor; and
- an operating system running within the processor, the operating system comprising an asynchronous procedure call (APC) module and a thread context monitor;
- a malware prevention module running with the processor;
- wherein the operating system runs one or more threads and the APC module maintains for each of the one or more threads information indicating one or more start events for each thread and the thread context monitor deduces stop events for each thread based on start events of other threads and maintains a data structure comprising start event information and stop event information for each thread; and
- wherein the malware prevention module is turned on or off based on the start event information and the stop event information in the data structure.
10. The computer system of claim 9, wherein the data structure comprises a table that indicates the status for each of the one or more threads.
Type: Application
Filed: Sep 23, 2019
Publication Date: Jul 16, 2020
Inventors: Matthew D. Spisak (Columbus, OH), Cody R. Pierce (Austin, TX), Kenneth D. Fitch (San Antonio, TX)
Application Number: 16/579,430