hmgle
commented
3 years ago Good question.
There are two points to explain:
- ptrace can only modify the memory of the traced process, but cannot expand this part of the memory
- The data size of SOCKS5 or HTTP proxy traffic will inevitably be larger than the raw TCP traffic. In other words, the memory requirement of the buffer that caches the proxy data is more than the raw TCP data.
Based on the above two points, we have no way to directly modify the internal traffic data of the traced process and convert it into SOCKS5 or HTTP proxy traffice data. The data must be taken out and convert to the proxy traffice outside the traced process.
The main job of graftcp-local is to receive the raw traffic data from the traced process and convert it to the proxy traffic data, so it contains a TCP server.
It is possible to merging the the graftcp-local and graftcp into one single binary, but this would make graftcp much more complex and difficult to implement. In order to avoid the TCP port conflicts caused by starting multiple instances, each instance must listen a different TCP port.
50 traced processes, one TCP server is simpler than 50 traced processes, 50 TCP server.
If you use graftcp often, you can alse add the graftcp-local service to systemd, to avoid opening another terminal for local to running every time:
make install_systemd
chaoqing
May I ask whether there is any concern on merging the graftcp-local and graftcp into one single binary?
It seems strange to me if I just want to proxy one command but need to open another terminal for local to running.
If it is already designed behavior which make merging in framework level a hard task, we can do it the simple way by spawn another thread inside go for local. Is this a valid solution?