Comment by hks0 | Hacker News Reader

Comment by hks0 | Hacker News Reader

I used to live in a country who is also a customer of GFW. Before v2ray came out, I had figured out devising any random protocol would defeat it. I would pass my SSH connecting used for socks5 through ROT13 or any ROTn, then the firewall won't gradually slow it down towards total stall after a few kilobytes. OpenSSH yells its name and version in plain text upon connection.

A few years later (still before v2ray) they got more aggressive: Unknown protocols were stalled after a few kilobytes. I then learned if I pretend I'm doing something legitimate (!) such as downloading favicon.ico within a proper HTTP channel, they won't touch my "packets" (the favicon content was my packet). I think there was also a Iodine project doing the same with ping packets but it was slower than favicon-as-packets for me. Today I see v2ray has taken it to the maximum extent, suggesting valid web page front for an IP, valid https certificates, etc.

When I started making money I was thinking about renting many IPs and send my traffic as round-robin to them as the detection relied heavily on IP consistency. That is, connections were fingerprinted by IP.

I don't live there anymore and don't get to verify this hypothesis, but given the leaked source codes it's an intersting weekend project.

What else is also interesting, I looked at traffic decoders in the list of leaked source files: TCP, HTTP, QUIC, ... but no mention of UDP, which made no difference in bypassing GFW. I guess the same IP rate limiter was at work with UDP at a lower level.

From my own personal experience with an outline server running on the same IP over 3 years, the GFW consistently ends up blocking it around 3 days after I first connect. Outline does use shadowsocks to obfuscate but I suspect the traffic detection is what triggers it after 3 days of observations. Running multiple servers and repeatedly cycling through them is an experiment I want to try the next time I'm there.

I've also observed similar behavior with the vpn I'm using as backup where the server I'm using tends to get blocked in around the same timeframe. It's using openvpn/wireguard as the underlying protocol which doesn't try to obfuscate itself so I suspect traffic pattern analysis plays a larger role in what gets blocked than the protocol itself. The exception was my recent trip week-long trip where I was mostly cycling between two servers without noticing either being blocked.

Makes sense; the "3 days" you mention reminds me of something sad ~10 years ago. At an expo, there was this company "Dowran" with a banner boasting about "adjustable internet disruption patterns on demand" and other corporate catch phrases. I can assume there's an operator who installs GWF and puts "3" as part of installer wizard.

>GFW consistently ends up blocking it around 3 days after I first connect

I saw a lot of speculation years ago that the GFW used to flag connections for human review. 3 days sounds like support ticket turnaround.

> I would pass my SSH connecting used for socks5 through ROT13 or any ROTn, then the firewall won't gradually slow it down towards total stall after a few kilobytes. OpenSSH yells its name and version in plain text upon connection.

Could you elaborate on that more? I'd love to dig into an implementation that does this, in case you still have the tools/scripts/programs available.

I'm asking because for the last couple years I've been on and off working on my warps [1] soft router prototype which aims to hide in plain sight using exfil network protocols.

(Think of it like DNS/HTTP smuggling but with the idea to use similar techniques in other network protocols, too)

[1] https://github.com/tholian-network/warps

The original PoC I had was incredibly simple: Just a python script that read traffic on a port on localhost, rotate each byte by a hard-coded number like 13, and send it over the wire. The counter part would run on the target server, read the byte and undo the rotation. It has zero (minus?) cryptographic security, but that's not the purpose here anyway. The PoV forwarder was transparent and could only tunnel port 22 of target server to 22000 of localhost.

Later I made a more elaborate version where it implemented its own HTTP and SOCKS4/5 proxy servers; I think you won't like it :D I wrote it in Java using Netty more than a decade ago, and published to Github when I relocated. Using Java I could run it directly as an android app or on a PC more easily.

This is the project: https://github.com/hkoosha/massrelay

Using Netty's vocabulary: If you add one extra HTTP handler to the pipeline, you get what I initially implemented in various forms:

- An HTTP handler that reads a header, say `Cache-Control: max-age=N` where N is the rotN to rotate bytes. - Next handler that starts rotating traffic bytes with the given `N`

For favicon-as-packet, my implementation was again with massrelay project but I forgot all the details. It shouldn't be hard: Netty keeps track of the connection state (packet number, etc...) and the handlers wrap/unwrap the traffic within favicon as transferred within HTTP channel.

Netty is a beautiful framework. I see you made your warps project in go, so the concepts might make more time to implement if you want to translate directly to a go project; Or you can just forget about massrelay and implement within your go project from scratch the way it makes sense, since the idea is pretty itself simple.

(That being said, I think GWF has advanced a lot, that's why something proper like v2ray works better now).

I have a similar program, which i call Relay, which effectively works exactly the same. Haven't worked on it in over 10 years but like OP i was in a similar situation, and it worked nicely, but really theres so much more that can be done in the obfuscation field. I eventually moved on to a more elaborate Java version, which worked very well when emulating, of all things, a TeamViewer connection, which had to be allowed on the network in question. So unless the firewall wanted to open up the ssl inside of it and examine in real time, i ended up not tipping it off. I'll add a very basic version of it for educational value if you want. It might not be exactly functional the way i remember but at least it shows how to chain a socket connection in code.

http://www.jofla.net/C++__/OWRTRelay/

Its a very minimal C program which was originally targeted for OpenWRT. But being C it should run easily most places. One would run on a router on a final remote server and another on a travel router which you would tether to.

YourPC <---> Your Travel Router <----internet----> Stationary Router <---> Final Server

Setting up the ports accordingly you had something which basically 'patched' the bytestream in the middle without it even knowning or needing to be changed on either end. It could relay any TCP connection.

There were many dialects which I eventually came up with (especially per packet length obfs) which could be added to the old C program.

Happy Hunting.

Reply on news.ycombinator.com