SANS Digital Forensics and Incident Response Blog

Dealing with ASLR When Analyzing Malware on Windows 8.1

If you're migrating your malware lab from Windows XP, watch out for the forced ASLR feature of the operating system, especially when using Windows 8.1. ASLR is good for security, but it complicates malware analysis efforts. IDA Pro, OllyDbg, UPX and other tools could get confused, but we can get around these issues.

ASLR and Your Windows Malware Lab

Microsoft explains that in "older versions of Windows, core processes tended to be loaded into predictable memory locations upon system startup. Some exploits work by targeting memory locations known to be associated with particular processes. ASLR [Address Space Layout Randomization] randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process."

Microsoft Windows 7 and beyond appear to use ASLR by default for all processes, unless the program declares itself incompatible with this mechanism. As the result, every time you run the malicious program, you might see the same instruction being assigned different addresses. This can confuse and slow you down when using a debugger and a disassembler. Moreover, if you're examining a specimen that was protected with UPX, unpacking it (e.g., via "upx -d") could produce a file that doesn't run.

While it was possible to turn off ASLR on your lab system using Microsoft's Enhanced Mitigation Experience Toolkit and perhaps some registry keys on Windows 7, these approaches don't appear to work on Windows 8.1. Fortunately, you can tweak the PE header of an executable to disable ASLR for that file prior to analyzing it on Windows 8.1.

ASLR vs. IDA Pro and OllyDbg

A Windows executable's PE header includes the ImageBase field, which stores the virtual memory address where the executable prefers to be loaded into memory. When ASLR is enabled, the OS ignores the preferred ImageBase value.

Consider the malicious process jusched.exe running on Windows 8.1, shown on the screenshot below. You can view whether the OS enabled ASLR for it by directing Process Hacker or Process Explorer to display the ASLR column. (This malware pretended to be the legitimate Java upgrade program jusched.exe, even though the malicious file was called pepper.exe, but that is beside the point.)

ASLR is enabled

Because of ASLR, every time you run this specimen on Windows 8.1, the OS will assign to it a different virtual base address in memory.

When you load the specimen into IDA Pro, you will see the addresses that match the preferred ImageBase designated in the file's PE header:

IDA Pro honors the preferred base address

However, OllyDbg will follow Windows' lead and randomize the virtual base address. This will lead to the same instruction appearing at a different offset than the one you saw in IDA Pro:

OllyDbg loads the specimen at a different base address

This isn't a huge deal, but the mismatching addresses can slow you down, especially if you like switching between IDA Pro and OllyDbg when examining malware.

ASLR vs. UPX

Another issue with ASLR is that it can break UPX-unpacked executables. The specimen mentioned above was packed with UPX. We can unpack it using "upx -d" as shown below. (As a reminder, even though this file ran as the process jusched.exe, it was called pepper.exe on the file system.)

Unpacking the specimen using UPX

Even though UPX unpacks the file cleanly, so that it would run normally on an older OS such as Windows XP, running this file on Windows 8.1 causes the specimen to crash. OllyDbg shows that when running on Windows 8.1, the specimen attempted to reference an invalid memory address:

OllyDbg report a memory access violation

Most Windows executables run fine with ASLR, either because they use relative addresses that don't depend on a specific ImageBase value, or because their PE header includes the necessary relocation information that allows the OS to translate memory address when the executable runs. Unfortunately, our specimen appears to have used hard-coded addresses that weren't valid when the unpacked program was loaded at an unexpected base address.

Disabling ASLR on Windows 8.1

When examining malware on Windows 8.1, designate your specimen as being incompatible with ASLR to avoid the problems described above. You can do this by disabling the DynamicBase flag in the DllCharacteristics field of the file's PE header. This will direct the OS to honor the preferred ImageBase address.

A convenient way to disable the file's DynamicBase flag is to use the setdllcharacteristics tool by Didier Stevens. To clear the flag, specify the "-d" parameter to this tool prior to starting your analysis, as shown below:

Clear the DynamicBase flag using setdllcharacteristics

Now, loading this file into OllyDbg shows the specimen being loaded as the preferred base address, with the addresses matching across OllyDbg and IDA Pro.

OllyDbg honors preferred ImageBase when DynamicBase is disabled

Process Explorer shows that ASLR is no longer enabled for this malicious process:

ASLR is not enabled

Similarly, clearing the DynamicBase flag on the file produced by "upx -d", allows the unpacked version of the specimen to run without problems even on Windows 8.1.

Lenny Zeltser

Lenny Zeltser teaches malware analysis at SANS Institute and focuses on safeguarding customers' IT operations at NCR Corp. He is active on Twitter and writes a security blog.