Re: [Vol-users] Analyzing diasassembly with little information

Thanks for the thorough replies!  I should of known part of it got paged.  That's probably a sign I need to finish reading Windows Internals. :)  This is the first piece of malware I'm analyzing and I loaded it into Olly today and could see it decrypting a PE file from the the resource section.  Pretty freaking cool!  I'll play around with Volatility again tomorrow... Thanks again for setting me straight! ________________________________ From: Michael Hale Ligh <michael.hale(a)gmail.com> To: fd ksdf <olroy123(a)yahoo.com> Cc: "vol-users(a)volatilityfoundation.org" <vol-users(a)volatilityfoundation.org> Sent: Monday, April 9, 2012 10:07 AM Subject: Re: [Vol-users] Analyzing diasassembly with little information Hello, The same thing anyone ever does with a disassembly ;-) Malfind will locate private (i.e. not backed by a file, no DLL), committed, executable memory, but interpretation of the instructions is up to a human. As Andrew said yesterday, your best bet is to find some code paths that lead to the region in question. Thread registers at the time of the memory dump may be available in _ETHREAD.Tcb.TrapFrame (see "Investigating Windows Threads with Volatility" [1]) which may help you reconstruct some state, and Carl Pulley's stack backtrace plugin [2] can give you some guidance. Regarding symbols, if the memory you're analyzing is part of a dll, exe, sys, then extract the PE with dlldump, procexedump, or moddump respectively and look at the debug section to get the PDB path which will give you symbols (or just load the extracted PE in IDA Pro and let it resolve the symbols for you). If the memory you're analyzing is *not* part of a dll, exe, sys (for example shell code or a block of injected functions) then you can't expect to have symbols anyway (though it'd be cool if attackers supplied symbols with shell code ;-)) The memory unreadable error is because 0x806f000-0x806ffff is paged to disk (i.e. not memory resident at the time the dump was acquired). Luckily, most malicious code spans more than two pages (0x2000) so don't be discouraged by one missing page. Instead, dump the whole vad region (using the vaddump command) and analyze it as a whole. What you see below is just the instructions at the start of the range 0x8070000, not the whole thing. Also if this is injected code, there's a chance its been injected into more than one process, so you might check if the missing page is available in the memory of another process. Hope it helps and good luck! MHL