GB2485602A

GB2485602A - Executing a program with a smaller address size than the processor on which it is executing

Info

Publication number: GB2485602A
Application number: GB201019726A
Authority: GB
Inventors: Jarrko Turkulainen
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2010-11-22
Filing date: 2010-11-22
Publication date: 2012-05-23
Also published as: GB201019726D0

Abstract

A processor, which uses an address size of m bits, executes a program written for a processor, which uses an address size of n bits, where m>n. The processor allocates a continuous block of memory on the computer. When the program makes a memory request, the base address of the block of memory is added to the n bit address in the program to get the m bit address for the memory access. The processor then carries out the memory access using the calculated address. n may be 32 and m may be 64. The program may be suspected malware. The processor may commit memory to the program when it detects a valid access to a location, which does not already have memory committed.

Description

t V.' INTELLECTUAL ..* PROPERTY OFFICE Application No. GB 1019726.7 RTM Date:18 February 2011 The following terms are registered trademarks and should be read as such wherever they occur in this document:

AMD

Microsoft Windows NT Windows Phenom Linux Intellectual Properly Office is an operating name of the Patent Office www.ipo.gov.uk

PROCESS EMULATION

Technical Field

The present invention relates to process emulation, that is the emulation of computer processes using software. The present invention is applicable in particular, though not necessarily, to a mechanism for emulating a 32-bit application running on a 64-bit processor.

Background

Malware is short for malicious software and is used as a term to refer to any software designed to infiltrate or damage a computer system without the owner's informed consent. Malware can include computer viruses, worms, trojan horses, rootkits, adware, spyware and any other malicious and unwanted software.

Many end users make use of anti-virus software to detect and possibly remove malware. In order to detect a malware file, the anti-virus software must have some way of identifying it amongst all the other files present on a device. Typically, this requires that the anti-virus software has a database containing the "signatures" or "fingerprints" that are characteristic of individual malware program files. When the supplier of the anti-virus software identifies a new malware threat, the threat is analysed and its signature is generated. The malware is then "known" and its signature can be distributed to end users as updates to their local anti-virus software databases.

Using approaches that solely rely on signature scanning to detect malware still leaves computers vulnerable to "unknown" or "zero day" malware programs/applications that have not yet been analysed for their signature. To address this issue, in addition to scanning for malware signatures, most anti-virus applications additionally employ heuristic analysis. This approach involves the application of general rules intended to distinguish the behaviour of any malware from that of clean/legitimate programs. For example, the behaviour of all programs/applications on a PC may be monitored and if a program/application attempts to write data to an executable file, the anti-virus software can flag this as suspicious behaviour. Heuristics can be based on behaviours such as API calls, attempts to send data over the Internet, etc. Techniques are commonly used to "protect" maiware against such conventional signature and heuristic detection approaches. These can include cloaking or packing malware such that it is only visible in a detectable form during execution of the malware. For this reason, it can be desirable to execute applications (requiring scanning) in a quarantined environment such that, whilst the application data is made visible in a detectable format, there is no risk of infection and/or damage to the host computer system. Execution of applications in a quarantined environment may also be desirable as it allows the behaviour of the applications to be safely observed. For example, execution of an application that causes registry keys to be written to, or modified on, the system registry may be considered suspicious.

Safe execution of an application may be achieved using a so-called "emulator". An emulator is a software implementation of hardware and software processes, albeit one that runs on top of the primary hardware and software processes themselves.

An emulator will, for example, create a virtual system registry in a space temporarily allocated to the emulator and will write any new keys to this virtual registry. Similarly, memory read and write operations will be made to an allocated virtual memory space that is mapped to the systems real memory. The object is to avoid making any permanent changes to the key states and functions of the hardware set up as a result of the execution of the application being scanned.

Many currently available applications are written in 32 bit code, using 32 bit memory addresses. Indeed, the majority of malware is written in such 32 bit code. However, computers available today are dominated by 64 bit processor architectures. These include computers employing 64 bit AMDTM processors. Microsoft Windows NTTM includes a software component known as Windows on Windows (W0W64) that allows the running of 32 bit code on a 64 bit processor architecture. Of course, running malware using W0W64 is likely to result in infection or other damage to the host computer. This is avoided by executing the code using an emulator, sometimes referred to as a "sandbox".

Considering now the implementation of an emulator for 32 bit application code that is running on a 64 bit processor architecture, it is necessary to create a virtual block of memory that can be mapped to the address space that is available to the 32 bit application code. It will be appreciated that 32 bit addresses are capable of addressing 4Gbytes of memory. Currently available emulators make use of paging structures to achieve this mapping, effectively maintaining a table mapping each address accessed by the application to a real address. This memory mapping process can significantly slow down the emulation process as each memory reference translation can take several native instructions to execute. Of course, this problem is not restricted to emulation carried out in connection with an anti-virus scan.

Summary

It is an object of the present invention to provide for the emulation of n-bit code on an m-bit processor architecture, where m is greater than n, and which improves the speed with which a virtual memory available to the emulator can be accessed.

According to a first aspect of the present invention there is provided a method of handling memory access requests made when emulating the execution of n-bit application code on a computer system comprising an m-bit processor, where n and m are integers and m is greater than n. The method comprises allocating or reserving an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address. Then, for each n-bit memory access request made by the n-bit application code during emulated execution, the n-bit address that is the subject of the access request is added to or subtracted from the m-bit base address, and the result used as the real address for the emulated memory access request.

According to a second aspect of the present invention there is provided a method of scanning a computer system comprising an m-bit processor for the presence of malware. The method comprises identifying an application that requires scanning, the application comprising n-bit application code, where m and n are integers and m is greater than n, and then executing the application code in an emulated environment. The method of the above first aspect of the invention is used to handle memory access requests generated during the emulation. The emulated execution is monitored to determine whether the application is, or contains, malware. The integer "n' may be 32 and "m" may be is 64.

In an embodiment of the invention, the n-bit addressable memory space is not accessible to processes other than the emulation. The n-bit addressable memory space may be reserved to the emulation process, the method comprising determining that a given memory access associated with the emulation is valid and relates to a memory location not yet committed to the emulator and, in response, committing the memory location to the emulation and satisfying the request.

According to a third aspect of the present invention there is provided a computer comprising an m-bit architecture including an m-bit processor, a memory addressable by m-bit addresses, and an emulator for emulating n-bit application code, where n and m are integers and m is greater than n. The emulator comprises a memory allocator for allocating or reserving an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address, and a memory access controller configured, for each n-bit memory access request made by the n-bit application code during emulated execution, to add or subtract the n-bit address that is the subject of the access request to or from the m-bit base address, and to use the result as the real address for the emulated memory access request.

According to a fourth aspect of the present invention there is provided computer program arranged, when run on a computer system having a m-bit architecture, to cause the computer system to emulate the execution of n-bit application code, where n and m are integers and m is greater than n. The computer program in particular causes the computer system to allocate or reserve an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address, and, for each n-bit memory access request made by the n-bit application code during emulated execution, to add or subtract the n-bit address that is the subject of the access request to or from the m-bit base address, and to use the result as the real address for the emulated memory access request.

Brief Description of the Drawings

Figure 1 is a flow diagram illustrating a method of scanning applications to detect malware; and Figure 2 illustrates schematically a computer system adapted to perform the malware scanning method of Figure 1.

Detailed Description

There is a need to provide an emulator for emulating the running of 32 bit application code, where the emulator runs on a 64 bit processor computer architecture. Whilst the following discussion concerns emulation for the purpose of scanning a computer system for malware, the underlying principles of the approach described here are applicable to emulation for other purposes.

An example of a 64 bit processor is the AMD PhenomTM processor range. In order to run 32 bit application code on such 64 bit processor architectures a software component such as W0W64 (a component of the Windows NTTM operating system) is typically used. In the case of an emulator or sandbox for emulating the running of 32 bit application code on a 64 bit processor architecture (requiring as it does the conversion of 32 bit instructions and addresses into a 64 bit form), some form of mapping is required which allows memory access instructions, made by the application, to be redirected to a safe, virtual memory area. This memory area is not used by standard processes of the computer system. Moreover, the emulation process does not alter important data stored in memory locations outside of this memory area which might otherwise impact on the normal operation of the system.

It is proposed here to take advantage of the large memory typically available on 64 bit machines by allocating a full 32 bit address space to the emulator, where this space is continuous. In order to map a real 32 bit address to the allocated virtual space, it is merely necessary to add a base address of the allocated space to the 32 bit address. Consider for example the case where the allocated memory block has a base address of: Oxl00000000. Assume further that the emulator is handling the following 32 bit application instruction: MOV EAX, [EBX] ; EBX=0x401000 that is an instruction to copy the content of the 32 bit memory location EBX = 0x40 1000 to register EAX. The emulator is configured to add the value of EBX to the base address of the allocated memory block, i.e. Oxi 00000000, such that the real 64 bit address referenced inside the emulator is Oxi 00410000.

It will be appreciated that implementation of the virtual memory merely involves, for each memory access request made by the emulated application, a simple ADD operation. This typically involves only a single clock cycle to implement and as such does not significantly slow the emulation process.

Figure 1 is a flow diagram further illustrating the method of handling memory access requests presented above. The process begins at step 100. At step 200, a malware scan is initiated. This may happen automatically, e.g. as result of a scheduled scan, or may be initiated by a user or system administrator. At step 300, the scanning application reserves or allocates an n-bit (in this case 32-bit or 4GB) addressable block of memory to the emulator.

An application requiring scanning is identified at step 400. This application could be for example an application that a user is attempting to install. The scanning process is started, and at step 500 the next (in this case the first) instruction is handled by the emulator. At step 600, if the instruction does not result in a memory access request, control passes to step 900 where it is determined whether or not execution of the application is complete. If not, control passes pack to step 500. If execution of the application is complete, control is passed to step 1000 where it is determined whether or not there are more applications to scan. If not, the process ends at step 1100. If there are more applications to scan, control passes back to step 400.

If, at step 600, execution of an instruction does result in a memory access request, at step 700 an m-bit (i.e. 64-bit) memory address is generated by adding the allocated memory space base address to the n-bit address being accessed. The access request is then satisfied at step 800. Control passes once again to step 1000.

Referring now to Figure 2 illustrates schematically a computer system 1, for example a pc, server, mobile terminal (e.g. a mobile phone or smartphone), adapted to implement to scanning process described above. The computer system includes a memory 2 that is used for storing software 3 and data including code for implementing the malware scanning application. The computer system relies upon an rn-bit (64 bit) architecture including an rn-bit processor 4. When the maiware scanning application is launched, the systern provides for a rnernory allocator 5 that reserves or allocates the required n-bit (32-bit) address space to the ernulator. It further provides for a rnernory access controller 6 that perforrns the n-bit to rn-bit address translation by adding the base address (or the allocated or reserved space) to the n-bit access address.

Whilst allocating a 4Gbyte block of rnernory to a 32 bit application code emulator is manageable given the large addressable rnernory space available to a 64 bit processor architecture (16 Terrabytes), in sorne cases the allocation rnay cause problerns. These rnight be overcorne by merely reserving the space for the emulator if the operating system supports this. At least WindowsTM and LinuxTM support reserving memory areas, without actually allocating (committing) any physical memory. Reserved memory is populated as the guest address space is referenced.

To put this in other words, the emulator reserves a 4GB block of memory. When an emulated application references memory, the address will point somewhere in this block. As the memory is just reserved, it is not necessarily accessible, unless the page is committed. So when the emulator makes the memory access, it should make sure it catches the exception in case the page has not committed. In that case, the emulator determines if the memory access was valid or if it should raise a page fault to the application. If it is valid, the emulator can commit and fill the page as appropriate. This is process called "paging".

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. For example, the invention is applicable to any computer system in which the bit length (n) of the application code is less than the number of bits (m) used by the processor architecture, i.e. m > n. For example, future systems might involve a 128-bit processor architecture running 64-bit application code. It will also be appreciated that, rather than adding the address (that is the subject of the access request) to the base address of the reserved memory area, that address may be subtracted from the base address, i.e. the base address represents the topmost address of the reserved memory area.

Claims

Claims 1. A method of handling memory access requests made when emulating the execution of n-bit application code on a computer system comprising an m-bit processor, where n and m are integers and m is greater than n, the method comprising: allocating or reserving an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address; and for each n-bit memory access request made by the n-bit application code during emulated execution, adding or subtracting the n-bit address that is the subject of the access request to or from the m-bit base address, and using the result as the real address for the emulated memory access request.
2. A method of scanning a computer system comprising an m-bit processor for the presence of malware, the method comprising: identifying an application that requires scanning, the application comprising n-bit application code, where m and n are integers and m is greater than n; executing the application code in an emulated environment; using the method of claim I to handle memory access requests generated during the emulation; and monitoring the emulated execution to determine whether the application is, or contains, malware.
3. A method according to claim I or 2, where n is 32 and m is 64.
4. A method according to any one of the preceding claims, wherein said n-bit addressable memory space is not accessible to processes other than the emulation.
5. A method according to any one of the preceding claims, wherein said n-bit addressable memory space is reserved to the emulation process, the method comprising determining that a given memory access associated with the emulation is valid and relates to a memory location not yet committed to the emulator and, in response, committing the memory location to the emulation and satisfying the request.
6. A computer comprising: an m-bit architecture including an m-bit processor; a memory addressable by m-bit addresses; an emulator for emulating n-bit application code, where n and m are integers and m is greater than n, the emulator comprising a memory allocator for allocating or reserving an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address, and a memory access controller configured, for each n-bit memory access request made by the n-bit application code during emulated execution, to add or subtract the n-bit address that is the subject of the access request to or from the m-bit base address, and to use the result as the real address for the emulated memory access request.
7. A computer program arranged, when run on a computer system having a m-bit architecture, to cause the computer system to emulate the execution of n-bit application code, where n and m are integers and m is greater than n, the computer program in particular causing the computer system to: allocate or reserve an n-bit addressable memory space on the computer system to the emulation process, the addressable space being a continuous block of addressable memory having an m-bit base address; and for each n-bit memory access request made by the n-bit application code during emulated execution, to add or subtract the n-bit address that is the subject of the access request to or from the m-bit base address, and to use the result as the real address for the emulated memory access request.