rossetoecioccolato wrote:PerpetualHorizon,
If you will permit me one additional question, in your blog post you state that:
"The error messages seen below are not a concern, they are just indicators that not all areas of memory can be safely read."
How did you make the determination that the areas of physical memory that M* was unable to read did not contain pertinent evidence? Did you acquire those physical addresses by some other means and determine that the contents were not relevant? Specifically, did you look for a real mode INT 13h hook? Maybe not TDL but some other bootkits relocate their real mode IVT INT 13h hook code to one of those regions.
> I have the TDL4 filesystem if you would like to mess with it. <
Which sample did you use to infect your VM. If you contact me offline I will take a look at it. However, the code that is already unpacked in memory is really a lot more useful to me.
Rossetoecioccolato.
Rossetoecioccolato,
I did not investigate this personally although I had intended to do so. An email exchange with one of the helpful devs of Memoryze explained the matter and pointed me to a link on the Mandiant website discussing mem areas that could not be read by memorydd. I was concerned about the possibility of malware hiding from a memdump, and never did determine why win32dd didn't work, but I got what I needed and did not dig further. I am honestly not certain the best way to acquire the physical addresses that memorydd missed, but I suppose I could have ran a memory map, and dumped those sections looking for a hook, but it didn't seem important enough to explore at the time.
I did not infect a VM - I ran analysis on a bare metal box that experienced a real-world infection. I do not have the original TDL4 installer for this particular infection, but of course we could collect others.
Have a great day and thanks for the information.
PH