Notifications
Clear all

Can't get getsids from memorydump ?

7 Posts
2 Users
0 Likes
1,311 Views
(@bastian)
Posts: 6
Active Member
Topic starter
 

Hello together,

I tried to get some informations from a memory dump to analyze it through the Volatility framework.

In this case some of the method's don't work, for example "getsids".
There is no error but the output file is empty.

The command I run is vol.exe -f c/md.mem –profile=Win7SP1x64 getsids > getsids.txt
I run it on the same machine.

Firstly it took two weeks without finishing, so I broke up, now it takes 1-2 hours to finish run, without result.

Maybe the memory dump is broken. I got the dump with Access Data FTK Imager and one time with DumpIt.

Should I try to create another memory dump with another tool, perhaps someone else have had similar problems ?

Thank you

 
Posted : 08/03/2017 12:16 am
Goovscoov
(@goovscoov)
Posts: 11
Active Member
 

You're sure that you're use the right profile?

Run plugins like imageinfo and kdgbscan

 
Posted : 11/04/2017 1:03 pm
(@bastian)
Posts: 6
Active Member
Topic starter
 

On the output of the kdbgscan and imageinfo command, there were different suggestions of profiles, I choosed the one in which I thought it's the same like the operating system I checked. So Win7SP1x64, but there were another Win7SP1x64_23418. I might try the second one or perhaps trying all suggestions ?

Volatility Foundation Volatility Framework 2.6
INFO volatility.debug Determining profile based on KDBG search…
Suggested Profile(s) Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win200
8R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_23418
AS Layer1 WindowsAMD64PagedMemory (Kernel AS)
AS Layer2 FileAddressSpace (C\md.mem)
PAE type No PAE
DTB 0x187000L
KUSER_SHARED_DATA 0xfffff78000000000L
Image date and time 2017-02-09 221109 UTC+0000
Image local date and time 2017-02-09 231109 +0100

Volatility Foundation Volatility Framework 2.6
***********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP1x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP0x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP1x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP1x64_23418
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP0x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x3aa090a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP1x64_23418
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP1x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP0x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP1x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win7SP1x64_23418
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP0x64
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

***********************************************
Instantiating KDBG using C\md.mem WinXPSP2x86 (5.1.0 32bit)
Offset (P) 0x1538c70a0
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win2008R2SP1x64_23418
PsActiveProcessHead 0x2c7bb90
PsLoadedModuleList 0x2c99e90
KernelBase 0xfffff80002a54000

 
Posted : 11/04/2017 9:48 pm
Goovscoov
(@goovscoov)
Posts: 11
Active Member
 

Oke, what I'm missing in your output is the most important.. the PsActiveProcessHead en PsLoadedModuleList counts. After the offsets they say how many processes and modules it has.

A Plugin like getsids needs pointer to the right KDBG. Some KDBG's Heads, like for example the PsActiveProcessHEad pointer (for pslist) can be invalid. The KDBG with active processes and modules are the right ones. Then you could either choose to use that profile name or use the parameter -g or –kdbg= and then the Virutal offset. Below I got some sample output where the right profile both Win10x64_14393 or Win10x64 will work using offset 0xf800e96fe500(in this situation all the same, kinda weird, Win10 and volatility is still meeeh sometimes so maby not the best example). Also notice the KPCR row. Most of the time if that has a offset you probably got the right one.
See if you can determine the right profile based on of this.


vol.py -f Scenario1_Image1.vmem kdbgscan
Volatility Foundation Volatility Framework 2.6
***********************************************
Instantiating KDBG using Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) 0xf800e96fe500
Offset (P) 0x22fe500
KdCopyDataBlock (V) 0xf800e95ddff4
Block encoded Yes
Wait never 0x19390400eed32056
Wait always 0x3bb4d41164e5800
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win10x64
Version64 0xf800e9700cf8 (Major 15, Minor 14393)
Service Pack (CmNtCSDVersion) 0
Build string (NtBuildLab) 14393.0.amd64fre.rs1_release.160
PsActiveProcessHead 0xfffff800e970d490 (73 processes)
PsLoadedModuleList 0xfffff800e9713060 (176 modules)
KernelBase 0xfffff800e940e000 (Matches MZ True)
Major (OptionalHeader) 10
Minor (OptionalHeader) 0
KPCR 0xfffff800e9750000 (CPU 0)

********************************************
Instantiating KDBG using Unnamed AS Win10x64 (6.4.9841 64bit)
Offset (V) 0xf800e96fe500
Offset (P) 0x22fe500
KdCopyDataBlock (V) 0xf800e97e69e3
Block encoded Yes
Wait never 0x3bb4d41164e5800
Wait always 0x19390400eed32056
KDBG owner tag check False
Profile suggestion (KDBGHeader) Win10x64
Service Pack (CmNtCSDVersion) -
Build string (NtBuildLab) -
PsActiveProcessHead 0xc8b2f2de12d3cab5 (0 processes)
PsLoadedModuleList 0xc8b2f64ed1d0cab5 (0 modules)
KernelBase 0xc8b2320e52d1cab5 (Matches MZ False)
Major (OptionalHeader) -
Minor (OptionalHeader) -

***********************************************
Instantiating KDBG using Unnamed AS Win10x64_14393 (6.4.14393 64bit)
Offset (V) 0xf800e96fe500
Offset (P) 0x22fe500
KdCopyDataBlock (V) 0xf800e95ddff4
Block encoded Yes
Wait never 0x19390400eed32056
Wait always 0x3bb4d41164e5800
KDBG owner tag check True
Profile suggestion (KDBGHeader) Win10x64_14393
Version64 0xf800e9700cf8 (Major 15, Minor 14393)
Service Pack (CmNtCSDVersion) 0
Build string (NtBuildLab) 14393.0.amd64fre.rs1_release.160
PsActiveProcessHead 0xfffff800e970d490 (73 processes)
PsLoadedModuleList 0xfffff800e9713060 (176 modules)
KernelBase 0xfffff800e940e000 (Matches MZ True)
Major (OptionalHeader) 10
Minor (OptionalHeader) 0
KPCR 0xfffff800e9750000 (CPU 0)

 
Posted : 12/04/2017 12:55 am
(@bastian)
Posts: 6
Active Member
Topic starter
 

Thank you.

I tested it against three memory dumps (same system) from three different memory imaging tools.

It seems the output of kdbgscan is the same as above.

I have to make further tests.

How do you captured the memory dump ?

Thanks a lot

 
Posted : 16/04/2017 7:26 pm
Goovscoov
(@goovscoov)
Posts: 11
Active Member
 

Depends on the situation.

In my example above I had a VM which I suspended, Vmware creates a .vmem file (which is your memory dump) of your VM when you suspend it.

On a (Windows)live system I would use tools with the minimal fingerprint hazard.
Tools Like DumpIt for example.
https://blog.comae.io/your-favorite-memory-toolkit-is-back-f97072d33d5c

 
Posted : 18/04/2017 11:05 am
(@bastian)
Posts: 6
Active Member
Topic starter
 

Hello,

It's not a vm.

I will try to use dumpit again, with internet connection and anti virus disabled, hope it gets some clues.

Now I run kpcrscan on the other memory dumps …

Thanks a lot

 
Posted : 26/04/2017 1:48 am
Share: