Fixing A FakeNet/-NG PCAP
Introduction
In this tutorial, we’ll demonstrate some of PacketSmith’s capabilities by using a pcap file generated by FakeNet-NG. FakeNet-NG is an open-source, next-generation dynamic network analysis tool developed by Mandiant, primarily used by malware and security researchers, bug hunters, and penetration testers. It’s beneficial for intercepting, redirecting, and decrypting TLS/SSL traffic, among other functions.
One of the most common use cases for FakeNet is redirecting and capturing malware C&C traffic, particularly when the C&C server is down, or when SSL/TLS interception is needed to peek into the plaintext traffic.
PCAP Issues
PCAP files generated by both older FakeNet and newer FakeNet-NG versions utilize non-standard data link layers, rather than common types like Ethernet II (linktype 0x01000000). Specifically, some versions employ a custom data link layer (linktype 0x0c000000), while other iterations use the standard RAW data link layer (linktype 0x65000000).
FakeNet and FakeNet-NG also introduce quirks with source and destination IPv4 addresses in their generated PCAPs. In older versions, you’ll find the source IP fixed at 127.0.0.2 and the destination IP at 127.0.0.1. Newer versions are a bit different: the source IP will be your system’s actual IP address. The destination IP, however, varies based on DNS resolution. If a DNS request is made, FakeNet allows you to configure the DNS A response record, effectively controlling the destination IP; otherwise, the dst IP is the same as the src IP.
Case Study
We’ll take the traffic generated by the malware sample with the sha-256 hash (2878432ad070bc31a99a11375a7521be96d0a30ebe8fd4bac12107828d8eb09d) as an example to highlight some of PacketSmith’s capabilities in replacing the datalink layer with an Ethernet II layer, deleting existing DNS requests/responses in the pcap and injecting new ones with our requirements, fixing checksum errors, updating src and dst IPv4 addresses and src and dst MAC addresses while honoring the TCP/UDP streams flows’ directionality. From here on, we’ll refer to the sample under study as Yunclou throughout the tutorial. Running the sample in a VM while FakeNet-NG is running with the default settings, we get the traffic in the attached pcap yunclou_fakenet_traffic_trimmed.zip (size: 1,985 bytes). To keep it short, the traffic was trimmed to focus on one TCP stream with the DNS request. The pcap consists of 18 frames.
The malware starts by communicating with the C&C server alicloudmail[.]logd[.]lol over TSL/SSL port 443. The domain was down at the time of writing.

The packet capture shown in Fig. 1 uses the standard RAW data link layer (linktype 0x65000000). Additionally, as shown, the src and dst IPv4 addresses are the same, and the domain name “alicloudmail[.]logd[.]lol” resolves to the configuration specified IP address 192.0.2.123.
To get a cursory look at the pcap, we execute the following “Info” command line option:
PacketSmith.exe —infile yunclou_fakenet_traffic_trimmed.pcap —Info pcap
– Pcap filename: yunclou_fakenet_traffic_trimmed.pcap
– Pcap size: 2552 bytes
– Pcap magic number: 0xd4c3b2a1 (little-endian – microsecond-resolution timestamp)
– Pcap snapshot length: 1500
– Pcap version: 2.4
– Pcap thiszone (correction time): 0 (time is in UTC)
– Pcap sigfigs (timestamp accuracy): 0
– Pcap link type: LINKTYPE_RAW
– Total number of frames: 18
– First packet (1) timestamp: 2025-07-09 19:05:10.795000 UTC
– Last packet (18) timestamp: 2025-07-09 19:05:12.323000 UTC
– First packet with the smallest size in the pcap: 40 bytes -> frame 5
– Last packet with the largest size in the pcap: 917 bytes -> frame 8
The intended modifications are:
- Substitute the Raw datalink layer with an Ethernet II layer.
- Delete existing DNS query/response packets (frames 1 and 2)
- Set the source IP address to 192.168.60.133 and the destination IP address to 49.38.27.16, following the proper TCP/UDP flows’ directionality.
- Assign appropriate source and destination MAC addresses for the new Ethernet layer.
- Replacing existing DNS request/response with DNS query/response for alicloudmail[.]logd[.]lol (resolving to 49.38.27.16) using gateway 192.168.60.1.
- Recompute the IPv4 and TCP checksums.
The choice of which options to use is dictated by the order in which the modifications are applied, as detailed in Appendix A (not shown here; it is in the documentation shipped with PacketSmith).
Command line synatx: PacketSmith.exe —infile <in_pcap> —outfile <out_pcap> <[options]>
Followed by the options, one at a time:
- Replace the Raw datalink layer for all frames with Ethernet layer using the option (check the Core Features page for a list of all layers PacketSmith is capable of replacing)
- —replace_lr raw
- If the existing datalink layer was set to the custom data link layer (linktype
0x0c000000), the option would be —replace_lr fakenet - We’ll end up with an Ethernet II layer with the following settings (the src and dst MAC addresses are randomly generated by the –replace_lr option):
Ethernet II, Src: 04:8e:eb:46:8e:45 (04:8e:eb:46:8e:45), Dst: 00:ca:c7:e7:cb:34 (00:ca:c7:e7:cb:34)
Destination: 00:ca:c7:e7:cb:34 (00:ca:c7:e7:cb:34)
Source: 04:8e:eb:46:8e:45 (04:8e:eb:46:8e:45)
Type: IPv4 (0x0800)
- Delete the first 2 frames from the pcap containing the DNS query/response packets using the option
- —del_frame 1,2
- Update source and destination IPv4 addresses by stream (format pattern: -S, —up_ip_addr stream:<ipv4|ipv6>,<src|dst>,<tcp|udp|both>,<from_ip_addr>,<to_ip_addr>), respectively
- —up_ip_addr stream:ipv4,src,tcp,192.168.60.133,192.168.60.133 —up_ip_addr stream:ipv4,dst,tcp,192.168.60.133,49.38.27.16
- Inject DNS query/response packets for alicloudmail[.]logd[.]lol (resolving to 49.38.27.16) using gateway 192.168.60.1
- This option is formatted as follows: —dns_rq_rsp <ref_frame_id>,<injection_index>,<is_swap>,<gateway_ip_addr (ipv4|ipv6)>,<domain_name>[,<ipv4/6_addr>:<ttl> … ,<ipv4/6_addr>:<ttl>]
- This option takes an optional list of A/AAAA IPv4/IPv6 addresses with their TTL values (in seconds) for the query response packet in case multiple records are required. And in case it is not specified, then only one A/AAAA record is added with the values: <dst_ipv4/6_address_from_reference_frame> and a TTL value of 8 seconds.
- —dns_qr_rsp 1,0,false,192.168.60.1,alicloudmail.logd.lol
- The is_swap flag is set to false because we don’t want to swap the src and dst IP addresses inherited from the reference frame id 1. This is the directionality we want.
- Update source and destination MAC addresses to match the flow direction, as determined by the stream’s source and destination IP addresses (anchored by the IP address). We use the same MAC addresses that were generated when replacing the data link layer.
- —up_macaddr stream:ip,src,04:8e:eb:46:8e:45 —up_macaddr stream:ip,dst,00:ca:c7:e7:cb:34
- The checksums for all of the frames are incorrect. To recompute the IPv4 and TCP/UDP checksums, you pass the checksum option:
- —checksum
- PacketSmith outputs a table showing the number of checksums fixed per protocol:
- —checksum
– IPv4 : 18
– UDP_IPv4 : 2
– TCP_IPv4 : 16
– UDP_IPv6 : 0
– TCP_IPv6 : 0
– ICMP : 0
– ICMPv6 : 0
– IGMP : 0
– FCS : 0
– Total : 36
The final, updated, and fixed pcap is available here: yunclou_fakenet_traffic_trimmed_fixed.zip (size: 2,136 bytes).
Fig.2 shows the complete 18-frame pcap, fixed.

Conclusion
This tutorial showcased some of PacketSmith’s features using a practical, real-world example. We hope you found the steps straightforward and the command-line options simple to use.
For detailed technical documentation and complete usage instructions, please refer to the accompanying PDF documentation included with PacketSmith. We’ll explore more advanced features in upcoming tutorials.
Author: Mohamad Mokbel (Netomize)
First release: July 15, 2025
Last updated: September 22, 2025 – (The command-line options for changing source and destination IP/MAC addresses have been updated for the upcoming v3.0 release, featuring a revamped format).
