Start Here First

If you want the shorter and lighter version of this story before the full engineering analysis, start with Audio Is Not Just Output. It Is a Channel.

TL;DR

  • Offensive Security starts with questions, not tools.
  • In Citrix and VDI, the real problem is not the feature itself, but whether information can still cross the boundary.
  • The audio path is not a vulnerability in the usual sense; it is a legitimate communication channel with measurable constraints.
  • The codec, not the modulation, became the real bottleneck.
  • Measurements mattered more than intuition, and simple designs survived better than sophisticated ones.
  • Writing the code was the easy part; understanding the channel was the hard part.

Introduction

One of the clearest differences between offensive and defensive thinking is not the tooling, the technical depth, or even the experience of the people involved. It starts earlier, with how each side defines the problem it is trying to solve.

In many organizations, security is translated into a list of capabilities to allow or block. VDI is a good example. An administrator can choose whether file transfer is allowed, whether the clipboard is blocked, whether local drives are mapped, or whether USB devices are permitted. At first glance, this seems like a reasonable way to evaluate security posture. The more capabilities you block, the smaller the attack surface appears.

Attackers, however, rarely think in terms of capabilities. From their perspective, a capability is just one implementation of a more basic idea: information transfer.

This shift, from capability-based thinking to channel-based thinking, marks one of the main differences between penetration testing and Red Team or Adversary Emulation thinking. Instead of asking whether files can be transferred, the first question becomes whether any mechanism still allows information to cross the boundary. It may sound like a semantic change, but it materially reshapes both system analysis and opportunity discovery.

Citrix environments illustrate this well. You can block all common file-sharing mechanisms and still leave channels that are essential for normal operation. Users still need to see the remote desktop, hear alerts, and provide keyboard input. Each mechanism serves a different functional purpose, but from an engineering standpoint they share the same property: they transfer information from one point to another.

Once this perspective is adopted, audio stops being just “sound output” and becomes a communication channel. More broadly, any component that can transfer information between two sides stops being just a feature and starts being a channel. It is a small conceptual shift on paper, but it has a large effect on offensive reasoning.

It is important to emphasize that this article is not about a Citrix vulnerability and does not present a “break” in the conventional sense. The audio channel behaves as designed and does not rely on a faulty implementation. The research is not about bypassing security through a bug. Instead, it examines how a legitimate path can be analyzed as a communication channel with defined engineering characteristics. That distinction matters because it highlights the difference between exploiting vulnerabilities and leveraging inherent system properties.

This is the starting point of the research described in this article.

The goal of this research was not simply to test whether exfiltration can be done through sound. The deeper question was whether Citrix audio can be treated as a communication channel in a full engineering sense, and which physical and technical constraints determine data rate, reliability, and resilience to codec-induced distortion.

The transition from an Offensive Security question to a Communication Engineering question happened before a single line of code was written. Most later decisions, from modulation choice, to protocol structure, to error-correction design, were driven by channel characteristics rather than by preference for any specific technology.

This is also the central message of the article. Although it ultimately presents a communication system operating over the Citrix audio path, it is not about audio alone. It is about the mindset shift that leads an attacker to stop viewing system components as isolated functionality and start viewing them as measurable communication channels with physical constraints.

Answering this question required stepping, at least temporarily, outside the cyber domain and into communication engineering. Only after understanding the physical principles governing the audio channel was it possible to make informed decisions about how to use it.

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

Breaking Down the Problem

After deciding to stop thinking in terms of capabilities and start thinking in terms of communication channels, it became clear that the next step was not writing code. In fact, writing code was one of the final stages in the process.

In any communication system, there is a fundamental question that must be answered before almost any other engineering decision: what is the nature of the channel available to me?

This may sound like a trivial question, but in practice it dictates almost everything that follows. Modulation strategy, transmission rate, error-correction design, packet structure, and even synchronization logic are all derived from channel characteristics, not from preference for a specific technology.

This is also where I see many studies start in the opposite direction. A modulation method is often chosen first, a proof of concept is built, and only then do people check whether that method is even suitable for the channel. To me, that is backward. Modulation is a solution to an engineering problem; it is not the starting point.

So before writing a single line of code, I tried to understand what really moves between both sides of the VDI boundary.

At that stage, the Citrix environment itself was almost secondary. Communication was the primary focus.

If we look at the audio path abstractly, it is simply a mechanism that moves a wave from one point to another. From a physical perspective, there is no essential difference between a radio wave, Wi-Fi, Bluetooth, or sound. In all cases, energy is transmitted over time, and the only question is how to make variations in that energy represent information. That is, in essence, the definition of a communication system.

The information itself is meaningless to the channel. The channel does not know whether we are trying to send a Word document, a ZIP file, an image, or a video. For the channel, everything is reduced to a bitstream. This means the real problem is not how to transfer a file, but how to map bits into physical variations that can be generated, transmitted, and reliably detected on the receiving side.

At that point, it became clear that the real objective was not building an exfiltration tool, but building a communication system. In classical communication-engineering terms, that means building a modem: a system that converts digital information into a signal suitable for a physical medium, sends it through a constrained channel, and reconstructs it at the receiver.

Once I viewed the problem this way, the work order changed completely. Instead of asking “which modulation is best?” I started with much more fundamental questions:

  • What is a wave, and how can it be used to carry information?
  • How can digital data be represented on top of a wave?
  • How do we convert a file into a sequence of physical signal changes?
  • What is modulation, and why are there so many modulation methods?
  • What is the channel bandwidth, and how does it constrain transmission rate?
  • What is signal-to-noise ratio (SNR), and why is it one of the most important parameters in any communication system?
  • Which frequencies survive channel passage, and which are attenuated or lost entirely?
  • Does the channel preserve all signal properties, or only some of them? Can we rely on phase, amplitude, frequency, or only on signal presence?
  • Does the channel behave linearly, or does it alter the signal as a function of intensity, content, or other attributes?
  • At what sampling rate does the channel operate, and how does this impact transferable information?
  • What is the maximum throughput the channel can support, and where is the true system bottleneck?

In retrospect, these were the most important questions in the entire research. From that point on, I was no longer looking for tricks to bypass system limits. I was trying to understand the limits themselves, because every limit you understand becomes a design constraint you can work with.

In other words, before deciding how to transmit, you must first understand what the channel is capable of carrying.

For that reason, the next chapter is not about Citrix or PowerShell. It is about wave physics. Before choosing modulation, setting transmission rates, or designing a protocol, you need to understand the physical properties of waves, which properties can be modified to represent information, and which properties survive channel passage. Only after that foundation can a communication system be designed in an informed way.

Warning note: the next chapter is very dense. If you do not want to dive into the physics behind the process, you can skip the physics chapter.

Understanding the Physics Before Writing Code

Before we can understand how to transmit information through sound, we need to start with a more fundamental principle: information does not “move” by itself. It is always represented through a change in some physical phenomenon.

When we send a WhatsApp message, browse the web, or listen to music over Bluetooth, there are no literal bits floating through the air. What actually propagates is a change in a physical property within a medium. In Wi-Fi, that medium is electromagnetic waves. In fiber optics, it is light. In an audio path, it is pressure variation in air.

In other words, a communication system does not transfer information directly; it transfers energy, while information is encoded through changes in that energy. This is the foundation of every modern communication system.

What Is a Wave?

A wave is a disturbance that propagates through space and transfers energy from one location to another, without transporting the material itself.

When a speaker plays music, it does not “send air” to the listener. The speaker diaphragm moves back and forth, creating periodic pressure changes in the air. Each air molecule moves slightly around its local position, transfers energy to neighboring molecules, and returns to nearly the same place. The result is a sound wave propagating through space.

The same principle applies to radio waves, light waves, and other communication forms. The difference is not in the idea itself, but in the type of energy being transferred and the medium in which it propagates.

The Three Core Properties of Any Wave

Every periodic wave has three basic properties we can control:

  • Frequency: Frequency is the number of cycles a wave completes per second, measured in hertz (Hz). A frequency of 1000 Hz means the wave completes one thousand cycles every second. In hearing terms, this is perceived as pitch. Higher frequency generally sounds higher.
  • Amplitude: Amplitude represents the strength of the wave’s oscillation. In sound waves, this maps to loudness. The farther the speaker diaphragm moves, the larger the pressure variation and the louder the perceived sound.
  • Phase: Phase describes where the wave is within its cycle relative to a reference point. If two waves have the same frequency and amplitude but one starts slightly later, they can look nearly identical while still being phase-shifted relative to one another.

Phase is not usually perceived directly by human hearing, but it is critically important in communication systems because it can carry additional information without changing frequency or amplitude.

The Anatomy of a Wave

Amplitude, frequency and phase describe the signal.

Learning note: This visualization is an abstraction of the core terms. It simplifies the model on purpose, but real mastery of waves requires many more concepts, definitions, and edge cases than what is shown here.
Animated sine wave An animated sine wave demonstrating amplitude, frequency and phase. Time Amplitude Amplitude Amplitude One cycle Phase

How Does a Wave Carry Information?

The existence of a wave is not enough to create communication. A sine wave with fixed frequency, amplitude, and phase can transfer energy from one point to another, but as long as it remains identical over time, the receiver has no way to infer new information from it. Once the receiver identifies the waveform parameters, every additional cycle is expected to be the same as the previous one. In communication terms, the signal adds nothing.

Information is created when the transmitter chooses between possible states and the receiver can distinguish those states. That choice can be expressed as changes in frequency, amplitude, phase, or timing. For example, if the transmitter uses one frequency to represent 0 and another frequency to represent 1, the receiver can analyze the signal over each time interval and reconstruct the bit sequence based on the detected frequency. The same principle applies to amplitude, where a lower level can represent one value and a higher level another, or to phase, where multiple phase states can represent multiple bits per symbol.

From this, it follows that the wave itself is not the information. The information is in the transmitter’s controlled choice to change a specific wave property, and in the receiver’s ability to detect that change despite noise, distortion, and channel constraints. The mapping process between digital information and physical signal states is called modulation.

The amount of information represented by each symbol depends on how many states the receiver can reliably distinguish. With two states, each symbol carries one bit. With four distinguishable states, each symbol carries two bits. Sixteen states carry four bits. In general, if there are $M$ possible states, the number of bits per symbol is log2(M).

However, increasing the number of states does not provide information for free. As the physical distance between states becomes smaller, it becomes harder for the receiver to distinguish them after the signal passes through a noisy or distorted channel. For example, it is relatively easy to detect whether a specific frequency is present or absent, but harder to differentiate sixteen nearby amplitude levels after an audio codec has changed gain, compressed dynamic range, or introduced distortion.

That is why modulation selection is not just a question of how many bits can be packed into each symbol. It requires balancing data rate against state spacing, channel quality, and the receiver’s measurement capability. An efficient communication system is not the one that encodes the most bits per symbol, but the one that transfers the largest amount of information that can still be recovered reliably under real channel conditions.

Codec

A codec is a mechanism that encodes and decodes a digital signal, typically to make it suitable for transmission or storage. The term codec comes from the combination of encoder and decoder. On the transmitter side, the codec receives a signal, processes it, and produces a compressed or channel-adapted representation. On the receiver side, it performs the reverse process and attempts to reconstruct the original signal.

In audio, a codec may reduce information by removing or approximating details considered less important to human hearing. A lossless codec allows exact reconstruction of the original information, while a lossy codec sacrifices some information to reduce required data rate.

From the perspective of a covert communication system, the codec is not just an audio component. It is part of the channel. It can attenuate certain frequencies, alter amplitude, reduce phase stability, smear short-time changes, or remove spectral components it considers insignificant. As a result, a precisely generated transmitter-side signal is not necessarily the same signal that reaches the receiver.

Noise

Noise is any unwanted change added to the signal, or any distortion applied to it during transmission, reception, or processing. Noise makes it harder for the receiver to distinguish the states that the transmitter intended to generate.

Noise is not limited to audible background sound. It can come from many sources, including hardware limitations, quantization error, audio compression, mixing with other sounds, operating system processing, packet loss, gain variation, or timing inaccuracy.

For example, if one frequency represents 0 and another represents 1, noise can shift the measured frequency, attenuate it, or add energy at a nearby frequency. If the states are too close, the receiver may decode the wrong value.

Signal quality is often measured using signal-to-noise ratio (SNR), which compares desired signal power to noise power. The higher the ratio, the easier it is to distinguish symbols and recover information reliably.

Wave communication illustration for the current section
Figure 2 - Visual support for the wave communication model

Time to Stop Guessing

One of the most common mistakes in engineering projects in general, and in Offensive Security research in particular, is the tendency to start building too early. It is easy to pick a modulation method that sounds promising, build a proof of concept, and start optimizing. The problem with this approach is that it assumes the channel will behave the way we expect it to.

In the case of an audio channel, that is a risky assumption.

By this point, it was already clear that the Citrix audio channel could carry information. The question was no longer whether it could be used, but how it should be used. In other words, it was time to stop guessing and start measuring.

This was also the point where I realized my goal was not to find the “best” modulation method, but to understand what information the channel could preserve across the full transmission path. The difference between those two approaches is substantial. The first starts from a solution and tries to fit it into the channel. The second starts from the channel and only then selects the appropriate solution.

At this stage, I began treating the audio path like any other communication system. If it is a communication channel, it can be characterized, measured, and bounded. So before making any engineering decision, I needed answers to a set of basic questions:

  • Which frequencies pass reliably through the full communication chain?
  • Is signal amplitude preserved, or does it drift along the path?
  • Is phase preserved consistently, or does processing alter it?
  • Are there frequency bands where the codec significantly degrades signal quality?
  • What is the shortest symbol duration that can be transmitted before the codec smears it in time?
  • Are the stereo channels preserved as independent channels, or do they mix during compression?
  • In practice, what data rate can be achieved without sacrificing reliability?

These were not theoretical questions. Each one led to an experiment, and each experiment influenced the final system architecture.

At this point, I also stopped looking at Citrix as a product. For me, Citrix was just one stage in a long processing chain. The signal did not travel directly from speaker to receiver. Along the way, it passed through the operating system, the Citrix audio subsystem, the compression codec, the transport protocol, the endpoint device, the local audio subsystem, and finally the recording stage through WASAPI. Every one of those components could alter, attenuate, or discard information from the signal.

In other words, the real challenge was not producing a sound wave. The real challenge was understanding which wave properties survive the entire path.

That became the starting point of the experiment series.

Instead of measuring only raw data rate, each experiment was designed to answer one question: can the channel preserve a specific signal property? The study examined frequency regions that survive codec passage consistently, long-term amplitude stability, phase behavior after channel traversal, the number of carriers that can be used in parallel, the effect of symbol duration on error rate, and the impact of switching between mono and stereo on throughput and reliability. Only after each of these questions had an evidence-based answer could design decisions begin.

In hindsight, most of the research time was not spent writing code. It was spent measuring. Every measurement eliminated several options, but also narrowed the solution space and clarified which decisions were truly compatible with the channel in front of us.

Only after the channel was characterized sufficiently could the communication system itself be designed.

Attacker Channel-First Decision Flow A flowchart showing how an attacker moves from an objective, through channel discovery, characterization and measurement, to system design and implementation. ATTACKER THINKING The Channel Comes Before the Code Start with the objective. Let the channel shape the implementation. 01 Define the objective Move information across a controlled boundary. Do not choose the technique yet. Is there a channel? What still crosses the boundary? NO Look again Stop thinking in features Reframe the problem YES 02 Characterize the channel Identify what the channel preserves, distorts or removes. 03 Measure instead of assuming Frequency · amplitude · phase · noise Symbol duration · codec behaviour · stereo 04 Design around the constraints Choose modulation, framing, error correction and recovery based on measured behaviour. 05 · LAST Write the code

And Then... Everything Broke

After several days of reading, understanding the core concepts, and building a mental model of the channel, I felt I was finally ready to begin.

I had a fairly clear picture of how information can be represented on top of a wave, which wave properties can be changed, and which principles modern communication systems rely on. On paper, all that seemed left was to choose a modulation method, write a bit of code, and start transmitting data.

In practice, almost all of my initial assumptions turned out to be partial, and sometimes simply wrong.

In hindsight, this was the most important phase of the entire research.

The transition from theory to a working system did not happen through one brilliant idea or a new algorithm. It happened through a long series of experiments, measurements, and small decisions, each of which forced me to abandon a previous assumption and adopt a better way of thinking.

More complex = better

That was probably the first assumption to break.

When you start reading about communication systems, it is very easy to be impressed by advanced modulation schemes. They can represent more bits per symbol, use bandwidth more efficiently, and reach much higher data rates. On paper, this looked like the obvious choice. In practice, the channel I worked with did not behave like a textbook channel at all.

Experimental transition from theoretical assumptions to measured channel behavior
Figure 3 - Theory breaks, measurement starts

As I went deeper, it became clear that the real question was not how much information can be represented per symbol, but how much of it survives the trip through the channel. At that stage, I still did not know which modulation would win. But it was already clear that the choice would not be based on how many bits could be packed into each symbol, but on how the channel actually behaves.

Fact 01

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

The channel decides. Not you.

At first, I was convinced I could choose any modulation method I wanted, and all that would remain was to implement it. In practice, almost every decision was made for me:

  • The channel decided which frequencies survive.
  • The codec decided which signal characteristics are preserved.
  • The noise decided how many states can actually be distinguished.

Fact 02

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

Channel-driven architecture constraints in practice
Figure 4 - The channel dictates architecture choices

Measurement beats intuition

At this stage, I had already understood something more important than any formula I had read. Almost every decision I tried to make from intuition turned out to be wrong.

  • More carriers did not necessarily increase the transfer rate.
  • More states did not necessarily increase the number of bits that actually made it through.

Even a modulation scheme that looked “inferior” in theory sometimes transferred more information, simply because it survived the channel better.

From that point on, I stopped asking, “What should work?” and started asking, “What do the measurements say?” That was probably the most significant shift in the entire research.

Fact 03

Measurements are always better than intuition.

Measurement-driven refinement of channel communication strategy
Figure 5 - Measurement over intuition in channel design

Up to this point, the objective was to understand the channel. Only after reliable measurements started to accumulate was it possible to begin building the system itself. Almost ironically, the coding phase turned out to be relatively straightforward. The real challenge was understanding what the channel allows, and what it will never allow. Only then could all of those insights be translated into engineering decisions and a working communication system.

VDI Bridge

After a long period of learning, experiments, measurements, and course corrections, the result was no longer just a Proof of Concept that could push a single signal from one side to the other. It had become a full communication system.

VDI Bridge was not born as a finished idea. It evolved gradually, with each engineering decision serving as a response to a limitation exposed in the previous experiment. Compression was added to deal with the channel’s limited bandwidth. Error-correction mechanisms were added after it became clear that even a low error rate is enough to corrupt binary information. Later, interleaving was introduced after it became clear that errors were not random but appeared in short bursts. Even the shift between modulation methods was not driven by theoretical preference, but by how the Citrix audio channel and codec behaved in practice.

In the end, the system that was built included all the components you would expect in a modern communication system: compression, framing, synchronization, modulation, error correction, interleaving, validation, and recovery stages on the receiver side. Even though the physical medium was an audio channel, the design process was not fundamentally different from designing any other communication system.

Of course, the code is available here: https://github.com/danieloz147/VDI-Bridge/

VDI Bridge demonstration video
01

Raw data

VDI Bridge accepts arbitrary binary information, including files, clipboard content and short control messages. The audio path carries raw bytes rather than Base64-encoded text.

Input
Arbitrary binary data
Use cases
Files, clipboard and control
VDI Bridge transmission pipeline. Select a stage to inspect the corresponding engineering decision.

What Is Worth Remembering From This Article

  • Offensive Security starts with questions, not tools.
  • Every system is a collection of communication channels.
  • Understanding the physics matters more than choosing the algorithm.
  • The codec was the real bottleneck, not the modulation.
  • Good measurements are worth more than good assumptions.
  • A simple system that works is better than a sophisticated system that does not survive the channel.
  • Almost every engineering decision was made after an experiment failed.
  • Writing the code was the easiest part of the project; understanding was the hardest.

When I look at VDI Bridge today, I no longer see a system that transfers information through sound. I see a learning process. The research started with a question about audio, continued through the world of digital communications, and ended with a new way of looking at systems. The speaker was only the starting point. The most important insight was that as long as there is a way to transfer information between two points, there is also a way to treat it as a communication channel. Once you start thinking that way, it becomes very hard to look at systems in any other way.

Looking For The Short Version?

This article is the full engineering deep dive. For the shorter overview focused on the mindset shift and the core lessons, read Audio Is Not Just Output. It Is a Channel.