{ "id": "ac402d1b-e946-48b3-867e-dd88b0109cb8", "created_at": "2026-04-06T00:13:58.629068Z", "updated_at": "2026-04-10T03:20:21.097369Z", "deleted_at": null, "sha1_hash": "d93816c89ff1ecfc9ce31b01c034328d48fa4650", "title": "GitHub - EddieIvan01/iox: Tool for port forwarding \u0026 intranet proxy", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 75972, "plain_text": "GitHub - EddieIvan01/iox: Tool for port forwarding \u0026 intranet\r\nproxy\r\nBy EddieIvan01\r\nArchived: 2026-04-05 19:53:23 UTC\r\nEnglish | 中文\r\nTool for port forward \u0026 intranet proxy, just like lcx / ew , but better\r\nWhy write?\r\nlcx and ew are awesome, but can be improved.\r\nWhen I first used them, I can't remember these complicated parameters for a long time, such as tran, slave,\r\nrcsocks, sssocks... . The work mode is clear, why do they design parameters like this(especially ew 's -l -d\r\n-e -f -g -h )\r\nBesides, I think the net programming logic could be optimized.\r\nFor example, while running lcx -listen 8888 9999 command, client must connect to :8888 first, then\r\n:9999 , in iox , there's no limit to the order in two ports. And while running lcx -slave 1.1.1.1 8888 1.1.1.1\r\n9999 command, lcx will connect two hosts serially, but it's more efficient to connect in concurrent, as iox\r\ndoes.\r\nWhat's more, iox provides traffic encryption feature (it's useful when there is a IDS on target). Actually, you can\r\nuse iox as a simple ShadowSocks.\r\nAnd iox also provides UDP traffic forward.\r\nOf course, because iox is written in Go, the static-link-program is a little large, raw program is 2.2MB (800KB\r\nafter UPX compression)\r\nFeatures\r\nTraffic encryption (optional)\r\nHumanized CLI option\r\nLogic optimization\r\nUDP traffic forward\r\nTCP multiplexing in reverse proxy mode\r\nUsage\r\nhttps://github.com/EddieIvan01/iox\r\nPage 1 of 4\n\nYou can see, all params are uniform. -l/--local means listen on a local port; -r/--remote means connect to\r\nremote host\r\nNote: after v0.4, -l/--local could specify which IP to listen on. If only ports are specified, the default is\r\n0.0.0.0:PORT\r\n-l 127.0.0.1:9999 -l *127.0.0.1:9999 # 127.0.0.1:9999\r\n-l 9999 -l *9999 # 0.0.0.0:9999\r\n`-l :9999` is also OK, but it's not recommended. Because `-l *:9999`(listen on 0.0.0.0:9999 with encryption) is\r\nWorking mode\r\nfwd\r\nListen on 0.0.0.0:8888 and 0.0.0.0:9999 , forward traffic between 2 connections\r\n./iox fwd -l 8888 -l 9999\r\nListen on 0.0.0.0:8888 , forward traffic to 1.1.1.1:9999\r\n./iox fwd -l 8888 -r 1.1.1.1:9999\r\nConnect 1.1.1.1:8888 and 1.1.1.1:9999 , forward between 2 connection\r\n./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999\r\nproxy\r\nStart Socks5 server on 0.0.0.0:1080\r\nStart Socks5 server on be-controlled host, then forward to internet VPS\r\nVPS forward 0.0.0.0:9999 to 0.0.0.0:1080\r\nYou must use in a pair, because it contains a simple protocol to control connecting back\r\n./iox proxy -r 1.1.1.1:9999\r\n./iox proxy -l 9999 -l 1080 // notice, the two port are in order\r\nfor ew:\r\nhttps://github.com/EddieIvan01/iox\r\nPage 2 of 4\n\n./ew -s rcsocks -l 1080 -e 9999\r\n./ew -s rssocks -d 1.1.1.1 -e 9999\r\nThen connect intranet host\r\n# proxychains.conf\r\n# socks5://1.1.1.1:1080\r\n$ proxychains rdesktop 192.168.0.100:3389\r\nEnable encryption\r\nFor example, we forward 3389 port in the intranet to our VPS\r\n// be-controller host\r\n./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565\r\n// our VPS\r\n./iox fwd -l *8888 -l 33890 -k 656565\r\nIt's easy to understand: traffic between be-controlled host and our VPS:8888 will be encrypted, the pre-shared\r\nsecret key is 'AAA', iox will use it to generate seed key and nonce (Normally, nonce shouldn't be reused. But\r\nconsider that iox's encryption is only for bypassing IDS, in order not to allocate extra space, the TCP\r\nstream encryption will reuse the nonce), then encrypt with Xchacha20 (replace AES-CTR with Xchacha20 in\r\nv0.3 version)\r\nSo, the * should be used in pairs\r\n./iox fwd -l 1000 -r *127.0.0.1:1001 -k 000102\r\n./iox fwd -l *1001 -r *127.0.0.1:1002 -k 000102\r\n./iox fwd -l *1002 -r *127.0.0.1:1003 -k 000102\r\n./iox proxy -l *1003 -k 000102\r\n$ curl google.com -x socks5://127.0.0.1:1000\r\nUsing iox as a simple ShadowSocks\r\n// ssserver\r\n./iox proxy -l *9999 -k 000102\r\nhttps://github.com/EddieIvan01/iox\r\nPage 3 of 4\n\n// sslocal\r\n./iox fwd -l 1080 -r *VPS:9999 -k 000102\r\nUDP forward\r\nOnly need to add CLI option -u\r\n./iox fwd -l 53 -r *127.0.0.1:8888 -k 000102 -u\r\n./iox fwd -l *8888 -l *9999 -k 000102 -u\r\n./iox fwd -r *127.0.0.1:9999 -r 8.8.8.8:53 -k 000102 -u\r\nNOTICE: When you make a multistage connection, the Remote2Remote-UDP-mode must be started last,\r\nwhich is the No.3 command in above example\r\nUDP forwarding may have behavior that is not as you expected. Actually, on GitHub now, there are only examples\r\nof forwarding a local listener to a remote host, so I can only implement them with my understanding\r\nYou can find why in the source code. If you have any ideas, PR / issue are welcomed\r\nLicense\r\nThe MIT license\r\nSource: https://github.com/EddieIvan01/iox\r\nhttps://github.com/EddieIvan01/iox\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://github.com/EddieIvan01/iox" ], "report_names": [ "iox" ], "threat_actors": [], "ts_created_at": 1775434438, "ts_updated_at": 1775791221, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d93816c89ff1ecfc9ce31b01c034328d48fa4650.pdf", "text": "https://archive.orkl.eu/d93816c89ff1ecfc9ce31b01c034328d48fa4650.txt", "img": "https://archive.orkl.eu/d93816c89ff1ecfc9ce31b01c034328d48fa4650.jpg" } }