KAR analyse vanaf de zolderkamer

Welkom bij deze liveblog. Hier documenteer ik in real-time hoe ik het KAR (Korte Afstand Radio) protocol reverse engineer — het systeem waarmee bussen prioriteit krijgen bij verkeerslichten (VRI’s).

Laatste update: 2026-07-19 22:30 CET

tl;dr

Ik woon naast een bushalte in Zaandam waar EBS bussen langskomen. Met een SDR en wat Python decodeer ik hun 4FSK radio-signalen op 429.85 MHz. Het blijkt Pacific Crest 4FSK te zijn (SATEL 3AS compatible) met een V.24/V.28 self-synchronizing scrambler. Inmiddels heb ik duizenden frames gedecodeerd en kan ik bus- van VRI-berichten onderscheiden. De envelope is open (RF, scrambling, handshake-patronen) — de brief (attribuut-mapping, radio-adres) nog niet. Het einddoel: replay via Si4463 om in de praktijk te testen.

Hoe het begon

Ik woon op zolder met uitzicht op de bushalte bij station Zaandam. Elke dag rijden EBS bussen 391 (Amsterdam Centraal), 69 (Zaandam Station) en 64 (Zaandijk Rooswijk) langs. En elke keer als er een bus komt, springen de verkeerslichten op groen.

Dat kan geen toeval zijn. Dat is KAR.

KAR is een Nederlands 4FSK radiosysteem op 429.85 MHz waarmee bussen (en trams, politie, brandweer, ambulance) zich aanmelden bij verkeerslichten. De VRI stuurt dan bevestiging en — als het goed is — geeft prioriteit.

Ik wilde weten: wat zegt die bus precies tegen het verkeerslicht?

De setup

Hardware:

• Nooelec NESDR SMArt v5 — een simpele USB SDR van €40
• Mac Mini op zolder — 24/7 capture machine
• M5StickC Plus2 + CC1101 — poging tot replay (inmiddels vervangen door Si4463)

Software:

• pyrtlsdr — Python binding voor de RTL-SDR
• kar_extract.py — eigen 4FSK decoder met exhaustive alignment sweep
• kardb.py — SQLite database met alle gedecodeerde frames

Eerste doorbraak: Pacific Crest 4FSK

Na veel vijven en zessen bleek het protocol Pacific Crest 4FSK te zijn, compatible met de SATEL 3AS radio-modem. Parameters:

De scrambler was de echte doorbraak. Het is een self-synchronizing scrambler die geen per-session key gebruikt — alleen de vorige 16 uitgangsbits. De descrambler functie:

p[n] = s[n] XOR s[n-1] XOR s[n-3] XOR s[n-12] XOR s[n-16]

Dit bewees ik door frames van verschillende bussen te vergelijken: de eerste 9 bytes waren identiek. Alleen een self-sync scrambler kan dat produceren met verschillende zenders.

6000 frames later

Op dit moment draait er continu een capture-loop op zolder. Elk uur een nieuwe capture van 300 seconden. De data wordt automatisch gedecodeerd, gedescrambled en opgeslagen in een SQLite database.

De stand van zaken:

• ~280 captures (en groeiend)
• ~6000 best frames — na consensus voting over 427 alignments
• Classificatie: bus-request (54%), bus-retransmit (17%), VRI-echo (14%), VRI-response (10%), VRI-status (6%)

Wat we weten

Bus- en VRI-berichten onderscheiden

Het blijkt dat VRI-berichten een hogere RSSI hebben (~0.8-1.1) dan bus-berichten (~0.03-0.5). De VRI staat immers vlakbij op het kruispunt, de bus komt van verder weg.

Echo’s en responses

De VRI stuurt twee soorten berichten terug:

• Echo (14%): stuurt exact dezelfde bytes terug die de bus stuurde — een bevestiging
• Response (10%): stuurt eigen inhoud — een antwoord met data

Byte-modificatie patronen

De VRI wijzigt specifieke bytes in consistent patroon:

• Byte [1] wordt vaak 0xee — een statuscode
• Bit-flips op posities 0x80 en 0x40 — vlaggen die aan/uit gaan
• Single-nibble XOR met 0x04 — een counter of checksum

Het 101-byte frame

Drie frames uit één capture bevatten een 101-byte bericht. Dit is bijna zeker het CROW KAR 24-attributen bericht — de volledige uitwisseling met voertuig-ID, lijnnummer, GPS-positie en stiptheid. Ongeveer 78% van de bytes is constant (protocol overhead), de rest is variabel per transmissie.

Blokkades

Niet alles gaat vanzelf:

• CC1101 4FSK Gray encoding — de CC1101 chip forceert Gray encoding in 4FSK mode, waardoor HDLC frame markers (0x7E) corrupt raken. Oplossing: Si4463 module besteld, die geen Gray encoding oplegt.
• KV-3 document — het formele KAR protocol document is niet publiek.
• CRC-16 — geen standaard CRC (CCITT, XMODEM, Modbus, DNP) matcht. Het is of een custom checksum of het zit niet in het radio-protocol maar hoger in de stack.

Volgende stappen

1. Verdiepen exchange-analyse: welke bus-frames triggeren welke VRI-responses?
2. Byte-positie mapping: welk CROW-attribuut staat op welke positie in het frame?
3. Si4463 firmware: replay-module bouwen om zelf KAR frames te kunnen versturen
4. KV-3 achterhalen: wellicht via een WOO-verzoek?

Dit is een liveblog. Nieuwe inzichten worden direct toegevoegd. Blijf scrollen voor updates.

🔴 Update 19 juli: Voertuig-ID niet in HDLC payload (en wat wél)

Grote doorbraak vandaag — maar niet de doorbraak die ik zocht. Na een exhaustieve byte-positie analyse over alle frame lengtes (1-101 bytes) bleek: het voertuignummer staat niet in de HDLC payload.

Ik heb elke byte-positie in elk frame-type gecontroleerd op correlatie met het EBS fleetnummer (4203-4402). LSB, MSB, nibble, XOR met constante — niks. Zelfs binnen één capture (één bus-pass) zijn alle bytes variabel. Geen session key, geen vaste identificatie.

Hoe weet de VRI dan welke bus het is?

Het antwoord staat in de SATEL 3AS radio handleiding. Deze radio’s hebben een eigen adresseringslaag — vergelijkbaar met een netwerklaag — die bovenop het HDLC frame wordt gezet. De VRI identificeert de bus op radio-niveau, voordat het HDLC frame wordt gedecodeerd.

Dit betekent: het voertuig-ID dat wij hebben (EBS fleetnummer 4203-4402) is niet hetzelfde als de KAR SID (0-65535) die in het protocol wordt gebruikt. En beide zitten waarschijnlijk verborgen in een deel van het radiosignaal dat onze decoder niet meepakt.

101-byte frame template volledig in kaart

Wat wel lukte: het 101-byte CROW bericht uit Capture #41 volledig in kaart brengen. Drie identieke frames van voertuig 4316 (lijn 391, omloop 1806):

79 van de 101 bytes zijn constant — dat is protocol overhead (headers, fixed fields, padding). De overige 22 bytes bevatten de CROW-attributen: vermoedelijk een counter (7 posities die synchroon XOR 0x10 krijgen), GPS-coördinaten, snelheid, stiptheid, en een custom checksum.

Helaas is dit frame slechts van één voertuig (V4316) gevangen — geen cross-vehicle vergelijking mogelijk om de velden te valideren.

VRI polling protocol ontdekt

Aan het einde van Capture #41 ontdekte ik een herhalende sequentie die het VRI polling protocol blootlegt:

aa65                  start marker
0951c244333ca296      VRI/station ID?
25d441bc568c          data met counter
844a                  ACK token
c4109a3e69d47cbad83475bc14f250  bericht (15 B)
0a6b54e4f1383609a4a3  bericht vervolg
2848                  ?
cdaa86ce329dd5d0aeb8393dfa915ee031  data (17 B)
8434                  ACK token
17c0765237            data (5 B)
7727527c2d28          data (6 B)

Dit is niet het KAR aanmeld/uitmeld protocol, maar de VRI polling loop — een periodieke uitwisseling tussen VRI en alle bussen in de buurt.

Wat dit betekent

1. Vehicle-ID zoeken in HDLC payload is een dood spoor — de identificatie zit in de radio-laag.
2. Het 101-byte CROW bericht is wel degelijk te ontleden — de vaste/variabele byte posities zijn nu bekend.
3. De VRI-polling structuur is zichtbaar in plaintext na descrambling.
4. Replay blijft het doel — met de Si4463 module (E30-400M20S) kunnen we frames versturen op de correcte frequentie zonder Gray encoding problemen.

Stand van zaken

• 282 captures, ~1M frames, 41 unieke voertuigen in de database
• Continuous capture draait 24/7 (PID 74522)
• Er is een find_vehicle_bytes.py voor geautomatiseerde correlatie-analyse
• De Si4463 module is onderweg — firmware moet nog geschreven worden

Volgende zet

Zodra de Si4463 module binnen is: firmware schrijven met een correcte driver voor de E30-400M20S, een replay frame bouwen (met correcte V.24/V.28 scrambling en HDLC framing), en testen bij de VRI op de hoek.

🔴 Update 19 juli (20:15): Si4463 driver — van eigenbouw naar open source

Toen ik de firmware voor de Si4463 schreef, leek dat simpel: een SPI interface, wat commandos, een 4FSK configuratie. Maar na een avond vergelijken met drie open source implementaties bleek: mijn driver zat er grotendeels naast.

Wat ik fout deed

Mijn waitForCTS() controleerde of bit 0 van de response 1 was (cts & 0x01). Maar de Si4463 antwoordt met 0xFF (alle bits hoog) als hij klaar is voor een nieuw commando. Alle werkende libraries doen:

while (spiXfer(0xFF) != 0xFF) delay(1);  // wacht op 0xFF, niet bit 0

De POWER_UP command verstuurde ik met 4 bytes — maar de chip verwacht 7 bytes inclusief de XO-frequentie (26 of 30 MHz). Zonder die informatie kan de chip de interne PLL en klokdeler niet correct initialiseren. Gevolg: het command werkt toevallig (de chip reageert), maar de synthesizer staat verkeerd.

Het grootste probleem: ik probeerde alle properties met de hand te zetten — frequentie, deviatie, datarate, packet config — maar Silicon Labs gebruikt een WDS tool (Wireless Development Suite) die een complete configuratie-array genereert van 27+ entries. Die zet niet alleen de voor-de-hand-liggende properties, maar ook:

• SYNTH_PFDCP_CPFF/CPINT — charge pump stromen voor de PLL
• MODEM_CHFLT_RX1/RX2 — receive filter coefficients
• MODEM_BCR_OSR/GAIN/GEAR — baud clock recovery
• MODEM_AFC_GEAR/WAIT/GAIN — automatic frequency control
• PA_MODE/PA_BIAS_CLKDUTY/PA_TC — power amplifier configuratie

Alleen al voor 4FSK zijn er ~40 register-properties die correct moeten staan. Overslaan of fout zetten → device zendt wel een carrier maar de modulatie is onleesbaar voor een SATEL 3AS ontvanger.

Wat ik ervan heb geleerd

De juiste aanpak

De werkende implementaties (ZakKemble’s Si446x library, Borchevkin’s driver, en Sholohov’s CW beacon) gebruiken allemaal dezelfde flow:

1. Reset (SDN hoog → wacht → SDN laag → wacht op CTS)
2. WDS config array laden — dit vervangt alle handmatige cmdSetProperty() calls
3. FIFO configureren (half-duplex mode voor 129-byte FIFO)
4. Data in TX FIFO schrijven
5. START_TX met channel, state-after-TX, packet length

De configuratie voor 429.85 MHz, 4FSK, 4800 bps moet gegenereerd worden met de Silicon Labs WDS software (Windows-only, helaas). Daarna kan ik die array in de firmware zetten en hoeft de driver alleen nog START_TX en FIFO-writes te doen — de radio staat dan perfect afgesteld.

Stand van zaken

• Si4463 module (AS10-M4463D-SMA) nog niet aangekomen
• Firmware (t-embed-si4463-replay/) heeft een herschreven driver nodig
• Open source libraries gevonden, bestudeerd en klaar om over te nemen
• Blog wordt geüpdatet zodra de module binnen is en de firmware werkt

Zodra die module er is: WDS config array genereren, de driver herschrijven op basis van ZakKemble’s code, en een werkende replay versturen. De rest van het protocol ligt al klaar — scramble, HDLC frame, CRC-16-IBM, bit stuffing. Het enige wat ontbreekt is een radio die het correct uitzendt.

🔵 Update 19 juli (20:45): 4FSK deviatie gemeten — exacte waarde voor Si4463 bekend

Tot nu toe wist ik niet wélke deviatie de SATEL 3AS radios gebruiken. De datasheet zegt “Pacific Crest compatible 4FSK, 4800 bps” maar niet óf dat ±2400 Hz of ±5000 Hz of iets anders is. Voor een werkende replay via de Si4463 moet de deviatie wél exact kloppen — anders herkent de VRI onze frames niet.

Meting uit echte bus-signalen

Ik schreef kar_measure_deviation.py: die laadt een burst capture, doet FM demodulatie (via np.diff(np.unwrap(np.angle(iq)))), filtert met een Gaussiaans LPF, en clustert de 4FSK symbolen met k-means in 4 groepen.

Het recept:

1. Burst detectie — vind het signaal in de ruis
2. FM demodulatie — converteer IQ naar instantane frequentie
3. Laagdoorlaat filter — 6 kHz cutoff om ruis te onderdrukken
4. Klokschatting — FM² spectrum piek rond 2400 Hz + zero-crossing verificatie
5. K-means — 4 clusters op alle FM samples → 4 symbol levels F0..F3
6. Omrekenen — rad/sample → Hz via freq_Hz = val * sample_rate / (2π)

De schoonste burst

Burst b003.cu8 (capture #41, 65 symbolen) gaf de meest betrouwbare meting:

De offset van ~22 kHz komt door de SDR centrumfrequentie die niet exact op de carrier zit. Wat telt is de onderlinge afstand:

De ratio van 0.309 bevestigt dat de symbolen lineair verdeeld zijn op posities −D, −D/3, +D/3, +D — exact zoals de Pacific Crest 4FSK standaard voorschrijft.

Waarom niet alle bursts even goed zijn

Over 20+ bursts gemeten varieert de deviatie van 1700-2350 Hz. Dat is geen echte variatie in de radio-instelling, maar een meetartefact: hoe zwakker het signaal, hoe meer de k-means de cluster center naar binnen trekt (de ruis trekt de centroid naar het zwaartepunt). Alleen de sterkste bursts (hoogste RSSI) geven de correcte waarde.

Wat dit betekent voor de Si4463 configuratie

De Si4463 gebruikt FREQ_DEV in eenheden van 10 Hz:

FREQ_DEV = 2400 Hz / 10 Hz = 240 = 0x00F0

Voor 4FSK zijn ook FSK4_TH1 en FSK4_TH0 nodig (decision thresholds). Die kan de chip automatisch berekenen als we ze op 0x0000 zetten — de Silicon Labs WDS tool doet dit standaard zo.

Conclusie: voor een replay op 429.85 MHz, 4FSK, 4800 bps, moet de Si4463 configuratie FREQ_DEV = 0x00F0 bevatten. De rest van de properties (MODEM_CHFLT, SYNTH_PFDCP, MODEM_BCR, MODEM_AFC, etc.) komt uit de WDS-generated array — maar de deviatie staat nu vast.

🟢 Update 19 juli (21:00): Nieuwe captures — plaintext goudmijn

De continuous capture draait inmiddels 316 captures (was 282) — maar kwantiteit zegt niet alles. De echte goudmijn zit in capture 301: 47 frames mét plaintext, inclusief complete bus→VRI→response exchanges.

Het dddd = a885 verband

In ciphertext zien we regelmatig het frame dddd van de bus. Na descrambling wordt dat a885 — precies het bus-prefix token dat we eerder herkenden (line-gerelateerd, gebruikt door 6+ voertuigen). Dit bevestigt dat de descrambler correct werkt: dezelfde 2-byte ciphertext produceert consistent dezelfde plaintext, en die plaintext matcht met onze eerdere handmatige analyse.

Schoonste exchange tot nu toe (capture 301)

De complete uitwisseling in plaintext toont hoe bus en VRI communiceren:

Bus (request)     → eb00a02392
VRI (response)    → 53b46ce388ae89

Bus (request)     → 773cf8cde6ce83a5
VRI (echo)        → 773cf8cde6ce83a5    (identiek!)

Bus (request)     → 59e4
VRI (echo)        → 59e4                (identiek!)

Bus (request)     → 73c2286e48a789df1ef0
VRI (echo)        → 73c2286e48a789df1ef0 (identiek!)

Bus (request)     → a96c2437b2181962e89e6829d7f0849f734e9ccb  (20 bytes!)
VRI (response)    → a96aa473b2181962e89e6829d7f0849f734e9ccb  (1 byte verschil)

Het patroon: VRI echoot vaak exact dezelfde content, maar bij sommige berichten stuurt de VRI een gemodificeerde response — en dan is het verschil minimaal (1 byte, soms 1 nibble).

De 20-byte near-miss

In de 20-byte exchange is het verschil precies 1 byte:

Bus:    a96c2437b2181962...
VRI:    a96aa473b2181962...
           ↑↑    ↑
         0x6c→0x6a  0x37→0x73

Wacht — dat zijn eigenlijk twee bytes die verschillen, niet één. Byte 1: 6c → 6a (XOR 0x06). Byte 5: 37 → 73. Dat laatste is een volledige byte-swap, geen bit flip.

Dit versterkt het beeld: de VRI heeft logica per veld — sommige velden past hij aan, andere laat hij intact. Dit is consistent met een protocol waarin de VRI een status- of volgordefield bijwerkt.

Nieuwe inzichten

1. eeee is geen fout maar een status code — zowel bus als VRI gebruiken eeee in 2-byte frames als status/heartbeat. De VRI stuurt eeee als hij niks te melden heeft; de bus gebruikt het soms ook als request.

2. De VRI echoot systematisch — minstens 50% van de bus-request wordt letterlijk teruggekaatst. Dit is waarschijnlijk een ACK op radio-niveau.

3. Lange frames (18-20 bytes) komen van meerdere voertuigen — V4402 in capture 169 stuurt 18-19 byte frames, niet alleen V4316. Het 101-byte frame blijft uniek voor V4316.

4. Plaintext decryptie werkt consistent — 47 frames in één capture met correcte V.24/V.28 descrambling. Geen framing errors.

De database bevat nu 1M+ frames met 6662 best-frames, 316 captures, en 26+ unieke voertuigen. Genoeg data voor de protocol analyse — het wachten is op de Si4463 module om replay te kunnen testen.

🟣 Update 19 juli (22:30): Handshake in ciphertext — en wat we níet hebben gekraakt

Na de plaintext-goudmijn van capture 301 ging ik dieper in op de ciphertext. Want één ding werd duidelijk: als de VRI één byte wijzigt in het gescambled frame, ziet de descrambler dat als 2–3 bytes verschil. De cascade van de V.24/V.28 scrambler maakt plaintext-vergelijkingen rommelig. De echte VRI-modificaties zitten in de cipher.

60 near-misses, 40 single-byte changes

Van alle bus→VRI pairs binnen 1 seconde (zelfde lengte, andere content) zijn er 79 simple near-misses (≤4 bytes verschil). Daarvan wijzigt de VRI in 40 gevallen precies één byte.

De dominante XOR-waarden:

Ongeveer 43% is een pure single-bit flip. De VRI toggelt statusflags — hij herschrijft geen hele berichten.

Capture 90: het handshake-recept

Het schoonste voorbeeld zit in capture 90, een 3-byte exchange:

t=192.8s  bus  c64088   → geen antwoord
t=192.8s  bus  c64088   (retransmit) → stil
t=193.8s  bus  c60088   (byte[1] bit 6 gewist)
t=194.0s  VRI  c6008c   (byte[2] bit 2 gezet = ACK)

De bus probeert eerst met bit 6 aan, krijgt niks, wist die bit, en pas dan antwoordt de VRI met één bit als bevestiging. Response-tijd: 0,2 seconden.

Andere single-byte highlights:

L3  Cap#311:  5edb26 → 5edb22   [2] bit2 clear
L3  Cap#143:  ee505e → ee50de   [2] MSB set
L9  Cap#64:   99d9…  → 9dd9…    [0] bit2 set
L9  Cap#82:   bd14…  → bd15…    [1] +1
L5  Cap#49:   b551…  → b511…    [1] bit6 clear

Geen rolling code

Ik dacht even aan meelopende codes — bussen passeren tientallen VRI’s per dag, een database van secrets per bus×kruispunt zou absurd zijn. De data bevestigt dat:

• Geen monotone counters over tijd per voertuig (0/17 consecutive steps)
• 27% van de bus-frames komt exact terug (hergebruik)
• Tokens als eeee / dddd verschijnen in tientallen captures
• Zelfde bus-payload → altijd dezelfde VRI-near-miss (0× verschillende responses)
• VRI SET vs CLEAR van bits is ongeveer 50/50 — statusflags, geen secret-advance

Wat wél uniek is per bus: payloads overlappen niet tussen fleetnummers. Dat past bij een vast radio-adres (SATEL-laag / KAR SID), niet bij crypto per sessie.

Fleetnummers in de payload? Nee

Alle captures van vandaag zijn continuous (cont_20260719_…) — 153 stuks, 0 met fleetnummer-label. Die labels komen alleen mee als de monitor DRGL/ovzoeker koppelt. Totaal in de DB: 121 tagged, 202 untagged.

Op de tagged set (oude monitor-runs) heb ik opnieuw gezocht: little-endian, big-endian, BCD, LSB, MSB van 4203/4341/etc. in cipher én plaintext. Discriminatie ≈ nul. Het EBS-voertuignummer speelt operationeel een rol, maar het staat niet als herkenbaar getal in het HDLC-frame.

Alle captures tot nu toe zijn overigens alleen EBS — bedrijf vs voertuig kunnen we dus nog niet scheiden. Andere VRI’s / andere vervoerders zouden dat wél kunnen.

Hoe groot is de kans dat replay werkt?

Belangrijk: 50% van de exchanges krijgt VRI-ACK na precies één bus-frame. Mediaan is 1 frame. In 76% van de long-frame cases is dat long frame het eerste bus-bericht — geen verplichte short handshake ervoor. Een smoke test met één captured frame is dus legitiem.

Als die stil blijft, helpt een hele nagespeelde conversatie waarschijnlijk niet: dan zit het probleem in RF of radio-adressering, niet in “te weinig frames”.

Eerlijke stand

Ik heb de envelope open:

• frequentie, 4FSK, deviatie ±2400 Hz
• V.24/V.28 scrambling
• bus vs VRI op RSSI + timing
• echo vs near-miss ACK in ciphertext
• geen rolling code, geen fleetnr in payload

De brief is nog dicht:

• welke byte wélk CROW-attribuut is
• waar het radio-adres / KAR SID zit
• of een replay prioriteit triggert

Wat nu wél en niet zinvol is

Minder zinvol: nog meer continuous captures bij deze VRI. Meer EBS, meer near-misses, weinig nieuwe structuur.

Zinvoller:

1. Wachten op de Si4463 — één praktijk-test zegt meer dan een week theorie
2. Andere VRI’s — andere SID/config, eventueel andere vervoerder, check of handshakes universeel zijn
3. Pas daarna multi-frame protocol uitwerken

Kortom: niet gekraakt, wél veel beter begrensd. De volgende echte sprong is hardware, niet nog een SQL-query.