Network packet generator
Subversive Technologies & Countermeasures
| |||||||||||||||
Network Packet Generator (npg) is a free GNU GPL Windows packet injector (generator) that utilizes WinPcap to send specific packets out a single or multiple network interfaces. These packets and other extended options can be defined on the command line, in a packet file, or combination of the two. A packet file can be either a Libpcap compatible capture dump or an npg formatted file that generates packets from raw byte streams providing the ability to create any packet type regardless of header, payload, or data link.
Contents |
[edit] Usage
- npg
- npg [-?hlw]
- npg [-vvvw] -fF <packet file name> -d <device interface>
- npg [-rtvvv] -p <packet byte stream> -d <device interface>
[edit] Options
-d < interface device >
Specifies a single device that will be used as a default device for any packets that do not explicitly define a device or devices to be injected through.
-f < npg packet file name >
Npg formatted packet file that defines the packets to be injected, and optionally their repeat count, time interval, device list, and PacketID
-F < Libpcap compatible packet file name >
Libpcap compatible packet file that will have its contents injected.
-l
Displays a list of usable interfaces in a format compatible with the -d switch.
-p < packet byte stream >
Specifies a single packet byte stream to be injected. This stream cannot contain any spaces and must be formatted in two character hex value byte. 00 - FF
-r < repeat count >
Numeric count of how many times to re inject the current packet. If time intervals are defined it will wait the specified time before re injecting each packet. This switch is only viable when used in conjunction with the -p switch.
-s
Synchronize the injected packets according to the time stamps specified in a Libpcap compatible file. This switch is only viable when used in conjunction with the -F switch or Libpcap compatible file.
-t < time interval >
Specifies the time interval in milliseconds to wait before the packet is injected. This switch is only viable when used in conjunction with the -p switch.
-v, -vv, -vvv
Verbose, Very Verbose, and Very Very Verbose. Determines how much status npg will display during operation. Verbose displaying minimum progress messages, Very Verbose displaying large amounts of status messages, and Very Very Very Verbose spamming incredible amounts of messages.
-w
Displays the current version of WinPcap installed.
-?, -h
Displays copyright information and list of command line switches.
- If no options are specified then npg will run in interactive mode and use prompt menus for operation.
[edit] Writing a packet file
A packet file consists of a mandatory packet block accompanied with optional injection rate, device list, and packet ID identifiers.
[edit] Packet block
A packet block is a stream of 4 bit hex value identifiers between a starting { and ending }. Each hex number is formatted as a two character byte expressed as a value between 00 and FF. This collection of numbers make up a raw packet byte stream where all headers and payloads must be defined by the user. Any spaces, tabs, or comments inside a packet block will be ignored by the npg file parser.
Example block:
{ 01 02 03 04 05 06 06 05 04 03 02 01 08 00 }
Example block:
{ 01 02 03 04 05 06
06 05 04 03 02 01
08 00 }
Example block:
{0102030405060605040302010800}
Example block:
{
0
1
0
2
0
3
}
[edit] Injection rate bracket
A single injection rate bracket may be defined before each packet block to inform the injector of how many times to inject the packet and how long to wait before each injection.
Declaring a rate bracket is done anywhere before the packet block with an opening [ and finished with a closing ]. The first numeric value inside this bracket will define the repeat count followed by a , delimiter and then another numeric value defining a milliseconds wait time interval.
Example rate bracket:
[0,1000]
Example rate bracket:
[3,0]
Example rate bracket:
[ 2 , 3000 ]
[edit] Packet ID bracket
Each packet can be tagged with a string value identifier between < and > brackets that will be displayed each time the packet is injected. In order to display a > character within a packet ID bracket you would declare it as >>.
Example PacketID bracket:
<This is an example of displaying a >> character within a packet ID bracket>
Example PacketID bracket:
<This is an example packet id message>
Example PacketID block:
< Multiple use of >> characters >> in a >> packetID >
[edit] Device bracket
Each individual packet can specify a single or multiple network device interfaces from witch it will be injected. To obtain a list of valid interface devices on the system npg can be run with the -l switch. When using an npg packet file if any packets are found without at least one assigned interface device an interactive menu will be triggered to assign a single default device to all unassigned packets. A libpcap compatible file does not store device information limiting it to single device injection and will always trigger an interactive default device selection menu.
Example device bracket:
(rpcap://\Device\NPF_{AB070CF2-8017-V021-B007-19300C0F301C})
Example: device bracket:
( rpcap://\Device\NPF_{AB070CF2-8017-V021-B007-19300C0F301C} )
Example device bracket:
(rpcap://\Device\NPF_{AB070CF2-8017-V021-B007-19300C0F301C} ,rpcap://\Device\NPF_{AC0700F2-1A10-V011-BG07-19A300C0F301C})
[edit] Comments
Comments can be added anywhere in the packet file using the # delimiter with anything past the delimiter to the EOL being ignored by the parser.
Example comment:
{
# Ethernet HEADER -----
01 02 03 04 05 06 # Destination MAC
06 05 04 03 02 01 # Source MAC
08 00 # Protocol
}
Example comment:
[1,1]<Ping Packet>#From this point on till EOL is ignored by the parser
Example comment:
# This entire line has been commented
[edit] Sample packets
# TCP/IP ICMP Echo Request
{
# Ethernet HEADER -----
01 02 03 04 05 06 # Destination MAC
06 05 04 03 02 01 # Source MAC
08 00 # Protocol
# IP HEADER -----------
45 # Version / Header Length
00 # Type of service
00 3c # Total length
00 a5 # Identification
00 00 # Flags / Fragment offset
80 # Time to live
01 # Protocol
b8 c8 # Checksum
c0 a8 00 02 # Source address
c0 a8 00 01 # Destination address
# ICMP HEADER ---------
08 # Type
00 # Code
4a 5c # Checksum
02 00 # Identification
01 00 # Sequence number
61 62 63 64 65 66 # Data (Windows ping)
67 68 69 6a 6b 6c
6d 6e 6f 70 71 72
73 74 75 76 77 61
62 63 64 65 66 67
68 69
}
# TCP/IP ARP Reply
{
# Ethernet2 Header ---------
01 02 03 04 05 06 # Destination MAC
06 05 04 03 02 01 # Source MAC
08 06 # Protocol
# ARP Header ---------------
00 01 # Hardware type
08 00 # Protocol type
06 # Hardware size
04 # Protocol size
00 02 # Opcode
06 05 04 03 02 01 # Sender MAC address
c0 a8 00 02 # Send IP
01 02 03 04 05 06 # Target MAC address
c0 a8 00 01 # Target IP
# Ethernet2 (Trailer) ------
00 00 00 00 00 00 # Trailer data
00 00 00 00 00 00
00 00 00 00 00 00
}
#DNS Request
{
# Ethernet2 Header ----
01 02 03 04 05 06 # Destination MAC
06 05 04 03 02 01 # Source MAC
08 00 # Protocol
# IP HEADER -----------
45 # Version / Header Length
00 # Type of service
00 39 # Total length
03 54 # Identifcation
00 00 # Flags / Fragment offset
80 # Time to live
11 # Protocol
76 b7 # Checksum
c0 a8 00 01 # Source address
00 00 00 00 # Destination address
# UDP HEADER ----------
04 05 # Source port
00 35 # Destination port
00 25 # Length
2c 94 # Checksum
# DNS HEADER ----------
46 9c # Transaction ID
01 00 # Flags
00 01 # Questions
00 00 # Answer RRs
00 00 # Authority RRs
00 00 # Aditionla RRs
07 77 69 6b 69 # Start Name
73 74 63 03 6f #
72 67 00 # End Name
00 01 # Type
00 01 # Class
}
# TCP/IP ICMP Echo Request
<ICMP Echo request>
[0,1000]
(rpcap://\Device\NPF_{AB070CF2-8017-V021-B007-19300C0F301C})
{
# Ethernet HEADER -----
01 02 03 04 05 06 # Destination MAC
06 05 04 03 02 01 # Source MAC
08 00 # Protocol
# IP HEADER -----------
45 # Version / Header Length
00 # Type of service
00 3c # Total length
00 a5 # Identification
00 00 # Flags / Fragment offset
80 # Time to live
01 # Protocol
b8 c8 # Checksum
c0 a8 00 02 # Source address
c0 a8 00 01 # Destination address
# ICMP HEADER ---------
08 # Type
00 # Code
4a 5c # Checksum
02 00 # Identification
01 00 # Sequence number
61 62 63 64 65 66 # Data (Windows ping)
67 68 69 6a 6b 6c
6d 6e 6f 70 71 72
73 74 75 76 77 61
62 63 64 65 66 67
68 69
}
[edit] FAQ
Q: Why use WinPcap?
A: While coding your own network driver is possible, there is no reason to reinvent the wheel when you have a mature and vetted package such as WinPcap available.
Q: Why not use Windows APIs?
A: Windows XP does not provide raw socket access therefore a 3rd party driver is required.
Q: Why write this tool when there is such a great capacity for abuse? Windows does not have raw socket access for a reason right?
A: This is a highly debated subject on any technology that has as much potential for positive effects and it does negative. The reality is *nix systems have had the ability as long as they have existed, and not providing it in a Windows environment limits professionals opportunities.
Q: What are some positive uses for npg?
A: Network research, penetration testing, education, and well as many others.
Q: Why was a text file chosen for the packets file?
A: Even though a text file loses many optimizations to a binary file as a storage method it does gain the benefits of inline commenting, ease of creation, and quick modifications without the need of an interpretive interface.
Q: Why was the current syntax chosen?
A: The packets file syntax was chosen to provide the most amount of flexibility in packet creation and timing, while allowing it to be heavily commented for human readability ease of creation and modification. By keeping the packet data as a raw byte stream virtually any protocol and packet can be emulated without having to change anything in npg.exe over time.
Q: When I attempt to execute npg.exe I receive an error box "This application has failed to start because wpcap.dll was not found. Re-installing the application may fix this problem"
A: More then likely you do not have the WinPcap driver installed. If the driver is installed try re-installing it with the most recent release.
Q: How do I know if anything happened?
A: -vv (double v) argument will display npg injection status in real time or Wireshark is a free network sniffer that also uses the WinPcap driver on the Windows platform.
Q: After answering all the interactive mode questions the window dissapears?
A: You are executing npg from Windows Explorer and it will close the window with the program terminates. Use a command shell to execute npg.
Q:I am having problems using npg with my wireless connection.
A:WinPcap FAQ answers this question.
Q:How can I learn to craft my own packets?
A:This intermediate article on packet crafting can help you get started.
[edit] Dependancies
In order to use npg you will need to install the Open Spource WinPcap package.
Npg has been successfully operated under the following builds:
WinPcap download page.
[edit] Compiling the source
Requirements:
- WinPcap Developers pack
- iphlpapi.lib also available in Windows SDK
[edit] Bug reports
Bug reports, comments, suggestions
[edit] Changelog
[edit] Version 1.0.1
- Added device listing compatible with the -d argument. Invoking this listing is done with the -l switch.
- Fixed CRC error in IP Header in packets.txt example
- Added example.bat for easier Windows Explorer execution of the example file packets.txt
- Fixed buffer overflow possibility by replacing scanf with fgets
- Updated examples in packets.txt
[edit] Version 1.0.2
- Added -S switch for separate timing interval function. -s will use the WinPcap version which is highly accurate but extremely cpu intensive. -S will use a npg function that is cpu easy and moderately accurate.
[edit] Version 1.1.0
- Removed WinPcap argument -s leaving only npg time interval injection
- Added ability to choose a separate device for each packet injected via packet file
- Changed time intervals to a single milliseconds value
- Added a PacketID field for each packet to display when it is injected for better user
feedback during execution
- Minor changes to the way the packet file parser works
- Added checks for multiple declarations of time intervals, devices, and PacketID per packet
- Changed the order of checks with device selection and packet file, device check will not go
into interactive if devices are declared for EVERY PACKET in the packet file.
- Added repeat counter for multiple injections of the same packet
- Added -w argument to display to currently installed version of the winPcap library
[edit] Version 1.1.1
- Added ability to specify more then one device per packet
- Started to clean and organize the cluttered source code, ParsePacketFile() still a mess
- Various minor fixes
[edit] Version 1.2.0
- Added -F libcap compatible binary file type for injection
- Corrected <CR> left over on file name selection function causing file not to be found
- Various minor fixes
[edit] Version 1.2.1
- Minor bug fixes
- Cleaned up the source files a bit
[edit] Version 1.3.0
- Corrected CRC in UDP Header potion of the DNS Request example
- Display argument list when invalid command line argument is attempted
- A > character is now a legal character inside of a < > packet ID bracket
- Added -t , -r , and -p arguments for command line injection without the use of a packet file
- Separated the file read and data parsing functions in the source code for easier audits and maintenance
- Fixed oversight with capital A-F values being invalid hex identifiers
- Added Error stop for lines that exceed the maximum read length on a packet file
- Removed artificial maximum packet size defined in npg
- Created npg(at)wikistc(dot)org contact address for bug reports, comments, suggestions, etc
- Increased packet file read in line max length to 4096
- Fixed device bracket when declaring the same device twice it would treat it as a two separate devices and inject the packets accordingly.
- Changed the behavior of time intervals usage. If a -t is specified in conjunction with -p switch the time interval will be used. If a time interval is specified in a npg packet file, time intervals will automatically be used. Any packets in the same packet file with no defined time intervals will default to 0. The -s switch is now only viable with -F libpcap compatible file, or when a libpcap is selected in interactive mode.
- Added more informative display to the -? -h output
- Minor bug fixes
[edit] Under development
- C++ code conversion
- GUI version with protocol header generator
[edit] Appendix
Download npg1.3.0.zip beta
