Re: [Crash-utility] DD image
----- Original Message -----
Hi Dave,
Crash utility support for such a raw dumpfile would be really useful
for some embedded devices.
Such device typically have no storage resource to write the dumpfile
in the supported format, but another CPU on the system can take out
the physical memory contents to a connected debugger PC. In this case,
only raw dumpfile is available since the latter CPU do not have the
knowledge of the crashed kernel.
Writing a small utility which converts a raw dump to one of the
supported format might be an idea. But it probably requires the
information from vmlinux.
So it seems natural to me that crash utility should support raw
dumpfile by itself.
Best Regard,
Takuo Koguchi
The primary requirement for the various dumpfile headers is that
they define a manner to find the location in the dumpfile of a
particular page of physical memory.
However, it sounds like this proposed dumpfile type would be a
page-for-page copy of physical memory? Perhaps there might be empty
memory holes in the file, but the file would be exactly equal in size
to the physical memory of the embedded system?
If that's true, it could be done in either of two ways:
(1) If this raw dumpfile was created such that, for example,
if the crash utility needed to read the page at physical
address 0xfffe000, it simply had to lseek() in the raw dump
to file offset 0xfffe000, then no header would be required.
A new dumpfile type and a plug-in function for pc->readmem()
would have to be created, and it should just work. But since
the raw dumpfile type would not be readily recognized during
invocation, it would have to be explicitly invoked, i.e.,
something like:
$ crash vmlinux --raw dumpfile
It's a little more involved than that, but you basically would
have to check all the places where dumpfile types are used, and:
(a) #define'ing and adding the new type to the MEMORY_SOURCES and
DUMPFILE_SOURCES #define's, and then
(b) ook for all instances where there are "if" or "switch"
statements
are made for the various dumpfile types, and add code for the new
type if necessary. It's not that hard, you can just emulate what
is done for an existing type. For example, check the code for all
instances of where the KDUMP #define and the KDUMP_DUMPFILE() macro
are used, and then do the right thing (if necessary) for the new
dumpfile type.
(2) Or as you suggest, it would be fairly simple to create a
utility that would pre-pend a simple ELF header that contained
a single PT_LOAD segment that described the whole chunk of
physical memory. That's essentially what the original NETDUMP
format does.
Dave
>
>----- Original Message -----
>> Hi ,
>>
>>
>> recently, some forensic research suggested that utilizing Crash
>> utility as independent solution to parse Linux memory dump in order
>> to
>> extract forensic artifacts. but in real forensic cases where there
>> is
>> need for minimizing the footprint on the comprised system, the
>> forensic analyst would perform only one action, which is physical
>> memory capture to minimize the footprint with dd. I just wonder if
>> there any chance that Crach utility would support dd image.
>>
>> Thanks,
>> Amer
>
>Certainly there is no support for such a raw dumpfile format.
>
>But I don't really understand what you mean by saying that the
>use of dd "would minimize the footprint"? I presume that you
>are asking whether you could do something like this on a live
>system?:
>
> $ dd if=/dev/mem of=memory-image
> $ crash vmlinux memory-image
>
>Theoretically it could be done, presuming that the read_mem()
>function in the /dev/mem driver would never fail until it reached
>the end of physical memory, i.e., would create an exact page-by-page
>copy of all physical pages from 0 to the end of physical memory.
>
>But if that's the case, and you can run crash on the system that
>you want to dump, try the "snap.so" extension module that comes
>with the crash utility source package. It creates a dumpfile
>while running on a live system, in an ELF format that crash
>understands.
>
>Dave