After quickly selling out our recent course in Reston, we have now
scheduled another training there in November:
http://volatility-labs.blogspot.com/2013/06/memory-forensics-training-resto…
This course is taught directly by Volatility developers, and provides
intense training in memory forensics for incident response, malware
analysis, and digital forensic investigation.
We already have quite a few people signed up and had to turn away
people last time, so please contact us ASAP if you are interested in
taking it.
Thanks,
Andrew (@attrc)
This post is off-topic; however, there are a lot of bright people on
this list so maybe someone will be able to help. I need to set a static
ipv4 address on an interface in WinPE4.0/WinFE4.0. For example the
following command works on Windows 8:
netsh.exe interface ip set address Ethernet static 192.168.0.5
255.255.255.0
On WinPE 4.0 I am getting an error that the interface is not found which
is odd since the interface appears in the list of interfaces. For example:
netsh.exe interface ip show interfaces
and
netsh.exe interface ip show interface Ethernet
both work as expected.
I can also add a route on the interface in WinPE, e.g.:
netsh.exe interface ip add route 192.168.0.0/24 Ethernet
works. It is just adding the static ip address that doesn't work. I
have also tried using the IF index instead of the interface name; still
no joy. Unfortunately I can't use dhcp in some applications because the
client broadcasts an announcement that I am present, which wouldn't be
prudent.
I am wondering if there isn't maybe some dependency that is missing from
my winpe installation?
Anyone have any thoughts?
Regards,
George.
Hi all,
I'm currently attempting to code up a bitmap (within an overlay) that consists of an array of 4 ulongs.
With (say) a single ulong, the following works great:
profile.merge_overlay({
'XXX': [ None, ['Flags', {'target': 'unsigned long', 'bitmap': { 'A': 0, 'B': 1, 'C': 2 }}]]
})
However, the obvious generalisation to 4 ulongs:
profile.merge_overlay({
'XXX': [ None, ['Flags', {'target': ['array', 4, ['unsigned long']], 'bitmap': { 'A': 0, 'B': 1, 'C': 2 }}]]
})
fails. Looking at the source, the profile.merge_overlay calls:
obj.Object(['array', 4, ['unsigned long']], offset=0, ..)
and this function in turn raises an exception (i.e. TypeError: unhashable type: 'list') when it calls:
vm.profile.has_type(['array', 4, ['unsigned long']])
Attempts at using obj.Array instead also flounder.
Does anyone have any hints or tips as to how best to deal with bitmaps that are arrays of bytes, ulongs or similar? Is it a case of having to extend the obj.Flags class so that such things can be handled?
Many thanks,
Carl.
I look at mostly Win7/64 systems and have always found shimcache data in memory images before. In the last several weeks only about 50% of the images I looked at had it. I'm running a 2.3 alpha build from a month or two ago (have been all this time).
While not strictly a Volatility issue, could someone explain under what circumstances the data wouldn't be available? I'm not a Windows internals expert (yet, I have part 1 and part 2 on my bookshelf, waiting...)
Thanks!
--
chort
Hi everyone,
I would like to ask you if it is possible to dump the hive file from a
memory image.
For some reason the printkey cmd does not return expected values.
In my virtualbox Windows xp sp3 image contains vboxtray.exe in the RUN key,
but I dont see it in the printkey -K
"Software\Microsoft\Windows\CurrentVersion\Run" cmd output
I am using volatility version 2.3 beta.
I want to use Windows registry recovery tool to check if it is able to get
the info I need.
Thank you
Jaro
Hello all,
First congrats on a great tool :)
I'm looking for some iso/distro to be able to do some "coldboot" testing,
and i was thinking on using LiME module.
Does anyone have done anything related to this, like a really small kernel
booting to usb, and dump the mem?
What do you guys use to do memory dumps? (on "real" systems not vm's ?)
Thanks
Thanks both of you for your help and advice. I will try to verify if the memory is allocated. I have to convert the memory image to the crash dmp.
The --base switch works very well. I overlooked it in the help.
Thanks
Jaro
Od: "Michael Hale Ligh" <michael.hale(a)gmail.com<mailto:michael.hale@gmail.com>>
Datum: po, 6. 3, 2013 16:48
Předmět: [Vol-users] DPC procedure localization
Komu: "George M. Garner Jr." <ggarner_online(a)gmgsystemsinc.com<mailto:ggarner_online@gmgsystemsinc.com>>
Kopie: "vol-users" <vol-users(a)volatilesystems.com<mailto:vol-users@volatilesystems.com>>
Thanks for the explanation George!
Jaroslav - to answer your other question "how can I dump this using the
offset 0x80013000?" you can use the moddump plugin with --base= 0x80013000.
MHL
On Mon, Jun 3, 2013 at 10:43 AM, George M. Garner Jr. <
ggarner_online(a)gmgsystemsinc.com<mailto:ggarner_online@gmgsystemsinc.com>> wrote:
> Jaroslav,
>
> Kernel timers come and go at a very high rate which leads to a significant
> number of invalid or spurious timer artifacts which result from the fact
> that the memory dump was acquired from the system while it was running.
> Not that the last two timers are signaled and the periods are not
> coherent. It is possible that the last two "timer" objects reside in
> memory that once was a kernel timer object and has since been freed and
> that some of the timer fields (e.g. the routine address) have been
> overwritten with incoherent data. Try running the !pool command on the
> last two timer addresses (0x863ead10 and 0x85e451e8) and see if that memory
> is currently allocated. (I am assuming that you either have or can convert
> your memory dump to MS crashdump format.)
>
> Regards,
>
> George.
>
>
> On 6/3/2013 9:15 AM, BRTAN Jaroslav wrote:
>
>> Hi all,
>>
>> I'd like to ask you for your help with analysis. The timers module shows
>> that there is a strange DPC at 0x8647e4e0.
>>
>>
>> Timers module output:
>>
>> Offset(V) DueTime Period(ms) Signaled Routine
>> Module
>> ---------- ------------------------ ---------- ---------- ----------
>> ------
>> 0x873097d0 0x0000002f:0x2db9d0c3 0 - 0xa7386d8e
>> arp1394.sys
>> 0x85b9a2c8 0x8000002d:0x6d7d7c8e 0 - 0x80538a98
>> ntoskrnl.exe
>> 0x8a332b20 0x0000002f:0x2ea5d991 0 - 0xb9ddef1a
>> NDIS.sys
>> 0x863ead10 0x00010014:0x863ead28 -205...072 Yes 0x8647e4e0
>> UNKNOWN
>> 0x85e451e8 0x00010014:0x85e45200 -205...072 Yes 0x8647e4e0
>> UNKNOWN
>>
>>
> ______________________________**_________________
> Vol-users mailing list
> Vol-users(a)volatilesystems.com<mailto:Vol-users@volatilesystems.com>
> http://lists.volatilesystems.**com/mailman/listinfo/vol-users<http://lists.volatilesystems.com/mailman/listinfo/vol-users>
>
The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
