- This topic has 5 replies, 2 voices, and was last updated 3 months, 1 week ago by
.
-
Posts
-
Hi, I tried your project – ProxiFyre. And it works fine. But, is it possible to transmit entire IP Packet to my Socks5 Server(Written in C#) instead of TCP Packet? I mean I have an Socks5 server where I’m able to parse any incoming packets, and maybe it is possible to receive entire IP Packet and then I can construct TCP Packet from this IP Packet in my Incoming packets handler inside my Socks5 server and send only TCP data trough to the Server\Client but keep IP Header data for my needs. Is it possible in theory at all or there will be issues with checksums or something else? Or maybe there is some better way to get access to the IP Headed of the TCP Packet on my Socks5 server?
Transmitting entire IP packets to a SOCKS5 server is theoretically possible, but SOCKS5 is inherently designed for TCP/UDP connections and does not natively support the transmission of raw IP packets. Modifying the protocol to handle IP packets would necessitate significant changes on both the client and server sides.
ProxiFyre consists of two components: a redirector that forwards connections to a transparent local proxy, and the transparent local proxy itself, which functions as a SOCKS5 client. The redirector has access to raw network packets (Ethernet frames), whereas the local proxy operates at the transport level (TCP, UDP). Therefore, technically, you can use the redirector component to intercept IP packets and send them to your proxy.
I assume you are talking about this part in the tcp_local_redirect.h
bool process_client_to_server_packet(INTERMEDIATE_BUFFER& packet, uint16_t port = 0)
And yes I already found the way how to get all headers and payload from the Ethernet packet
But I’m not sure how to pass this packet to the internal ProxiFyre local proxy, still inspecting the code.
If I got it correctly I need to pass this packet from this redirect function to internal proxy that is connected to my Socks5 server as client and send this packet as TCP\UDP payload, or you meant I have to create my own extra TCP\UDP clients to connect my to Socks5 server directly?
The file
tcp_local_redirect.hreroutes selected outgoing connections to a local proxy and can be modified to redirect these packets to a remote host. However, it does not incorporate any SOCKS5 protocol logic. I should note that I may not fully understand your requirements, as forwarding entire IP packets is typically utilized in various types of tunnels rather than in proxies.Finally got back to the project after some rl issues. And yes, seems like I was trying to do silly things with these proxy servers… Just tried NdisApiDotNet example and it works basically the way I want not like I wanted before. So actually this example is nice, but the only one thing I’m gonna ensure:
Example code: https://github.com/wiresock/ndisapi.net/blob/master/NdisApiDemo/Program.cs
There are two methods that run in a Task each. But when I debug it, or want to put some latency simulation for a few seconds it seems like adapter “stucks” and the traffic on the adapter literally stops unless I stop debug and delay timer ends. So is there any way to capture packets in some kind of order that can handle packets whatever time I want and in same time receive new packets, or there is no such build-in option and the only way to do this functionality is to build my own order? Like if I want to filter some packets one by one I should add new packets to my own queue when I receive it from the driver “filter.ReadPackets” and in the driver just block every packet and then, after filtering\editing the packet just manually send it through the driver? Also should I also recalculate checksums after I edit some bytes in the packets?
Thanks for reaching out, and I’m glad to hear that you got the NdisApiDotNet example working the way you want.
Regarding your question, the behavior you’re observing when you introduce latency or debug the Task is expected. Pausing the packet reading, processing, and re-injecting loop will indeed cause the network adapter to “freeze” because the driver depends on that continuous loop to maintain traffic flow. When the loop is interrupted, the driver is essentially left waiting, which stops the traffic.
If you need to extract packets for out-of-band processing, this should be handled in a dedicated thread. This way, the main loop can continue processing and re-injecting packets while your separate thread manages the additional processing. This approach ensures that network traffic continues to flow smoothly without interruption.
And yes, when you modify packets, recalculating checksums is necessary to ensure the integrity of the data. If checksums are not recalculated, the modified packets may be rejected or cause issues further down the line.
- You must be logged in to reply to this topic.