Patent Description:
Malware is any software intentionally designed to cause damage to a computer, a server, a client, or a computer network. A wide variety of malware types exist, including computer viruses, worms, Trojan horses, ransomware, spyware, adware, rogue software, wiper, and scareware. Memory-resident malware or fileless malware is a type of malware that inserts itself into a computer or a device in a particular way, loading its own program into permanent memory, such as readable access memory (RAM). To analyze malware, static and dynamic analysis techniques are used. Static malware analysis involves examining any given malware sample without actually running or executing the code. This is usually done by determining the signature of the malware binary; the signature is a unique identification for the binary file. Dynamic malware analysis, unlike static malware analysis, involves analysis while running the code in a controlled environment. The malware is run in a closed, isolated sand box environment and then its behavior is studied. <CIT> proposes a processor-based dedicated fixed function hardware to perform integrity measurements. <CIT> proposes a software-based security-retrofit solution. <CIT> proposes a system for testing and/or validating that an untrusted device is operating according to an expected state.

The present disclosure relates to systems for detecting malware.

The present disclosure relates to systems for detecting malware. Malware can infect systems and reduce or inhibit of performance of such systems, which can lead to unwanted system performance or compromise. For example, a cyber-attack can be launched on a system that may have access to a network. If the cyber-attack is successful, the system can be compromised, which can lead to system failures or in some instances to a loss of life. Systems that have limited amount of computing resources and are exposed to a network (e.g., a computer network, a satellite network, wireless network, wired network, and the like) are vulnerable to being compromised by malware. In some instances, limited power computing systems, for example, weapon systems, employ integrity checks on program code at a boot time. However, sophisticated malware may be used that can circumvent boot time code compromise verification. In some examples, the integrity checks are not designed to detect a particular virus. Moreover, in some limited power computing systems, implementing additional integrity checks during the boot time may not be possible due to the limited amount of computing resources available on the system.

Systems and methods are described herein for detecting and in some instances removing malware on systems that have a defined amount of processing resources. The systems and methods described herein do not require an elevated amount of processing resources for detection and in some examples removal of the malware. In some examples, a malware detector can be employed on the weapons system or other systems with limited amount of computing power to provide for real-time malware monitoring on such resource constrained platforms.

In some examples, the malware detector can be employed to monitor a system for unwanted memory and/or data changes indicative of malware compromise. The malware detector can be executed during a runtime of program code. The malware detector can employs a program code analyzer, a static data analyzer, and an unused memory location analyzer. Each analyzer of the malware detector can be caused to execute during different instances of time during the runtime of the program code. In some examples, each of the analyzers is executed periodically or a-periodically during the runtime of the program code. The program code analyzer can be configured to evaluate instruction data for executing the program code at a first set of memory locations within the memory for malware in response to being selected by analyzer manager. The static data analyzer can be configured to evaluate static data for use by the program code at a second set of memory locations within the memory for the malware in response to being selected by analyzer manager. The unused memory location analyzer can be configured to evaluate null data indicative of unused memory locations within the memory at a third set of memory locations within the memory storing for the malware in response to being selected by analyzer manager. Each of the analyzers can be configured to generate a malware alert indicative that respective data within corresponding memory locations with the memory has been compromised. The memory can include volatile and non-volatile memory. Because the volatile and the non-volatile memory of the system is monitored by the malware detector for malware attacks, the malware detector can minimize an impact of the malware attack on the system (e.g., reduce a spread of the malware) by reducing an amount of time that is needed to detect the malware.

<FIG> is an example of a malware detector <NUM>. The malware detector <NUM> can be employed on a weapon system, or any system that may have a limited amount of computing power (e.g., for real-time data processing). Thus, in some examples, the malware detector <NUM> can be employed on an unmanned aerial vehicle (UAV) (e.g., a drone), a satellite system, or a space vehicle. The malware detector <NUM> can be embodied as machine readable instructions that can be executed by a processor of the weapon system. The malware detector <NUM> can be configured monitor the weapon system for malware. In some examples, the malware detector <NUM> can be configured to detect the malware during a runtime of a computer program. By detecting the malware during the runtime of the computer program, the malware detector <NUM> can alert a user and/or remove the detected malware. By way of example, the computer program can be represented as a program code corresponding to machine readable instructions that can be executed by a processor of the weapon system. In some examples, the program code can correspond to weapon system code for configuring and/or controlling sub-systems of the weapon system for operation. While examples are presented with respect to configuring the weapon system with the malware detector, the examples herein should not be construed and/or limited to only such examples. The malware detector <NUM> can be used on any system that may be vulnerable to a malware attack (e.g., a cyber-attack).

By way of example, upon initialization of the weapon system, the malware detector <NUM> can be executed by the processor of the weapon system to monitor and detect for malware on-board the weapon system. The malware detector <NUM> can include an analyzer manager <NUM>. The analyzer manager <NUM> can be configured to select one of a program code analyzer <NUM>, a static data analyzer <NUM>, and an unused memory location analyzer <NUM> based on analyzer execution data <NUM>. The analyzer execution data <NUM> can identify or determine when each of the program code analyzer <NUM>, the static data analyzer <NUM>, and the unused memory location analyzer <NUM> are executed during the runtime of the computer program. Thus, the analyzer execution data <NUM> can characterize a schedule for execution of the program code analyzer <NUM>, the static data analyzer <NUM>, and the unused memory region analyzer <NUM>. In some examples, the analyzer manager <NUM> can be configured to select the program code analyzer <NUM> based on the schedule. For example, the schedule can identify instances in time at which the program code analyzer <NUM> is to cause one of the analyzers <NUM>, <NUM>, and <NUM> to be executed. In some examples, each of the analyzers <NUM>, <NUM>, and <NUM> can be executed periodically or a-periodically at different instances in time during the runtime of the computer program.

In some examples, the analyzer execution data <NUM> can identify a first set of address locations for a first set of memory locations (e.g., address locations) within a memory of the weapon system. The memory of the weapon system can include volatile memory and/or non-volatile memory. In some examples, the first set of memory locations can store instruction data <NUM>. The instruction data <NUM> stored at the first set of memory locations of the memory can include at least some of the instructions (e.g., central processing unit (CPU) instructions) for executing the computer program. The analyzer manager <NUM> can be configured to provide the first set of address locations for the first set of memory locations from the analyzer execution data <NUM> to the program code analyzer <NUM> for malware evaluation of the instruction data <NUM> stored at the first set of memory locations within the memory.

The program code analyzer <NUM> can be configured to evaluate the instruction data <NUM> stored at the first set of memory locations within the memory to determine whether the first set of memory locations has been compromised by the malware. For example, the program code analyzer <NUM> can be configured to execute a hash function on the instruction data <NUM> at the first set of memory locations within the memory, and compare the hash to an expected hash. The expected hash can correspond to a baseline hash for the first set of memory locations within the memory. The term "baseline hash" can be referred to as a "pristine hash" or "golden hash". The baseline hash can be associated with a version of the instruction data <NUM> at the first set of memory locations during runtime of the computer program that has not been affected by the malware. For example, the baseline hash can be a hash of a set of instructions of the instruction data <NUM> that does not include one or more instructions embedded by the malware. The program code analyzer <NUM> can be configured to generate malware alert data <NUM> in response to determining that the hash of the instruction data <NUM> at the first set of memory locations within the memory is not equal to the expected hash. Because the malware can embed unwanted instructions into the instruction data <NUM>, the hash of the instruction data <NUM> will be different from the hash of the instruction data <NUM> without the embedded unwanted instructions. The malware alert data <NUM> can provide an alert that the first set of memory locations have been compromised by the malware.

In some examples, the malware alert data <NUM> can identify the first set of addresses for the first set of memory locations within the memory that have been compromised by the malware. The malware alert data <NUM> can be provided to the analyzer manager <NUM>. The analyzer manager <NUM> can be configured to provide the malware alert data <NUM> to a user to alert the user that the weapon system has been comprised by the malware. In some examples, the analyzer manager <NUM> can be employed to communicate the malware alert data <NUM> to an output device (e.g., a computer, a display, etc.), which can be configured to render the malware alert data <NUM> to alert the user. In some examples, the program code analyzer <NUM> can be configured to provide the malware alert data <NUM> to the output device.

In some examples, the analyzer manager <NUM> can be configured to select the static data analyzer <NUM> based on the analyzer execution data <NUM>. For example, the schedule of the analyzer execution data <NUM> can indicate that the static data analyzer <NUM> is to be executed during the runtime of the computer program. In some examples, the analyzer execution data <NUM> can identify a second set of address locations for a second set of memory locations within the memory. The second set of memory locations within the memory can be configured to store at least some of static data <NUM> that may be used by the program code. The static data <NUM> stored at the second set of memory locations within the memory can include data that does not change during execution of the program code. Thus, the static data <NUM> can be representative of a collection of data in the memory that can be fixed in size. For example, the static data <NUM> can include one or more arrays. The analyzer manager <NUM> can be configured to provide the second set of address locations for the second set of memory locations within the memory from the analyzer execution data <NUM> to the static data analyzer <NUM> for malware evaluation of the static data <NUM> stored at the second set of memory locations within the memory.

The static data analyzer <NUM> can be configured to evaluate the static data <NUM> stored at the second set of memory locations within the memory to determine whether the static data <NUM> stored therein has been compromised by the malware. For example, the static data analyzer <NUM> can be configured to execute a hash function on the static data <NUM> at the second set of memory locations within the memory, and compare the hash to an expected hash. The expected hash can correspond to a baseline hash for the second set of memory locations within the memory. The baseline hash can be associated with a version of the static data <NUM> at the second set of memory locations within the memory that has not been affected by the malware. For example, the baseline hash can be a hash of the static data <NUM> that does not include the one or more instructions embedded by the malware. The static data analyzer <NUM> can be configured to generate the malware alert data <NUM> in response to determining that the hash of the static data <NUM> at the second set of memory locations within the memory is not equal to the expected hash for the static data <NUM>. Because the malware can embed unwanted instructions into the static data <NUM>, the hash of the static data <NUM> will be different from the hash of the static data <NUM> without the embedded unwanted instructions. The malware alert data <NUM> can provide an alert that the second set of memory locations within the memory have been compromised by the malware. In some examples, the malware alert data <NUM> can identify the second set of addresses for the second set of memory locations within the memory that have been compromised by the malware.

In some examples, the analyzer manager <NUM> can be configured to select the unused memory location analyzer <NUM> based on the analyzer execution data <NUM>. For example, the schedule of the analyzer execution data <NUM> can indicate that the unused memory location analyzer <NUM> is to be executed during the runtime of the computer program. In some examples, the analyzer execution data <NUM> can identify a third set of address locations for a third set of memory locations within the memory. The third set of memory locations within the memory can be configured as unused regions within the memory at which no data is stored during runtime of the program code. In some examples, the unused regions can store null data <NUM> representative of a null value (e.g., zero or another fixed value) to indicate that no data is stored at the third set of memory locations within the memory. Thus, in some examples, the third set of memory locations can store no data and the storage of no data can be represented by the null data <NUM>.

The analyzer manager <NUM> can be configured to provide the third set of address locations for the third set of memory locations within the memory from the analyzer execution data <NUM> to the unused memory location analyzer <NUM> for malware evaluation of the null data <NUM> stored at the third set of memory locations within the memory. The unused memory location analyzer <NUM> can be configured to evaluate the null data <NUM> stored at the third set of memory locations within the memory to determine whether the null data <NUM> stored therein has been compromised by the malware. For example, the unused memory location analyzer <NUM> can be configured to execute a hash function on the null data <NUM> at the third set of memory locations within the memory, and compare the hash to an expected hash. The expected hash can correspond to a baseline hash for the third set of memory locations within the memory. The baseline hash can be associated with a version of the null data <NUM> at the third set of memory locations within the memory that has not been affected by the malware. For example, the baseline hash can be a hash of the null data <NUM> that does not include the one or more instructions embedded by the malware.

The static data analyzer <NUM> can be configured to generate the malware alert data <NUM> in response to determining that the hash of the null data <NUM> at the third set of memory locations within the memory is not equal to the expected hash for the null data <NUM>. Because the malware can embed unwanted instructions into the null data <NUM>, the hash of the null data <NUM> will be different from the hash of the null data <NUM> without the embedded unwanted instructions. The malware alert data <NUM> can provide an alert that the third set of memory locations within the memory have been compromised by the malware. In some examples, the malware alert data <NUM> can identify the third set of addresses for the third set of memory locations within the memory that have been compromised by the malware.

Accordingly, by employing the malware detector <NUM> on-board the weapon system, cyber-attacks can be identified before the malware is able to spread and/or impact a performance of the weapon system. Moreover, because the malware detector <NUM> does not require an elevated amount of processing resources for detection and in some examples removal of the malware, the malware detector can be employed on the weapons system or other systems with limited amount of computing power to provide for real-time malware monitoring on such resource constrained systems.

<FIG> is an example of a computing system <NUM>. In some examples, the computing system <NUM> can be representative of an on-board system, such that can be used on an aerial vehicle, a satellite, a space vehicle. Thus, in some examples, the computing system <NUM> can be representative of a processing system that has a limited amount of computing power on a corresponding platform on which the processing system is to be used. The computing system includes a processor <NUM> and non-volatile memory <NUM>. While the example in <FIG> illustrates a single processor and non-volatile memory in other examples, a plurality of processors and non-volatile memories can be used. By way of example, the processor <NUM> can be one or more processor cores. The non-volatile memory <NUM> can be one of a hard disk drive, a solid-state drive, a flash memory, or the like. In the present example of <FIG>, although the components of the computing system are illustrated as being implemented on the same computer system <NUM>, in other examples, the components could be distributed across different systems (e.g., computers, devices, etc.) and communicate, for example, over a network (e.g., a wireless and/or wired network). By way of example, the network can be an avionics bus network (ABN) of an aerial vehicle, such as a manned or an unmanned aerial vehicle.

The non-volatile memory <NUM> can store machine-readable instructions that can be retrieved and executed by the processor <NUM> for executing a computer program. By way of example, the computer program can be a weapon computer program, such as for targeting an object (e.g., an aerial vehicle, ground vehicles, ground forces, and the like). The computer program can be stored in the memory as machine-readable instructions and referred to herein as program code <NUM>. The program code <NUM> can include instruction data that can be used by the processor <NUM> to execute the computer code. The instruction data can correspond to the instruction data <NUM>, as shown in <FIG>. The instruction data of the program code <NUM> can be stored at a first memory region <NUM> of the non-volatile memory <NUM>. In some examples, the program code <NUM> can include static data. The static data can correspond to the static data <NUM>, as shown in <FIG>. In some examples, the static data can be used by the instruction data. For example, one or more instructions of the instruction data can execute a function, a command, and the like based on the static data. In some examples, the static data does not form part of the program code <NUM>. Thus, in some examples, the static data can be used by the computer program corresponding to the instruction data for implementing one or more actions (e.g., functions, commands, and the like). The static data can be stored at a second memory region <NUM> of the non-volatile memory <NUM>.

In some examples, the non-volatile memory <NUM> can include a third memory region <NUM>. The third memory region <NUM> of the non-volatile memory <NUM> can be representative of unused memory locations with the non-volatile memory <NUM>. In some examples, the third memory region <NUM> of the non-volatile memory <NUM> can store null data representative of a null value (e.g., zero or another fixed value) to indicate that no data is stored at the third set of memory locations within the memory. Thus, in some examples, the third memory region <NUM> of the non-volatile memory <NUM> can store no data and the storage of no data can be represented by the null data. In some examples, the null data at the third memory region <NUM> of the non-volatile memory <NUM> can correspond to the null data <NUM>, as shown in <FIG>. In some examples, the non-volatile memory <NUM> can store machine-readable instructions that can be retrieved and executed by the processor <NUM> for executing a malware detector module <NUM> for malware evaluation as described herein. The malware detector module <NUM> can include or correspond to the malware detector <NUM>, as shown in <FIG>.

In some examples, the processor <NUM> can include volatile memory <NUM>. By way of example, the volatile memory <NUM> can be representative of random access memory (RAM). In other examples, the volatile memory <NUM> can be implemented as a memory module. By way of example, the volatile memory <NUM> may be implemented as a dual in-line memory module (DIMM). In additional or alternative examples, the volatile memory <NUM> may be implemented as a double data rate type (DDR) device. Thus, in some examples, the volatile memory <NUM> can be implemented as a double data rate <NUM> (DDR3) device, a double data rate <NUM> (DDR4) device, a low power DDR3 (LPDDR3) device, a low power DDR4 (LPDDR4) device, a Wide I/O <NUM> (WIO2) device, a high bandwidth memory (HBM) dynamic random-access memory (DRAM) device, a HBM <NUM> DRAM (HBM2 DRAM) device, a double data rate <NUM> (DDR5) device or a low power DDR5 (LPDDR5) device (e.g., a mobile DDR device).

In some examples, the processor <NUM> can include a control unit <NUM>. To execute the computer program, the control unit <NUM> can be configured to cause at least some of the instruction data from the first memory region <NUM> of the non-volatile memory <NUM> to be retrieved. The control unit <NUM> can be configured to cause the retrieved instruction data to be stored at a first memory region <NUM> of the volatile memory <NUM>. In some examples, the retrieved instruction data can correspond to the instruction data <NUM>, as shown in <FIG>. The control unit <NUM> can be configured to execute the retrieved instruction data at the first memory region <NUM> to run the computer program. In some examples, during a runtime of the computer program, the control unit <NUM> can be configured to access the non-volatile memory <NUM> to execute the machine readable instructions representative of the malware detector module <NUM>. In some examples, during the runtime of the computer program, the control unit <NUM> can be configured to cause at least some of the static data stored at the second memory region <NUM> of the non-volatile memory <NUM> to be retrieved. The control unit <NUM> can be configured cause the retrieved static data to be stored at a second memory region <NUM> of the volatile memory <NUM>. In some examples, the retrieved static data can correspond to the static data <NUM>, as shown in <FIG>. In some examples, the volatile memory <NUM> can include a third memory region <NUM>. The third memory region <NUM> of the volatile memory <NUM> can store null data representative of a null value (e.g., zero or another fixed value) to indicate that no data is stored at the third set of memory locations within the volatile memory <NUM>. Thus, in some examples, the third memory region <NUM> of the volatile memory <NUM> can store no data and the storage of no data can be represented by the null data. In some examples, the null data at the third memory region <NUM> of the volatile memory <NUM> can correspond to the null data <NUM>, as shown in <FIG>. In some examples, memory regions as described herein with respect to <FIG> can be referred to as memory locations within a corresponding memory. For clarity and brevity purposes other elements of the processor <NUM> have been omitted, such as an arithmetic/logic unit, registers, buses, etc..

In some examples, during the runtime of the computer program, the control unit <NUM> can cause the processor <NUM> to execute the malware detector module <NUM> to determine whether if any of the first memory regions <NUM> and <NUM>, the second memory regions <NUM> and <NUM>, and/or the third memory regions <NUM> and <NUM> have been compromised by malwares. Upon execution, the malware detector module <NUM> can employ an analyzer manager <NUM>. The analyzer manager <NUM> can be configured similar to the analyzer manager <NUM>, as shown in <FIG>. The analyzer manager <NUM> can be programmed to select one of a program code analyzer <NUM>, a static data analyzer <NUM>, and an unused memory location analyzer <NUM> based on analyzer execution data (e.g., the analyzer execution data <NUM>, as shown in <FIG>). The program code, static data, and unused memory location analyzers <NUM>, <NUM>, and <NUM> can correspond to the program code, static data, and unused memory location analyzers <NUM>, <NUM>, and <NUM>, as shown in <FIG>. The analyzer manager <NUM> can be programmed to select one of the program code analyzer <NUM>, the static data analyzer <NUM>, and the unused memory location analyzer <NUM> based the analyzer execution data in a same or similar manner as described herein with respect to <FIG>. Thus, during the runtime of the computer program, the analyzer manager <NUM> can be programmed to cause each of the analyzers <NUM>, <NUM>, and <NUM> to be executed periodically or a-periodically and thus at different instances in time to evaluate the memory regions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

In some examples, the program code analyzer <NUM> can be programmed to evaluate the instruction data stored at the first memory region <NUM> within the non-volatile memory <NUM> to determine whether the instruction data stored therein has been compromised by the malware. For example the program code analyzer <NUM> can be programmed to invoke a hash function <NUM> to execute a hash on the instruction data at the first memory region <NUM>, and compare the hash of the instruction data at the first memory region <NUM> to an expected hash for the instruction data at the first memory region <NUM>. In some examples, the malware detector module <NUM> can include an expected hash database <NUM>. The expected hash database <NUM> can identify an expected hash for each memory region the memory regions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Thus, the expected hash database <NUM> can include expected hash values for each memory region the memory regions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> for different instances of time during the runtime of the computer program. Because data in at least some memory regions can change (e.g., in size and/or value) during the runtime of the computer program (e.g., the memory regions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>), the expected hash database <NUM> can include different expected hash values for times at which the at least some memory regions is evaluated by the malware detector module <NUM> for the malware. As described herein, an expect hash for a memory region corresponding to a set of memory locations in memory can correspond to a baseline has for the memory region that is free of embedded instructions and/or data by the malware.

In some examples, the program code analyzer <NUM> can be programmed to generate malware alert data (e.g., the malware alert data <NUM>, as shown in <FIG>) in response to determining that the hash of the instruction data at the first memory region <NUM> is not equal to the expected hash for the instruction data at the first memory region <NUM>. Because the malware can embed unwanted instructions and/or data into the instruction data at the first memory region <NUM>, the hash of the instruction data at the first memory region <NUM> will be different from the hash of the instruction data at the first memory region <NUM> without the embedded unwanted instructions and/or data. The malware alert data can provide an alert that the first memory region <NUM> has been compromised by the malware. In some examples, the malware alert data can identify a location of the first memory region <NUM> within the non-volatile memory <NUM>.

In some examples, the program code analyzer <NUM> can be programmed to evaluate the retrieved instruction data stored at the first memory region <NUM> within the volatile memory <NUM> to determine whether the retrieved instruction data stored therein has been compromised by the malware in a same or similar manner as described herein with respect to the first memory region <NUM> of the non-volatile memory <NUM>. Thus, in some examples, the program code analyzer <NUM> can be programmed to invoke the hash function <NUM> to execute a hash on the retrieved instruction data at the first memory region <NUM>, and compare the hash of the retrieved instruction data at the first memory region <NUM> to an expected hash for the retrieved instruction data at the first memory region <NUM> from the expected hash database <NUM>. In some examples, the program code analyzer <NUM> can be programmed to generate the malware alert data in response to determining that the hash of the retrieved instruction data at the first memory region <NUM> is not equal to the expected hash for the retrieved instruction data at the first memory region <NUM>.

In some examples, the static data analyzer <NUM> can be programmed to evaluate the static data stored at the second memory region <NUM> within the non-volatile memory <NUM> to determine whether the static data stored therein has been compromised by the malware. For example the static data analyzer <NUM> can be programmed to invoke the hash function <NUM> to execute a hash on the static data at the second memory region <NUM>, and compare the hash of the static data at the second memory region <NUM> to an expected hash for the static data at the second memory region <NUM> from the expected hash database <NUM>. In some examples, the static data analyzer <NUM> can be programmed to generate the malware alert data in response to determining that the hash of the static data at the second memory region <NUM> is not equal to the expected hash for the static data at the second memory region <NUM>. Because the malware can embed unwanted instructions and/or data into the static data at the second memory region <NUM>, the hash of the static data at the second memory region <NUM> will be different from the hash of the static data at the second memory region <NUM> without the embedded unwanted instructions and/or data. The malware alert data can provide an alert that the second memory region <NUM> has been compromised by the malware. In some examples, the malware alert data can identify a location of the second memory region <NUM> within the non-volatile memory <NUM>.

In some examples, the static data analyzer <NUM> can be programmed to evaluate the retrieved static data stored at the second memory region <NUM> within the volatile memory <NUM> to determine whether the retrieved static data stored therein has been compromised by the malware in a same or similar manner as described herein with respect to the second memory region <NUM> of the non-volatile memory <NUM>. Thus, in some examples, the static data analyzer <NUM> can be programmed to invoke the hash function <NUM> to execute a hash on the retrieved static data at the second memory region <NUM>, and compare the hash of the retrieved static data at the second memory region <NUM> to an expected hash for the retrieved static data at the second memory region <NUM> from the expected hash database <NUM>. In some examples, the static data analyzer <NUM> can be programmed to generate the malware alert data in response to determining that the hash of the retrieved static data at the second memory region <NUM> is not equal to the expected hash for the retrieved static data at the second memory region <NUM>.

In some examples, the unused memory location analyzer <NUM> can be programmed to evaluate the null data stored at the third memory region <NUM> of the non-volatile memory <NUM> to determine whether the null data stored therein has been compromised by the malware. For example, the unused memory location analyzer <NUM> can be programmed to invoke the hash function <NUM> to execute a hash on the null data at the third memory region <NUM>, and compare the hash of the null data at the third memory region <NUM> to an expected hash of the null data at the third memory region <NUM> from the expected hash database <NUM>. In some examples, the unused memory location analyzer <NUM> can be programmed to generate the malware alert data in response to determining that the hash of the null data at the third memory region <NUM> is not equal to the expected hash for the null data at the third memory region <NUM>. Because the malware can embed unwanted instructions and/or data into the third memory region <NUM>, the hash of the null data at the third memory region <NUM> will be different from the hash of the null data at the third memory region <NUM> without the embedded unwanted instructions and/or data. The malware alert data can provide an alert that the third memory region <NUM> has been compromised by the malware. In some examples, the malware alert data can identify a location of the third memory region <NUM> within the non-volatile memory <NUM>.

In some examples, the unused memory location analyzer <NUM> can be programmed to evaluate the null data stored at the third memory region <NUM> within the volatile memory <NUM> to determine whether the null data stored therein has been compromised by the malware in a same or similar manner as described herein with respect to the third memory region <NUM> of the non-volatile memory <NUM>. Thus, in some examples, the unused memory location analyzer <NUM> can be programmed to invoke the hash function <NUM> to execute a hash on the null data at the third memory region <NUM>, and compare the hash of the null data at the third memory region <NUM> to an expected hash for the null data at the third memory region <NUM> from the expected hash database <NUM>. In some examples, the unused memory location analyzer <NUM> can be programmed to generate the malware alert data in response to determining that the hash of the null data at the third memory region <NUM> is not equal to the expected hash for the null data at the third memory region <NUM>.

In some examples, the malware detector module <NUM> can include a malware remover <NUM> that can be programmed to remove the embedded unwanted instructions based on respective addresses identified by the malware alert data provide by at least one of the analyzers <NUM>, <NUM>, and <NUM>. In further examples, the malware remover <NUM> can be programmed to evaluate the embedded unwanted instructions and/or data to determine a type of malware. For example, the malware remover <NUM> can be programmed to evaluate the unwanted instructions to determine an action and/or a function that the unwanted instructions are programmed to execute. The malware remover <NUM> can be programmed to communicate with a malware database <NUM> identifying different types of malware and instructions for removing a respective malware. Each malware identified in the malware database <NUM> can be associated with respective actions and/or functions that the respective malware is programmed to execute. The malware remover <NUM> can be programmed to evaluate the action and/or function of the unwanted instructions relative to the malware database <NUM> to identify the type of malware. The malware remover <NUM> can be programmed to employ the instructions for removing the identified malware to remove the malware and thus minimize an impact of the malware on the computing system.

Accordingly, by employing the malware detector module <NUM> as part of the computing system <NUM> on-board a weapon system, cyber-attacks can be identified before the malware is able to spread and/or impact a performance of the weapon system. Moreover, because the malware detector module <NUM> does not require an elevated amount of processing resources for detection and in some examples removal of the malware, the malware detector module <NUM> can be employed on the weapons system or other systems with limited amount of computing power to provide for real-time malware monitoring and removal on such resource constrained systems.

In view of the foregoing structural and functional features described above, example methods will be better appreciated with references to <FIG>. While, for purposes of simplicity of explanation, the example methods of <FIG> are shown and described as executing serially, it is to be understood and appreciated that the example method is not limited by the illustrated order, as some actions could in other examples occur in different orders, multiple times and/or concurrently from that shown and described herein.

<FIG> is an example of a method <NUM> for detecting malware. The method <NUM> can be implemented by the malware detector <NUM>, as shown in <FIG>. Thus, in some examples, references can be made to the examples of <FIG> and <FIG> in the following description of <FIG>. The method <NUM> can begin at <NUM> by accessing instruction data <NUM> (e.g., the instruction data <NUM>, as shown in <FIG>) for executing a program code (e.g., the program code <NUM>, as shown in <FIG>) at a set of memory locations (e.g., the first memory region <NUM> and/or <NUM>, as shown in <FIG>) within memory (e.g., the memory <NUM> and/or <NUM>, as shown in <FIG>). By way of example, the instruction data <NUM> stored at the set of memory locations in the example of <FIG> can be represented in hexadecimal form. For example, to access the instruction data <NUM> at <NUM>, the malware detector can be configured to employ the set of memory addresses <NUM> associated with the set of memory locations. In some examples, the set of memory locations can store other data (e.g., program data). By way of example, the instruction data <NUM> can be represented at <NUM> using Unicode character form.

In some examples, at <NUM>, executing a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on the instruction data <NUM>. At <NUM>, comparing the hash of the instruction data <NUM> to an expected hash for the instruction data <NUM> to determine whether the set of memory locations have been compromised by a malware. In some examples, the method <NUM> can proceed (shown as "YES" in <FIG>) to <NUM> based on the comparison indicating that the hash of the instruction data <NUM> equals the expected hash for the instruction data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that no malware has been detected at the set of memory locations within the memory. In some examples, the method <NUM> can proceed (shown as "NO" in <FIG>) to <NUM> based on the comparison indicating that the hash of the instruction data <NUM> does not equal the expected hash for the instruction data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that one malware has been detected at the set of memory locations within the memory. By way of example, the indication of malware can correspond to the malware alert data <NUM>, as shown in <FIG>.

<FIG> is another example of a method <NUM> for detecting malware. The method <NUM> can be implemented by the malware detector <NUM>, as shown in <FIG>. Thus, in some examples, references can be made to the examples of <FIG> and <FIG> in the following description of <FIG>. The method <NUM> can begin at <NUM> by accessing static data <NUM> (e.g., the static data <NUM>, as shown in <FIG>) for use by a program code (e.g., the program code <NUM>, as shown in <FIG>) at a set of memory locations (e.g., the second memory region <NUM> and/or <NUM>, as shown in <FIG>) within memory (e.g., the memory <NUM> and/or <NUM>, as shown in <FIG>). By way of example, the static data <NUM> stored at the set of memory locations in the example of <FIG> can be represented in hexadecimal form. For example, to access the static data <NUM> at <NUM>, the malware detector can be configured to employ the set of memory addresses <NUM> associated with the set of memory locations. In some examples, the set of memory locations can store other data (e.g., program data). By way of example, the static data <NUM> can be represented at <NUM> using Unicode character form.

At <NUM>, executing a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on the static data <NUM> at the set of memory locations within the memory. At <NUM>, comparing the hash of the static data <NUM> to an expected hash for the static data <NUM> to determine whether the set of memory locations have been compromised by a malware. In some examples, the method <NUM> can proceed (shown as "YES" in <FIG>) to <NUM> based on the comparison indicating that the hash of the static data <NUM> equals the expected hash for the static data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that no malware has been detected at the set of memory locations within the memory. In some examples, the method <NUM> can proceed (shown as "NO" in <FIG>) to <NUM> based on the comparison indicating that the hash of the static data <NUM> does not equal the expected hash for the static data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that malware has been detected at the set of memory locations within the memory. By way of example, the indication of malware at the set of memory locations within the memory can correspond to the malware alert data <NUM>, as shown in <FIG>.

<FIG> is yet another example of a method <NUM> for detecting malware. The method <NUM> can be implemented by the malware detector <NUM>, as shown in <FIG>. Thus, in some examples, references can be made to the examples of <FIG> and <FIG> in the following description of <FIG>. The method <NUM> can begin at <NUM> by accessing null data <NUM> (e.g., the null data <NUM>, as shown in <FIG>) at a set of memory locations (e.g., the third memory region <NUM> and/or <NUM>, as shown in <FIG>) within memory (e.g., the memory <NUM> and/or <NUM>, as shown in <FIG>). By way of example, the null data <NUM> stored at the set of memory locations in the example of <FIG> can be represented in hexadecimal form. For example, to access the null data <NUM> at <NUM>, the malware detector can be configured to employ the set of memory addresses <NUM> associated with the set of memory locations. By way of example, the null data <NUM> can be represented at <NUM> using Unicode character form.

At <NUM>, executing a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on the null data <NUM> at the set of memory locations within the memory. At <NUM>, comparing the hash of the null data <NUM> to an expected hash for the null data <NUM> to determine whether the set of memory locations have been compromised by a malware. In some examples, the method <NUM> can proceed (shown as "YES" in <FIG>) to <NUM> based on the comparison indicating that the hash of the null data <NUM> equals the expected hash for the null data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that no malware has been detected at the set of memory locations within the memory. In some examples, the method <NUM> can proceed (shown as "NO" in <FIG>) to <NUM> based on the comparison indicating that the hash of the null data <NUM> does not equal the expected hash for the null data <NUM>. At <NUM>, the method <NUM> can include providing an indication (e.g., to the analyzer manager <NUM>, as shown in <FIG>) that malware has been detected at the set of memory locations within the memory. By way of example, the indication of malware at the set of memory locations within the memory can correspond to the malware alert data <NUM>, as shown in <FIG>.

<FIG> is another example of a method <NUM> for detecting malware. The method <NUM> can be implemented by the malware detector <NUM>, as shown in <FIG>. Thus, in some examples, references can be made to the examples of <FIG> and <FIG> in the following description of <FIG>. The method <NUM> can begin at <NUM> by executing during a first period of time a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on instruction data (e.g., the instruction data <NUM>, as shown in <FIG>) for executing a program code (e.g., the program code <NUM>, as shown in <FIG>). The instruction data can be stored at a first set of memory locations (e.g., the first memory region <NUM> and/or <NUM>, as shown in <FIG>) with a memory (e.g., the memory <NUM> and/or <NUM>, as shown in <FIG>). At <NUM>, comparing, during the first period of time, the hash of the instruction data to an expected hash for the instruction data to determine whether the first set of memory locations have been compromised by the malware.

At <NUM>, executing, during a second period of time, a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on static data for use by the program code. The static data can be stored at a second set of memory locations (e.g., the second memory region <NUM> and/or <NUM>, as shown in <FIG>) with the memory. At <NUM>, comparing, during the second period of time, the hash of the static data to an expected hash for the static data to determine whether the second set of memory locations have been compromised by the malware. At <NUM>, executing, during a third period of time, a hash function (e.g., the hash function <NUM>, as shown in <FIG>) on null data indicative of unused memory locations within the memory. The null data can be stored at a third set of memory locations (e.g., the third memory region <NUM> and/or <NUM>, as shown in <FIG>) with the memory. At <NUM>, comparing, during the third period of time, the hash of the null data to an expected hash for the null data to determine whether the third set of memory locations have been compromised by the malware.

In some examples, at <NUM> a first malware alert identifying a first set of address locations for the first set of memory locations can be generated in response to determining that the hash of the instruction data is not equal to the expected hash for the instruction data. In some examples, at <NUM>, a second malware alert identifying a second set of address locations for the second set of memory locations can be generated in response to determining that the hash of the static data is not equal to the expected hash for the static data. In some examples, at <NUM>, a third malware alert identifying a third set of address locations for the third set of memory locations can be generated in response to determining that the hash of the null data is not equal to the expected hash for the null data.

Claim 1:
A malware detector (<NUM>) comprising:
an analyzer manager (<NUM>) configured to select one of a program code analyzer (<NUM>), a static data analyzer (<NUM>), and an unused memory location analyzer (<NUM>) for malware detection within memory of a system based on analyzer execution data, the analyzer execution data characterizing a schedule for execution of the program code, the static data, and the unused memory location analyzers during runtime of a computer program,
the program code analyzer (<NUM>) being executed, in response to being selected by the analyzer manager (<NUM>), to execute a hash function on instruction data for executing the computer program at a first set of memory locations within the memory and to compare a resultant hash of the instruction data at the first set of memory locations within the memory to an expected hash for the instruction data at the first set of memory locations within the memory to determine whether the first set of memory locations have been compromised by malware,
the static data analyzer (<NUM>) being executed, in response to being selected by the analyzer manager (<NUM>), to execute a hash function on static data for use by the computer program at a second set of memory locations within the memory and to compare a resultant hash of the static data at the second set of memory locations within the memory to an expected hash for the static data at the second set of memory locations within the memory to determine whether the second set of memory locations have been compromised by the malware, and
the unused memory location analyzer (<NUM>) being executed, in response to being selected by the analyzer manager (<NUM>), to execute a hash function on null data indicative of unused memory locations at a third set of memory locations within the memory and compare a resultant hash of the null data at the third set of memory locations within the memory to an expected hash for the null data at the third set of memory locations within the memory to determine whether the third set of memory locations have been compromised by the malware.