On Tue, 2004-10-19 at 15:53, Jerry Shenk wrote:
The real issue here is how to handle an incident. The goal is to
minimize the amount of altered data...if the system's running, we can't
eliminate altering data. So, do we want to grab processes, grab network
traffic & connections, grab current memory or, do we want to pull the
plug (and risk the bombed drive;).
Is that really the case? I can't believe there are no products to fill
that need yet.
Back in the old Commodore (or was it Atari?) days, there existed ROM
cards that could be inserted into the system and after pushing a button
on it, the system jumped into a debugger. Shouldn't it be possible to do
the same with modern PC compatible hardware?
The old M68000 CPUs had a pin labeled HLT (for HALT). Pulling that to
GND caused the CPU to "freeze". Isn't there a similar provision in
Intel/AMD CPUs?
So technically we should be able to a) halt the CPU and prevent it (and
the running OS) from executing any further instructions, and b) by
inserting a device onto the bus, inspect the systems memory.
I can envision two types of products:
1) A card is inserted which causes the CPU to stop. The card then
proceeds to dump the memory content to an attached hard drive for
off-site analysis.
2) A card is inserted which causes the CPU to stop. The card then
inspects the memory, identifies the OS, and presents some information
about it in a GUI similar to EnCase. Instead of browsing file systems
you could browse raw memory or sections of the OS (if ID'ed). Things
like process tables and perhaps even other counters might be recoverable
and presentable.
Before I drift off too far into a "whishlist", is anyone aware if these
type of "debugger cards" exist for modern PCs? If so, why wouldn't the
forensic community make use of them to answer some of the questions
surrounding live system analysis?
Regards,
Frank
signature.asc
Description: This is a digitally signed message part
