nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-03-19 21:35:26 -05:00
Code Issues Projects Releases Wiki Activity
putty-source/windows/psocks.c

27 lines
549 B
C
Raw Normal View History

Auxiliary application: 'psocks', a simple SOCKS server. This is built more or less entirely out of pieces I already had. The SOCKS server code is provided by the dynamic forwarding code in portfwd.c. When that accepts a connection request, it wants to talk to an SSH ConnectionLayer, which is already a trait with interchangeable implementations - so I just provide one of my own which only supports the lportfwd_open() method. And that in turn returns an SshChannel object, with a special trait implementation all of whose methods just funnel back to an ordinary Socket. Result: you get a Socket-to-Socket SOCKS implementation with no SSH anywhere, and even a minimal amount of need to _pretend_ internally to be an SSH implementation. Additional features include the ability to log all the traffic in the form of diagnostics to standard error, or log each direction of each connection separately to a file, or for anything more general, to log each direction of each connection through a pipe to a subcommand that can filter out whatever you think are the interesting parts. Also, you can spawn a subcommand after the SOCKS server is set up, and terminate automatically when that subcommand does - e.g. you might use this to wrap the execution of a single SOCKS-using program. This is a modernisation of a diagnostic utility I've had kicking around out-of-tree for a long time. With all of last year's refactorings, it now becomes feasible to keep it in-tree without needing huge amounts of scaffolding. Also, this version runs on Windows, which is more than the old one did. (On Windows I haven't implemented the subprocess parts, although there's no reason I _couldn't_.) As well as diagnostic uses, this may also be useful in some situations as a thing to forward ports to: PuTTY doesn't currently support reverse dynamic port forwarding (in which the remote listening port acts as a SOCKS server), but you could get the same effect by forwarding a remote port to a local instance of this. (Although, of course, that's nothing you couldn't achieve using any other SOCKS server.)
2020-02-23 16:27:04 +00:00
/*
* Main program for Windows psocks.
*/
#include "putty.h"
#include "ssh.h"
#include "psocks.h"
static const PsocksPlatform platform = {
NULL /* open_pipes */,
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 10:18:38 +01:00
NULL /* found_subcommand */,
Auxiliary application: 'psocks', a simple SOCKS server. This is built more or less entirely out of pieces I already had. The SOCKS server code is provided by the dynamic forwarding code in portfwd.c. When that accepts a connection request, it wants to talk to an SSH ConnectionLayer, which is already a trait with interchangeable implementations - so I just provide one of my own which only supports the lportfwd_open() method. And that in turn returns an SshChannel object, with a special trait implementation all of whose methods just funnel back to an ordinary Socket. Result: you get a Socket-to-Socket SOCKS implementation with no SSH anywhere, and even a minimal amount of need to _pretend_ internally to be an SSH implementation. Additional features include the ability to log all the traffic in the form of diagnostics to standard error, or log each direction of each connection separately to a file, or for anything more general, to log each direction of each connection through a pipe to a subcommand that can filter out whatever you think are the interesting parts. Also, you can spawn a subcommand after the SOCKS server is set up, and terminate automatically when that subcommand does - e.g. you might use this to wrap the execution of a single SOCKS-using program. This is a modernisation of a diagnostic utility I've had kicking around out-of-tree for a long time. With all of last year's refactorings, it now becomes feasible to keep it in-tree without needing huge amounts of scaffolding. Also, this version runs on Windows, which is more than the old one did. (On Windows I haven't implemented the subprocess parts, although there's no reason I _couldn't_.) As well as diagnostic uses, this may also be useful in some situations as a thing to forward ports to: PuTTY doesn't currently support reverse dynamic port forwarding (in which the remote listening port acts as a SOCKS server), but you could get the same effect by forwarding a remote port to a local instance of this. (Although, of course, that's nothing you couldn't achieve using any other SOCKS server.)
2020-02-23 16:27:04 +00:00
NULL /* start_subcommand */,
};
int main(int argc, char **argv)
{
psocks_state *ps = psocks_new(&platform);
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 10:18:38 +01:00
CmdlineArgList *arglist = cmdline_arg_list_from_GetCommandLineW();
psocks_cmdline(ps, arglist);
Auxiliary application: 'psocks', a simple SOCKS server. This is built more or less entirely out of pieces I already had. The SOCKS server code is provided by the dynamic forwarding code in portfwd.c. When that accepts a connection request, it wants to talk to an SSH ConnectionLayer, which is already a trait with interchangeable implementations - so I just provide one of my own which only supports the lportfwd_open() method. And that in turn returns an SshChannel object, with a special trait implementation all of whose methods just funnel back to an ordinary Socket. Result: you get a Socket-to-Socket SOCKS implementation with no SSH anywhere, and even a minimal amount of need to _pretend_ internally to be an SSH implementation. Additional features include the ability to log all the traffic in the form of diagnostics to standard error, or log each direction of each connection separately to a file, or for anything more general, to log each direction of each connection through a pipe to a subcommand that can filter out whatever you think are the interesting parts. Also, you can spawn a subcommand after the SOCKS server is set up, and terminate automatically when that subcommand does - e.g. you might use this to wrap the execution of a single SOCKS-using program. This is a modernisation of a diagnostic utility I've had kicking around out-of-tree for a long time. With all of last year's refactorings, it now becomes feasible to keep it in-tree without needing huge amounts of scaffolding. Also, this version runs on Windows, which is more than the old one did. (On Windows I haven't implemented the subprocess parts, although there's no reason I _couldn't_.) As well as diagnostic uses, this may also be useful in some situations as a thing to forward ports to: PuTTY doesn't currently support reverse dynamic port forwarding (in which the remote listening port acts as a SOCKS server), but you could get the same effect by forwarding a remote port to a local instance of this. (Although, of course, that's nothing you couldn't achieve using any other SOCKS server.)
2020-02-23 16:27:04 +00:00
sk_init();
winselcli_setup();
psocks_start(ps);
cli_main_loop(cliloop_null_pre, cliloop_null_post, NULL);
}
Reference in New Issue Copy Permalink