RE: Re:Re:Re:Re:Read physical memory

Rats, why has this thread become fragmented into a dozen different threads
all with varying numbers of RE: up front?

The biggest problem I can see with forensics avoiding any kind of doubt is
one of time and space. Time because it’s almost guaranteed that your
forensics software will NEVER be co-existent with your suspected malware at
the time the malware is doing its mischief. More than likely to get the
machine from the perps apartment to the forensic lab, power had to be
toggled and that is going to mean a reboot. Sure if it’s a laptop just make
sure the battery is up to snuff, but if it’s a desktop or server you’ve got
to figure out how to plug it into a UPS without interrupting the power which
is going to cause a reboot.

So … since SneakyPeek.exe from the Miami Dade PD will only be in memory
once the target machine has been transported in time and space to the
forensics lab, with more than likely an interruption in power, how is it
proposed to reconstruct the target machine with the same memory loading and
structure as existed in the machine at the time the perp performed their
evil deeds? Were I the perp, and thinking ahead, I’d at least have a flash
drive in my pocket that would be used to load the EvilDeeds.exe, with an
auto-purge-and-securely-reformat-flash-drive connected to F13.

Finally … given that again the perp is thinking ahead, and they are using
an HDD/SSD with full disk encryption, have enabled it, and given they
absolutely refuse to let go of the password, any type of post-mortem
forensics analysis has an extremely tough nut to crack since now you cannot
even get to the dump or pagefile. The best you can do without that password
is either a REALLY GOOD guess, or the various “cracker” software out there,
which again means corrupting memory with your tools.

Not an easy thing to do, and the really funny part is that the harder WE try
to make it difficult for the bad guys, the more difficult WE make it for the
good guys to prove the bad guys are really bad.

Gary G. Little
H (952) 223-1349
C (952) 454-4629

-----Original Message-----
[] On Behalf Of Pavel A.
Sent: Tuesday, January 12, 2010 5:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Re:Read pysical memory

“James Harper” wrote in message
>> Note that the recommended approach, should you absolutely require an
> all-
>> processors corral barrier, is to use KeIpiGenericCall. Attempting to
> “roll
>> your own” with DPCs is fraught with subtle and difficult-to-catch (or
> debug)
>> deadlocks (consider the scenario of multiple callers attempting to
> enter N
>> distinct “home-brewed” processor corral barriers simultaneously
> without
>> coordination).
> KeIpiGenericCall
> Versions: Available on Microsoft Windows Server 2003 and later operating
> systems.
>> That being said, what the prior poster asked for is certainly not a
>> recommended course of action.
> I don’t think anyone disagrees with that :slight_smile:
> It’s an interesting problem though… and I think that in this case no
> matter what you did there would always be reasonable doubt involved -
> I’d certainly hate for someone to be convicted on the basis of the
> outcome of such a thing!
> James

Days are nearing when law will require to have something like AMT or other
“big brother eye”
built into our machines ?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at

Information from ESET Smart Security, version of virus signature
database 4763 (20100112)

The message was checked by ESET Smart Security.

Information from ESET Smart Security, version of virus signature
database 4763 (20100112)

The message was checked by ESET Smart Security.