CODEWITHSUNDEEP
windowsdebuggingreverse-engineeringwindbgida
nomad
nomad

Reputation: 91

Why the DLL loaded in memory doesn't fully correspond to the original DLL file?

Please, correct me if I'm wrong anywhere...

What I want to do: I want to find a certain function inside some DLL, which is being loaded by Windows service, during remote kernel debugging via WinDBG. (WinDBG plugin in IDA + VirtualKD + VMWare VM with Windows 10 x64). I need to do it kernel mode, because I need to switch the processes and see all the memory

What I did:

  1. I found an offset to the function in IDA (unfortunately, the DLL doesn't have debug symbols).
  2. Connected to the VM in Kernel Mode.
  3. Found the process of the service by iterating over the svchost-processes (!process 0 0 svchost.exe) and looking at CommandLine field in their PEBs (C:\Windows\system32\svchost.exe -k ...).
  4. Switched to the process (.process /i <address>; g), refreshed the modules list (.reload)
  5. Found the target DLL in user modules list and got its base address.

The problem: The DLL loaded into memory doesn't fully correspond to the original DLL-file, so I can't find the function there. When I jump to the address like <dll_base_address> + <function_offset> there is nothing there and around. But I found some other functions using this method, so it looks correct. Then I tried to find the sequence of bytes belonging to the function according to the original DLL-file and also got nothing. The function uses strings, which I found in data section, but there are no xrefs to them. Looks like that function has completely disappeared...

What am I doing wrong?

P.S.: Also I dumped memory from <dll_start> to <dll_end> and compared it with the original file. Besides different jump addresses and offsets, sometimes the assembler code is completely missed...

Upvotes: 2

Views: 340

Answers (2)

nomad
nomad

Reputation: 91

It appeared, that some memory pages were paged out (moved to secondary storage). This command loads the pages from secondary storage and they appear in disassembly:

.pagein /f /p <process_address> <memory_page_address>

See for more: The DLL is partly missed in remote kernel debugging

Upvotes: 1

Thomas Weller
Thomas Weller

Reputation: 59303

It appeared that the memory pages were paged out. .pagein command did the trick

Upvotes: 1

Related Questions