Dontlookup

From NURDspace
Revision as of 01:25, 12 April 2026 by Melan (talk | contribs)
Jump to navigation Jump to search
dontlookup
NoPicture.png
Participants Melan
Skills
Status Active
Niche Sdr
Purpose
Tool No
Location
Cost
Tool category

dontlookup Property "Tool Image" (as page type) with input value "File:{{{Picture}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. {{{Picture}}} {{#if:No | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:No | [[Tool Cost::{{{Cost}}} | }}

dontlookup

dontlookup is an open-source tool by researchers at UC San Diego for parsing IP traffic encapsulated in raw DVB-S2(X) satellite captures. It was presented at CCS 2025.

The name is a reference to the fact that satellite internet providers apparently did not expect anyone to be passively listening.

NURDspace uses it (or plans to) in combination with the Intellian i4 Satellite Dish and a DVB-S2 receiver to capture and inspect unencrypted satellite internet traffic off the air.

What It Does

Many satellite internet providers beam IP traffic down to large coverage areas using DVB-S2 or DVB-S2X. A significant portion of this traffic is unencrypted. By capturing the raw transport stream with a DVB-S2 receiver and running it through dontlookup, you can extract actual IP packets and open them in Wireshark.

Capturing

Background: BBframes

DVB-S2 transmits data in Baseband Frames (BBframes) — the lowest-level data unit after forward error correction. IP traffic is encapsulated inside these frames, either directly or via GSE or MPEG-TS wrappers. dontlookup operates on raw BBframe payloads.

The problem is that virtually every DVB-S2 receiver card exposes only a processed MPEG-TS stream to userspace. The DVB API in Linux was designed for TV reception, so the driver demodulates the signal and hands you PIDs — the raw BBframe layer is discarded. If the satellite provider uses MPEG-TS encapsulation you get lucky and this works fine. If they use direct IP or GSE encapsulation, which does not map to MPEG-TS PIDs, you get nothing.

Background: Blind Scan

When tuning a satellite receiver normally, you already know what you are looking for — frequency, symbol rate, polarisation, and FEC parameters. These are typically sourced from a database like [LyngSat] or a channel list. Blind scan is the alternative: the receiver sweeps the entire band and attempts to lock onto any signal it finds, determining the parameters itself.

This matters for dontlookup because the most interesting transponders — those carrying unencrypted IP backhaul — are generally not listed in any public database. They are not broadcast television services; they are private data links that nobody was expected to be looking at. A receiver limited to known transponders will never find them.

Blind scan is more computationally intensive than directed tuning and takes longer to complete a full sweep, but it is the only reliable method to discover unknown transponders. Not all DVB-S2 receiver hardware exposes blind scan capability to the Linux DVB API, even if the underlying demodulator chipset supports it — this is one of the reasons the TBS5927 became the reference hardware for this project.

TBS Driver Patch

The dontlookup repo ships a kernel patch (tbsdriver.patch) for TBS DVB-S2 receiver cards that exposes the raw BBframe stream to userspace, bypassing the normal DVB API. This is required to capture proprietary or non-MPEG-TS encapsulations.

However, the researchers used a TBS5927 which has become unobtainium.

A TBS5925 may work and is on its way to NURDspace for testing. User:20h also generously acquired a TBS-5580. Neither has been confirmed working yet.

The TBS5925 is documented to work with EUMETCast: TBS5925 EUMETCast setup guide.

SAT>IP Devices

The Digibit R1 SAT>IP tuner used at NURDspace presents itself as a network-attached DVB-S2 tuner. It handles LNB power, DiSEqC, and tuning over the network, but only streams MPEG-TS over SAT>IP. There is no way to get raw BBframes out of it without hardware modifications.

Further investigation revealed it runs STMicro's proprietary STAPI stack internally — stpti5_core, stfdma_core etc. — with no /dev/dvb/ device exposed. minisatip talks directly to STAPI, bypassing the Linux DVB API entirely. Intercepting data at the STAPI layer to get raw BBframes would require significant reverse engineering effort.

STV090x Based Chipsets

The STV090x demodulator (used in many DVB-S2 cards) is capable of outputting raw BBframes at the hardware level, but the Linux driver simply never implements it. Investigation of stv090x.c showed it writes an output configuration register at init:

{ STV090x_OUTCFG, 0x00 },  /* serial TS output, hardware default */

The crucial register is PDELCTRL2 with FRAME_MODE_FIELD set to 1 — discovered via a 2012 linux-media mailing list post documenting exactly this on a TBS6925. One register bit is all it takes.

The plan was to apply a similar patch to a SkyStar 2 eXpress HD (SAA716x + STV090x). This ran into a separate problem: newer AMD motherboards have removed the 3.3V rail from PCIe slots. DVB cards use 3.3V for logic; GPUs do not. The SkyStar and other PCIe satellite tuners simply failed to enumerate, while a GPU in the same slot worked fine. Testing on an older motherboard has not yet been attempted.

MiniTiouner / Longmynd

The MiniTiouner is a USB DVB-S2 receiver designed by the British Amateur Television Club (BATC) for amateur TV reception, primarily targeting the QO-100 geostationary amateur transponder. Unlike the TBS cards, it uses the STV0910 demodulator which outputs raw BBframes natively — no kernel patching required.

The Longmynd software (also by BATC) drives the MiniTiouner and outputs BBframes directly over UDP, making it straightforwardly compatible with dontlookup.

The catch is availability: purchasing the kit requires a BATC membership, and the hardware is not sold elsewhere.

Professional IRD: Adtec RD-60

An Adtec RD-60 professional broadcast IRD is also available. This is the kind of kit used by actual broadcasters to receive satellite feeds.

Relevant outputs and interfaces:

  • DVB-ASI output carries raw MPEG-TS bitstream over the professional broadcast standard ASI interface. Feeding this into a PCIe ASI capture card gives a clean TS stream, but it is still just TS — not BBframes.
  • Web API and serial command interface — professional IRDs sometimes have diagnostic modes that surface baseband data below the normal TS output. This has not been explored yet.

Internally, the RD-60 runs Linux on a PowerPC CPU. The receiver and ASI sections communicate with the PowerPC over PCI, which means in principle the full data path is accessible from software — including potentially below the TS layer. This makes it a more interesting target for BBframe extraction than it first appears.

<!-TODO: investigate PCI-attached receiver section from Linux userspace on the PowerPC -->

GNU Radio / gr-dvbs2rx

An SDR-based approach using gr-dvbs2rx (a GNU Radio out-of-tree module for DVB-S2 demodulation) was also explored. This would allow a HackRF or similar SDR to demodulate DVB-S2 and potentially extract BBframes entirely in software, without any dedicated DVB receiver hardware.

The main constraint is bandwidth. Typical Ku-band transponders run at 27–45 Msym/s, requiring roughly that much RF bandwidth — well beyond the HackRF's 20 MHz maximum. However, some data-only transponders run significantly narrower symbol rates and could fit within an SDR's bandwidth.

Combining two HackRFs in a phase-coherent configuration (the HackRF has explicit support for clock synchronisation between units) could double the available bandwidth and is cheaper than a LimeSDR.

Links