The Code

This page contains bits and pieces related to the source code, for those who want to poke around in it, and perhaps taylor it to their own needs.


Contains a dll responsible for authenticating. The code implements a single user "proxy" with password "socks", but you can easily replace that and build another dll containing your own users. You can also write code to read your users from the registry, a file or a database. The dll MUST implement the functions Socks4Authenticate and Socks5Authenticate with the given signatures for the dll to be loadable by SocksProxy. Perhaps I will put other SocksAuth dlls into the release in the future.


A dll responsible for reading the configuration from registry. You can also write your own dll with a static configuration, or reading it from a file or someplace else. The dll MUST implement the functions Init, LogFilePath and SocksListeners with the given signatures for the dll to be loadable by SocksProxy.


The function LogFilePath is finding a place to put the logfiles, specifically "C:\Users\All Users\Application Data\SocksProxy" or "C:\ProgramData\Application Data\SocksProxy" depending on how you look at it, and the version of Windows, you are using. If you want to use a different path, this is where to put it.


This directory contains the actual proxy, the tcp networking code, Socks logic, code related to installing and running the service, and so on.


This file is doing the logging to the log files. Two log files are being written, SocksProxy.log contains all loggings, SocksProxyError.log contains all error loggings only. If you change the code, note that you should not call the logf-functions, before initlogf has been called.


The function Socket::sendsocket is sending data on a tcp socket, or possibly returning without sending, if the socket is not yet ready. In a proxy, it is not possible to keep postponing sending indefinitely, and if called with block set to true, it will indeed block until it was possible to send the buffer. Blocking is actually also a bad idea, as the same thread is responsible for sending data in the other direction as well, and the client application may also still be sending, and the thread also has to listen for messages from the Engine object (Engine.cpp). A possible improvement could be to have two threads instead of one per session, but I have chosen to solve the problem like this, and logging it thoroughly. Note that before blocking, the internal buffer is increased up to 1MB, see TcpEndpoint::queuebuf in Tcp.cpp.


This file is responsible for resolving dns names, and finding the public ip through external services. The file is per default using my own service, but in the top of the file, you will find two other options I have found on the internet that you can use instead by uncommenting the desired option only and rebuild the proxy.


This directory contains a simple setup program that can be used to configure the proxy without getting your hands greasy in the registry editor. Note that it has two modes, guided by the radiobutton in the top, one to configure the program 'locally' for the current user only (when the proxy is run with -l, intended for testing), and another to configure the program 'globally' when run as a service (or without -l).


Last revised: 2014-12-10