# PSC | E2E Encryption For Multi-Hop Tty Sessions Or Portshells + TCP/UDP Port Forward **URL:** \ **Category:** Tools & Scripts\ **Tags:** tools, programming, gaming\ **Created:** [January 31, 2021, 9:43am UTC](https://onehack.st/t/psc-e2e-encryption-for-multi-hop-tty-sessions-or-portshells-tcp-udp-port-forward/171434 "2021-01-31T09:43:20Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![TheStrength](https://onehack.st/user_avatar/onehack.st/thestrength/32/46753_2.png) [@TheStrength](https://onehack.st/u/TheStrength)\ **Post date:** [January 31, 2021, 9:43am UTC](https://onehack.st/t/psc-e2e-encryption-for-multi-hop-tty-sessions-or-portshells-tcp-udp-port-forward/171434/1 "2021-01-31T09:43:20Z")
![image](https://onehack.st/uploads/default/original/3X/2/9/293f579d2d68988baf4836a2de32a3b6027d55d6.png) # PortShellCrypter – PSC [![asciicast](https://camo.githubusercontent.com/dd4bd84c1b22bba8b782b4c36945a09a0867b684ffdc1e72b2d54ea852923ebb/68747470733a2f2f61736369696e656d612e6f72672f612f3338333034332e737667)](https://asciinema.org/a/383043) _DNS lookup and SSH session forwarded across an UART connection to a Pi_ PSC allows to e2e encrypt shell sessions, single- or multip-hop, being agnostic of the underlying transport, as long as it is reliable and can send/receive Base64 encoded data without modding/filtering. Along with the e2e pty that you receive (for example inside a portshell), you can forward TCP and UDP connections, similar to OpenSSH’s `-L` parameter. This works transparently and without the need of an IP address assigned locally at the starting point. This allows forensicans and pentesters to create network connections for example via: - UART sessions to a device - `adb shell` sessions, if the OEM `adbd` doesn’t support TCP forwarding - telnet sessions - modem dialups without ppp - other kinds of console logins - mixed SSH/telnet/modem sessions - … Just imagine you would have an invisible ppp session inside your shell session, without the remote peer actually supporting ppp. It runs on _Linux, Android, OSX, FreeBSD, NetBSD_ and (possibly) _OpenBSD_. PSC also includes _SOCKS4_ and _SOCKS5_ proxy support in order to have actual web browsing sessions via portshells or modem dialups remotely. ## Build Edit the `Makefile` to reflect your pre shared keys, as defined at the top of the `Makefile`. Then just type `make` on _Linux_. On _BSD_, you need to install _GNU make_ and invoke `gmake` instead. On _OSX_, you need to install _OpenSSL_ and declare the apropriate installation path inside the `Makefile` and type `make`. On _Linux_, PSC will use _Unix98_ pseudo terminals, on other systems it will use _POSIX_ pty’s but that should be transparent to you. I once added _4.4BSD_ pty and _SunOS_ support back in the stone age for a particular reason, so it may or may not build even with _Solaris_. ## Usage Plain and simple. On your local box, execute `pscl`, and pass any TCP or UDP ports you want to forward _from_ the remote site to a particular address. For example: ```auto linux:~ > ./pscl -T 1234:[192.168.0.254]:22 -U 1234:[8.8.8.8]:53 PortShellCrypter [pscl] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc pscl: set up local TCP port 1234 to proxy to 192.168.0.254:22 @ remote. pscl: set up local UDP port 1234 to proxy to 8.8.8.8:53 @ remote. pscl: Waiting for [pscr] session to appear ... linux:~ > [UART / SSH / ... login to remote side ...] ``` On the remote site (the last hop) with the shell session, no matter if its in a portshell, SSH, console login etc, you execute `pscr`: ```auto linux:~ > ./pscr PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc pscl: Seen STARTTLS sequence, enabling crypto. linux:~ > ``` Once you execute `pscr`, both ends establish a crypto handshake and lay an additional protocol over your existing session that is transparent for you. You can then connect to `127.0.0.1:1234` on your local box to reach `192.168.0.254:22` via TCP or the `8.8.8.8` resolver via UDP. This also works with [IPv6] addresses, if the remote site has IPv6 connectivity. Actually, you can even use it to translate IPv4 software to IPv6, since you always connect to `127.0.0.1` on the local side. You can pass multiple `-T` and `-U` parameters. If you lost track if your session is already e2e encrypted, you can send a `SIGUSR1` to the local `pscl` process, and it will tell you. PSC is also useful if you want to use tor from a remote SSH shell, where you can forward the socks5 and the DNS port to the remote hosts `127.0.0.1` address. Since SSH does not forward UDP packets, you would normally use two `socat` connectors or similar to resolve via the tor node. PSC has the advantage of keeping the UDP datagram boundaries, while `socat` over `SSH -L` may break datagram boundaries and create malformed DNS requests. The session will be encrypted with `aes_256_ctr` of a PSK that you choose in the `Makefile`. This crypto scheme is mallable, but adding AAD or OAD data blows up the packet size, where every byte counts since on interactive sessions and due to Base64 encoding, each typed character already causes much more data to be sent. UART sessions may be used via `screen` but for example not via `minicom` since minicom will create invisible windows with status lines and acts like a filter that destroys PSC’s protocol. PSC tries to detect filtering and can live with certain amout of data mangling, but in some situations it is not possible to recover. Similar thing with `tmux`. You should avoid stacking pty handlers with PSC that mess/handle their incoming data too much. The `SHELL` environment variable needs to be set for both `pscl` and `pscr` in order for PSC to know which shell to execute on the pty. `SHELL` is set in most environments by default, but in case it isn’t, PSC needs to be executed like `SHELL=/bin/bash pscl` etc. ## SOCKS4 and SOCKS5 support `pscl` also supports forwarding of TCP connections via _SOCKS4_ (`-4 port`) and _SOCKS5_ (`-5 port`). This sets up _port_ as SOCKS port for TCP connections, so for instance you can browse remote networks from a portshell session without the need to open any other connection during a pentest. For _chrome_, _SOCKS4_ must be used, as the PSC SOCKS implementation does not support resolving domain names on their own. Instead, it requires IPv4 or IPv6 addresses to be passed along. Since _chrome_ will set the _SOCKS5_ protocol _address type_ always to _domain name_ (`0x03`) - even if an IP address is entered in the address bar - SOCKS5 is not usuable with _chrome_. But you can use _chrome_ with _SOCKS4_, since this protocol only supports IPv4 addresses, not domain names. ## GitHub: > **[GitHub - stealth/psc: E2E encryption for multi-hop tty sessions or...](https://github.com/stealth/psc)** > > E2E encryption for multi-hop tty sessions or portshells + TCP/UDP port forward