Adaptive QR Streaming Framework

Background

High-security environments — military systems, nuclear controls, industrial SCADA networks, and financial clearinghouses — use air-gapped networks: machines physically isolated from all RF and wired external links to prevent remote intrusion and data exfiltration. Even in an air-gapped system, administrators must still move data in (firmware updates, security patches, configuration files) and move data out (audit logs, diagnostics). Traditionally this relies on USB drives or optical media, which introduce the BadUSB class of hardware-level attacks and cumbersome media-management logistics.

Screen-Camera Communication (SCC) is a compelling alternative. Data is modulated into a sequence of visual frames on a transmitter screen and demodulated by a receiver camera. Because visible light cannot penetrate walls, the channel requires direct line-of-sight — eavesdropping is confined to a physically controlled space. No RF radiation, no electrical connections; the only link is a beam of light.

Existing SCC research splits into two camps. Systems like ChromaCode (Peng et al., 2018) and DeepLight (Tran et al., 2021) pursue imperceptible communication — hiding data in the subtle colour variations of ordinary video so the stream looks like normal content. While technically impressive, these systems require deep-learning decoders, are sensitive to ambient lighting colour temperature, and offer lower reliability for mission-critical data transfer. The other camp — including this project — uses overt high-contrast QR codes that are clearly visible, prioritising data integrity, robustness, and implementation simplicity over aesthetics.

Yet even within the overt camp, existing solutions are rigid. Systems like that of Liu et al. (2020) — which achieved up to 900 Kbps using colour multiplexing — operate with fixed parameters and cannot adapt to the capabilities of different cameras, distances, or lighting conditions. An operator has no way to tune the channel for their hardware. This is the gap the Adaptive QR Streaming Framework is designed to fill.

Research Problem

The core problem is the inefficiency and rigidity of current offline screen-camera communication systems. Existing solutions lack an adaptive framework that allows users to optimise the critical trade-off between data throughput and transmission reliability by dynamically configuring spatial (grid size) and temporal (frame rate) transmission parameters. This limitation hinders the effective deployment of SCC in real-world air-gapped environments where hardware capabilities and environmental conditions vary significantly.

Consider a secure manufacturing facility where an engineer must transfer a 5 MB configuration file to an air-gapped control unit. With a high-resolution industrial camera in controlled lighting, the optimal choice is a dense 3×3 QR grid at 30 fps. In a dimly lit server room with a standard webcam at 2 metres, the system should revert to a robust 1×1 stream at a slower rate. No existing tool lets the operator make this choice systematically — and no literature empirically maps the trade-off.

Study Objectives

The overarching aim is to design, implement, and rigorously evaluate a configurable screen-camera communication system that uses adaptive layouts of dynamic QR codes to optimise data transfer in offline environments.

Primary objective

To develop a robust, adaptive QR streaming framework that enables unidirectional data transmission between a screen and a camera by dynamically modulating the spatial layout (grid size) and temporal frequency (frame rate) of the QR codes, specifically for offline, air-gapped scenarios.

Secondary objectives

1. Prototype Development — Design and implement a fully functional sender-receiver system. The system encodes arbitrary binary files into QR code sequences, arranges them into user-configurable grids (1×1, 2×2, 3×3), displays frames at precise user-defined intervals, and decodes the captured stream in real time to reconstruct the original file.
2. Performance Characterisation — Systematically measure the impact of grid size and frame interval on Raw Throughput (bps transmitted), Goodput (successfully decoded bps), Bit Error Rate (BER), and Frame Error Rate (FER) under controlled laboratory conditions.
3. Predictive Modelling — Formulate and validate a mathematical regression model that predicts total transmission time and expected reliability for a given file size and configuration, addressing the operational need for predictability in mission planning.
4. Environmental Robustness Analysis — Evaluate system resilience against real-world channel impairments: varying distances (0.5 m – 2.0 m), viewing angles (0° – 30°), and ambient lighting conditions. Determine the operational envelope for each grid configuration.
5. Feasibility Assessment — Demonstrate practical utility by conducting end-to-end transfers of various data types (text documents, binary executables, images) in a simulated air-gapped environment, validating efficacy against theoretical limits described in recent SCC surveys.

Research Questions

Four specific research questions guide the investigation and map directly to the experimental design of the automated harness.

How the Optical Channel Works

The channel is entirely simplex (one-way) with no back-channel. Reliability is achieved through cyclic repetition and per-chunk integrity checks, not retransmission.

1. File segmentation — The input file is read in binary mode and split into fixed-size chunks. Each chunk is wrapped in a custom protocol header carrying: Sequence ID · Total chunks · CRC-32 checksum · Base64-encoded payload.
2. META frame — Before each cycle a dedicated META QR frame is displayed carrying filename, file size in bytes, total chunk count, chunk size, SHA-256 hash of the whole file, and (when encrypted) the PBKDF2 salt, AES-GCM IV, and password verifier hash.
3. Grid composition — For an N×N grid, N² QR codes are generated and stitched into a single composite frame. The sender uses a render-ahead scheduler with drift correction so each frame is displayed for exactly the configured interval.
4. Optical transmission — Frames are displayed on any LCD or OLED screen. A camera on the receiver side captures the screen at its maximum resolution. No RF, no wires; the only medium is visible light across a direct line-of-sight gap.
5. Multi-QR detection — Each captured frame is decoded using the native BarcodeDetector API (Chromium) or jsQR (fallback). All codes in the frame are detected simultaneously. Each decoded string is parsed and its CRC-32 is verified before the chunk is accepted.
6. Reassembly & integrity check — Chunks are inserted into an ordered buffer by sequence number, in any order, across any number of cycles. Duplicates are silently ignored. Once all unique chunks are present, the file is reconstructed and its SHA-256 is verified. A match triggers the download; a mismatch rejects the file.

Experimental Design

Independent variables

The automated harness sweeps the following variables in a full factorial design:

Dependent variables — Key Performance Indicators (KPIs)

The following metrics are recorded per configuration by the automated receiver:

Raw Throughput (bps)

Total bits received per second, including duplicate detections. Reflects the channel capacity utilised by the transmitter.

Goodput (bps)

Unique, correctly decoded data bits per second — excluding protocol headers, CRC bytes, and duplicate receptions. This is the effective user-data rate.

Bit Error Rate (BER)

Ratio of incorrect bits to total bits transmitted, measured by comparing received chunks against the ground-truth payload broadcast over the BroadcastChannel. A lower BER indicates higher channel reliability.

Frame Error Rate (FER)

Fraction of data frames in which at least one QR code in the grid failed to decode. A grid with FER = 0 decoded every code in every frame; FER = 1 decoded nothing.

Chunk Success Rate

Proportion of unique chunks decoded relative to the total number of chunks in the file. A rate of 1.0 means the file can be reconstructed; anything below 1.0 means missing chunks remain.

Mean Processing Latency (ms)

Average time from frame capture to completion of QR detection and chunk buffering, per frame. Constrains the maximum achievable frame rate on a given device.

Encryption — AES-256-GCM with PBKDF2

The encrypted sender and receiver pages (03 and 04) add an optional password layer on top of the standard protocol. When a password is provided the following happens:

Sender side

1. A cryptographically random 16-byte salt and 12-byte IV are generated fresh for every transmission.
2. The password is passed through PBKDF2 (100 000 iterations, SHA-256 hash function) using the random salt, producing a 256-bit AES-GCM key. The high iteration count makes brute-force attacks computationally expensive.
3. The file bytes are encrypted with AES-256-GCM. The resulting ciphertext is what gets chunked, sequenced, and streamed via QR codes — the plaintext never leaves the sender device.
4. The META frame carries: the base64-encoded salt · the base64-encoded IV · a SHA-256 hash of the raw 256-bit PBKDF2 key bytes (the password verifier). The actual password is never transmitted.

Receiver side

1. The ciphertext is fully reassembled and its SHA-256 is verified against the value in the META frame. This confirms transmission integrity independently of the password.
2. A password prompt appears. The entered password is re-derived with PBKDF2 using the embedded salt, producing a candidate key.
3. SHA-256 of the candidate key bytes is compared to the stored password verifier hash. A wrong password is detected immediately — no decryption is attempted — and the user can retry.
4. When the password is correct, AES-GCM decryption produces the original file. The AES-GCM authentication tag provides an additional cryptographic guarantee: if even one bit of the ciphertext was altered, decryption throws an error.

Research Methodology

The study adopts Design Science Research (DSR), structured around the DSRM process model proposed by Peffers et al. (2007). DSR is a problem-solving paradigm that seeks to create new innovations — "artifacts" — that solve identified problems and whose utility can be rigorously evaluated. The six DSRM steps are:

1. Problem Identification & Motivation — Define the inefficiency of fixed-parameter SCC systems and justify the value of an adaptive optical link.
2. Define Solution Objectives — The artifact must be configurable (variable grid and frame rate), robust (error detection and correction), and accessible (standard off-the-shelf hardware only).
3. Design & Development — Implement the Tx and Rx modules with the full protocol stack: segmentation, QR generation, grid composition, frame scheduling, capture, preprocessing, multi-QR detection, reassembly, and SHA-256 verification.
4. Demonstration — Transfer reference datasets (text, binary executables, images) under ideal conditions (0.5 m, direct LoS, controlled lighting) to confirm bit-perfect end-to-end reconstruction.
5. Evaluation — Run the automated harness across the full factorial parameter matrix. Collect telemetry CSV files, perform regression analysis, and validate the predictive model.
6. Communication — Disseminate via final undergraduate dissertation/thesis, potential conference paper, and open-source code release.

Related Work

Three bodies of prior work directly inform this project:

Liu et al. (2020) achieved approximately 150 Kbps in real time and 300 Kbps in post-processing using standard black-and-white QR codes, rising to 900 Kbps with colour multiplexing across the RGB channels. However, colour-based systems are fragile: small deviations in white balance or ambient colour temperature cause significant bit errors. This motivates our decision to use high-contrast monochrome QR codes and seek throughput gains through spatial multiplexing (more codes per frame) rather than spectral multiplexing (colour channels).

Jin et al. (2021) demonstrated SCC specifically for air-gapped network administration, achieving over ten times the efficiency of static manual scanning. Their work confirmed the viability of the scenario but focused only on stream continuity — they did not vary the number of codes per frame, leaving the spatial multiplexing trade-off unmapped.

Sewpersadh et al. (2024) surveyed the field and noted that while theoretical throughputs of up to 7.67 Mbps are possible with synchronised links, standard smartphones and monitors typically reach about 900 Kbps in practice. The primary constraints are the screen refresh rate, the rolling-shutter effect, and decoder processing overhead — all of which this framework exposes as configurable parameters so that operators can navigate them for their specific hardware.

Project Timeline

Browser compatibility: Multi-QR detection for 2×2 and 3×3 grids requires the native BarcodeDetector API — use Chrome or Edge for the full experiment. A jsQR fallback handles 1×1 streams in all browsers. The automated harness additionally requires getDisplayMedia (screen capture), also Chromium only.