The information in this page is based on the USENIX ‘GSMem’ paper [1] by Mordechai Guri et al (see reference below).
RAMEAR uses the hardware every computer already has to secretly transmit your data, without you realising!
What it does
RAMEAR is combination transmitter and receiver designed for transmitting signals outside of standard computer interfaces.
The inspiration of RAMEAR comes from the following GSMem paper presented at USENIX.
We have taken a standard Ubuntu PC, and managed to wirelessly transmit data from it - even though the PC has no Ethernet connection, no WiFi and no Bluetooth.
This is accomplished by bashing the Data Bus of the computer - the main communication avenue between the RAM and the CPU of the computer. We use a special assembler instruction to transmit 128 bits in parallel to the RAM, bypassing the cache. We repeatedly run this instruction to transmit random data over a period of 500ms, effectively increasing the radiated RF power from the bus substantially.
A ‘1’ transmission in our system corresponds to a period of high activity on the Data bus, and a ‘0’ transmission corresponds to average activity.
On the receiving end, we calculate the amplitude of the signal and process it [5 stages] to decode the waveform. We developed the transmission system from scratch in order to fit our needs, including both developing noise rejection code ourselves and automatic clock synchronisation.
How we built it
On the transmission end, we used standard hardware to emulate a wall-gapped-system, potentially inside a secure facility. We wrote some low-profile code in C which hits the data bus at its maximumum frequency - on this computer, approximately 513Mhz [that's 513 million 128-bit transactions per second]. The code has a very low memory footprint [as it writes to the same location continually], and also has a very low CPU footprint - as the memory frequency is much lower than the CPU frequency.
On the receiving end, we use a python script to process the RF data from the bladeRF. During the course of the hackathon we developed our own transmission protocol, and our own algorithms for automatic clock resynchronisation and noise rejection. In order to reject noise, we did have to maximise the transmission period, such that our data rate is approximately 2 bits per second. However, for an example use case of transmitting a 512 bit secure key from a remote air-gapped computer, this only takes 4 minutes to transmit, which we consider reasonable.
Challenges we ran into
We get noise from the frequency channel of our RAM. We had to do a lot of signal processing to reconstruct the data we send to our RAM. The main challenges were involved with the RF processing (we had no prior RF experience) and decoding of the signal. We are dealing with extremely noisy data with no synchronising clock, and therefore the decoding algorithm was complex. However, we are comfortable with how it performed at the end - in several tests it managed to transmit 40 bytes consecutively without a single error.
Accomplishments that we're proud of
Actually managing to make it work was a challenge - especially when it came to data decoding. The data decoding automatically resynchronises the clock on high quality pulses, and then relies on this timing when the signal becomes worse in quality. Secondly, the system automatically keeps track of the high and low signal powers, and continually readjusts the thresholds to ensure that a drift in power still remains readable.
What we learned
- How to use the BladeRF
- How to integrate assembler instructions into a C program
- How to calculate the power of a I/Q RF signal
- How to roll-your-own clock resynchronisation
What's next for RAMEAR
At another hackathon we would love to increase the power of the system and improve its range. We believe we should be able to achieve substantially greater ranges by incorporating more RF knowledge into the project - using tools such as increasing the gain in hardware.
We would also like to hijack the mobile baseband in your phone to pick up these signals automatically - without the need for a Software Defined Radio (SDR) like the BladeRF. Overall, for 36 hours - we are happy!
Reference
- Guri, M., Kachlon, A., Hasson, O., Kedma, G., Mirsky, Y. and Elovici, Y., 2015. GSMem: data exfiltration from air-gapped computers over GSM frequencies. In 24th USENIX Security Symposium (USENIX Security 15) (pp. 849-864). Link to Paper
Log in or sign up for Devpost to join the conversation.