5:35 a.m.
Hi,
Yesterday during a challenge we had to use the linux_dump_map plugin
to dump a process stack, and the documentation at
https://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_pro…
says it has the -p option to select a process.
However, as far as I can tell looking in the svn history, this plugin
never had the -p option. And it's definitely not working currently.
I've heard a confirmation that the option was working in version
2.2-rc1, so maybe it was a global option?
The reason I'm mailing this is because, if the -s is virtual memory,
would you not get possible overlap in areas? How do you know it dumped
the correct VMA? Note that every time I tried, I got the correct area.
Cheers,
Edwin
7:06 a.m.
After some more research, I think it is a bug and the attached patch
hopefully fixes it.
On 7 March 2013 11:35, Edwin Smulders <edwin.smulders(a)gmail.com> wrote:
Hi,
Yesterday during a challenge we had to use the linux_dump_map plugin
to dump a process stack, and the documentation at
https://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_pro…
says it has the -p option to select a process.
However, as far as I can tell looking in the svn history, this plugin
never had the -p option. And it's definitely not working currently.
I've heard a confirmation that the option was working in version
2.2-rc1, so maybe it was a global option?
The reason I'm mailing this is because, if the -s is virtual memory,
would you not get possible overlap in areas? How do you know it dumped
the correct VMA? Note that every time I tried, I got the correct area.
Cheers,
Edwin
11:03 a.m.
Hi Edwin,
You're right, it looks like there were a few different issues with that
plugin. I applied a patch [1] similar to yours that should make things
easier. It now accepts -p, but also takes a --dump-dir argument instead of
--outfile. You can dump all VMAs from all processes, all VMAs from a
specific process (or multiple processes with -p 1,2,3) or a specific VMA
from a specific process. The output file name includes the task ID as well
as the VMA starting address. There's a summary printed to stdout to
minimize confusion.
For example:
Task VM Start VM End Length Path
---------- ---------- ---------- ---------- ----
1 0x08048000 0x0811d000 0xd5000 dumps/task.1.0x8048000.vma
1 0x0811e000 0x08124000 0x6000 dumps/task.1.0x811e000.vma
1 0x08124000 0x08125000 0x1000 dumps/task.1.0x8124000.vma
1 0x08125000 0x081b0000 0x8b000 dumps/task.1.0x8125000.vma
1 0xb7522000 0xb752e000 0xc000 dumps/task.1.0xb7522000.vma
Can you try the patch and let me know if it works for you?
Thanks,
MHL
[1]. https://code.google.com/p/volatility/source/detail?r=3169
On Thu, Mar 7, 2013 at 7:06 AM, Edwin Smulders <edwin.smulders(a)gmail.com>wrote:
After some more research, I think it is a bug and the
attached patch
hopefully fixes it.
On 7 March 2013 11:35, Edwin Smulders <edwin.smulders(a)gmail.com> wrote:
Hi,
Yesterday during a challenge we had to use the linux_dump_map plugin
to dump a process stack, and the documentation at
https://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_pro…
says it has the -p option to select a process.
However, as far as I can tell looking in the svn history, this plugin
never had the -p option. And it's definitely not working currently.
I've heard a confirmation that the option was working in version
2.2-rc1, so maybe it was a global option?
The reason I'm mailing this is because, if the -s is virtual memory,
would you not get possible overlap in areas? How do you know it dumped
the correct VMA? Note that every time I tried, I got the correct area.
Cheers,
Edwin
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
5:24 a.m.
Hi MHL,
The whole plugin is definitely much better now, and it works. Thanks!
Cheers,
Edwin
On 7 March 2013 17:03, Michael Hale Ligh <michael.hale(a)gmail.com> wrote:
Hi Edwin,
You're right, it looks like there were a few different issues with that
plugin. I applied a patch [1] similar to yours that should make things
easier. It now accepts -p, but also takes a --dump-dir argument instead of
--outfile. You can dump all VMAs from all processes, all VMAs from a
specific process (or multiple processes with -p 1,2,3) or a specific VMA
from a specific process. The output file name includes the task ID as well
as the VMA starting address. There's a summary printed to stdout to minimize
confusion.
For example:
Task VM Start VM End Length Path
---------- ---------- ---------- ---------- ----
1 0x08048000 0x0811d000 0xd5000 dumps/task.1.0x8048000.vma
1 0x0811e000 0x08124000 0x6000 dumps/task.1.0x811e000.vma
1 0x08124000 0x08125000 0x1000 dumps/task.1.0x8124000.vma
1 0x08125000 0x081b0000 0x8b000 dumps/task.1.0x8125000.vma
1 0xb7522000 0xb752e000 0xc000 dumps/task.1.0xb7522000.vma
Can you try the patch and let me know if it works for you?
Thanks,
MHL
[1]. https://code.google.com/p/volatility/source/detail?r=3169
On Thu, Mar 7, 2013 at 7:06 AM, Edwin Smulders <edwin.smulders(a)gmail.com>
wrote:
After some more research, I think it is a bug and the attached patch
hopefully fixes it.
On 7 March 2013 11:35, Edwin Smulders <edwin.smulders(a)gmail.com> wrote:
Hi,
Yesterday during a challenge we had to use the linux_dump_map plugin
to dump a process stack, and the documentation at
https://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_pro…
says it has the -p option to select a process.
However, as far as I can tell looking in the svn history, this plugin
never had the -p option. And it's definitely not working currently.
I've heard a confirmation that the option was working in version
2.2-rc1, so maybe it was a global option?
The reason I'm mailing this is because, if the -s is virtual memory,
would you not get possible overlap in areas? How do you know it dumped
the correct VMA? Note that every time I tried, I got the correct area.
Cheers,
Edwin
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4269
days inactive
4270
days old
vol-users@lists.volatilityfoundation.org
3 comments
2 participants
participants (2)
-
Edwin Smulders -
Michael Hale Ligh