Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

How to analyze the full dump memory file of a process

Interesting low-level stuff, operating system related issues, packer/vx acrobatics, drivers and non-newbie programming in general, including win32 assembly and whatever else.
Locked
akovid
Junior Member
Posts: 9
Joined: Sun Aug 11, 2013 8:31 pm

How to analyze the full dump memory file of a process

Post by akovid »

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
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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: Select all


	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
Junior Member
Posts: 9
Joined: Sun Aug 11, 2013 8:31 pm

Post by akovid »

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
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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 ... dumps.html
http://computer.forensikblog.de/en/2006 ... cture.html
akovid
Junior Member
Posts: 9
Joined: Sun Aug 11, 2013 8:31 pm

Post by akovid »

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. :thinking: :thinking:
[ATTACH]2792[/ATTACH]
Attachments
procdump_of_a_process.PNG
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

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: Select all



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
Junior Member
Posts: 9
Joined: Sun Aug 11, 2013 8:31 pm

Post by akovid »

:) :) ok
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

you can hope to see all these HEADER Signatures

Code: Select all


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
Junior Member
Posts: 9
Joined: Sun Aug 11, 2013 8:31 pm

Post by akovid »

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
Locked