Full Engineering Version

If you want the full communication-engineering analysis, measurements, and design tradeoffs, continue to Deep Dive: When the Speaker Becomes a Communication Channel.

TL;DR

  • Attackers should think in terms of information transfer, not product features.
  • In Citrix and VDI, audio is not just sound output. It is a communication channel.
  • The real challenge was not writing code. It was understanding what the channel preserves and what it destroys.
  • The channel, not preference, dictated the final architecture.
  • If you want the full communication-engineering treatment, read the deep dive: /2026/07/21/think-like-an-attacker-when-the-speaker-becomes-a-communication-channel/.

Introduction

Most security reviews begin by listing features: file transfer, clipboard, USB redirection, browser access, audio, printing, and so on. The assumption is simple: if enough features are blocked, the attack surface becomes small enough to manage.

That is often a useful defensive view. It is not how an attacker thinks.

An attacker usually does not care whether a system exposes a feature called file transfer. The real question is more fundamental: can information still cross the boundary?

That shift sounds semantic, but it changes everything. Once you stop thinking in terms of named features and start thinking in terms of channels, you stop asking what the product claims to allow. You start asking what the system still makes physically possible.

Citrix environments are a good example. You can disable the clipboard, block drive mapping, prevent USB passthrough, and still leave several paths that must remain available for normal operation. Users still need to see the remote desktop. They still need to hear alerts. They still need to provide input. Every one of those paths is a form of information transfer.

That is the key idea behind this research. Audio was not interesting because it was a forgotten feature. It was interesting because it was still a live channel.

A split scene where defensive controls block common transfer paths while an attacker uses audio as a communication channel
Blocking features does not always block channels

The Mindset Shift

The most important change in this project happened before a single line of code was written.

At first, the problem looked like an offensive-security question: can data be moved across a VDI boundary through sound?

Very quickly, that stopped being the real question.

The real question became this: if Citrix audio is treated as a communication channel, what does that channel actually preserve? Which parts of a signal survive the trip? Which parts are destroyed by the codec, the operating system, the transport path, and the endpoint audio stack?

That is a very different problem. It is no longer about finding a trick. It is about characterizing a medium.

Once you look at it that way, the work changes completely. Instead of choosing a clever modulation method first, you start by measuring the channel. You ask which frequencies survive, whether amplitude stays stable, whether phase remains usable, how much noise is introduced, and how short a symbol can be before the codec smears it beyond recognition.

In other words, the project moved from offensive security into communication engineering.

Fact 01

The best modulation is not the one that carries the most information, but the one that survives the channel best.

What Broke First

One of the first assumptions to collapse was the idea that the most advanced-looking modulation scheme would automatically be the best choice.

On paper, complex modulation looks powerful. It promises better spectral efficiency, more bits per symbol, and higher theoretical throughput. But those advantages only matter if the receiver can still distinguish the states after the signal has passed through the real channel.

That was not what happened here.

The Citrix audio path did not behave like a clean textbook channel. The codec introduced its own preferences. Some frequency regions held up better than others. Some signal properties survived reasonably well. Others degraded enough to become unreliable. At that point, theory stopped being the deciding factor.

Measurement took over.

Fact 02

I did not choose the architecture. The channel chose it for me.

At this stage, that became the most useful mental model. The channel dictated what could survive. The codec dictated what remained distinguishable. The noise dictated how much ambition was realistic.

Channel-driven architecture constraints in practice
The channel dictated the architecture more than theoretical preference did

Why Measurements Mattered

The deepest lesson from this work was not about Citrix specifically. It was about methodology.

At almost every stage, intuition was less useful than direct measurement.

Ideas that sounded superior in theory often performed worse in practice. More carriers did not always help. More states did not always mean more usable bits. A scheme that looked less elegant on paper sometimes transferred more real information, simply because it survived the channel better.

That is the point where this stopped being an exercise in cleverness and became an engineering problem. Instead of asking what should work, the right question became: what does the channel prove that it can carry?

Fact 03

Measurements are always better than intuition.

What Came Out of It

The result was not just a rough proof of concept. Over time, it became a full communication system: compression, framing, synchronization, modulation, error correction, interleaving, validation, and recovery.

That system became VDI Bridge.

It was not built by starting with a perfect design and then coding it faithfully. It was built by failing, measuring, adjusting, and narrowing the solution space until only the combinations compatible with the real channel remained.

If you want to see the implementation layer, the demonstration, and the transmission pipeline, the deep dive goes through the engineering decisions in detail:

Measurement-driven refinement of channel communication strategy
The implementation was the result of constraints, not preference

What Is Worth Remembering

  • Attackers should think about channels, not just named features.
  • A system can remain restrictive at the product level while still exposing usable paths for information transfer.
  • Good measurements are more valuable than elegant assumptions.
  • The architecture of a communication system is often dictated by the channel itself.
  • If you want the full engineering analysis, continue to the deep dive: /2026/07/21/think-like-an-attacker-when-the-speaker-becomes-a-communication-channel/.