Welcome to the Through Glass Transfer information site.
Through Glass Transfer is the label that has been given to a suite of tools that demonstrate the unauthorised infiltration and exfiltration of code and data through secure networks, particularly to highlight the vulnerability exposed through offshoring (human resources off-shore, systems and data on-shore) using commonly deployed enterprise security architectures. In that regard, the information presented on this site does not have a CVE-ID, because it does not reveal a new vulnerability in any specific application or technology, but rather a flaw in the end to end architecture.
ThruGlassXfer (TGXf) is a protocol and application designed to let people download files through a screen. It is a proof-of-concept created to demonstrate a long standing and poorly understood vulnerability in enterprise security.
The TGXf protocol is a transport protocol that allows one way transfer of data, between two peers, typically in the form of binary data bundles (files), though streams are possible. The protocol supports high latency, interrupted transfers and error detection. The TGXf transport protocol utilises QR codes as frames in an optical packet network, though it will work on any packet protocol. Quick Response Codes were chosen for the proof-of-concept because they were designed to be recognised and decoded rapidly by machine.
ThruGlassXfer (TGXf) is also an application. It has been built as a proof-of-concept to demonstrate the effectiveness of the TGXf protocol. The ThruGlassXfer (TGXf) app has been made available in both the Apple and Google app stores and Linux binaries for the transmit (server) side have been made available below.
ThruKeyboardXfer (TKXf) is a protocol and application designed to let people upload files through a keyboard. It is a proof-of-concept created primarily to support TGXf (by showing that it is trivial to upload the encoder to sensitive compute/server platforms), but TKXf also serves to demonstrate the same poorly understood vulnerability in enterprise security (though inbound, rather than outbound, from the enterprise perspective).
Like TGXF, the TKXf protocol is a transport protocol that allows one way transfer of data between two peers. Unlike TGXf however, the TKXf protocol only supports a basic file transfer capability (a binary file encoded in a shell script for the target system) with a simple control structure - i.e. no recoverability from interrupted transfers and no error detection. The TKXf protocol utilises the USB HID keyboard packet as frames in its packet network, though it will also work on any packet protocol. TKXf requires a hardware device to interface as the USB HID keyboard, the Arduino hobby platform was selected for its ease of use.
ThruKeyboardXfer (TKXf) is also an application. It has been built as a proof-of-concept to demonstrate the effectiveness of the TKXf protocol. The ThruKeyboardXfer (TKXf) software has been made available for the Arduino and Linux platforms - please see below.
ThruConsoleXfer (TCXf) is an application that combines both TKXf and TGXf to create an asynchronous network socket that passes from the most sensitive compute/server platforms through the screen and keyboard of end user computing devices owned by the enterprise, and terminates on an attacker controlled device.
By the nature of the component protocols, TCXf remains undetected and unmitigated by existing enterprise security architectures.
clientlessTGXf (clTGXf)
clientlessTGXf is an alternate implementation of TGXf. It is designed to demonstrate a screen based transfer that doesn't require a binary client on server targets (the DCE), where the stream can be captured and processed without a camera, and also shows that the QR code can be replaced with even ASCII text.
highspeedTGXf (hsTGXf)
Like clientlessTGXf, highspeedTGXf is an alternate implementation of TGXf. However, hsTGXf is designed to demonstrate a high performance (>1Mbps) screen based transfer that doesn't require a binary client on the target (the DCE), where the stream can be captured and processed without a camera, and also shows that the QR code can be replaced with raw pixel data.
Watch TGXf demonstrations:
Watch TKXf demonstrations:
Watch a TCXf demonstration:
Watch clientlessTGXf demonstrations:
Watch highspeedTGXf demonstrations:
ThruGlassXfer (TGXf)
Anywhere that data can be visually rendered, technical risk will exist.
TGXf encodes binary data into packets that can be displayed on the screen of one computer and then captured (via camera) on another, where they are decoded and the data is stored on disk. By doing this, TGXf turns any display surface into an egress (outbound) binary data transfer interface.
ThruKeyboardXfer (TKXf)
Anywhere that data can be entered, technical risk will exist.
As a part of the development process for TKXf, a TKXf-like transfer was created by encoding a binary payload and storing it on a programmable keyboard (the Arduino platform with USB HID keyboard capability) which sends this payload as a script (currently BASH or PERL) that is typed into the target system. When run, this script exports the original binary payload. See the image: ThruKeyboardXfer (TKXf) programmable keyboard.
TKXf encodes binary data into packets that can be sent out of the serial port of one computer and entered via keyboard on another, where they are decoded and the data is stored on disk. By doing this, TKXf turns any keyboard interface into an ingress (inbound) binary data transfer interface. The TKXf-like programmable keyboard device is transformed into a TKXf keyboard stuffer by adding a USB serial interface for the attacker's computer. This change allows the attacker to send a continuous steam of data (rather than a single pre-programmed file). See the image: ThruKeyboardXfer (TKXf) keyboard stuffer.
ThruGlassXfer (TGXf) and ThruKeyboardXfer (TKXf)
Given that in each case (TGXf and TKXf) these are simply a new type of file transfer protocol, the proof-of-concept software does not create new risk when being used to transfer files between consenting parties. However, there are common use cases where one party would not want to consent, and one of those cases is the remote worker (particularly an offshore partner).
When a remote worker (VPN user) with read access to files on a company's computers, uses TGXf to download those files, or TKXf to upload malicious software, that user circumvents the company's security controls. Controls such as packet filtering (firewalls), harmful code detection/containment (AV), intrusion detection or prevention systems (IDS/IPS), unauthorised change detection and data leakage prevention (DLP) all fail to mitigate these protocols. Defence in depth strategies that layer multiple session termination points (such as jump hosts, virtual desktops and hosted application environments) fail to mitigate both TKXf and TGXf, as in both cases the screen and keyboard is abstracted from zone to zone (at the application layer), and in the case of TGXf the protocol is capable of leveraging both terminal and graphical interfaces.
The included screen shot is of a graphical desktop with terminal software displaying a TGXf packet rendered via ANSI terminal sequences (which would also work through your browser while viewing this page). See the image: ThruGlassXfer (TGXf) via xterm using ANSI codes.
ThruConsoleXfer (TCXf)
By removing the file-based transfer aspects of each protocol (TGXf and TKXf) and then combining both protocols into a single application, ThruConsoleXfer, TCXf is now able to create an asynchronous TCP socket that routes the egress data flow via the screen and camera (TGXf) and the ingress data flow via the keyboard (TKXf). See the image: ThruConsoleXfer (TCXf) application architecture.
ThruConsoleXfer (TCXf) application architecture
When TCXf is deployed, the Data Center End (DCE) is run on the application server, routed via the screen and keyboard of the end user computing platform that the enterprise gave to the attacker (in this case, the offshore partner), and the Personal Computer End (PCE) is run on the attacker's own computer (outside of enterprise control). In this way, TCXf transparently traverses the entire enterprise security architecture unchecked and unmitigated. See the image: ThruConsoleXfer (TCXf) enterprise impact.
For more technical detail, please see the TCXf White Paper.
clientlessTGXf (clTGXf)
clientlessTGXf provides the same file transfer functionality as TGXf but via an alternate implementation.
The receiving device for clientlessTGXf is a HDMI capture device that stores the video stream as a video file (MP4). The video file is then processed frame by frame for TGXf packets that are decoded and written to disk.
The risk to heed from clientlessTGXf is that regardless of the proof-of-concept implementations on this site, in practice, data could be encoded in the display in any format - graphically as pixel data or images and logos, or in text as letters, words or phrases. I.e. don't dwell exclusively on application signatures or particular data structures (like QR codes).
highspeedTGXf (hsTGXf)
highspeedTGXf provides the same file transfer functionality as TGXf but via an alternate implementation.
Like clientlessTGXf, the receiving device for highspeedTGXf is a HDMI capture device that stores the video stream as a video file (MP4/AVI/MOV). The video file is then processed frame by frame for TGXf packets that are decoded and written to disk.
The risk to heed from highspeedTGXf is that regardless of the proof-of-concept implementations on this site, in practice, data could be encoded in the display in any format - in this case, graphically as pixel data or images and logos. I.e. don't dwell exclusively on application signatures or particular data structures (like QR codes). Furthermore, the screen represents a significant data theft opportunity with hsTGXf capable of exfiltrating gigabytes of data per user session per day.
Your legal liability may have changed with the release of this software, and it stems from an artificial distinction drawn between being able to read data from a screen and being able to download that data.
Some people regard a file displayed to a screen as being within control of the computer system that governs that file, which then differs from a file that is downloaded to your computer such that the source computer system no longer has control over that file. In information security terms, once information has been displayed on a screen the source computer system has lost control of it (it has effectively been uploaded to the room). All that remains to download that data is acquiring it from the screen and writing it to disk on another computer. A human can perform this task manually today - remembering a handful of numbers and letters and then typing that information in to a computer at home. TGXf automates that download capability, such that information displayed in a certain structure on one computer can be readily acquired by another.
Unfortunately this distinction has been codified into our legal and regulatory frameworks.
For an Australian example, please refer to the Australian Privacy Principles guidelines (Privacy Act 1988) - version 1.0, February 2014: An Australian organisation (APP entity) that holds personal information 6.6, and makes that personal information available for use 6.8 but not disclosure 6.11(b) to an overseas recipient 8.5 is accountable 8.1 for ensuring that the overseas recipient does not breach the Australian Privacy Principles 8.2. Personal information is disclosed when the Australian organisation releases the subsequent handling of the information from its effective control 8.8, which includes disclosure through unauthorised access, if it did not take reasonable steps to protect the personal information from unauthorised access 8.10. The reasonable steps include implementing strategies to manage, amongst other things, ICT Security, data breaches and regular monitoring and review 11.8.
Of the six security considerations 11.10 set out in the Australian National Privacy Principles, TGXf would appear to directly enable:
This issue is not limited to Australia. Any modern legal or regulatory frameworks that rely upon the same distinction for use and disclosure to govern personal or private information (PI), personally identifiable information (PII) or personal health information (PHI) will have some business impact from the release of this software. For example HIPAA (see HIPAA Administrative Simplification, Regulation Text, 45 CFR Parts 160, 162, and 164 for the definitions of disclosure on page 12 and use on page 17).
The following Risk Calculator has been designed to help you calculate your relative exposure based on cost case studies from a number of jurisdictions, the method of the theft (from remembering one word per day to high speed transfer through the screen), the number of attackers and the average size of a PI/PII/PHI record in your organisation.
If you are looking to contextualise or validate the above risk modeling then please also see the Data Breach Calculator.
A number of demonstrations can be found as links in the About TGXf (top) section of this site. However, if you only see three demonstrations, then the following are highly recommended.
ThruGlassXfer (TGXf)
The following video demonstrates a Through Glass Transfer with the TGXf protocol only. Shown is a common laptop with Windows 7 and Firefox, playing the below Open Letter PDF from Youtube (at version 8 with 5 FPS), in HD mode. An Android smart phone (HTC One XL) with the ThruGlassXfer app on it is held facing the laptop screen so that the phone's primary camera can clearly read the displayed QR codes. For this demonstration the phone has been put in flight mode, ensuring that it has no data network access.
Video: Android smart-phone in flight mode, downloading a PDF from Youtube via a Laptop screen
Observe the yellow progress bar updating on the phone as data is received and stored. At the end of the video the popup advises that the file has been completed successfully. The background noise is from a rack of computers next to me. The video is dark because it was filmed at night in an unlit room to make both screens clear in the final video. And, yes, there is a giant crack running through the face of that phone.
ThruConsoleXfer (TCXf)
The following video is a demonstration of a TCXf infiltration/exfiltration in multi-hop security architectures.
On the left of the scene, with the red tape markers, is the attacker PC. The attacker PC is running a 64bit Linux Mint live CD and is not connected to any network. It has a USB Camera (Microsoft LifeCam, seen here sitting on two small Pringles cans) connected to it via USB, as well as a Midnight Code "Keyboard Stuffer" - a USB serial device (Freetronics USB Serial Adapter), that uses TTL to output to a USB HID keyboard device (Freetronics Leostick).
The defender (enterprise) devices are denoted with the green/yellow tape markers. In the middle of the scene is an enterprise end user device; a HP Thin Client device with a hardened Windows XPe (embedded) Operating System on it. Two instances of the PuTTY (SSH client) have been launched from the Windows XPe system to a 64bit Linux PC (scene right). The Linux PC on the right represents the enterprise application server, where the user has access to sensitive assets for use, but not disclosure (can work with files, but not download them).
The attacker's camera can see the end user device screen (TGXf), while the attacker's keyboard stuffer appears on the end user device as a USB HID keyboard (TKXf). In this configuration, the attacker can establish a TCXf (ThruConsoleXfer) where the PCE (Personal Computer End) is on the attacker's device (outside of enterprise control) and the DCE (Data Center End) is on the application server (at the heart of the enterprise). The result is a full-duplex TCP socket (8442/TCP) on the attacker's PC that connects to matching full-duplex TCP socket on the application server (8442/TCP) via the screen and keybard (which is abstracted within the enterprise via the SSH session).
Video: TCXf Demo - IP networking over Screen and Keyboard!
Apologies for the auto-focus on this video. If you want to know what is happening at each change in the scene, then please see the complete time-line that can be found in the description of the video on Youtube.
This demonstration is designed to show the full power of the TCXf solution. Rather than infiltrating or exfiltrating individual files, this TCXf connection has been used to connect a PPP peer on the attackers PC with a PPP peer on the application server at the heart of the enterprise. It is important to note that the user requires privilege on the application server in order to create a network interface (i.e. run the ppp daemon), but that no other aspect of this demonstration requires privileged access. Once the attacker has established the PPP link he runs an SSH session directly from the attacker PC to the application server on top of the IP network that now runs over the screen and keyboard on the Windows XPe and HP Thin Client end user device.
This access will circumvent all of the controls deployed in typical enterprise security architectures.
clientlessTGXf (clTGXf)
The following video demonstrates a Through Glass Transfer via the clientlessTGXf protocol.
Video: clientlessTGXf download (decode) in Linux
A file has been encoded in the clientless version of the Through Glass Transfer protocol (TGXf). Here the HDMI intercepted video (saved as an MP4 file) is being decoded by the receiving tool. The video is being played back frame by frame, with analysis of the screen for characters of a certain size. Once characters are located a randomly coloured box is drawn around it and it is handed off for character recognition. The recogniser has been trained on ones (1) and zeros (0), which are stored in a linked list by their location. After the frame has been fully recognised it is handed off to the TGXf protocol code which looks for 16 bits (1's and 0's) in the same row on the screen. Each of these TGXf rows is then processed as a sequence (datagram) in the layer 4 transport protocol. The counter helps the protocol to detect and reject errors (such as tearing from mismatched screen draws).
This is a proof of concept that shows data can be downloaded in binary formats through terminal/shell sessions via the screen, without the need for a client on the server or QR codes. The upload software is 300 bytes of BASH script, while the decoder is C++ source released under the GPL, which should port well to other platforms, including Windows.
highspeedTGXf (hsTGXf)
The following video demonstrates a Through Glass Transfer via the highspeedTGXf protocol.
Video: 12.1Mbps highspeedTGXf transfer downloaded (decoded) in Linux
The Through Glass Transfer White Paper (a 5.5Mbyte PDF) has been encoded in the high-speed version of the Through Glass Transfer protocol (TGXf). The file has been uploaded in 3.6 seconds from a Web browser in full-screen mode, on a PC with a 720p display, using hsTGXf at a resolution of 1240 pixels by 650 pixels with data encoded at 3 bit-per-pixel (BPP) and 10 frames-per-second (FPS).
Here, the HDMI intercepted video (RGB data saved in a lossless format) is being decoded by the receiving tool. The video is being played back frame by frame, with analysis of the screen for pixels in a certain location (the bounded region in the video). At three bits-per-pixel (BPP), the colour channels (Red, Green, Blue) in each pixel within the bounded region are evaluated. A colour channel that is "substantially light" is regarded as a binary 1, while "substantially dark" colour channel is regarded as binary 0. The bounded region therefore creates an effective datagram/packet size of 300,250 bytes (1240x650x3/8) and at 10 frames-per-second (FPS) operates with an effective throughput of 12.1Mbps.
This is a proof of concept that shows gigabytes of data could be rapidly exfiltrated (downloaded) in binary formats through remote enterprise desktop sessions via the screen, without the need for a binary client or the use of QR codes. Further, it should be clear from all of these video demonstrations, that targeting a specific implementation will not protect an organisation from data exfiltration via the screen.
Please find the proof-of-concept application that you are looking for, under the appropriate label. Note that the MD5 checksums are available for the locally hosted files. Also note that build and test instructions can be found in the TCXf White Paper.
Presentations
TGXf has been presented at various security conferences globally. If you're not looking for the presentation from a specific conference, then note the topics presented as each presentation is flavoured to that particular conference:
ThruGlassXfer (TGXf)
The TGXf proof-of-concept application is available via the following links:
Make sure to set the Options so that the Max Errors is 50 and Timeout is 50 seconds on the receiving device, until you're comfortable with TGXf transfers.
The higher the performance of the receiving device, the more robust the transfer. For example, the receiving HTC One XL (1.5Ghz Qualcomm Snapdragon S4 MSM8960 SoC) out performed the receiving iPhone 5 (1.3Ghz Apple A6 SoC).
Note that these implementations have been limited to files of 65,535 bytes in size, or less. Please see the FAQ below regarding source code releases.
ThruKeyboardXfer (TKXf)
The TKXf proof-of-concept application is available via the following links:
ThruConsoleXfer (TCXf)
The TCXf proof-of-concept application is available via the following links:
clientlessTGXf (clTGXf)
The clientlessTGXf proof-of-concept application is available via the following links:
highspeedTGXf (hsTGXf)
The highspeedTGXf proof-of-concept application is available via the following links:
An open letter, sent to CERT Australia and the Australian Information Commissioner on 21 June 2014, has been published in both TEXT and PDF formats to Youtube. It is available in all TGXf encoding methods, so that you can get a feel for the nature of Through Glass Transfers.
The higher the version number, the more data per image. The higher the FPS number, the more images displayed per second.
If you just want to download the open letter then the Version 8 and FPS 5 encodings (blue buttons) are recommended, or follow this link to the PDF.
At the COSAC/SABSA conference on Tuesday the 30th of September 2014 in Dublin, the presentation Piano Thieving for Experts: That Bathroom Window IS Big Enough worked through the principles and methods used to understand the vulnerability, to articulate it architecturally and then consider the flaws in enterprise security architecture, and strategies chosen by historical figures and the US DoD.
Following that presentation the 200 page (approx.) TCXf White Paper was released, documenting:
There are also a number of articles that have been written addressing different aspects of ThruGlassXfer, which you may also find useful:
If you're looking for an insider view on the development of the project, then a good friend of mine at the Cranky Potato blog has been following the project since before it was public:
Other note-worthy references that have been publicly produced since the original publications:
If you want to defeat the proof-of-concept TGXf protocol implementation then you could filter QR codes at strategic points in your security architecture. Though the tools to do this don't currently now exist, this control will not mitigate all screen based transfers.
If you want to defeat the proof-of-concept TKXf protocol implementation then you could start by looking for Arduino USB device identifiers on end user devices, and raise alarms on their connection. Note that this value can be changed at build time (to look like a HP Chicony keyboard at 0x03F0:0x0024 for example), that this will not identify all keyboard based transfer attempts, and that it may result in a substantial number of false positives. I would not deploy this solution, but as I have been asked for the details please find the Arduino VID:PID values below:
In both cases, a number of mitigation proposals have been made in the COSAC/SABSA presentation and the white paper. It needs to be made clear that there is no known effective technical mitigation strategy for this vulnerability that doesn't also severely constrain productivity.
No. TGXf is a uni-directional protocol. This means that a video recording of sufficient quality will adequately transfer the file contents out of your work place to a location more convenient to the attacker. Any of the high-end spy pen, spy watch or spy glasses devices will do. And before you set out to ban those devices as well, you might want to do some research as high definition miniature cameras are in almost anything you can imagine, my favourite being the religious artefacts for the additional legal implications of search and confiscatiscation.
Further-more, even if you were successful in creating a camera free environment, high performance data exfiltration would still be possible via the same channel. The architecture issues have been discussed at COSAC/SABSA and in the TCXf White Paper as well as demonstrated via clientlessTGXf.
The cause is a class of vulnerability known as a covert channel. Of the two types of covert channel, timing and storage, TGXf is a storage based covert channel. The effect is data exfiltration (data extraction or data theft).
A modern computer will use HDMI to display data on a 1080p screen. If you were to read pixel data directly from the HDMI interface then that equates to 1920 pixels wide x 1080 pixels high x 24 bit (True Color) x 24 frames per second which is 1,194,363,600 bits per second or approximately 150 Megabytes per second (faster than Gigabit Ethernet).
The two protocols that comprise TCXf have differing data rates.
ThruGlassXfer (TGXf)
For implementation simplicity the TGXf protocol has been defined as supporting the following QR code versions and their respective usable capacities;
The TGXf protocol also allows frame rates of 1, 2, 5, 8 and a maximum of 10 frames per second (to allow at least a 2x over-sample on 30fps cameras).
Applying the matrix you get a data transfer rate of between 10 bytes per second (80bps) and 4,080 bytes per second (32kbps). Which isn't shabby considering that in all cases (ECC, resolution and FPS) conservative values have been chosen, and that this is a binary clean communications channel.
ThruKeyboardXfer (TKXf)
TKXf, as inplemented in the proof-of-concept, has an upper bound of 3 bytes per two milliseconds (12kbps). With additional work, it may be possible to increase this two-fold by carefully using the blanking keyboard packet (to 24kbps), and increasing it by one third if base64 encoding were used instead of a straight hexadecimal encoding (32kbps).
ThruConsoleXfer (TCXf)
Per the above calculations, TCXf as implemented today has a limit of 32kbps/12kbps (egress/ingress). This is interesting when you consider that The Cuckoo's Egg began with a 1200 baud (1.2kbps) connection.
Of the reviews I've found and read, one of my favourites is this very apt analysis from Rodger, describing TCXf as Satan's 1200/75 Modem.
clientlessTGXf (clTGXf)
The clientlessTGXf protocol as implemented today peaks at about 1kbps (egress). However due to the independent decoding cycle, the download side of the same transaction (pending available processing power) runs at about 100bps.
highspeedTGXf (hsTGXf)
The highspeedTGXf upload bandwidth is limited to the largest screen resolution and refresh rate (see above for the maximum theoretical transfer rates), but in practice the rate is limited by the receiver. The off-the-shelf gamer capture device tested (Game Capture HD II) seems to peak at about 1.5Mbps (1240 x 650 x 1bpp x 2fps, egress). Of the professional video capture cards tested, the DeckLink Mini Recorder was constrained to YUV capture and therefore 1 bit-per-pixel (black or white) data, peaking at 4.7Mbps (1240 x 650 x 1bpp x 8fps, egress). While the DeckLink 4K Extreme 12G supported 10bit-per-channel RGB capture, a lack of open source tools to process the resulting R210 RGB48LE AVI file correctly limited this card to 3 bits-per-pixel data, maxing out at 12.1Mbps (1240 x 650 x 3bpp x 10fps, egress).
This project has been designed to draw the attention of the information security industry to the problem. I work in the industry but like you the security of my government, health, financial and other private records are beyond my control. If you are unable to contribute to the improvement process directly then consider showing your support. Feel free to link to this site from your social site, blog or email signature, and you're welcome to link to or re-serve the logo at http://thruglassxfer.com/logo.png.
The most common cause of failed transfers for new users is timing out before the first packet is received, or too many errors during the transfer. Make sure to set the Options so that the Max Errors is 50 and Timeout is 50 seconds on the receiving device, until you're comfortable with TGXf transfers.
If you are still having difficulties then see the reliability question, below.
Without file-system access in the Apple platform we could only hand data off to a native handler, which includes images and text. It seems that everyone else gets around this by using a local sqlite database to store their files. If this proof-of-concept application is updated, it may use this method to bring it to parity with the other builds.
This is also why the text field is awkward to use on the iPhone (with the virtual keyboard riding over it). It was a feature that only existed on the Apple and all of the testing for text transfers was done with cut-n-paste.
During testing on the smart phone versions of TGXf, particularly, we learnt some interesting lessons:
Also note that the receiving CRC check has been disabled in the Android and Apple app versions of TGXf for usability reasons. The upshot is that you can try and open a file from a transfer that completed with errors (it will have chunks missing), and if you re-transmit the same file you may correctly fill the omissions from the first failed transfer even if the second transfer also completes with errors.
Turn flight-mode on and try again - it's really happening!
There are many projects that have developed either scripted command interfaces, infiltration or exfiltration via the keyboard, or a type of URL encoding or data exfiltration via the screen. Unfortunately neither my friends nor I had seen most of these projects before I developed TGXf. While none of these technologies completely overlaps with TGXf, TKXf or TCXf, Ben and Scott's QR code exfiltrator and VSzA and d3adOne's keyboard exfiltrators were so close to where I wanted to go that I probably wouldn't have started this project if I had have seen those first. For the sake of future researchers, and to credit these original thinkers, I am providing a comprehensive link repository here:
If you believe that your project should be included here, then please let me know.
Through Glass Transfer is a Midnight Code project, created by Ian Latter. The reference TGXf C code was ported to both IOS and Android by James Hudson.
