On Wed, 26 Jul 1995, Paul Robichaux wrote:
Hal said:
This sounds very good if it already is almost working. The TCP connection which is opened would have to be to a server on the local machine, so it would be important that the software support that. Also, the local SOCKS relay would of course not want its winsock calls to be intercepted and translated in this way, so there would need to be some alternative way to access "vanilla" winsock. Can you give any more information on the NEC work?
This should be fairly straightforward: take the existing winsock.dll or winsock32.dll and rename it. Install the NEC DLL with the old winsock's name, then have the NEC DLL do a LoadLibrary() to attach the original version.
In any case, Trumpet Winsock has got a buit-in socksifier, even in the non-time-limited version 2.0b. It's activated by the "Firewall setup" dialogue box, and seems to work: I've just tested it with a sockd 4.2b running on a Linux box. NEC's DLL will add the same functionality to other stacks, but experimental encrypting relays could be tested right now with Trumpet Winsock. Think about it, this could be the ultimate encryption hook: I don't think that NSA could arrive to ban firewall support... Now for a catchy name for SOCKS-based encrypting relays: what about "SafeSox"? :-)