blissfulness be with me.
Friday, 12 February 2016
ProxyGambit 是一个简单的匿名设备，可以让你在世界的任何地方访问互联网，并且不会透露你的真实位置或IP，它可以通过长距离无线链路或者反向隧道 GSM 桥，从 Internet/IP 支裂你的流量，最终又返回到互联网，然后从一个离你很远的无线网络退出来。 Anonymize and fracture network traffic/Internet access over a point-to-point wireless link or through TCP->GSM->wifi tunnel (advanced resurrection of ProxyHam)http://samy.pl/proxygambit/
ProxyGambit is a simple anonymization device that allows you to access the Internet from anywhere in the world without revealing your true location or IP, fracturing your traffic from the Internet/IP through either a long distance radio link or a reverse tunneled GSM bridge that ultimately drops back onto the Internet and exits through a wireless network you're no where near.
While a point to point link is supported, the reverse GSM-to-TCP bridge allows you to proxy from thousands of miles away with nothing other than a computer and Internet with no direct link back to your originating machine.
A high speed (150Mbps+) link is available with direct line of sight from 10km+ away, or if further away, a 2G GSM connection produces a reverse TCP tunnel serializing a shell into the device accessible from anywhere in the world via the Internet or GSM. Either method proxies your connection through local wifi networks near the device, shielding and making it more difficult to determine your true location, IP and identity.
ProxyGambit improves upon ProxyHam not only by allowing a greater direct range, but also enables you to proxy fromanywhere in the world using just an Internet connection, which can then proxy through a reverse GSM serial link onto a public wifi network.
Once set up, no special hardware is needed to bridge through the GSM link and back out onto wifi -- just you, a computer and a net connection (which will not be as easily identified.)
This is an insecure, bare bones proof of concept. The fragmentation of data through alternate mediums is a useful and effective concept and those interested in privacy, anonymization, or deanonymization should explore this area further. Entropy is both gained and lost with these methods and many risks are involved when deploying any system of this nature.
Code available on github, Linux image available here
$35: A Raspberry Pi 2 Model B (or cheaper RPi Model B+) computer is a critical portion of the core and drives the Linux serial link while also bridging our public wifi to radio connection.
$8: Any ATmega328 device will suffice, such as my favorite Arduino Nano, which provides a software proxy layer between the serial UART of the Raspberry Pi and the FONA GSM board. A logic level converter or voltage divider is required to prevent imminent destruction of hardware which we perform with a few inexpensive resistors.
FONA GSM Board
$40: The Adafruit FONA GSM board uses a SIM800 chip which allows us to connect an Arduino to GSM, providing us a 2G Internet link, and can additionally allow SMSs and voice calls to our friends to verify whether their refrigerators are running.
$98: For low cost and low profile, I suggest either a pair of the Ubiquiti NanoStation LocoM2s (2.4GHz) which reach 5km+, or a pair of the Ubiquiti NanoStation LocoM5s (5GHz) which reach 10km+, but are slightly more expensive at $62 or $124 for both. These devices are not interchangeable. Additionally, if you choose the LocoM5, you can actually use one of the devices to acquire Internet access at Burning Man.
$10: You can use anything such as an Edimax adapter, or a more powerful Alfa AWUS036NH adapter. This all depends on how far you'd like your ProxyGambit device to reach. This is specifically to connect to the "exit node" of the proxy link where your Internet traffic will ultimately come out of and appear to be coming from.
$8: You will need a SIM card with access to a 2G network. You can purchase prepaid SIM cards in cash with 2G through T-Mobile.
$6: An SD card is required for the Raspberry Pi to host the operating system and data.
Powered USB Hub
$10: I avoid two issues with Raspberry Pi -- the limited power output from USB, and the limited power input from most USB power supplies. I do this by using a 2.5A powered USB hub in a virtual loop. The hub acts as the power supply for the Raspberry Pi, preventing any need for a power supply, while ironically I connect the source of the hub back into one of the Raspberry Pi USB slots. This may appear dangerous as a voltage or data loop, but the Pi's USB-voltage-in has data lines split off, and the USB hub prefers power from its voltage rectifier rather than the recirculated power lines.
3.7 Lithium-Ion (LiOn or LiPo) Battery
$13: The FONA GSM board annoyingly requires a 3.4-4.0V voltage source in addition to a 5V source, so I use a small lipo battery for this. The FONA has a built-in charger so I tie the charger directly to the 5V from the Arduino, which actually bypasses the Arduino voltage regulator and instead grabs power from our high-current USB hub.
The microcontroller code produces a serial connection over a reverse TCP tunnel through a 2G GSM link and ties it to the UART serial lines of the Raspberry Pi. Compile this onto your Arduino, but be sure to change the TCP_PORT and TCP_HOST definitions in pg_gsm_avr.ino to connect to your own server. We abuse the fact that the SIM800 GSM chip allows only outbound TCP connections and produce a reverse tunnel. The hardware serial lines are hardwired (with a voltage divider) to the Raspberry Pi's serial, and we employ software serial to communicate to the FONA board.
We use the Adafruit FONA library to produce an outbound TCP connection over the 2G GSM/GPRS link. This actually allows a reverse tunnel back in which we link to serial.
Raspberry Pi Linux Image w/Network Bridging + UART
We use Raspberry Pi Wheezy (2015-05-05) image with network bridging via bridge-utils and serial UART enabled to communicate with our microcontroller. Make sure to set up the wifi connection you want to use via/etc/wpa_supplicant/wpa_supplicant.conf, or you can serial in over GSM later on to connect to a network.
The SIM800 is not able to open listening sockets, but is capable of making outbound TCP connections. We abuse this property to bridge traffic that was once IP into GSM traffic, but upon retrieval, we tunnel it back into IP through an entirely different, unrelated and physically separated network (the exit wifi node).
From your own server (defined in pg_gsm_avr.ino), run: