Hello,
I'm using Antergos with the 4.6.4-1 kernel and after dumping my computer's
memory using lime worked without any problems, I went on creating a profile
for my system according to the instructions on
https://github.com/volatilityfoundation/volatility/wiki/Linux#using-the-pro…,
while creating the system.map using "cp /proc/kallsyms
/boot/System.map-4.6.4-1" (because there is no system.map in ArchLinux, as
mentioned on https://github.com/volatilityfoundation/profiles/issues/13)
Unfortunately I experience the same problem as described in the last link,
since volatility gives an error message about this profile saying "***
Failed to import volatility.plugins.overlays.linux.linux (ValueError: too
many values to unpack)".
On the issue thread linked above someone gives the following answer:
"Old issue, but could still be interesting.
This is most likely due to kallsyms giving additional information on
certain lines ([serio] or [kvm] for example), and Volatility on the other
hand only expecting three space separated values:
(str_addr, symbol_type, symbol) = line.strip().split()
That's why before using the output of the kallsyms proc file to build a
profile, some lines must be checked to fit the expected format."
Now this answer doesn't really help me to solve the issue and create a
working profile for my system. Does someone has any idea how I could
proceed in order to do so? As far as I know, nobody was ever able to build
a profile working for Arch, so I think this would be really helpful for
many people.
I uploaded the profile created by myself and the files I used for doing so
on GoogleDrive, in case someone might even be able to create a profile
using those files:
https://drive.google.com/open?id=0B62Y5Qk_rdbWbWlDZ21VUEVrZGc
Many thanks in advance and kind regards
David
Hello everyone,
I apologize if this is not correctly described, but I have been trying to read Para-virtualized (PV) core dump files from a Xen Hypervisor. Now, I have managed to read the core dump when the VM is in HVM mode and read pfn values of a Ubuntu system with this external GitHub project (address space from Xenelf.py file): https://github.com/banne01/xen-core-velocity (after modifying line 126 to show elf_hdr instead of elf64_hdr to solve a weird error message).
However, I cannot seem to figure out how the p2m values are properly read from a PV SUSE Linux Enterprise Server VM. There is a pfn value and a gmfn value in the p2m array of values which I cannot seem to read and interpret properly even if I specifically tell volatility to focus on just the pfn values. In addition, Volatility succeeds in instancing the address space for the SLES coredump but it still errors out after all the other address spaces have been exhausted.
If anyone has any feedback or ways to point me in the right direction, could you let me know?
Thanks, and best regards.
Michael Seborowski
We wanted to send a quick update before heading to Vegas.
If you will be around Black Hat during the pre-conference trainings
and/or briefings, and want to meet up then let us know. Jamie and I will
be around during the pre-conf trainings and then the whole team will be
around for the briefings.
Also, if you are headed to DFRWS, then be sure to check out Dr. Golden's
talk on Analyzing Objective-C malware through memory forensics. This is
some work that we did which will be headed to core Volatility soon after.
And finally - we have upcoming trainings in Amsterdam and Reston that
are quickly filling. If you wish to attend then please contact us ASAP
in order to reserve a seat:
http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n
--
Thanks,
Andrew (@attrc)
Hi Kim,
In this case, its not the overlays. I can tell because details for the
two processes you /do/ see from psscan are all okay. If a bad overlay
was the issue, your results would be all or nothing.
Cheers - I may follow up with you off-list to offer a little other advice.
Thanks,
Michael
On 7/25/16 11:40 AM, Kim Palechek wrote:
> I don’t have access to the machine but I’m sure our Forensics guys do as they were the ones who retrieved the image for us. I’ll discuss with Steve on what he wants to do or if he wants to acquire another image.
>
> Thank you so much for getting back to me so quickly and for your help! I wasn’t sure if it was another issue with the overlays and x64 machines.
>
>
>
>
> Kim Palechek, CISSP, CEH
> IT Security Operations Specialist, (Information Security, Risk and Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com
>
> The absence of evidence is not the evidence of absence.
>
> On 7/25/16, 11:15 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
>
> Hi Kim,
>
> Yes, unfortunately we're only able to enumerate 1 process in the linked
> list. This typically happens when the acquisition tool fails to acquire
> one or more pages of memory containing the necessary puzzle pieces (or
> "links"). In some cases, if its a minor smearing issue, you can still
> salvage some data by using psscan, which does a brute force scan of the
> entire memory dump for processes (even if they aren't linked). However,
> I noticed your psscan results only had 2 entries. This means the
> acquisition tool failed to acquire a whole lot more than just a couple
> pages. In the past, we've seen that happen quite a bit with DumpIt, FTK
> Imager, and Memoryze.
>
> Do you still have access to the suspect machine by any chance?
>
> Thanks,
> Michael
>
> On 7/25/16 11:07 AM, Kim Palechek wrote:
> > Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition.
> >
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win7SP1x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win7SP0x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win2008R2SP1x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> > **************************************************
> > Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> > Offset (V) : 0xf80001dfa110
> > Offset (P) : 0x1dfa110
> > KDBG owner tag check : True
> > Profile suggestion (KDBGHeader): Win2008R2SP0x64
> > Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> > Service Pack (CmNtCSDVersion) : 1
> > Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> > PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> > PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> > KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> > Major (OptionalHeader) : 6
> > Minor (OptionalHeader) : 1
> > KPCR : 0xfffff80001dfbd00 (CPU 0)
> >
> >
> >
> >
> >
> >
> > Kim Palechek, CISSP, CEH
> > IT Security Operations Specialist, (Information Security, Risk and Compliance)
> > 3M Information Technology
> > 3M Center, Bldg, 0224-04-E-21
> > Phone: 736-6526
> > kspalechek(a)mmm.com
> >
> > The absence of evidence is not the evidence of absence.
> >
> > On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
> >
> > Hi Kim,
> >
> > Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
> > results?
> >
> > Also, do you know what tool was used for acquisition? My gut feeling is
> > this is probably related to a bad capture, but I'll wait on the kdbgscan
> > results to tell for sure.
> >
> > Thanks,
> > Michael
> >
> > On 7/25/16 7:42 AM, Kim Palechek wrote:
> > > I need some assistance with an issue that I recently came across. I am
> > > trying to run volatility plugins against the image Win2008R2SP1x64 and
> > > it doesn’t seem to be providing complete information. Below are a few
> > > examples. Any ideas on the ‘lack of information’?
> > >
> > >
> > >
> > >
> > >
> > > $ *vol.py pstree*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Name Pid PPid
> > > Thds Hnds Time
> > >
> > > -------------------------------------------------- ------ ------ ------
> > > ------ ----
> > >
> > > 0xfffffa8024e15040: 0 0 0
> > > ------ 1970-01-01 00:00:00 UTC+0000
> > >
> > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > $ *vol.py psscan*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Offset(P) Name PID PPID PDB
> > > Time created Time exited
> > >
> > > ------------------ ---------------- ------ ------ ------------------
> > > ------------------------------ ------------------------------
> > >
> > > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> > > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
> > >
> > > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> > > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
> > >
> > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > >
> > >
> > > $ *vol.py pslist*
> > >
> > > Volatility Foundation Volatility Framework 2.5
> > >
> > > Offset(V) Name PID PPID Thds Hnds
> > > Sess Wow64 Start Exit
> > >
> > > ------------------ -------------------- ------ ------ ------ --------
> > > ------ ------ ------------------------------ ------------------------------
> > >
> > > 0xfffffa8024e15040 0 0 0 --------
> > > ------ 0
> > >
> > >
> > >
> > >
> > >
> > > */Kim Palechek, CISSP, CEH
> > > /*IT Security Operations Specialist, (Information Security, Risk and
> > > Compliance)
> > > 3M Information Technology
> > > 3M Center, Bldg, 0224-04-E-21
> > > Phone: 736-6526
> > > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
> > >
> > >
> > >
> > > The absence of evidence is not the evidence of absence.
> > >
> >
> > 3M security scanners have not detected any malicious content in this message.
> >
> > To report this email as SPAM, please forward it to spam(a)websense.com
> >
>
> 3M security scanners have not detected any malicious content in this message.
>
> To report this email as SPAM, please forward it to spam(a)websense.com
>
Hi Kim,
Yes, unfortunately we're only able to enumerate 1 process in the linked
list. This typically happens when the acquisition tool fails to acquire
one or more pages of memory containing the necessary puzzle pieces (or
"links"). In some cases, if its a minor smearing issue, you can still
salvage some data by using psscan, which does a brute force scan of the
entire memory dump for processes (even if they aren't linked). However,
I noticed your psscan results only had 2 entries. This means the
acquisition tool failed to acquire a whole lot more than just a couple
pages. In the past, we've seen that happen quite a bit with DumpIt, FTK
Imager, and Memoryze.
Do you still have access to the suspect machine by any chance?
Thanks,
Michael
On 7/25/16 11:07 AM, Kim Palechek wrote:
> Thank you so much for getting back so quickly. Below are the results of the kdbgscan. Encase is the tool used for acquisition.
>
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win7SP1x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win7SP0x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win2008R2SP1x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
> **************************************************
> Instantiating KDBG using: Kernel AS Win2008R2SP1x64 (6.1.7601 64bit)
> Offset (V) : 0xf80001dfa110
> Offset (P) : 0x1dfa110
> KDBG owner tag check : True
> Profile suggestion (KDBGHeader): Win2008R2SP0x64
> Version64 : 0xf80001dfa0e8 (Major: 15, Minor: 7601)
> Service Pack (CmNtCSDVersion) : 1
> Build string (NtBuildLab) : 7601.23418.amd64fre.win7sp1_ldr.
> PsActiveProcessHead : 0xfffff80001e31420 (1 processes)
> PsLoadedModuleList : 0xfffff80001e4f730 (52 modules)
> KernelBase : 0xfffff80001c0d000 (Matches MZ: True)
> Major (OptionalHeader) : 6
> Minor (OptionalHeader) : 1
> KPCR : 0xfffff80001dfbd00 (CPU 0)
>
>
>
>
>
>
> Kim Palechek, CISSP, CEH
> IT Security Operations Specialist, (Information Security, Risk and Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com
>
> The absence of evidence is not the evidence of absence.
>
> On 7/25/16, 10:53 AM, "Michael Ligh" <michael.ligh(a)mnin.org> wrote:
>
> Hi Kim,
>
> Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
> results?
>
> Also, do you know what tool was used for acquisition? My gut feeling is
> this is probably related to a bad capture, but I'll wait on the kdbgscan
> results to tell for sure.
>
> Thanks,
> Michael
>
> On 7/25/16 7:42 AM, Kim Palechek wrote:
> > I need some assistance with an issue that I recently came across. I am
> > trying to run volatility plugins against the image Win2008R2SP1x64 and
> > it doesn’t seem to be providing complete information. Below are a few
> > examples. Any ideas on the ‘lack of information’?
> >
> >
> >
> >
> >
> > $ *vol.py pstree*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Name Pid PPid
> > Thds Hnds Time
> >
> > -------------------------------------------------- ------ ------ ------
> > ------ ----
> >
> > 0xfffffa8024e15040: 0 0 0
> > ------ 1970-01-01 00:00:00 UTC+0000
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > $ *vol.py psscan*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Offset(P) Name PID PPID PDB
> > Time created Time exited
> >
> > ------------------ ---------------- ------ ------ ------------------
> > ------------------------------ ------------------------------
> >
> > 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> > 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
> >
> > 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> > 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> >
> > $ *vol.py pslist*
> >
> > Volatility Foundation Volatility Framework 2.5
> >
> > Offset(V) Name PID PPID Thds Hnds
> > Sess Wow64 Start Exit
> >
> > ------------------ -------------------- ------ ------ ------ --------
> > ------ ------ ------------------------------ ------------------------------
> >
> > 0xfffffa8024e15040 0 0 0 --------
> > ------ 0
> >
> >
> >
> >
> >
> > */Kim Palechek, CISSP, CEH
> > /*IT Security Operations Specialist, (Information Security, Risk and
> > Compliance)
> > 3M Information Technology
> > 3M Center, Bldg, 0224-04-E-21
> > Phone: 736-6526
> > kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
> >
> >
> >
> > The absence of evidence is not the evidence of absence.
> >
>
> 3M security scanners have not detected any malicious content in this message.
>
> To report this email as SPAM, please forward it to spam(a)websense.com
>
Hi Kim,
Could you run kdbgscan --profile=Win2008R2SP1x64 on it and paste the
results?
Also, do you know what tool was used for acquisition? My gut feeling is
this is probably related to a bad capture, but I'll wait on the kdbgscan
results to tell for sure.
Thanks,
Michael
On 7/25/16 7:42 AM, Kim Palechek wrote:
> I need some assistance with an issue that I recently came across. I am
> trying to run volatility plugins against the image Win2008R2SP1x64 and
> it doesn’t seem to be providing complete information. Below are a few
> examples. Any ideas on the ‘lack of information’?
>
>
>
>
>
> $ *vol.py pstree*
>
> Volatility Foundation Volatility Framework 2.5
>
> Name Pid PPid
> Thds Hnds Time
>
> -------------------------------------------------- ------ ------ ------
> ------ ----
>
> 0xfffffa8024e15040: 0 0 0
> ------ 1970-01-01 00:00:00 UTC+0000
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> $ *vol.py psscan*
>
> Volatility Foundation Volatility Framework 2.5
>
> Offset(P) Name PID PPID PDB
> Time created Time exited
>
> ------------------ ---------------- ------ ------ ------------------
> ------------------------------ ------------------------------
>
> 0x00000000023551b0 conhost.exe 13692 372 0x0000000058bbe000
> 2016-07-18 18:05:03 UTC+0000 2016-07-18 18:06:09 UTC+0000
>
> 0x000000000235b060 WmiPrvSE.exe 4540 636 0x00000000b4803000
> 2016-07-18 18:06:51 UTC+0000 2016-07-18 18:08:23 UTC+0000
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> $ *vol.py pslist*
>
> Volatility Foundation Volatility Framework 2.5
>
> Offset(V) Name PID PPID Thds Hnds
> Sess Wow64 Start Exit
>
> ------------------ -------------------- ------ ------ ------ --------
> ------ ------ ------------------------------ ------------------------------
>
> 0xfffffa8024e15040 0 0 0 --------
> ------ 0
>
>
>
>
>
> */Kim Palechek, CISSP, CEH
> /*IT Security Operations Specialist, (Information Security, Risk and
> Compliance)
> 3M Information Technology
> 3M Center, Bldg, 0224-04-E-21
> Phone: 736-6526
> kspalechek(a)mmm.com <mailto:kspalechek@mmm.com>
>
>
>
> The absence of evidence is not the evidence of absence.
>
Hello all,
I am analyzing a memory dump and looking at execution in a period of known
bad activity, and have been able to gather quite a bit of information using
volatility. For some reason though, shimcache and psscan return no results,
although all the other plugins I've run (and volshell) have worked fine. I
find it hard to believe that psscan for one can find no _EPROCESS
structures, so I'm not sure what's happening. Also, in the results from the
timeliner, I have several entries with blank shimcache entries like
"macb,---------------,0,0,0,"[SHIMCACHE] "" during times I can correlate
with shimcache entries on disk, so I know something is just not being
picked up.
Any ideas on why shimcache/psscan would produce no results? I'm not sure
about the best way to track down the reason.
Thanks!
Erika
On Donnerstag, 23. Juni 2016, 13:49:58 wrote Klaus Möller:
> Hi,
>
> I've a problem with an image from a Microsoft Surface tablet.
> I've verified that the OS is Windows 10 Pro 64Bit,
After a few more hours, here's the "output" from netscan:
$ vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem
--kdbg=0xf8033ca31a14 netscan
Volatility Foundation Volatility Framework 2.5
Offset(P) Proto Local Address Foreign Address State Pid
Owner Created
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
0xe0008817c4c0 UDPv4 0.0.0.0:0 *:* 980
?j? 2016-06-15 08:13:14 CEST+0200
0xe0008817c4c0 UDPv6 :::0 *:* 980
?j? 2016-06-15 08:13:14 CEST+0200
0xe00088d67c90 UDPv6 ::1:16528 *:* 1168
??q? 2016-06-15 14:19:21 CEST+0200
0xe00089d8f330 UDPv4 0.0.0.0:0 *:* 980
?j? 2016-06-16 12:32:29 CEST+0200
0xe00089d8f330 UDPv6 :::0 *:* 980
?j? 2016-06-16 12:32:29 CEST+0200
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
? 2016-06-06 18:03:41 CEST+0200 *:* 512
?
same problems here: the command takes hours to complete and the output
strings are garbled.
Best regards,
Klaus Möller, DFN-CERT
--
Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team)
Phone: +49 40 808077-555, Fax: +49 40 808077-556
DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de
Hi,
I've a problem with an image from a Microsoft Surface tablet.
I've verified that the OS is Windows 10 Pro 64Bit, and "imageinfo" confirms
that:
Suggested Profile(s) : Win10x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/srv/evidence/memdump.mem)
PAE type : No PAE
DTB : 0x1ab000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2016-06-16 12:52:11 CEST+0200
Image local date and time : 2016-06-16 12:52:11 +0200
However, all comands take hours to complete, imageinfo took about an hour,
kdbgscan was closer to 10 hours (I let it run through the night).
$ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence//memdump.mem kdbgscan
Volatility Foundation Volatility Framework 2.5
**************************************************
Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) : 0xf8033cb38a60
Offset (P) : 0x268d38a60
KdCopyDataBlock (V) : 0xf8033c9965d0
Block encoded : Yes
Wait never : 0x1d323b0baac9580
Wait always : 0xf0e3591e003a646a
KDBG owner tag check : False
Profile suggestion (KDBGHeader): Win10x64
Service Pack (CmNtCSDVersion) : -
Build string (NtBuildLab) : -
PsActiveProcessHead : 0xb276fbddbd63c845 (0 processes)
PsLoadedModuleList : 0xf249d7ddbd63c805 (0 modules)
KernelBase : 0xfe52e3ddbd63c885 (Matches MZ: False)
Major (OptionalHeader) : -
Minor (OptionalHeader) : -
**************************************************
Instantiating KDBG using: Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) : 0xf8033cb38a60
Offset (P) : 0x268d38a60
KdCopyDataBlock (V) : 0xf8033ca31a14
Block encoded : Yes
Wait never : 0xf0e3591e003a646a
Wait always : 0x1d323b0baac9580
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win10x64
Version64 : 0xf8033cb38dc0 (Major: 15, Minor: 10586)
Service Pack (CmNtCSDVersion) : 0
Build string (NtBuildLab) : 10586.306.amd64fre.th2_release_s
PsActiveProcessHead : 0xfffff8033cb4d160 (91 processes)
PsLoadedModuleList : 0xfffff8033cb52cd0 (202 modules)
KernelBase : 0xfffff8033c874000 (Matches MZ: True)
Major (OptionalHeader) : 10
Minor (OptionalHeader) : 0
KPCR : 0xfffff8033cb91000 (CPU 0)
KPCR : 0xffffd001cc54a000 (CPU 1)
KPCR : 0xffffd001cc5c9000 (CPU 2)
KPCR : 0xffffd001cc648000 (CPU 3)
I think the later part is the right one, but when I run pslist with the value
for
KdCopyDataBlock, I get something like this, using other options/values simply
gives
empty output.
$ ./vol.py --tz=CET --profile=Win10x64 -f /srv/evidence/memdump.mem
--kdbg=0xf8033ca31a14 psscan
Volatility Foundation Volatility Framework 2.5
Offset(P) Name PID PPID PDB Time
created Time exited
------------------ ---------------- ------ ------ ------------------
------------------------------ ------------------------------
0x0000c001edeb7bce 42...2 23...8 0x6b76ffffffd80000
5914-08-12 10:20:02 CET+0100
0x0000c001eed47b6e o 42...2 57...7 0x2b30fffffff00000
9767-04-28 16:32:54 CET+0100
0x0000e00087491680 4 0 0x00000000001ab000
2016-06-06 18:03:31 CEST+0200
0x0000e0008765d7c0 0?? 3600 3524 0x000000017ccc3000 2016-06-06
18:03:44 CEST+0200
0x0000e000876657c0 ??e? 3608 3600 0x000000017ccf8000
2016-06-06 18:03:44 CEST+0200
0x0000e00087f73080 7200 4812 0x00000001cbc8e000
2016-06-07 23:07:21 CEST+0200
0x0000e000897597c0 ??s? 372 4 0x0000000250219000
2016-06-06 18:03:31 CEST+0200
0x0000e0008a27f7c0 6012 5208 0x0000000200ad7000
2016-06-06 18:13:22 CEST+0200
0x0000e0008a2c45c0 ?;? 6088 700 0x00000001f4eeb000
2016-06-06 18:10:22 CEST+0200
0x0000e0008a3067c0 4260 6572 0x00000001edf60000
2016-06-06 23:16:37 CEST+0200
0x0000e0008cbc67c0 P??? 2564 700 0x0000000173299000
2016-06-06 18:03:41 CEST+0200
0x0000e0008cf997c0 ??|? 2780 700 0x000000013a0e0000
2016-06-06 18:03:41 CEST+0200
I can't say wether the addresses and pids (the first two ones look bad) are
correct, but the process name field surely does not look good. Any ideas?
Best regards,
Klaus Möller, DFN-CERT
--
Dipl. Inform. Klaus Moeller (Consulting Analysis Training Team)
Phone: +49 40 808077-555, Fax: +49 40 808077-556
DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737
Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Wir sind auf der it-sa: 18.-20.10.2016 http://www.it-sa.de
Has anyone encountered DEST records in index.dat files? I looked at the
source code and docs of open source tools that parse index.dat/MSHIST
files and I don't see any reference to DEST records...
I ask as I was digging around a memory sample that I generated to look
at IE records, and saw this:
0x04517313 a7 c2 cf 11 bf f4 44 45 53 54 00 00 16 00 08 00
......DEST......
0x04517323 66 63 03 00 00 00 da 00 68 63 28 00 01 00 82 00
fc......hc(.....
0x04517333 00 00 c2 c5 41 6e 03 c7 d1 01 c2 cd 17 57 2d c7
....An.......W-.
0x04517343 d1 01 01 00 00 00 00 00 00 00 00 00 00 00 3a 00
..............:.
0x04517353 32 00 30 00 31 00 36 00 30 00 36 00 31 00 35 00
2.0.1.6.0.6.1.5.
0x04517363 32 00 30 00 31 00 36 00 30 00 36 00 31 00 36 00
2.0.1.6.0.6.1.6.
0x04517373 3a 00 20 00 56 00 61 00 41 00 41 00 41 00 40 00
:...S.a.l.t.r.@.
0x04517383 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 77 00
h.t.t.p.:././.w.
0x04517393 77 00 77 00 2e 00 6e 00 62 00 63 00 2e 00 63 00
w.w...n.b.c...c.
0x045173a3 6f 00 6d 00 2f 00 00 00 4e 00 42 00 43 00 20 00
o.m./...N.B.C...
0x045173b3 54 00 56 00 20 00 4e 00 65 00 74 00 77 00 6f 00
T.V...N.e.t.w.o.
0x045173c3 72 00 6b 00 20 00 2d 00 20 00 53 00 68 00 6f 00
r.k...-...S.h.o.
0x045173d3 77 00 73 00 2c 00 20 00 45 00 70 00 69 00 73 00
w.s.,...E.p.i.s.
0x045173e3 6f 00 64 00 65 00 73 00 2c 00 20 00 53 00 63 00
o.d.e.s.,...S.c.
0x045173f3 68 00 65 00 64 00 75 00 6c 00 65 00 00 00 00 00
h.e.d.u.l.e.....
The strings are in unicode, but you can see the DEST marker followed by
binary timestamps, followed by the traditional hist format of
DATEDATE:machine@URL ....
If DEST records don't appear on disk, then maybe they are a memory-only
data structure? I would like to convert carving for these into a
Volatility plugin, but I want to make sure I understand any prior work
on them first.
--
Thanks,
Andrew (@attrc)
