I think I figured it out! The NFS layers are based on RPC layers. Since RPC doesn't know which port it should be using, it doesn't bind to any ports by default, so there's no way for TCP to go to RPC. So I did bind_layers(TCP, RPC, sport=2049) and bind_layers(TCP, RPC, dport=2049) and now it appears to be working!
Thanks for your patience!
@0xKate I'm noticing that there is no do_dissect() in https://github.com/secdev/scapy/blob/master/scapy/contrib/nfs.py nor in https://github.com/secdev/scapy/blob/master/scapy/contrib/oncrpc.py. Does that mean that these modules cannot dissect their respective protocols? (i.e., they can only build them?)
Yes you are on the right track, what you have should be working. do_dissect() is pretty low level, all you needed is the RPC + transport bindings, and to either import the contrib directly
from scapy.contrib import nfs which causes all its bindings to execute, or run load_contrib('nfs') which does the same.from scapy.contrib.nfs import ACCESS_Call
from scapy.contrib.oncrpc import RPC
from scapy.layers.inet import UDP
from scapy.main import load_contrib
from scapy.packet import bind_layers
from scapy.sendrecv import sniff
if __name__ == '__main__':
load_contrib('nfs')
bind_layers(UDP, RPC, sport=2049)
bind_layers(UDP, RPC, dport=2049)
pkts = sniff(offline="nfsv3.pcap")
for packet in pkts:
if ACCESS_Call in packet:
print(packet.show())
sniff_filter = "tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and dst port 443"
sniff(filter=sniff_filter, prn=self._packet_callback, store=0)
sniff(filter=sniff_filter, prn=self._packet_callback, store=0)
Hi, on hypervisors Virtual Machines (e.g. qemu) are usually connected to Virtual Bridges (e.g. Linux Bridge or OVS bridge) through tap devices.
When I try to inject Ethernet frame into tap device with sendp(..., iface=vnet0) the frame goes to the VM but not to the Bridge.
Has anyone figured out how to send such frames with scapy to the Bridge instead? Basically the goal would be that scapy would allow to imitate VM.
No it's not possible, you can't sniff a socket used by something else without root. (You can of course read any socket with Scapy but it will consume packets, which isn't what you're asking for)
Does anyone know?
I found a way to capture on remote interfaces. For anyone interested in it:
from scapy import *
def live_capture(*args):
iface_list = [['-i', iface] for iface in args]
dumpcap_args = ['dumpcap'] + [arg for sublist in iface_list for arg in sublist] + ['-w', '-']
dumpcap = subprocess.Popen(args=dumpcap_args, stdout=subprocess.PIPE)
capture = sniff(offline=dumpcap.stdout, prn=lambda pkt: pkt.show(), store=0)
return capture
# pass your device names
live_capture('rpcap://[192.168.0.100]:2002/wl1', 'rpcap://[192.168.0.101]:2002/wl1')
Hi! I went through some docs and some code and it seems that docs are not about latest release (2.4.5) but more like about current repository state. There some functions and classes from docs are absent in release but present in current repository. Was this done intended or is it a bug of documentation, that those structures got into 2.4.5-docs?
You are absolutely correct, the "latest" (default) doc relates to the current repo. You can find the "stable" = released doc over https://scapy.readthedocs.io/en/stable/
How can we write packets sniffed with AsyncSniffer to a pcap file without using prn?
Okay, I just achieved this by applying the same thing used in sniff method to my AsyncSniffer object:
from scapy.utils import wrpcap
from scapy.compat import cast
from scapy.plist import PacketList
def write_async(capture):
capture = cast(PacketList, capture.results)
wrpcap('capture.pcap', capture)
Hello all,
The other day I was working on WEP encryption and decryption with scapy and I came across what I consider a bug in 2.4.5.
A Python3 example:
import binascii
import pyDot11
from rc4 import rc4
from scapy.all import *
keyText = '0123456789'
pkts = rdpcap('../PCAPs/ICMPs/wep_pings.pcap')
pkt = pkts[0]
iVal = pkt[Dot11WEP].iv.decode('latin1')
seed = pyDot11.wepCrypto.seedGen(iVal, keyText).decode('latin1')
stream = rc4(pkt.wepdata.decode('latin1'), iVal+ seed) A Python2 example:
```
Without going into it detailed again let me ask. Is there a reason that hexstr() works differently in Python3 than it did in Python2?
In [60]: hexstr(stream, onlyhex = 1)
Out[60]: 'C2 AA C2 AA 03 00 00 00 08 00 45 00 00 54 00 00 40 00 40 01 C3 B0 3B C3 80 C2 A8 64 C2 88 C3 80 C2 A8 64 C2 94 08 00 C2 9D 65 C3 87 06 00 00 C2 9C C3 99 C3 B6 C2 B9 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'
With some modifications:
newStream = []
newStream.append(" ".join(map(lambda stream:"%02x"%ord(stream), stream)))
newStream = " ".join(newStream)
In [65]: newStream
Out[65]: 'aa aa 03 00 00 00 08 00 45 00 00 54 00 00 40 00 40 01 f0 3b c0 a8 64 88 c0 a8 64 94 08 00 9d 65 c7 06 00 00 9c d9 f6 b9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'
the object newStream is the expected output. Thanks for any assistance.
It's not clear how it's working differently on Python 2 and 3 when reading your examples :/?
hexstr() is adding C2 to the start of it, twice.
It will handle Open, WEP or WPA; each with their own trick aside from Open for pure injection.
The stream obj ^^ debugging took me some time as I kept following the math for RC4 and couldn't wrap my head around the diffs for 2v3; I had "assumed" hexstr() was the same as I had no reason to think otherwise as far as the bytes, their accuracy and order go.
For the PCAPs in question:
https://github.com/stryngs/pyDot11
https://github.com/stryngs/pyDot11
There is also now a question of Dot11FCS being missing in a unique and interesting way for ICMP these days vs when I took the PCAP of the wep traffic from years back.
As those bytes don't change it must therefore be the "scapy interpretation".
I'd like to know what are the exact parameters passed to tshatk/tcpdump. How can I do that?
10 replies
stryngs (stryngs):
hexstr works fine as long as you pass it bytes in both cases. I can't reproduce your issue
@infern0d:matrix.org The string in question that converts incorrectly when using hexstr() is:
'\xaa\xaa\x03\x00\x00\x00\x08\x00E\x00\x00T\x00\x00@\x00@\x01\xf0;\xc0\xa8d\x88\xc0\xa8d\x94\x08\x00\x9de\xc7\x06\x00\x00\x9c\xd9\xf6\xb9\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Python2 style:
hexstr(stream, onlyhex = 1)
Out[4]: 'aa aa 03 00 00 00 08 00 45 00 00 54 00 00 40 00 40 01 f0 3b c0 a8 64 88 c0 a8 64 94 08 00 9d 65 c7 06 00 00 9c d9 f6 b9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'
Python3 style:
hexstr(x, onlyhex = 1)
Out[8]: 'C2 AA C2 AA 03 00 00 00 08 00 45 00 00 54 00 00 40 00 40 01 C3 B0 3B C3 80 C2 A8 64 C2 88 C3 80 C2 A8 64 C2 94 08 00 C2 9D 65 C3 87 06 00 00 C2 9C C3 99 C3 B6 C2 B9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'
Bytes are not used. I'm simply showing a diff between the method Python2 vs Python3.