Last segment regarding Air-Gap and PGP I used USB to transfer files betweeen the online and offline Machine. Youtube commenters pointed out, what if USB gets pwned. Referenced Stuxnet. As someone who's had a lot of fun with USB hacking (Switchblade, Rubber Ducky) -- ok, I'll bite. Today we'll transfer files between two machines without USB, Ethernet, WiFi or Bluetooth.
First using 2D Barcodes
Matrix Barcodes or 2D Barcodes are a way of storing data across both the X and Y axis. This allows for a much higher data density. Common 2D barcodes include Data Matrix, Aztec Code and QR Code. The first two are public domain system with Data Matrix being able to handle some 2300 alphanumeric characters and Aztec handling around 3800 digits, 3000 letters, or 1900 bytes. While not exactly patent free, the QR Code or Quick Response Code, has become a defacto standard especially among smartphones. It was originally developed and patented by a Toyota subsidiary but they've chosen not to exercise the patent. It also has one of the higher densities being able to handle some 1200 ASCII characters with an error correction level of 30%.
This should be sufficient for short messages. Longer messages could be broken up into multiple codes. Thankfully generating them is quite simple on any platform.
Android demo using Barcode Generator. I love this app as it requires no special permissions at all.
qrencode -o hello.qr -t ANSI
cat message.asc | qrencode -o message.qr.png -t PNG; eom message.qr.png
Reading QR Code on another machine
zbarcam /dev/video0 --raw > message.txt
zbarcam /dev/video0 --raw --nodisplay > message.txt
Additional reading on QR codes
Second, using audio
First thought was to use something very basic like DTMF or Dual Tone Multi Frequency. You may remember it as touch tone from oldschool landlines. The other idea was to use CW or Continuous Wave. You likely know that as Morse Code.
Unfortunately Morse Code, while still as awesome today as it was in 1836, doesn't support more than an case insensitive alphanumeric characters. PGP messages rely on ASCII including upper and lowercase letters, numbers and special characters.
Still I think it's worth mentioning that Morse Code is still pretty cool and useful and can be transmitted and received using linux tools without much trouble. The FCC used to require Morse Code proficiency for Amateur Radio or HAM licenses but dropped that in 2007.
echo Hello World | cwpcm -f 3200 -w 120 > /dev/dsp
So to effectively transmit ASCII from one computer to another over audio we'll have to use a more modern encoding scheme. And while this would be an awesome opportunity to break out soundmodem and get into AX.25 networking - I'll save that for another day. Instead I'm going to turn back to the good ol days of Bell Tones and Frequency Shifty Keying. That's right - we're going back to baud rates and modems.
Modem: Modulator, Demodulator. Typically over POTS. You may remember your old 56k modem but before that the original models used a primitive technique of alternating between two audio frequencies which corresponded to two different bits, say a one and a zero. These two symbols were measured by their baud rate or symbols per second. The first commercial modems for computers were the Bell 101 modem in 1958 and Bell 103 modem in 1962. They operated at 110 baud and 300 baud respectively. The Bell 103 was pretty sophisticated using a pair of frequencies for the calling party and a separate pair of frequencies for the answering party.
Little trivia for you: It used to be that only AT&T equipment could be connected to the telephone network. I won't descend into a rant about proprietary networks and state endorsed monopolies, but suffice it to say the brilliant hack of the day was to use an acoustic coupler on your Bell handset. A set of microphone and speaker suction cups would connect to the handset. Check out War Games.
Now to give you some perspective at 300 baud the average HD Hak5 episode weighing in at about a gigabyte would take around 330 days to download. A megabyte would take around 8 hours.
Thankfully we're not transferring megabytes, just short PGP messages so this should be quite sufficient.
minimodem --rx --ascii 110
minimodem --tx --ascii 110
Of course message integrity could be increased by using an audio cable from one computer to the next, but that wouldn't make for such a loud and obnoxious demo - would it?
So what do you think? Are you ready to hot glue your USB ports and take a step back to 1960s analog technology? Let me know in the comments or email directly, email@example.com. You can also find my PGP key at hak5.org/keys/darren and be sure to check out the full show notes at Hak5.org for links to further reading on the subject.
BitTorrent Labs released a file sharing application called BitTorrent Sync recently, as a competitor to Dropbox, OwnCloud, and SparkleShare. It IS closed source though, so there's a con.
It was designed with security and encryption in mind. Files are transferred using AES-128 encryption, and session keys are generated using Perfect Forward Secrecy. Keys are randomly created using /dev/random for Mac and Linux and Crypto API for Windows. Files are transferred securely, but security must also be in effect on each machine, because the files will be save in their unencrypted state.
It works similarly to Dropbox, in that it syncs a folder from one computer to the next, and can also be used via mobile. Syncing is fast and efficient, and relatively easy to set up. BitTorrent Sync runs on Peer to peer protocol, the same protocol used by uTorrent and BitTorrent. It lets you transfer large files among your PC's relatively fast.
There is no central company server, and all files are just directly synced from one pc to another, cross platform. Works on Win, Mac, Linux, Android, iOS.
On mobile, you can send files from Android to iOS or vice versa with a QR Code in the app, and download a backup of your phone onto your computer.