scapy(1)
NAME
scapy - Interactive packet manipulation tool
SYNOPSIS
scapy [-h] [-s file]
DESCRIPTION
This manual page documents briefly the Scapy tool.
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.
PHILOSOPHY
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 SYNACK". 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.
HOW IT WORKS
Scapy uses the python interpreter as a command board. That means that
you can use directly python language (assign variables, use loops,
define functions, etc.)
The idea is simple. Scapy mainly does two things : sending packets and
receiving answers. You define a set of packets, it sends them, receives
answers, matches requests with answers and returns a list of packet
couples (request, answer) and a list of unmatched packets. This has the
big advantage over tools like nmap or hping that an answer is not
reduced to (open/closed/filtered), but is the whole packet.
On top of this can be build more high level functions, for example one
that does traceroutes and give as a result only the start TTL of the
request and the source IP of the answer. One that pings a whole network
and gives the list of machines answering. One that does a portscan and
returns a LaTeX report.
OPTIONS
Options for scapy are:
-h display help screen and exit
- -s FILE
- use FILE to save/load session values (variables, functions, intances, ...)
COMMANDS
Only the vital commands to begin are listed here for the moment.
- ls() lists supported protocol layers. If a protocol layer is given as
- parameter, lists its fields and types of fields.
- lsc() lists some user commands. If a command is given as parameter,
- its documentation is displayed.
- conf this object contains the configuration.
EXAMPLES
More verbose examples are available at
http://www.secdev.org/projects/scapy/ Just run scapy and try the following commands in the interpreter.
Test the robustness of a network stack with invalid packets:
sr(IP(dst="172.16.1.1", ihl=2, options="0x02", version=3)/ICMP())
Packet sniffing and dissection (with a bpf filter or thetereal-like
output):
a=sniff(filter="tcp port 110")
a=sniff(prn = lambda x: x.display)
Sniffed packet reemission:
a=sniff(filter="tcp port 110")
sendp(a)
Pcap file packet reemission:
sendp(rdpcap("file.cap"))
Manual TCP traceroute:
sr(IP(dst="www.google.com", ttl=(1,30))/TCP(seq=RandInt(), sport=RandShort(), dport=dport)
Protocol scan:
sr(IP(dst="172.16.1.28", proto=(1,254)))
ARP ping:
srp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst="172.16.1.1/24"))
ACK scan:
sr(IP(dst="172.16.1.28")/TCP(dport=(1,1024), flags="A"))
Passive OS fingerprinting:
sniff(prn=prnp0f)
Active OS fingerprinting:
nmap_fp("172.16.1.232")
ARP cache poisonning:
sendp(Ether(dst=tmac)/ARP(op="who-has", psrc=victim, pdst=target))
Reporting:
report_ports("192.168.2.34", (20,30))
BUGS
Does not give the right source IP for routes that use interface
aliases.
May miss packets under heavy load.
AUTHOR
Philippe Biondi <phil@secdev.org>
- This manual page was written by Alberto Gonzalez Iniesta <agi@agi.as>
and Philippe Biondi for the Debian GNU/Linux system (but may be used by
others).