What is Scapy
Scapy is a powerful interactive packet manipulation program. It is able to forge
or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and
replies, and much more. It can easily handle most classical tasks like
scanning, tracerouting, probing, unit tests, attacks or network discovery (it can replace
hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.).
It also performs
very well at a lot of other specific tasks that most other tools can't handle,
like sending invalid frames, injecting your own 802.11 frames,
combining technics (VLAN hopping+ARP cache poisoning, VOIP decoding on
WEP encrypted channel, ...), etc. See interactive tutorial and the quick demo: an interactive session (some examples may be outdated).
What makes scapy different from most other networking tools
First, with most other tools, you won't build someting the author did
not imagine. These tools have been built for a specific goal and
can't deviate much from it. For example, an ARP cache poisoning
program won't let you use double 802.1q encapsulation. Or try to find
a program that can send, say, an ICMP packet with padding (I said
padding, not payload, see?). In fact, each time you have a new need, you
have to build a new tool.
Second, they usually confuse decoding and interpreting. Machines are good
at decoding and can help human beings with that. Interpretation is reserved
to human beings. Some programs try to mimic this behaviour. For instance they
say "this port is open" instead of "I received a SYN-ACK". Sometimes they
are right. Sometimes not. It's easier for beginners, but when you
know what you're doing, you keep on trying to deduce what really happened from
the program's interpretation to make your own, which is hard because you lost
a big amount of information. And you often end up using tcpdump -xX to
decode and interpret what the tool missed.
Third, even programs which only decode do not give you all the
information they received. The network's vision they give you is the
one their author thought was sufficient. But it is not complete, and
you have a bias. For instance, do you know a tool that reports the
Scapy tries to overcome those problems. It enables you to build exactly the
packets you want. Even if I think stacking a 802.1q layer on top of TCP has no
sense, it may have some for somebody else working on some product I don't know.
Scapy has a flexible model that tries to avoid such arbitrary limits.
You're free to put any value you want in any field you want, and stack them
like you want. You're an adult after all.
In fact, it's like building a new tool each time, but instead of dealing with a hundred line C
program, you only write 2 lines of Scapy.
After a probe (scan, traceroute, etc.) Scapy always gives you the full
decoded packets from the probe, before any interpretation. That means that you
can probe once and interpret many times, ask for a traceroute and look
at the padding for instance.
Scapy runs natively on Linux, and on most Unixes with libpcap, libdnet and
their respective python wrapper (see scapy's portability page).
Scapy < 2.x needs Python 2.4 or upcomming versions.
Scapy ≥ 2.x needs Python 2.5 or upcomming versions.
Send questions, bug reports, suggestions, ideas, cool usages of Scapy, etc.
To avoid spam, you must subscribe to the mailing list to post.
Other documents on Scapy :
Scapy development uses Mercurial version control system. Scapy reference repository is at
http://hg.secdev.org/scapy/. Project management is done with Trac.
Trac works on Scapy's reference repository. It provides a freely editable wiki (please contribute!) that can reference tickets, changesets, files
from the project. It also provides a ticket management service that I use to avoid forgetting patches or bugs.
Mercurial distributed way of working enables me to provide two repositories where anybody can commit stuff: the
Scapy community repository.
- Session management
- Link layer not well managed yet
- Does not give the right source IP for routes that use interface aliases (/proc/net/route reports only master interface)
- DNS packets not reassembled exactly as the original (no compression used)
- May miss packets under heavy load
- BPF filters do not work on PPP interfaces