4

The memorydumps I work with are from a Windows XP SP2 run inside a VirtualBox VM. I aquire the memorydumps with vboxmanage debugvm dumpguestcore --filename dump.vmem. The windows paging is disabled.

My idea is to identify executable vads that were created after a process was created by for example LoadLibrary() calls. As these vads should not correspond to any dll imported.

Therefor I recursively walk the processes / modules import directories (DIRECTORY_ENTRY_IMPORT and DIRECTORY_ENTRY_DELAY_IMPORT). Whenever I find a new dll, I mark the corresponding vad as imported and start scanning from there.

I use the volatility plugin ProcExeDump to dump the module and peFile to read the import directories from the dumped module.

Such a recusive walk looks like this:

PID: 600, services.exe

msvcrt.dll - 0x77c10000
    kernel32.dll - 0x7c800000
        ntdll.dll - 0x7c900000
advapi32.dll - 0x77dd0000
    secur32.dll - 0x77fe0000
        netapi32.dll - 0x5b860000
            ws2_32.dll - 0x71ab0000
                ws2help.dll - 0x71aa0000
                    user32.dll - 0x77d40000
                        cant parse delay import directory
rpcrt4.dll - 0x77e70000
userenv.dll - 0x769c0000
    authz.dll - 0x776c0000
        cant parse delay import directory
    ole32.dll - 0x774e0000
        gdi32.dll - 0x77f10000
    oleaut32.dll - 0x77120000
scesrv.dll - 0x758e0000
    cant parse delay import directory
umpnpmgr.dll - 0x758c0000
    winsta.dll - 0x76360000
ncobjapi.dll - 0x5f770000
    msvcp60.dll - 0x76080000

As you can see, sometimes the delay import directories can't be read although the module has the directory and the size of the directory is not 0.

In the above example I was able to identify 20 executable vads that correspond to imported modules. (20 out of a total of 38 executable vads)

Among the other 18 executable vads, there are many that belong to other dlls such as version.dll, uxtheme.dll or apphelp.dll

example:

Start: 2008285184, 0x77b40000L
Flags: CommitCharge: 1, ImageMap: 1, Protection: 7
ControlArea @8a3f4bf8 Segment e15392a0
Dereference list: Flink 00000000, Blink 00000000
NumberOfSectionReferences:          1 NumberOfPfnReferences:          12
NumberOfMappedViews:                4 NumberOfUserReferences:          5
WaitingForDeletion Event:  00000000
Control Flags: Accessed: 1, File: 1, HadUserReference: 1, Image: 1
FileObject @8a4fc660, Name: \WINDOWS\system32\apphelp.dll
First prototype PTE: e15392d8 Last contiguous PTE: fffffffc
Flags2: Inherit: 1

Any Ideas why the import directories can't be parsed? Or any other comments regarding my idea? Maybe a way to achive the same just another way...

Any help is most appreciated, thank you!

user3365
  • 197
  • 7
  • 1
    not a full answer, but FYI a delay import is purely a 'decorative' structure for the loader:
    • it's not taken into consideration by the loader
    • it's handled by extra code added by the compiler
     – Ange Dec 16 '13 at 15:26
  • Well, if my asumption that all executable vads that have a dll FileObject are related to imported modules is correct. There should be none such vad that I dont find when scanning the import and bound import directories? – user3365 Dec 16 '13 at 17:27
  • one suspicion: only the delay-load tables are failing to be parsed. Have you verified that the tool is behaving correctly? That is, do you have a confirmed example where the delay-load table is parsed correctly? Perhaps it is failing on the Attributes field, whose use and allowed values are documented incorrectly by MS's PECOFF specification, at least where MSVC files are concerned. – peter ferrie Dec 18 '13 at 19:08

0 Answers0