Crash Dump Analysis Patterns (Part 75)
CARE: Crash Analysis Report Environment
DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.
Twitter @ DumpAnalysis You can now follow portal and blog news at DumpAnalysis on Twitter
LinkedIn Group Dr. Watson Enthusiasts All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)
2010 (0x7DA) - The Year of Dump Analysis 2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade
Sometimes we look for modules that were loaded and unloaded at some time. lm command lists unloaded modules but some of them could be mapped to address space without using runtime loader. The latter case is common for drm-type protection tools, rootkits, malware or crimeware which can influence a process execution. In such cases we can hope that they still remain in virtual memory and search for them. WinDbg .imgscan command greatly helps in identifying MZ/PE module headers. The following example just illustrates this command without implying that the found module did any harm:
0:000> .imgscan
MZ at 000d0000, prot 00000002, type 01000000 - size 6000
Name: usrxcptn.dll
MZ at 00350000, prot 00000002, type 01000000 - size 9b000
Name: ADVAPI32.dll
MZ at 00400000, prot 00000002, type 01000000 - size 23000
Name: javaw.exe
MZ at 01df0000, prot 00000002, type 01000000 - size 8b000
Name: OLEAUT32.dll
MZ at 01e80000, prot 00000002, type 01000000 - size 52000
Name: SHLWAPI.dll
[…]
We don’t see usrxcptn in either loaded or unloaded module lists:
0:002> lm
start end module name
00350000 003eb000 advapi32
00400000 00423000 javaw
01df0000 01e7b000 oleaut32
01e80000 01ed2000 shlwapi
[...]
Unloaded modules:
This is why I call this pattern Hidden Module. We can use Unknown Component pattern to see the module resources if present in memory:
0:002> !dh 000d0000
[...]
SECTION HEADER #4
.rsrc name
418 virtual size
4000 virtual address
600 size of raw data
1600 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
(no align specified)
Read Only
[...]
0:002> dc 000d0000+4000 L418
[…]
000d4140 […] n…z.)…F.i.l.
000d4150 […] e.D.e.s.c.r.i.p.
000d4160 […] t.i.o.n…..U.s.
000d4170 […] e.r. .D.u.m.p. .
000d4180 […] U.s.e.r. .M.o.d.
000d4190 […] e. .E.x.c.e.p.t.
000d41a0 […] i.o.n. .D.i.s.p.
000d41b0 […] a.t.c.h.e.r…..
0:002> du 000d416C
000d416c "User Dump User Mode Exception Di"
000d41ac "spatcher"
This component seems to be loaded or mapped only if userdump package was fully installed where usrxcptn.dll is a part of its redistribution. Although from the memory dump comment we also see that the dump was taken manually using command line userdump.exe we see that the full userdump package was additionally installed which was probably not necessary (see Correcting Microsoft article about userdump.exe):
Loading Dump File [javaw.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'Userdump generated complete user-mode minidump with Standalone function on COMPUTER-NAME'
- Dmitry Vostokov @ DumpAnalysis.org -
_1125.png)
Coming Soon:
Debugging Notebook: Essential Concepts, WinDbg Commands and Tools
Crash Dump Analysis for System Administrators and Support Engineers
New Magazines:
Debugged! MZ/PE: MagaZine for/from Practicing Engineers
New Books:
Memory Dump Analysis Anthology, Volume 3
First Fault Software Problem Solving: A Guide for Engineers, Managers and Users
x64 Windows Debugging: Practical Foundations
Also available:
Windows Debugging: Practical Foundations
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
August 8th, 2008 at 1:57 pm
Every once in a while someone will ask how to execute code in a PE image without having to use the OS loader. For ex, someone will ask how to read a DLL from a socket and then execute it (without saving to disk and then calling LoadLibrary).
This post implies that it can be done and it *is* done with usrxcptn.dll (”it” referring to not using the OS loader).
Is usrxcptn.dll a Microsoft DLL? If so, do they have an alternative to the OS loader?
thanks,
Marc
August 8th, 2008 at 4:13 pm
I’ve just checked that this DLL is present in address space only if we add the application to Process Dumper applet in Control Panel. Process Dumper applet is installed when we do full installation of userdump package. Actually I added notepad.exe there and open it under WinDbg with loader snaps enabled in gflags.exe and I don’t see this DLL in loader traces.
The alternative to OS loader is widely used. You can just read the file into memory and jump to its code (of course after changing page protection and some other stuff). You can also map the file from the disk into virtual memory and in this case OS will load entire file contents for you.
usrxcptn.dll is a Microsoft DLL - you can find it in their userdump package.
August 8th, 2008 at 5:57 pm
Did you notice if usrxcptn.dll was loaded at its preferred address? Otherwise manual fixups of global addresses within the module would have to be done (the OS loader takes care of this for you). Unless of course they know the code to execute doesn’t reference any globals.
Marc
August 10th, 2008 at 11:27 am
[…] - Hidden Module […]
August 12th, 2008 at 10:02 am
No it wasn’t loaded at its preferred address which is in PE header specified as:
0000000000400000 image base