PDA

View Full Version : How to analyze the full dump memory file of a process

akovid
August 11th, 2013, 20:36
I have used process explorer to dump a process memory.Also, I am using winhex to analyze the full dump file of a process. But when I use ReadProcessMemory function to read some value, the offset of a particular value differ from the offset of the dump file. I want to know why the offsets of a particular value are different. For example, the offset of MZ in dump file is 0x000CCBDB while I have to pass 0x00400000 offset in ReadProcessMemory function in order to read the same MZ value. Could anyone please explain why is this happening.
blabberer
August 12th, 2013, 01:29
dump format is semi / UN Documented
to read dump file you would need to use dbgeng functions

it knows how to read the streams inside dump file look up documentation for IdebugAdvanced2 gAdvanced2->Request ();

Code:




	if (( status = g_Advanced2->Request(



		DEBUG_REQUEST_READ_USER_MINIDUMP_STREAM,



		&InBuffer,



		sizeof(InBuffer),



		OutBuffer,



		OutBufferSize,



		&OutSize



		) ) != S_OK ) {


the dbgeng also knows where to map certain MZ (you will find Several MZ in the dump file corresponding to the dlls (modules ) that were loaded when the full dump was taken.

when you are using ReadProcessmemory you are required to provide the virtual address

so the main module if it was mapped at 0x400000 you would be requred to provide it
and the next time if aslr (address space layout randomization) was effective the module might have been mapped at 0x10000000
and for a live readprocessmemory session you have to provide 0x1000000 not 0x400000
akovid
August 12th, 2013, 11:20
Thanks a lot blabberer. Your explanation is just great..
I have one doubt regarding the full memory dump i.e whether the memory dump offsets are the virtual address offsets?
blabberer
August 12th, 2013, 12:56
Quote:

whether the memory dump offsets are the virtual address offsets?


a dump file doesn't have any concepts of virtual relative or absolute anything

it is a collection of streams

the header will have a pointer to the description of each type of stream

a module stream might contain (use dbgeng / dbghelp functions to access) list of modules
a xyz data stream might contain pointers to the location of xyz data
a thread stream might contains pointers to location / definition / context / ...... of the threads

you can fopen("foo.dump","rb" to open the dump and fseek() , ftell() fread() around yourself if you know how to traverse the streams

see some links on the file format header

http://computer.forensikblog.de/en/2008/02/64bit-crash-dumps.html
http://computer.forensikblog.de/en/2006/03/dmp-file-structure.html
akovid
August 12th, 2013, 18:51
Thanks Blabberer for such a nice explanation. One thing I want to point out that my dump file with .dmp extension is showing entirely different signature i.e the file signature starts with MDMP . I have taken full dump from procdump.
2792
blabberer
August 12th, 2013, 19:25
do not quote unnecessarily quote only selected parts if it is required absolutely
use reply to thread instead of reply with quote

yes it can have HDMP too iirc

like i said it is undocumented
PAGEDUMP PAGEDU64 etc are Signatures of page.sys that was forensically retrieved out of crashed but un rebooted machine
MDMP can be visual studio dump
iirc HDMP is from windbg .dump /ma command

it is undocumented so it can have anything who knows it can have BILL ATE MY DUMP too in some exotic os
Code:






F:\windbg>strings *.dll | grep -i dmp

F:\windbg\dbgeng.dll: .dmp

F:\windbg\dbgeng.dll: PAGE.DMP

F:\windbg\dbgeng.dll: VDMProcessException

F:\windbg\dbgeng.dll: .dmp

F:\windbg\dbgeng.dll: .mdmp

F:\windbg\dbgeng.dll: .hdmp

F:\windbg\dbgeng.dll: .kdmp

F:\windbg\dbgeng.dll: SDMPt

F:\windbg\dbgeng.dll: SDMPt

F:\windbg\dbgeng.dll: 9MDMPu

F:\windbg\dbgeng.dll: MDMP

F:\windbg\dbgeng.dll: hMDMP

F:\windbg\dbghelp.dll: MDMP

F:\windbg\dbghelp.dll: hMDMP

F:\windbg\dbghelp.dll: 8MDMPu

F:\windbg\sos.dll: Unable to enumerate any modules in the DMP file!

F:\windbg\sos.dll:        <CustomActions1> !cce System.Configuration.ConfigurationException 1; j ($t1 = 1) '.dump /ma /u c:\dumps\mydump.dmp' ; ''  </CustomActions1>



F:\windbg>
akovid
August 12th, 2013, 19:31
ok
blabberer
August 12th, 2013, 20:23
you can hope to see all these HEADER Signatures

Code:




User-defined comments

Address        Disassembly                               Comment

00417E38       CMP     DWORD PTR DS:[EDX], 45474150      PAGEDUMP

00418838       CMP     DWORD PTR DS:[EDX], 45474150      PAGEDU64

0041A198       CMP     DWORD PTR DS:[EDX], 45474150      PAGEDUMP

0041B148       CMP     DWORD PTR DS:[EDX], 45474150      PAGEDU64

0041C138       CMP     DWORD PTR DS:[EDX], 45474150      PAGEDUMP

0041CD58       CMP     DWORD PTR DS:[EDX], 45474150      pageDU64

0041E9D5       CMP     DWORD PTR DS:[EDX], 52455355      USERDUMP

0041FF15       CMP     DWORD PTR DS:[EDX], 52455355      USERDU64

00423284       CMP     DWORD PTR DS:[ECX], 504D444D      mdmp

00428F06       CMP     EAX, DWORD PTR DS:[EDX+EE8]       cedx,ceds,cedc
akovid
August 13th, 2013, 10:31
Yeah blabberer. Actually I got confused with executable file format. Because PE file format have a consistent MZ value, so I thought that even in memory dump there will be consistent format. But after reading post number 6, I got to know that file signature of dump file totally depends on which file the dump has been taken, e.g page.sys file, and from which environment dump has been collected i.e visual studio.
Thanks blabberer