VIRUS BULLETIN www.virusbtn.

com

MALWARE ANALYSIS
‘HOLEY’ VIRUS, BATMAN! this virus only uses ANSI APIs. The result is that some files
cannot be opened because of the characters in their names,
Peter Ferrie and thus cannot be infected.
Microsoft, USA
The virus searches in the current directory (only), for files
whose names end in ‘.exe’. For each such file that is found,
Some might think that all of the entrypoints in Portable
the virus attempts to open it and map a view of the contents.
Executable (PE) files are known – but they would be wrong.
There is no attempt to remove the read-only attribute, so
As we saw with the W32/Deelae family [1], a table that has
files that have that attribute set cannot be infected. The virus
been overlooked for more than a decade can be redirected
registers an exception handler at this point, and then checks
to run code in an unexpected manner. Now, a table that was
if the file can be infected.
used in Windows on the Itanium platform also exists on the
x64 platform, and (surprise!) it can be misused too. The
W64/Holey virus shows us how. RELOCATION ALLOWANCE
The virus is interested in Portable Executable files for the
HAPI HAPI, JOY JOY x64 platform. Renamed DLL files are not excluded, nor
are files that are digitally signed. The subsystem value is
The virus begins by retrieving the address of ntdll.dll by
checked, but incorrectly. The check is supposed to limit
walking the InMemoryOrderModuleList list from the
the types to GUI or CUI but only the low byte is checked.
PEB_LDR_DATA structure in the Process
Thus, if a file uses a (currently non-existent) subsystem
Environment Block. This is an unusual choice – the
with a value in the high byte, then it could potentially be
InLoadOrderModuleList list is more common – but it is not
infected too. In fact, there are many common checks that
incorrect, and it is compatible with the changes that were
are missing from this virus. Perhaps it was written in a
made in Windows 7. The virus also saves the pointer to the
hurry to meet some kind of deadline. The code also lacks
current position in the list so that it can resume the parsing
some obvious optimizations, again suggesting that it was
later to find the address of kernel32.dll.
written hastily.
If the virus finds the PE header for ntdll.dll, it resolves
The virus checks the Base Relocation Table data directory
the required APIs. It uses hashes instead of names, but the
to see if the relocation table is the last section. The check
hashes are sorted alphabetically according to the strings
is very specific – it is not enough that the relocation
they represent. This means that the export table needs to
table exists within the last section, but it must be the last
be parsed only once for all of the APIs, rather than parsed
section. That is, it starts at the start of the section, and
once for each API (as is common in some other viruses).
the assumption is that the entire section is devoted to
Each API address is placed on the stack for easy access,
relocation information – which can cause a problem. The
but because stacks move downwards in memory, the API
virus checks that the value in the SizeOfRawData field
addresses end up in reverse order in memory. Interestingly,
is at least 687 bytes long. Of course, the relocation table
the virus checks that the exports really exist by limiting
could be much smaller than this, and other data might
the parsing to the number of exports in the table. This is
follow it. This data will be overwritten when the virus
probably a great situation for emulators that don’t export
infects the file.
all of the right functions – the sample will run the host
code instead of crashing – but it doesn’t benefit the virus in We do not know why the SizeOfRawData field was used
any way. instead of the value in the Size field in the data directory,
because the value in the Size field cannot be less than the
The table is terminated with a single byte whose value is
size of the relocation information, and it cannot be larger
0x2a (the ‘*’ character). This is used to allow the file mask
than the size of the section. This is because the value in
to follow immediately in the form of ‘*.exe’. We do not
the Size field is used as the input to a loop that applies the
know whether the character was chosen because of the
relocation information. It must be at least as large as the
mask, or whether the mask was placed there simply because
sum of the sizes of the relocation data structures. However,
of the chosen character.
if the value were larger than the size of the relocation
The virus retrieves the address of kernel32.dll by fetching information, then the loop would access data after the
the next entry in the list, using the pointer that was saved relocation table, and that data would be interpreted as
earlier. The same routine is used to retrieve the addresses relocation data. If the relocation type was not a valid value,
of the API functions that it requires. Despite the strong then the file would not load. If the value in the Size field
similarities with some other viruses that support Unicode, were less than the size of the relocation information, then

4 SEPTEMBER 2011
 VIRUS BULLETIN www.virusbtn.com

it would eventually become negative and the loop would YOU HAVE BEEN INTERRUPTED
parse data until it hit the end of the image and caused an
At this point the virus attempts to find the section that
exception.
contains the entrypoint by searching for the first section
which ends after the entrypoint. There are two bugs here,
one is relatively minor, however the other is fatal for the
EXCEPTIONAL BEHAVIOUR
host. The minor bug is that the virus assumes that the
The virus also requires that the file has no Exception Table. entrypoint is located within a section. It is quite possible
If this is the case, then the virus creates a RUNTIME_ to place the entrypoint in the file header. It is possible to
FUNCTION structure and places it at the start of the last place the entrypoint outside of the image, and through a
section. The RUNTIME_FUNCTION structure contains bit of trickery, cause it to ‘move’ back inside the image
the begin and end addresses of the code which will be (the details about how this is done are not relevant here).
described by the UNWIND_INFO structure, and a pointer It is possible for the file to contain no sections, but still
to that structure. The virus sets the begin address to equal have the appropriate values in the appropriate places. Of
the host entrypoint value, and the end address to one byte course, these are edge cases that are not very interesting
later than that. The UNWIND_INFO structure pointer is to consider.
set to the address immediately after the pointer, and the
However, the fatal bug relates to the section scanning.
UNWIND_INFO structure is placed directly after the
When the virus finds a section which ends after the
RUNTIME_FUNCTION structure. The UNWIND_INFO
entrypoint, it marks that section as writable and
structure exists to allow Windows to unwind the stack
attempts to fetch the byte at the relative virtual address
if an exception occurs. However, the virus does not
that correponds to the value of the entrypoint. The
need to worry about such a thing. All it has to do is set
byte is saved in the virus body, and replaced with an
the appropriate flags and store a callback pointer in the
interrupt 3 instruction. The idea here is that when the
structure. Then, when an exception occurs, the virus code
host is executed, the interrupt 3 instruction will cause
will be called.
an exception that will be handled by the callback whose
The virus makes the last section both writable and pointer is in the Exception Table. The bug is that even
executable. It sets the Exception Table data directory entry after the first such section is found (the entrypoint
to point to the start of the last section, and sets the Size section), the loop is not exited. Instead, every section after
field appropriately. The virus copies itself to the file, and the entrypoint section will also be treated as though it
zeroes some flags in the header. Of particular interest are were the entrypoint section. What happens next depends
the flags that correspond to ASLR (Address Space Layout on several conditions. The entrypoint value is converted
Randomization), NX (No eXecute) and NO_SEH (No to a physical address by adding the difference between the
Structured Exception Handling). Zeroing the ASLR flag PointerToRawData and the VirtualAddress. The addition
ensures that the image will not move in memory. This is will occur for each section after the entrypoint section,
irrelevant for the virus, though, because the virus code is usually resulting in a continually decreasing value that still
entirely position-independent. It might be a bit of left-over points within the entrypoint section. If the value becomes
code from a previous virus by the same author. Zeroing negative (for example, if the initial entrypoint value is
the NX flag enables the virus to run from a section that small, and the difference is large), then an exception will
is not marked as executable. Again, this is irrelevant occur when attempting to fetch the byte from the section.
for the virus because the virus marks its code section The exception will cause the loop to exit, and everything
as executable. However, by zeroing the NO_SEH flag, will appear to be fine – this is probably what happened
the virus enables exception handling to be called by the when the virus was tested, and is probably the reason
file. If the flag were not cleared, then Windows would the bug was not found. However, if the entrypoint value
terminate the application at the moment that an exception is large enough and if the difference is small enough
occurred. (it can even be zero, if the file alignment value matches
The virus zeroes the Base Relocation Table data directory. the section alignment value), then the value can survive
This is the only way to ensure that Windows does not several, and possibly all of the iterations of the loop,
attempt to read the relocation data. Even though there resulting in multiple bytes being replaced in the host
exists a flag that can be set in the PE header which is entrypoint section.
supposed to tell Windows that the relocation data has The bug leads to two other problems, one of which is
been removed, Windows ignores this flag in certain benign, and the other one causes the host to be damaged.
circumstances. The first problem is that when the last section is examined,

SEPTEMBER 2011 5
 VIRUS BULLETIN www.virusbtn.com

if the entrypoint RVA is larger than the size of that section,

then an exception will occur and the infection routine will
exit. This is fine because when the loop completes, an
exception is raised anyway. The second problem is that,
as noted above, the virus might alter one byte in multiple
places within the entrypoint section. If those bytes are
not all the same (or if they are, but the file alignment and
section alignment match, such that the same byte is fetched
more than once), then when the exception occurs during
execution, the original byte cannot be restored. Further,
if those bytes are data, then the host might not behave
correctly even if the bytes are all the same because the virus
will never have a chance to restore them.

TOUCH AND GO
The virus code ends with an instruction to force an
exception to occur. This is used as a common exit condition.
However, the virus does not recalculate the file checksum,
even though it might have changed as a result of infection,
and it does not restore the file’s date and timestamps,
making it very easy to see which files have been infected,
even though the file size does not change.

ANCIENT HISTORY
It’s funny, in a way, that I described a variation of this
technique at a time when Windows NT was still current.
The idea was that by changing the file format in a
particular way, an exception would be raised during
the file load. At that point, nothing in the host had been
executed. Given an Exception Table with the right layout,
it should have been possible to cause the handler to be
executed. (Try emulating that...) However, as noted above,
the Exception Table was not used by Windows until the
introduction of the Itanium platform, so fortunately the
technique was not viable.

CONCLUSION
The Exception Table hook is an interesting technique. It
allows for light entrypoint obscuring, in much the same
way as the Thread Local Storage technique did a decade
ago, and it becomes yet another place in the file that needs
to be scanned. Only time will tell if it will become as
popular.

REFERENCES
[1] Ferrie, P. Deelaed learning. Virus Bulletin,
November 2010, p.8. http://www.virusbtn.com/pdf/
magazine/2010/201011.pdf.

6 SEPTEMBER 2011