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 the and build another dll containing your own users.
You can also write code to read your users from the registry, a file or a
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
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