Forum Replies Created
-
Posts
-
Dear Olivier,
Yes, the Windows Packet Filter (WinpkFilter) API indeed supports advanced filtering capabilities that can be utilized to process packets meeting specific IP and port conditions. This can be achieved using WinpkFilter’s built-in static filters, which provide control over which packets are captured or redirected for user-mode processing based on defined criteria.
To streamline packet capture for specific conditions (such as
ip=172.31.*andtcp.dstport==80), you can use static filters to target only the packets that match your designated IP range and port number. An example demonstrating basic static filter usage can be found here.Please feel free to reach out for more examples or further guidance.
Best regards,
Vadim/** @brief Resets a TCP session by sending a forged RST packet. * This function clones the original packet, swaps the necessary fields to create a RST packet,recalculates the checksums, and re-injects both the modified original and the forged RST packets. * @param packet The original packet to be processed.@return true if the session is successfully reset, false otherwise. */ bool reset_tcp_session( intermediate_buffer& packet) { bool result = true; if (const auto ethernet_header = reinterpret_cast<ether_header_ptr>(packet.m_IBuffer); ntohs( ethernet_header->h_proto) == ETH_P_IP) { if (const auto ip_header = reinterpret_cast<iphdr_ptr>(ethernet_header + 1); ip_header->ip_p == IPPROTO_TCP) { const auto tcp_header = reinterpret_cast<tcphdr_ptr>(ip_header + 1); // 1. Clone the original packet and obtain headers intermediate_buffer cloned_packet = packet; const auto clone_ethernet_header = reinterpret_cast<ether_header_ptr>(cloned_packet.m_IBuffer); const auto clone_ip_header = reinterpret_cast<iphdr_ptr>(clone_ethernet_header + 1); const auto clone_tcp_header = reinterpret_cast<tcphdr_ptr>(reinterpret_cast<PUCHAR>(clone_ip_header) + sizeof(DWORD) * clone_ip_header->ip_hl); // 2. Swap Ethernet addresses for the clone std::swap(clone_ethernet_header->h_dest, clone_ethernet_header->h_source); // 3. Swap IP addresses for the clone std::swap(clone_ip_header->ip_dst, clone_ip_header->ip_src); // 4. Swap TCP ports for the clone std::swap(clone_tcp_header->th_dport, clone_tcp_header->th_sport); // 5. Swap SEQ/ACK for the clone std::swap(clone_tcp_header->th_ack, clone_tcp_header->th_seq); // 6. Update ACK from the original packet with m_data size for the clone if (clone_tcp_header->th_flags & TH_SYN) clone_tcp_header->th_ack = htonl(ntohl(clone_tcp_header->th_ack) + 1); else clone_tcp_header->th_ack = htonl(ntohl(clone_tcp_header->th_ack) + ntohs(clone_ip_header->ip_len) - clone_ip_header->ip_hl * 4 - clone_tcp_header->th_off * 4); // 7. Set new packet buffer length cloned_packet.m_Length = sizeof(ether_header) + clone_ip_header->ip_hl * 4 + sizeof(tcphdr); // 7.1. Adjust tcp m_data offset clone_tcp_header->th_off = 0x5; // 8. Set IP total length clone_ip_header->ip_len = htons(static_cast<short>(cloned_packet.m_Length - sizeof(ether_header))); // 9. Set TTL clone_ip_header->ip_ttl = 128; // 10. Set TCP flags clone_tcp_header->th_flags = TH_RST | TH_ACK; // 11. Recalculate checksums CNdisApi::RecalculateTCPChecksum(&cloned_packet); CNdisApi::RecalculateIPChecksum(&cloned_packet); // 7-11 for original packet only done if it is not a connection establishment phase if (tcp_header->th_flags != TH_SYN) { packet.m_Length = sizeof(ether_header) + ip_header->ip_hl * 4 + tcp_header->th_off * 4; ip_header->ip_len = htons(static_cast<short>(packet.m_Length - sizeof(ether_header))); tcp_header->th_flags = TH_RST | TH_ACK; CNdisApi::RecalculateTCPChecksum(&packet); CNdisApi::RecalculateIPChecksum(&packet); } // 12. Re-inject the modified original and forged RST packets PINTERMEDIATE_BUFFER packets[] = {&packet}; PINTERMEDIATE_BUFFER cloned_packets[] = {&cloned_packet}; // Check if the packet is not a SYN packet for sending to the appropriate filter if (tcp_header->th_flags != TH_SYN) { if (packet.m_dwDeviceFlags == PACKET_FLAG_ON_SEND) { result = result && send_packets_to_adapters(packets, 1); } else { result = result && send_packets_to_mstcp(packets, 1); } } // Send cloned packets to the opposite filter based on the flag if (packet.m_dwDeviceFlags == PACKET_FLAG_ON_SEND) { result = result && send_packets_to_mstcp(cloned_packets, 1); } else { result = result && send_packets_to_adapters(cloned_packets, 1); } } } return result; }Windows Server 2003 is an outdated operating system, and building binaries specifically for it using modern versions of Visual Studio can be quite challenging. The main issue is that current toolchains are optimized for more recent versions of Windows and may not offer full backward compatibility with older APIs and libraries that are specific to Windows Server 2003.
The basic samples you successfully ran on Windows Server 2003 were built using Visual Studio 2012 and Visual C++ 6.0.
I would recommend paying attention to the following points:
1. Ensure that all structures used for driver communication are properly packed.
2. If you are using a 64-bit driver, make sure to build your code for 64-bit as well.
3. The adapter handle must correspond to the selected network interface.
4. The event handle should be a native Windows handle.
5. I suggest building and using the ndisapi.dll C interface in Go instead of reimplementing all the DeviceIoControl calls directly in Go.
The fragmentation of Wireguard UDP packets is unusual and typically indicates problems with your Wireguard server setup. While it’s possible that these packets could be fragmented along the route, I find this unlikely. If packet fragmentation is occurring, consider adjusting the MTU on both your Wireguard server and client. Packets inside the tunnel can be fragmented and will be reassembled, but it’s uncommon for the Wireguard packets themselves to be fragmented. In my experience, I have not encountered this issue with my servers, although I have received a few complaints about it.
I will consider implementing Wireguard packet defragmentation, but please note that handling packet fragmentation and defragmentation can have a significant performance impact.
If logging is enabled, try disabling it to see if it improves performance, as extensive logging can significantly increase latency. For troubleshooting, I recommend using the WireSock CLI directly instead of WireSockUI.
It would be helpful to have the console log and PCAP files for further analysis. One possible cause could be that WireSock doesn’t support packet defragmentation, which can lead to issues like the one you’re encountering.
You can check out a recent discussion on a somewhat similar BitTorrent issue here
The ability to capture a sent packet depends on how the drivers are layered. In some cases, it might not be possible. I recommend trying to capture the packet using Wireshark on the destination machine.
If the adapter handle is configured correctly, you should be able to send any packet on a wired network. However, with WiFi, the situation is more complex since the MAC addresses must be accurate.It appears the system entered sleep mode at 18:03:02 and resumed at 18:14:24, right? However, the error remains unclear—it looks like the handshake packet failed to send over the UDP socket. I can build a version with extended logging to gather more details. At the very least, knowing the specific error code would be helpful. Is the Internet connection functioning correctly after the resume?
The approach largely depends on the context. In general, if you need to work with a process context in the kernel driver, using WFP call-outs makes sense as they provide a more direct way to filter traffic based on process information at the kernel level. However, for user-mode operations, the overhead introduced by GetExtendedTcpTable() is similar to what you would encounter if you implemented the same functionality via a kernel driver.
So, if you’re aiming for a user-mode solution without the complexity of working in kernel mode, GetExtendedTcpTable() is a reasonable choice. But if you’re okay with working in the kernel and need tighter control, WFP call-outs would offer more flexibility and direct access to connection events like Connect and others.
Typically, the WireSock VPN client automatically attempts to reconnect if the VPN connection is lost, as in your situation. Could you provide more details, such as the client version and whether you’re running it as a service or an application? Additionally, any logs you can share would be helpful in diagnosing the issue.
I briefly reviewed the AmneziaWG repositories and noticed that there’s no existing library to handle packet obfuscation/deobfuscation, and I’d prefer not to extract the client code to create one myself. It would be much more convenient if the AmneziaWG authors developed such a library. I’ve submitted an issue about this. If you’re interested in this feature, please consider supporting it:
https://github.com/amnezia-vpn/amneziawg-windows-client/issues/15
Да, есть такая проблема, и без антиспама никак и с ним неудобно. Давайте попробуем один из этих каналов:
https://t.me/wiresock
https://www.reddit.com/r/WireSock/s/zHPkfxYEspCurrently, localhost connections are not supported because they were not prioritized as essential functionality. While the initial handshake packet is sent over Windows sockets, the subsequent packets are injected directly into the NDIS layer, causing them to be misdirected in case of localhost server. I plan to address this and add localhost support in future releases.
