Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 1,474 total)
  • Author
    Posts
  • in reply to: WireSock DNS is going over VPN (bug?) #13949
    Vadim Smirnov
    Keymaster

      All DNS requests on Windows are resolved within the DNSCACHE process, making it impossible to identify the originating application.

      in reply to: Winpkflt Rebind #13947
      Vadim Smirnov
      Keymaster

        Yes, that’s exactly what I mean. This technique is implemented in the WireSock VPN Client’s Transparent mode to ensure that packets sent by the TCP stack fit within 1420 bytes.

        in reply to: Winpkflt Rebind #13945
        Vadim Smirnov
        Keymaster

          I would apply MSS clamping when relaying the TCP SYN packet from the Ethernet to the WireGuard interface. If issues persist despite the MSS clamping, I recommend recording the processed traffic (see the capture example) and analyzing it in Wireshark

          in reply to: Connected to tunnel, but no traffic works #13942
          Vadim Smirnov
          Keymaster

            Logs and PCAP files would be helpful for investigating your issue.

            in reply to: Winpkflt Rebind #13941
            Vadim Smirnov
            Keymaster

              The Ethernet connection likely has a larger MTU than the WireGuard adapter. To address this discrepancy, you need to clamp the Maximum Segment Size (MSS) for TCP connections.

              in reply to: Can’t connect to WireGuard server #13938
              Vadim Smirnov
              Keymaster

                I don’t see any handshake responses in the log. WireSock sends multiple handshake packets to the server, but there’s no response. This behavior is typical when the WireGuard protocol is blocked. You might want to try using the SOCKS5 configuration option—it could resolve the issue.

                Vadim Smirnov
                Keymaster

                  Hello Olivier,

                  Thank you for your message and for considering WinpkFilter as a solution for your network monitoring module. I’m glad to hear it aligns well with your requirements, and I appreciate your kind words about my responsiveness.

                  For your trial, you are welcome to use the publicly available version of WinpkFilter. However, please keep in mind that I don’t recommend using this build in a production environment on a permanent basis, as it may lead to potential conflicts.

                  Should you need any further assistance or clarification, feel free to reach out.

                  Best Regards,
                  Vadim

                  in reply to: Query on Filtering Capabilities in Windows Packet Filter API #13934
                  Vadim Smirnov
                  Keymaster

                    Olivier,

                    Yes, you can use a single instance of CNdisApi. Please refer to the dual_packet_filter class, which demonstrates how two threads can operate across two network interfaces.

                    Additionally, you can assume the timestamp when the Read call occurs, with some level of precision. For higher accuracy, minor driver modifications would be needed; for example, the reserved bytes in INTERMEDIATE_BUFFER could be used to store more precise timestamps.

                    in reply to: Ошибка 0xc0000005 #13929
                    Vadim Smirnov
                    Keymaster

                      С 1.4.7 есть проблема на Windows 7. Она собрана с версией компилятора Rust, который не поддерживает Windows 7. Используйте 1.4.5.

                      in reply to: Privacy[Приватность] #13927
                      Vadim Smirnov
                      Keymaster

                        Ни WireSock ни WireSockUI не собирают, не хранят и никуда не отсылают никакой телеметрии. Но, разумеется, мы не можем гарантировать, что этого не делает тот сервис который вам предоставляет Wireguard сервер. Поэтому я бы рекомендовал использовать свой собственный VPS.

                        in reply to: Kernel Logging #13925
                        Vadim Smirnov
                        Keymaster

                          The driver shares a substantial amount of code across various Windows versions, so currently, the only available tracing method is through DbgPrint, which is enabled only in debug builds. If you’re specifically asking about ETW traces, this type of logging hasn’t been implemented yet. However, it can certainly be added for driver builds on Windows 7 and later versions if needed.

                          in reply to: Query on Filtering Capabilities in Windows Packet Filter API #13923
                          Vadim Smirnov
                          Keymaster

                            Hello Olivier,

                            Yes, flags are supported. Please see the definition of the TCP filter below. Note that it’s an exact match, so you may need multiple filters to cover all desired flag combinations for SYN, SYN-ACK, RST, and FIN.

                            
                            /**
                            * @brief TCPUDP_FILTER structure is used to set the TCP/UDP filter for the network adapter.
                            *
                            * @param m_ValidFields This field stores the valid fields flags. These flags determine which fields in the structure are valid. The flags
                            * can be a combination of the following values: TCPUDP_SRC_PORT, TCPUDP_DEST_PORT, TCPUDP_TCP_FLAGS.
                            * @param m_SourcePort This field is a PORT_RANGE structure that stores the source port range for the filter.
                            * @param m_DestPort This field is a PORT_RANGE structure that stores the destination port range for the filter.
                            * @param m_TCPFlags This field stores the TCP flags for the filter. It is an unsigned char representing the TCP flags combination.
                            */
                            typedef struct _TCPUDP_FILTER
                            {
                            #define TCPUDP_SRC_PORT 0x00000001
                            #define TCPUDP_DEST_PORT 0x00000002
                            #define TCPUDP_TCP_FLAGS 0x00000004
                            DWORD m_ValidFields; // Specifies which of the fields below contain valid values and should be matched against the packet
                            PORT_RANGE m_SourcePort; // Source port
                            PORT_RANGE m_DestPort; // Destination port
                            unsigned char m_TCPFlags; // TCP flags combination
                            unsigned char Padding[3];
                            } TCPUDP_FILTER, * PTCPUDP_FILTER;
                            
                            
                            
                            // 4.3 Check TCP flags
                            if (pFilter->m_Filter.m_TransportFilter.m_TcpUdp.m_ValidFields & TCPUDP_TCP_FLAGS)
                            {
                            if (pTcpHdr->th_flags != pFilter->m_Filter.m_TransportFilter.m_TcpUdp.m_TCPFlags)
                            {
                            dwFilterIndex++;
                            pFilter = (PSTATIC_FILTER_LIST_ITEM)pFilter->m_qLink.Flink;
                            continue;
                            }
                            }
                            
                            
                            in reply to: Query on Filtering Capabilities in Windows Packet Filter API #13919
                            Vadim Smirnov
                            Keymaster

                              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.* and tcp.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

                              in reply to: Sending a packet to Adapter, can’t see anywhere #13916
                              Vadim Smirnov
                              Keymaster
                                /**
                                @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;
                                }
                                in reply to: Error running sample program #13906
                                Vadim Smirnov
                                Keymaster

                                  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.

                                Viewing 15 posts - 1 through 15 (of 1,474 total)