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 padding ?
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 Project

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.


Related projects

Help, documentation


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 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.


Ongoing developments

  • IPv6
  • Session management
  • Bluetooth

Known bugs

  • 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 

Credit To

error: Content is protected !!