Pig (which can be understood as
generator) is a
Linux packet crafting tool.
You can use
Pig to test your
IPS among other stuff.
Pig brings a bunch of well-known attack signatures ready to be used and you can expand this collection
with more specific things according to your requirements.
Until now it is possible to create
IPv4 signatures with transport layer based on
You can also create signatures based on
ARP protocol, besides building up the packet since its
How to clone this repo?
It is pretty simple:
someones@err..InTheWolf:~/src# git clone https://github.com/rafael-santiago/pig pig someones@err..InTheWolf:~/src# cd pig someones@err..InTheWolf:~/src/pig# git submodule update --init
How to build it?
You need to use the
Hefesto to build
pig. After following
the steps to put
Hefesto working on your system. Move to the
pig sub-directory named as
src and run
the following command:
After this command you should find the
pig binary under the path
src/bin. You can use the binary relatively from
src/bin or install it.
If for some reason you are having build troubles you should try to read some remarks present in
How to install it?
For installing you need to be inside the
src sub-directory and call:
someones@err..InTheWolf:~/src/pig/src# hefesto --install
For uninstalling, being inside the
src sub-directory you should call:
someones@err..InTheWolf:~/src/pig/src# hefesto --uninstall
The pigsty files
Pigsty files are plain text files where you can define a set of packet signatures. There is a specific syntax to be
followed. Look out an example of a pigsty file:
[ signature = "Hello", ip.version = 4, ip.ihl = 5, ip.tos = 0, ip.src = 18.104.22.168, ip.dst = 22.214.171.124, ip.protocol = 17, udp.dst = 1008, udp.src = 32000, udp.payload = "Hello!!" ]
Basically, all signature data must goes between square brackets:
Inside this area the piece of information is supplied by the scheme
field = data.
If you have some experience with Computer Networks is sure that the majority of fields listed on
have strong meaning for you. You must use these fields to create your further signatures.
Table 1: The
pig signature fields.
|Field||Stands for||Protocol||Data type||Sample definition|
||The signature name||-||string||
||Ethernet Dest. MAC||Ethernet||MAC||
||Ethernet Source MAC||Ethernet||MAC||
||Internet Header Len||IP||number||
||Type of service||IP||number||
||Time to live||IP||number||
||Source address||IP||ip address||
||Dest. address||IP||ip address||
||IP raw payload||IP||string||
||TCP reserv. field||TCP||number||
||TCP urg. flag||TCP||bit||
||TCP ack. flag||TCP||bit||
||TCP psh. flag||TCP||bit||
||TCP rst. flag||TCP||bit||
||TCP syn. flag||TCP||bit||
||TCP fin. flag||TCP||bit||
||TCP window size||TCP||number||
||ARP hardware type||ARP||number||
||ARP protocol type||ARP||number||
||ARP hardware length||ARP||number||
||ARP operation code||ARP||number||
||ARP src hw address||ARP||MAC||
||ARP src proto addr||ARP||ip address||
||ARP dst hw address||ARP||MAC||
||ARP dst proto addr||ARP||ip address||
When creating a signature you do not need specify all data. If you specify only the most relevant packet parts
the remaining parts will be filled up with default values. The
checksums are always recalculated.
Tip: take a look in sub-directory
pigsty. You will find lots of signature files and you will see that is
pretty simple define new ones.
Specifying IP addresses geographically
Yes, it is possible. In order to use this feature you just need to specify the values listed on
ip adddress typed fields.
Table 2: IPs by geographic area.
|Value to use||Stands for|
||IP addresses from North America|
||IP addresses from South America|
||IP addresses from Asia|
||IP addresses from Europe|
Specifying my own addresses
You should in any
ip address typed field use
user-defined-ip as value. Note that you need to use the
command line option
--targets in this case. See section Using pig for more information.
Contribute sending more packet signatures
If you create
pigsty files that you judge be relevant beyond your own environment open a pull request in order
to include these useful files here. Thank you in advance!
Pig usage is very straightforward being necessary to supply four basic options which are:
Do you want to know more about each option, huh?... So let's go:
- The option
--signaturesreceives a list of file paths to
- The option
--gatewayis where you specify your gateway address. Be aware that
piggenerates or at least try to generate the
ethernet framestoo. Due to it the gateway address is rather important in order to correctly compose the
- The option
--net-maskfor routing issues must receive your network mask.
- The option
--lo-ifaceis the place where you should inform the name of the local network interface you will use to "drain out" the generated packets.
- The option
--no-gatewayindicates that any packet will send outside the network.
Supposing that we want to generate
DDos based traffic:
someones@err..InTheWolf:~# pig --signatures=pigsty/ddos.pigsty\ > --gateway=10.0.2.2\ > --net-mask=255.255.255.0 --lo-iface=eth0
Now we want to messing up with everything:
someones@err..InTheWolf:~# pig --signatures=pigsty/ddos.pigsty,pigsty/attackresponses.pigsty,\ > pigsty/badtraffic.pigsty,pigsty/backdoors.pigsty\ > --gateway=10.0.2.2 --net-mask=255.255.255.0 --lo-iface=eth0
Defining timeouts between the signature sendings
For it use the option
--targets option. You can specify a list based on exact IPs, IP masks and
someones@err..InTheWolf:~# pig --signatures=pigsty/local-mess.pigsty\ > --targets=126.96.36.199,192.30.70.*,188.8.131.52/9\ > --gateway=10.0.2.2\ > --net-mask=255.255.255.0\ > --lo-iface=eth0
Not using the gateway
This is useful when the loaded signatures will not send data outside the current network. In order to flag it you need to use
--no-gateway. When the
--no-gateway option is used you do not need to specify the gateway's address
because the packets will not flow outside the current segment. As a result to inform the network mask becomes irrelevant too.
someones@err..InTheWolf:~# pig --signatures=pigsty/local_traffic.pigsty --no-gateway --lo-iface=eth2
In the sample above the ethernet frame will not be a pig's responsibility anymore. For this reason
pig will not complain
about the lack of
--no-gateway option is rather handy in cases that you need to generate
ARP traffic. Take a look in this another
document explaining how to perform ARP spoofing with pig.
Sending only one signature and going back
Maybe you need to send only one signature and so return to the caller in order to check what happened after. This kind of
requirement is common when you use this application as support for
system tests or
unit tests. So, if you need
to do this you should try to use the option
someones@err..InTheWolf:~# pig --signature=pigsty/syn-scan.pigsty --targets=127.0.0.1 --single-test\ > --gateway=10.0.2.2 --net-mask=255.255.255.0 --lo-iface=eth0
After running this command
pig will select only one signature from the file
syn-scan.pigsty and try to send it and then exit.
If some error has occurred during the process
pig will exit with
exit-code equals to
pig will exit
exit-code equals to
Specifying the pigsty traverse mode
pig's operation mode is about an endless
loop which spits tons of packets into the network respecting a
previous defined timeout.
You can define how
pig traverses the loaded packets for sending them using the option
--loop=<mode>. Until now
the modes are two:
random (the default) and
sequential mode will re-iterate the signatures when it hits the end of the loaded packet signatures list.
Sub-tasks are useful minor tasks related with packet crafting which are shipped into
pig for helping you on
your crafting session. These task can be acessed using the option
By the fact of practically being sub-programs, the sub-tasks have their own idiosyncrasies and due to it
the details about them follows in their own manual. Take a look at the
Table 3 for following up to it.
Table 3: The
|Sub-task||What does it perform?||Manual|
||Imports packet from a PCAP file into a pigsty file||
||Executes pig on interactive mode||
From the Ethernet frame to the topmost layer...
Until now you can build up packets based on
TCP in their transport layer. You can also build
However, you can still build up packets starting from the
Ethernet frame. The nice thing about it is the possibility
of virtually building up anything above the
For instance, even
pig until now, does not offering support for cooked
IPv6 building up, you can still build
it up using a raw
Ethernet based pigsty. Look:
[ eth.hwdst = "5C:AC:4C:AA:F5:B5", eth.hwsrc = "08:95:2A:AD:D6:4F", eth.type = 0x86DD, eth.payload = "\x60\x00\x00\x00\x00\x20\x3a\xff\xfe\x80\x00\x00\x00\x00\x00\x00\x0a\x95\x2a\xff\xfe\xad\xd6\x4f\xfe\x80\x00\x00\x00\x00\x00\x00\x55\x51\x00\xc2\x18\x0f\xdb\x46\x88\x00\x32\x01\xe0\x00\x00\x00\xfe\x80\x00\x00\x00\x00\x00\x00\x0a\x95\x2a\xff\xfe\xad\xd6\x4f\x02\x01\x08\x95\x2a\xad\xd6\x4f", signature = "IPv6 from Sparta" ]
Taking in consideration that the inclusion of the destination and source
MAC addresses inside an "Ethernet pigsty" is
optional we can get the job done even without using any
It is nice when you have to test new protocols over your environment among other anomalous funny stuff. On this raw way,
pig can keep itself useful to you.
Testing pig from scratch
Save the following data as
[ signature = "oink", ip.version = 4, ip.ihl = 5, ip.tos = 0, ip.src = 127.0.0.1, ip.dst = user-defined-ip, ip.protocol = 17, udp.dst = 1008, udp.src = 32000, udp.payload = "Oink!!\n" ]
tty run the
UDP mode listen for connections on port
someones@err..InTheWolf:~# nc -u -l -p 1008
pig using the
"oink.pigsty", informing as target the
someones@err..InTheWolf:~# pig --signatures=oink.pigsty --targets=127.0.0.1\ > --gateway=10.0.2.2 --net-mask=255.255.255.0 --lo-iface=eth0
netcat should start receiving several
oinks and... yes, congrats!!
pig is up and running on your system! ;)
Try to sniff your Network to get more information about these
UDP packets that are flowing around your interfaces...