Gr3ytrac3 on Cyberdev | 0xSEC

Project Detailed Summary Documentation

Sun, 19 Apr 2026 00:00:00 +0000

A thinking partner that accelerates kernel vulnerability analysis and exploitation reasoning.

First: what would this AI do?

There are a few serious directions you could take:

1. Exploit reasoning assistant (high-value)

An AI that:

Reads kernel code (Linux, drivers, modules)
Identifies potential vulnerability patterns (UAF, race conditions, integer overflows)
Explains why something is exploitable
Suggests exploitation strategies (heap feng shui, primitives, etc.)

👉 This is extremely valuable because:
Most tools find bugs. Very few help you reason about exploitation paths.

QEMU/KVM Audio Boundary Crossing: Silent Injection Between Host and Guest

Sat, 19 Apr 2025 00:00:00 +0000

Background

Modern Linux desktop virtualization stacks route VM audio through the host audio server — typically PipeWire — via SPICE or VirtIO-sound. The assumption baked into this architecture is that the boundary between host audio context and guest audio context is enforced at the application layer.

It isn’t.

The Finding

Through careful mapping of the full PipeWire/SPICE audio pipeline, I confirmed that bidirectional silent audio injection is possible between a host and a running VM guest. An attacker with access to either side of the boundary can inject audio data into the other side without any user-visible indication.

Invisible Wire: Covert Channel Research Over Linux Desktop Audio

Mon, 10 Mar 2025 00:00:00 +0000

The Premise

A covert channel is a communication path that was never intended to transfer information. Classic examples exploit CPU cache timing, network packet timing, or shared memory. This work explores a less-studied surface: the Linux desktop audio subsystem.

The core question: can audio hardware and software infrastructure — PipeWire, ALSA, the kernel audio stack — be used to exfiltrate data from a host without triggering conventional detection mechanisms?

Why Audio

Audio is interesting as a covert channel carrier for several reasons:

Linux Microphone Debugging: When PipeWire Lies to You

Wed, 15 Jan 2025 00:00:00 +0000

The Problem

PipeWire reports devices as available. Applications claim to be recording. No audio is captured. This is the debugging sequence that actually works.

Step 1 — Verify the device exists at the kernel level

arecord -l
# List all capture hardware devices
# If empty: driver issue, not PipeWire

Step 2 — Check PipeWire sees it

pw-cli list-objects | grep -A5 "Audio/Source"
# Should show your capture device

Step 3 — Check WirePlumber routing

wpctl status
# Look at Sources section
# Active source should have [vol: 1.00] not [vol: 0.00]

Step 4 — Test capture directly via PipeWire

pw-record --target=<node-id> test.wav
# Get node-id from wpctl status output
# Record 5 seconds, play back with pw-play test.wav

Step 5 — Check permissions

ls -la /dev/snd/
# Your user needs to be in the audio group
groups $USER | grep audio
# If not: sudo usermod -aG audio $USER && reboot

Common Culprits

WirePlumber defaulting to wrong capture node after suspend/resume
Volume set to 0.00 at the WirePlumber layer despite mixer showing 100%
PipeWire session manager not running (systemctl --user status pipewire-session-manager)
Flatpak app sandboxed away from real audio devices

Note
On Fedora, the session manager is wireplumber. On some distros it may be pipewire-media-session. Check which is active before debugging the wrong daemon.

Links

Mon, 01 Jan 0001 00:00:00 +0000