Live data from Hacker News

Show HN: Tunnelling TCP through a file

github.com

1–10 of 42 posts

Show HN: Tunnelling TCP through a file

#1
This program can be used to tunnel TCP connections through a file.

People have used it for interesting things:

- Bridging connections which would otherwise be blocked by a firewall

- Tunneling through RDP (similar to an SSH tunnel)

- Exposing a localhost web server to others

Key features I put effort into:

1. The shared file is restarted every 10 MB, so it doesn't grow indefinitely.

2. Optimisations for latency & bandwidth. (800 Mbps on a Gigabit LAN. 108 Mbps if file tunneling through RDP)

3. Synchronisation between two sides (each side can be started and restarted in any order)

I'd love to hear about any weird and wonderful uses you might have for it.

Thanks, Fidel

Show HN: Tunnelling TCP through a file
github.com

Re: Show HN: Tunnelling TCP through a file

#2
That’s cool. A question that immediately comes to my mind is this: how is this different than using the Windows SMB native support for named pipes over the IPC$ share? From your example it would seem the users on both sides of the share would require the same AAA for your implementation as would be required to use IPC$ via SMB.

If that is indeed the case, (I am not a Windows pr SMB expert, so perhaps you will tell me it is not the case and to be clear, I am not asserting that it is or trying to say anything negative; I am just curious and you seem like a pretty likely source to be able to answer the question, since something motivated you to write this tool)

One difference would seem at first brush is that a named pipe used for this would not need to be periodically truncated in 10 minute intervals to prevent runaway file growth. Again, not knocking what you’ve made at all, I’m genuinely curious for the answer.

Re: Show HN: Tunnelling TCP through a file

#5

Neat idea. For better performance, you might want to use native filesystem APIs, for example on windows use CreateFile with the FILE_WRITE_THROUGH flag to prevent caching and and extra flushing.

I think you can use named pipes if you are using SMB. Here is a example code in python (not tested).

import socket import win32pipe import win32file import sys

BUFFER_SIZE = 4096

def create_pipe(pipe_name): return win32pipe.CreateNamedPipe(pipe_name, win32pipe.PIPE_ACCESS_DUPLEX, win32pipe.PIPE_TYPE_BYTE | win32pipe.PIPE_READMODE_BYTE | win32pipe.PIPE_WAIT, 1, BUFFER_SIZE, BUFFER_SIZE, 0, None)

def open_pipe(pipe_name): return win32file.CreateFile(pipe_name, win32file.GENERIC_READ | win32file.GENERIC_WRITE, 0, None, win32file.OPEN_EXISTING, 0, None)

def proxy_server(machine_name): server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind(('0.0.0.0', 8080)) server_socket.listen(1)

    pipe_name_1 = r'\\' + machine_name + r'\pipe\proxy_pipe_1'
    pipe_name_2 = r'\\' + machine_name + r'\pipe\proxy_pipe_2'

    while True:
        client_socket, _ = server_socket.accept()
        pipe_1, pipe_2 = create_pipe(pipe_name_1), create_pipe(pipe_name_2)
        win32pipe.ConnectNamedPipe(pipe_1, None)
        win32pipe.ConnectNamedPipe(pipe_2, None)

        while True:
            data = client_socket.recv(BUFFER_SIZE)
            if not data:
                break
            win32file.WriteFile(pipe_1, data)
            response = win32file.ReadFile(pipe_2, BUFFER_SIZE)[1]
            client_socket.send(response)

        client_socket.close()
        win32file.CloseHandle(pipe_1)
        win32file.CloseHandle(pipe_2)
def proxy_client(server_name, machine_name): target_host, target_port = 'cnn.com', 80

    pipe_name_1 = r'\\' + server_name + r'\pipe\proxy_pipe_1_' + machine_name
    pipe_name_2 = r'\\' + server_name + r'\pipe\proxy_pipe_2_' + machine_name

    pipe_1, pipe_2 = open_pipe(pipe_name_1), open_pipe(pipe_name_2)
    target_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    target_socket.connect((target_host, target_port))

    while True:
        data = win32file.ReadFile(pipe_1, BUFFER_SIZE)[1]
        if not data:
            break
        target_socket.send(data)
        response = target_socket.recv(BUFFER_SIZE)
        win32file.WriteFile(pipe_2, response)

    target_socket.close()
    win32file.CloseHandle(pipe_1)
    win32file.CloseHandle(pipe_2)
if __name__ == '__main__': if len(sys.argv)
    mode, machine_name = sys.argv[1], sys.argv[2]

    if mode == 'server':
        proxy_server(machine_name)
    elif mode == 'client':
        if len(sys.argv) 

Re: Show HN: Tunnelling TCP through a file

#7

That’s cool. A question that immediately comes to my mind is this: how is this different than using the Windows SMB native support for named pipes over the IPC$ share? From your example it would seem the users on both sides of the share would require the same AAA for your implementation as would be required to use IPC$ via SMB. If that is indeed the case, (I am not a Windows pr SMB expert, so perhaps you will tell me…

There are many other protocols besides SMB that can be used to share a file. Webdav, ftp, nfs, two systems accessing a third file share, shared folders in a VM, ... Or a file share provided by RDP like in the example, which does not include the IPC share as far as I know.

Re: Show HN: Tunnelling TCP through a file

#8

So there’s multiple writers to the file? How is this arbitrated? Also how does either side know when the file has been updated?

It looks like one file per direction, and this is a point to point connection. It looks like each side just reads to the end of the file and then tries to read more to see if any new data is available.

Re: Show HN: Tunnelling TCP through a file

#9
post #7

That’s cool. A question that immediately comes to my mind is this: how is this different than using the Windows SMB native support for named pipes over the IPC$ share? From your example it would seem the users on both sides of the share would require the same AAA for your implementation as would be required to use IPC$ via SMB. If that is indeed the case, (I am not a Windows pr SMB expert, so perhaps you will tell me…

There are many other protocols besides SMB that can be used to share a file. Webdav, ftp, nfs, two systems accessing a third file share, shared folders in a VM, ... Or a file share provided by RDP like in the example, which does not include the IPC share as far as I know.

Hah! You answered my question re how is it different. It’s strange… I re-read your comment twice a with a furrowed brow: “provided by RDP like in the example” and kept thinking to myself “what? There was a screenshot clearly showing…” yada yada SMB. So I went back to the look at the image in the readme. /smh. You know how they say eyewitness testimony is often among the least accurate, even immediately after the incident in question, yet the eyewitness is always so sure, “but I just saw it and…” Wow. Mind playing tricks on me.

Anyway, you’re right, there was no SMB involved in that readme. :-) So strange when you can’t trust your own eyes or short-term memory. Crazy.

Post reply on HN