Hi MHL!
> Date: Thu, 21 Jun 2012 11:11:39 -0400
> Subject: Re: [Vol-users] format of UDP record in memory
> From: michael.hale@gmail.com
> To: dragonforen@hotmail.com
> CC: vol-users@volatilesystems.com
>
> Mike,
>
> On Thu, Jun 21, 2012 at 12:10 AM, Mike Lambert <dragonforen@hotmail.com> wrote:
> > I've used 1.3 and 2.0 but neither gives me any "old" UDP artifacts. I know
> > they are there because I have the pcap, so I am looking for them in memory.
>
> Volatility *can* find old artifacts (i.e. no longer in use by the OS),
> but that doesn't mean it *will* find *all* old artifacts. In other
> words, if a system sends 5 UDP packets, you may find all 5 in memory,
> or you may find none, depending on how quickly the memory dump was
> taken after the 5 UDP packets were constructed and how many
> allocations/deallocations the kernel is making during those times.
>
Yes, that is why I was looking for them. Just looking for my artifacts. <g>
Thank you! That is exactly what I was looking for! There is always a nice person there to send you the link you need! Back in the old days we called those "equates" (any old PDP11 programmers out there? PDP 11/70 RSX11 (later IAS))
> > For example I'm looking for
> > from a connection UDP 192.168.136.129:1044 to 204.13.161.100:6600
> >
> > I'm looking at
> >
> > 11 83 89 CO A8 88 81 CC 0D A1 64 04 14 19 C8
> >
> > that looks like
> >
> > UDP Unk Unk 192.168.136.129 204.13.161.100 1044 6600
> >
> > The "Unk" means I don't know what they are (the 83 (seems to be constant)
> > and 89 (changes slightly)).
> >
> > I've found this in the kernel
> > 01fb5017 [kernel:2180730903] UDP to 204.13.161.100
>
> This is a string "UDP to 204.13.161.100" which is a completely
> different artifact from the UDP structure itself. If an application
> logs outgoing UDP packets (such as a firewall or event log), then its
> very likely to stay in memory longer than the UDP structure.
The "UDP to ..." is me talking, not an artifact I was looking for. I was trying to explain why I thought the item I was looking at was an artifact.
You bring up a very good point (that it could be in an application). That was why I checked to see and found it in the kernel. I think that is the best way to double check, do you agree or should I be thinking differently?
And thanks! An artifact in a monitoring program can be very valuable because it can linger longer than in the OS! Excellent point.
>
> > This may just be a parameter block that is passed to the OS, but it does
> > show that there was such a packet sent.
> >
> > Tell me what I need to be looking for if I am in the wrong place.
>
> Also, if you're analyzing a memory dump by suspending the VM, that has
> significant impact on the lifetime and availability of network
> structures. When you suspend/pause a VMware guest, VMware tools runs a
> bat script on the guest (I think its vm-suspend.bat) which forcefully
> closes TCP/UDP and frees the IP.
This is great info! I do not use that method. I keep it real. I was analyzing a VM whose memory I had collected with win32dd.
I try not to get 'cute' and unintentionally introduce an unknown variable. Thank you very much for this reminder.
>
> Hope this helps,
> MHL
Michael, thank you! You always help and I appreciate it. I love Volatility and use it almost exclusively. I have my Cookbook open on my lap as well. <g>
I'd like to thank you for your blog too. A lot of great info. For example, thank you for the "threads" command with the -F options. Great Stuff!!
Always my best,
Mike Lambert
>
> > Thanks,
> > Mike
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users@volatilityfoundation.org
> > http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >