encrypted—you must either modify the encrypted data or eliminate the
encryption altogether. Neither of these options is particularly easy, so for now
you’ll just reapply the patch in memory each time you launch the program.Loading KERNEL32.DLL
You might remember that before taking this little detour to deal with that
RDTSCthread you were looking at a KERNEL32.DLLstring right in the middle
of the code. Let’s find out what is done with this string.
Immediately after the string appears in the code the program is retrieving
pointers for two NTDLL functions, one with a checksum of 1974C, and
another with the familiar 6DEF20(the checksum for NtDelayExecution).
The code first calls NtDelayExecutionand then the other function. In step-
ping into the second function in SoftICE, you see a somewhat more confusing
picture. This API isn’t just another direct call down into the kernel, but instead
it looks like this API is actually implemented in NTDLL, which means that it’s
now implemented inside your copied code. This makes it much more difficult
to determine which API this is.
The approach you’re going to take is one that I’ve already proposed earlier
in this discussion as a way to determine which API is being called through the
obfuscated interface. The idea is that when the checksum/RVA table was ini-
tialized, APIs were copied into the table in the order in which they were read
from NTDLL’s export directory. What you can do now is determine the entry
number in the checksum/RVA table once an API is found using its checksum.
This number should also be a valid index into NTDLL’s export directory and
will hopefully reveal exactly which API you’re dealing with.
To do this, you must but a breakpoint right after Defender finds this API
(remember, it’s looking for 1973Cin the table). Once your breakpoint hits you
subtract the pointer to the beginning of the table from the pointer to the cur-
rent entry, and divide the result by 8 (the size of each entry). This gives you the
API’s index in the table. You can now use DUMPBIN or a similar tool to dump
NTDLL’s export table and look for an API that has your index. In this case, the
index you get is 0x3E(for example, when I was doing this the table started at
53830000 and the entry was at 538301F0, but you already know that these
are randomly chosen addresses). A quick look at the export list for NTDLL.DLL
from DUMPBIN provides you with your answer.ordinal hint RVA name
.
.
70 3E 000161CA LdrLoadDllThe API being called is LdrLoadDll, which is the native API equivalent of
LoadLibrary. You already know which DLL is being loaded because you
saw the string earlier: KERNEL32.DLL.400 Chapter 11