12:10 a.m.
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.
Can someone tell me the format of a UDP artifact in memory please?
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 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.
Thanks,
Mike
10:43 a.m.
Mike,
You need to tell us which operating system because the format changes
frequently. In particular, Windows Vista introduced a new unified IP
stack which is nothing like the TCP-IP implementation in previous
versions of Windows.
Regards,
George.
11:30 a.m.
Hi George,
Sorry, I'm using XP SP3
Mike
Date: Thu, 21 Jun 2012 10:43:33 -0400
From: ggarner_online(a)gmgsystemsinc.com
To: vol-users(a)volatilityfoundation.org
Subject: Re: [Vol-users] format of UDP record in memory
Mike,
You need to tell us which operating system because the format changes
frequently. In particular, Windows Vista introduced a new unified IP
stack which is nothing like the TCP-IP implementation in previous
versions of Windows.
Regards,
George.
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
11:11 a.m.
Mike,
On Thu, Jun 21, 2012 at 12:10 AM, Mike Lambert <dragonforen(a)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.
Can someone tell me the format of a UDP artifact in
memory please?
Don't forget volatility is open source. The file with UDP structures
for different OS can be viewed here:
http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/…
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.
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.
Hope this helps,
MHL
Thanks,
Mike
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
11:54 a.m.
Hi MHL!
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))
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 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.
Date: Thu, 21 Jun 2012 11:11:39 -0400
Subject: Re: [Vol-users] format of UDP record in memory
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
CC: vol-users(a)volatilityfoundation.org
Mike,
On Thu, Jun 21, 2012 at 12:10 AM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
Yes, that is why I was looking for them. Just looking for my artifacts. <g>
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.
Can someone
tell me the format of a UDP artifact in memory please?
Don't forget volatility is open source. The file with UDP structures
for different OS can be viewed here:
http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/…
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. 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.
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(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
2 p.m.
Mike,
For example I'm looking for
from a connection UDP 192.168.136.129:1044 to 204.13.161.100:6600
UDP is a stateless protocol, btw, so strictly speaking there never was
any connection to leave artifacts. It is a crude method, however, you
can try scanning memory for the remote IP address. At a minimum you
need to look for the IP encoded as an ascii and Unicode string and as an
integer value in both network and host byte order. You can also try
searching for the ROT13 encoding of the ascii and Unicode string
representations. Once you find the IP address in memory you can use
(often) use the PFN database to determine which process owns the memory
block.
Also, sometimes you can find the raw packet in a deallocated ndis common
buffer. Would have to look up how to find those, though. XP is a
distant memory for me. Trying to remember stuff from 5 or 6 years ago. :-)
Regards,
George.
3:10 p.m.
Hi George,
Yes, I search memory for all of the things you mention (except ROT13). I output offsets
with encase and give it to Volatility to tell me who's it is (that was where I used
the "UDO to 210...." label that Michael mentioned). It all works very well. I
also include the ports in binary. It is then dead easy to see the convergences.
I don't know how to find the buffer yet. However with Michael providing me with the
map of the structures, that may be the ticket.
This was more curiousity. I produced nothing with Volatility for old (mere minutes in this
case) but wanted to be suree by doing the binary searches.
I have a lot to learn. It keeps me busy.
Thanks for taking the time to respond, I appreciate all of your input.
Best,
Mike
Date: Thu, 21 Jun 2012 14:00:14 -0400
From: ggarner_online(a)gmgsystemsinc.com
To: vol-users(a)volatilityfoundation.org
Subject: Re: [Vol-users] format of UDP record in memory
Mike,
For example I'm looking for
from a connection UDP 192.168.136.129:1044 to 204.13.161.100:6600
UDP is a stateless protocol, btw, so strictly speaking there never was
any connection to leave artifacts. It is a crude method, however, you
can try scanning memory for the remote IP address. At a minimum you
need to look for the IP encoded as an ascii and Unicode string and as an
integer value in both network and host byte order. You can also try
searching for the ROT13 encoding of the ascii and Unicode string
representations. Once you find the IP address in memory you can use
(often) use the PFN database to determine which process owns the memory
block.
Also, sometimes you can find the raw packet in a deallocated ndis common
buffer. Would have to look up how to find those, though. XP is a
distant memory for me. Trying to remember stuff from 5 or 6 years ago. :-)
Regards,
George.
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
3:18 p.m.
Yeah some plugins for carving ndis stuff have been on my list of things to do for a while.
That would be a useful addition. Also ikelos started porting the packetscan plugin from
1.3 but it probably won't be ready until 2.2 (unless someone wants to pitch in and
help with it). See http://code.google.com/p/volatility/issues/detail?id=233.
MHL
Sent from my iPad
On Jun 21, 2012, at 2:00 PM, "George M. Garner J.r (online)"
<ggarner_online(a)gmgsystemsinc.com> wrote:
Mike,
For example I'm looking for
from a connection UDP 192.168.136.129:1044 to 204.13.161.100:6600
UDP is a stateless protocol, btw, so strictly speaking there never was any connection to
leave artifacts. It is a crude method, however, you can try scanning memory for the
remote IP address. At a minimum you need to look for the IP encoded as an ascii and
Unicode string and as an integer value in both network and host byte order. You can also
try searching for the ROT13 encoding of the ascii and Unicode string representations.
Once you find the IP address in memory you can use (often) use the PFN database to
determine which process owns the memory block.
Also, sometimes you can find the raw packet in a deallocated ndis common buffer. Would
have to look up how to find those, though. XP is a distant memory for me. Trying to
remember stuff from 5 or 6 years ago. :
Regards,
George.
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
4528
days inactive
4529
days old
vol-users@lists.volatilityfoundation.org
7 comments
4 participants
participants (4)
-
George M. Garner J.r (online) -
Michael -
Michael Hale Ligh
-
Mike Lambert