Shrnutí: New York jako první americký stát přijal zákon, který nařizuje výrobcům 3D tiskáren, CNC frézek a dalších digitálních výrobních strojů zabudovat do jejich zařízení software, jenž před každým tiskem nebo obráběním prohledá soubor se vzorem a porovná ho s databází zbrojních plánů. Pokud algoritmus vyhodnotí soubor jako podezřelý, stroj se nespustí. Zákon byl přijat jako součást státního rozpočtu na fiskální rok 2026–2027 a podepsán guvernérkou Kathy Hochul.

1. Jak zákon vznikl a co přesně říká

Příslušná ustanovení jsou součástí rozpočtového zákona S.9005 / A.10005C (New York State Budget 2026–2027). Klíčová část je skryta v Part C, která obsahuje dva podčástky:

• Subpart A — trestněprávní ustanovení týkající se výroby nelegálních zbraní na 3D tiskárnách a sdílení digitálních plánů.
• Subpart B — technický mandát: povinné zabudování tzv. blocking technology do všech 3D tiskáren a CNC strojů prodávaných v New Yorku.

Zákon definuje „3D tiskárnu" extrémně široce — jako:

jakýkoliv stroj schopný vyrobit trojrozměrný objekt z digitálního návrhového souboru metodou přídavné výroby (additive manufacturing) nebo trojrozměrných úprav objektu metodou subtraktivní výroby (subtractive manufacturing).

Tato definice tedy pokrývá nejen klasické FDM/SLA 3D tiskárny, ale i CNC frézy, CNC routery, soustruhy, laserové řezačky a v důsledku i hobbyistické plotry jako je Cricut. Jednoduše: pokud stroj převádí digitální soubor na fyzický objekt, zákon se na něj vztahuje.

2. Co je "blocking technology" a jak má fungovat

Zákon definuje blocking technology jako hardware, software, firmware nebo jiná integrovaná technická opatření, která zajistí, že stroj nezahájí zpracování žádné zakázky, dokud nebude příslušný soubor vyhodnocen algoritmem detekce zbrojních plánů (firearms blueprint detection algorithm).

Algoritmus má za úkol:

1. Vyhodnotit soubor (STL, G-code nebo jiný CAD formát).
2. Zjistit, zda lze soubor použít k výrobě střelné zbraně nebo nelegálního dílu.
3. Podezřelý soubor zablokovat — stroj se nespustí.

Zákon nevyžaduje jen software. Vyžaduje, aby byl tento mechanismus přítomen přímo v každém prodávaném zařízení. Zároveň ruší možnost online prodeje a zásilkového doručení — veškerý prodej a přenos 3D tiskáren musí probíhat osobně (in-person). Pokuty za porušení dosahují až 10 000 USD za incident.

Zákon neobsahuje žádné výjimky pro:

• komerční výrobce (automobilový, letecký, medicínský průmysl),
• výzkumné instituce,
• federálně licencované zbrojíře (federally licensed gunsmiths),
• školy a vzdělávací instituce.

3. Trestný čin za digitální soubor

Subpart A zavádí nový typ trestného činu: distribuci nebo držení digitálního návrhového souboru, který by mohl sloužit k výrobě dílu střelné zbraně, je nově zločinem třídy E (Class E felony), pokud jej sdílíte s kýmkoliv, kdo není federálně licencovaným zbrojířem registrovaným v New Yorku.

Podle výkladu zákona se tato definice teoreticky vztahuje na:

• novináře reportující o dané problematice,
• výzkumné pracovníky studující 3D tisk a bezpečnost,
• designéry a umělce pracující s tvarovými soubory.

Trestní třída E v New Yorku odpovídá trestu odnětí svobody až na 4 roky.

4. Technický problém: proč to pravděpodobně nefunguje

Zákon naráží na zásadní technické překážky, na které upozornily firmy i nezávislí experti.

4a. Algoritmus čte geometrii, ne záměr

Detekční algoritmus porovnává tvary — geometrii objektu. Problém je, že běžné průmyslové díly sdílejí geometrii se součástkami zbraní. Trubka vypadá jako hlaveň, konzola jako rám zbraně, konektor jako spoušťový mechanismus. Jeden výrobce otestoval svůj firmware na navrhovaném algoritmu ještě před přijetím zákona: systém označil 17 % zcela legitimních tisků jako podezřelých — šlo o díly motorů, jígy, nástroje.

Firma Adafruit a její spoluzakladatel Philip Torrone to shrnuli lapidárně:

„Nevyžadujeme, aby stolní pily skenovaly dřevo kvůli zbraňovým tvarům. Nevyžadujeme, aby soustruhy volaly domů, než začnou obrábět kov. Ale přesně to tento zákon dělá s každým strojem, každým souborem a každou zakázkou."

4b. Open-source firmware — Marlin, Klipper, RepRap

Drtivá většina desktopových 3D tiskáren a CNC strojů běží na open-source firmwaru — primárně Marlin a Klipper. Tento software vyvíjejí dobrovolníci a komunity, není připojen ke státní databázi a není navržen pro compliance infrastrukturu. Stroje jsou navíc velmi často offline — záměrně nepřipojeny k internetu. Implementace zákonného požadavku by vyžadovala kompletní přepis firmwaru, což je technicky i kapacitně mimo možnosti komunitních projektů.

EFF (Electronic Frontier Foundation) zákon veřejně oponovala a označila blocking technology za "cenzurní software sledující každý tisk".

5. Software ThreeDGunT a role manhattanského státního zástupce

Zákon nevznikl ve vzduchoprázdnu. Španělská firma Print&Go se sídlem v Lleida (Katalánsko) již dříve vyvinula software nazvaný 3D GUN'T. Tento systém:

• porovnává každou tiskovou zakázku s databází zbrojních plánů,
• používá AI k rozpoznávání tvarů typických pro součástky zbraní,
• v případě shody automaticky blokuje tisk a upozorní správce.

Print&Go má přes 420 000 uživatelů a software je integrován přímo do firmwaru zařízení při výrobě.

Manhattanský okresní státní zástupce Alvin Bragg začal tento software prosazovat u výrobců 3D tiskáren ještě před tím, než zákon existoval. V roce 2025 zaslal dopisy firmám Creality a Flashforge s hrozbou právní odpovědnosti, pokud software 3D GUN'T neadoptují. Vyzval rovněž k odstranění zbrojních CAD souborů z cloudových platforem výrobců.

Jinými slovy: vymáhací mechanismus byl postaven dříve, než byl zákon napsán. Zákon pak byl upraven tak, aby odpovídal již existujícímu řešení.

6. Chystané zákony: prověrka před koupí tiskárny

Paralelně se v zákonodárném sboru New Yorku projednává Assembly Bill A2228 (a jeho senátní protějšek S3562), který dosud nebyl přijat, ale je aktivní v komisích obou komor. Tento návrh by zavedl povinnou prověrku trestní minulosti při koupi 3D tiskárny — stejný typ prověrky jako při koupi střelné zbraně. Prodejce by musel žádat státní divizi trestního soudnictví, která má 15 pracovních dní na rozhodnutí.

Zákon sponzoruje assembleymemberka Jenifer Rajkumar a v různých podobách koluje v zákonodárném sboru od roku 2023.

7. Šíření do dalších států

New York není jediný. Washington State projednával HB 2321 — prakticky identický zákon vyžadující blocking technology v 3D tiskárnách. Podle návrhu by washingtonský generální prokurátor vytvořil a průběžně aktualizoval databázi zakázaných zbrojních souborů. Zákon byl v lednu 2026 postoupen do komise pro občanská práva a soudnictví.

Vzorový zákon, jakmile projde v jednom státě, mají ostatní tendenci kopírovat — a výrobci, kteří chtějí prodávat v celých USA, si nemohou dovolit vyrábět dvě různé verze produktu. V praxi tedy regulace jednoho státu de facto ovlivní zboží prodávané v celé zemi.

Přehled klíčových faktů

Zdroje

• New York State Legislature — S.9005 / A.10005C text zákona
• The Reload — New York Bans Digital Gun Files, Aims at 3D Printers
• Electronic Frontier Foundation — Stop New York's Attack on 3D Printing
• Reclaim the Net — New York Budget Bill Mandates File Scans for 3D Printers
• 3D Printing Industry — Adafruit Warns of Flaws in the New Firearm Screening Bills
• Manhattan DA — D.A. Bragg Calls On 3D-Printing Companies To Address Proliferation Of Illegal Firearms
• Print&Go — 3D GUN'T: Print&Go's solution to prevent 3D printed Ghost Guns
• Fabbaloo — Washington Bill Would Require Weapon-Blocking Software in 3D Printers
• NY State Assembly — A2228 — background check bill
• NYS Focus — What's in the 2026 NY State Budget
• Times Union — Hochul pushes ban on 3D technology used to make guns

The post New York schválil zákon o sledování 3D tiskáren a CNC strojů first appeared on Hard Wired.

Nálepka za pár korun, telefon, a najednou Vám URL otevírá samo. NFC tagy z rodiny NTAG patří k nejlevnějším způsobům, jak fyzickému světu přidat softwarovou vrstvu — a přitom na to nepotřebujete pájku, kompilátor ani Arduino. Tenhle článek je hands-on návod, jak zapsat URL na NTAG215 přímo z iPhonu pomocí aplikace NFC Tools. Po cestě vysvětlím, co se v čipu při zápisu skutečně děje, protože pochopit, co máte v ruce, je polovina úspěchu příštího projektu.

Co je NTAG a proč by Vás měl zajímat

NTAG je rodina pasivních NFC čipů od firmy NXP Semiconductors. Pracují na 13,56 MHz, splňují standard NFC Forum Type 2 a ISO/IEC 14443-A, a nemají vlastní napájení — energii i hodinový signál si berou z magnetického pole čtečky (typicky Vašeho telefonu). To je důvod, proč Vám tag vydrží roky bez údržby a proč stojí v řádu korun.

Pro makery jsou zajímavé tři varianty:

Čísla v praxi: do NTAG213 se vejde URL do zhruba 130 znaků (po odečtení NDEF režie), do 215 přibližně jeden plnohodnotný kontakt s telefonem a e-mailem, do 216 i krátká Wi-Fi konfigurace plus URL bokem. Nálepky se prodávají od 5 Kč za kus, kvalitní plastové karty od 15 Kč, klíčenky od 20 Kč. Pro experimenty se hodí balíček deseti kusů od českého dodavatele (neven.cz) nebo dvacet kusů z AliExpressu — cenový rozdíl je marginální, ale dodací doba zásadní.

Potkáte je všude. Marketingové nálepky v obchodech, vstupenky na lyžovačku, visačky na zboží proti padělání, Amiibo figurky od Nintenda, párovací tagy bezdrátových sluchátek. NXP udává životnost 10 let retence dat a 100 000 zápisových cyklů, což pro většinu maker projektů znamená „vydrží to déle než zájem o projekt".

Anatomie čipu

Vnitřek NTAG215 si lze představit jako sešit rozdělený na 135 stránek po 4 bajtech. Některé stránky jsou Vaše hřiště, jiné jsou výrobní data, která nezměníte ani kdybyste chtěl.

Page 0x00 – 0x02   UID a system bytes      (read-only)
Page 0x03          Capability Container    (jednou píšete, OR-uje se)
Page 0x04 – 0x81   User memory             (504 B, zde žije Vaše data)
Page 0x82          Dynamic Lock Bytes
Page 0x83 – 0x84   Konfigurace (AUTH0, ACCESS)
Page 0x85          PWD (heslo, 4 bajty)
Page 0x86          PACK (potvrzení, 2 bajty)

UID (Unique Identifier) má 7 bajtů a je z výroby spálené v křemíku — žádná aplikace ho nepřepíše. Slouží mimo jiné jako sůl pro výpočet hesla u Amiibo (ale o tom zase jindy).

User memory je oblast, kam píšete přes NFC Tools. Data se ukládají ve formátu NDEF (NFC Data Exchange Format), což je standardizovaná obálka NFC Fora. Bez NDEF by si Váš iPhone se zápisem na Android tagem nerozuměl — díky NDEF rozumí oba.

Configuration pages určují, jestli je čip chráněn heslem (registry PWD a AUTH0), jestli a od které stránky platí ochrana (AUTH0), a jestli má heslo limit neúspěšných pokusů (ACCESS bit AUTHLIM). Když na ně narazíte v NFC Tools, většinou se jim chcete vyhnout, dokud nevíte, co děláte — špatně nastavený AUTHLIM dokáže udělat z funkčního tagu drahou nálepku natrvalo.

NTAG215 navíc umí pár chytrostí navíc oproti staršímu NTAG203: 32-bitové heslo (PWD_AUTH), digitální podpis pravosti od NXP (ECC originality signature, který odlišuje pravé NTAG od čínských klonů) a tzv. UID mirror, kdy si do NDEF zprávy můžete nechat automaticky zrcadlit UID čipu — užitečné pro per-tag analytiku bez nutnosti programovat každý kus zvlášť.

Co budete potřebovat

K tomu, co budeme dělat, stačí překvapivě málo:

• iPhone 7 nebo novější s iOS 13 a výš. Starší modely NFC sice mají, ale nepodporují třetí stranou ovládaný zápis. Pokud máte iPhone 13 a novější, bude čtení a zápis jednoznačně rychlejší a spolehlivější díky lepší anténě.
• NFC Tools od vývojáře Wakdev, zdarma z App Store. Existuje i placená „Pro Edition", ale pro zápis jednoduché URL ji nepotřebujete. Pro varianty jsou navíc plánovací funkce a profily — užitečné, až budete chtít sériově programovat víc tagů najednou.
• NTAG215 nálepku, kartu nebo klíčenku. Pro tento návod používám NTAG215, ale postup je identický pro NTAG213 i NTAG216, lišit se bude jen kapacita.

Jedna technická poznámka k platformě: iPhone má NFC anténu v horní části zařízení, kolem objektivu kamery. Android telefony ji mívají vzadu uprostřed nebo dole. Pokud jste zvyklý držet Android telefon plochou stranou na tag, s iPhonem to nepůjde — musíte přiložit horní hranu. Začátečníci se tady často zaseknou na tom, že „tag prostě nefunguje", přitom jen čtou špatnou částí telefonu.

Druhá poznámka, méně příjemná: iOS je v NFC schopnostech rok zpátky oproti Androidu. Pro zápis NDEF a čtení standardních tagů je vše v pořádku, ale na low-level operace (přímý přístup k jednotlivým stránkám, práce s MIFARE Classic, dump celé paměti) potřebujete buď Android, nebo specializovaný hardware jako Proxmark3 či Flipper Zero. Pro náš úkol je iPhone naprosto dostatečný.

Hands-on: zápis URL hardwired.dev

Konečně k věci. Předpokládám, že máte NFC Tools nainstalovanou a v ruce prázdný NTAG215. Postup má pět kroků.

Krok 1: Přečtěte tag

Otevřete NFC Tools a v dolním menu zvolte záložku Read. Telefon se přepne do skenovacího režimu a nahoře vyskočí systémový dialog „Připraveno ke skenování". Přiložte horní hranu iPhonu k tagu a držte ji nehnutě zhruba sekundu. Telefon zavibruje a vrátí Vám informace o čipu.

V odpovědi uvidíte něco jako:

Serial Number: 04:A3:B7:12:5F:80:C1
Tag type: ISO 14443-3A (NXP - NTAG215)
Technologies available: NFC A
Manufacturer: NXP Semiconductors
Maximum data size: 504 bytes
NDEF: Yes (writable, 0/504 bytes used)

Tohle je výchozí stav nového čipu. UID začínající 04 je typické pro NXP. NDEF je deklarováno jako prázdné a zapisovatelné.

Krok 2: Vytvořte záznam

Přepněte se na záložku Write. Klepněte na Add a record. Otevře se seznam typů — vCard, Wi-Fi, Bluetooth pairing, e-mail, telefon, geolokace, a další. Vás zajímá první položka: URL / URI.

V dalším okně vyberte schéma. NFC Tools má rozbalovací menu s běžnými prefixy (http://, https://, tel:, mailto: a další), a zbytek URL napíšete do textového pole. Pro náš účel:

• Schéma: https://
• URL: hardwired.dev

Aplikace Vám pod políčkem ukáže, kolik bajtů záznam zabere — pro https://hardwired.dev to bude méně než 20 bajtů. Klepněte na OK. Vrátíte se na obrazovku Write, kde teď uvidíte jeden NDEF záznam typu URI připravený k zápisu.

Krok 3: Zapište na tag

Klepněte na velké tlačítko Write. Telefon znovu otevře skenovací dialog. Přiložte horní hranu iPhonu k tagu a držte. Zápis NDEF zprávy o 20 bajtech trvá zhruba 200 milisekund — celý dialog ale obvykle zmizí až po vteřině, protože iOS si dává malou rezervu na ověření.

Po úspěšném zápisu uvidíte zelenou hlášku Write complete. Pokud místo toho dostanete chybu, nejčastější příčiny jsou tři: tag je zamčený lock bytes (nelze nic dělat), tag má heslo (potřebujete ho zadat ve Security menu), nebo jste ho odtrhli moc rychle (zkuste znovu).

Krok 4: Ověřte zápis

Vraťte se na záložku Read a tag přečtěte znovu. Tentokrát uvidíte v odpovědi přibyl řádek navíc:

NDEF: Yes (writable, 17/504 bytes used)

Record 0
  Type: URI
  URI: https://hardwired.dev

Tag teď nese Vaši URL. 17 z 504 bajtů využito — zbytek paměti je stále volný a Vy můžete přidat další záznamy (např. WhatsApp link, kontakt, Wi-Fi heslo) bez omezení, dokud nevyplníte kapacitu.

Krok 5: Otestujte v reálném světě

A teď to nejlepší. Zamkněte iPhone (jen stisk power tlačítka, do podivných stavů ho dávat nemusíte) a přiložte ho horní hranou k tagu. Na zamčené obrazovce se objeví banner s URL hardwired.dev. Klepnutím se otevře Safari.

Tohle je důležitý moment: na iPhonu funguje background NFC scanning pouze pro NDEF záznamy standardních typů — URL, telefonní číslo, e-mail, geolokace a několik dalších. Wi-Fi konfigurace nebo vCard se zamčené obrazovce neobjeví, protože iOS je nevyhodnocuje na pozadí (z bezpečnostních důvodů). Pokud chcete, aby tag spustil Wi-Fi připojení, musíte mít NFC Tools otevřenou, nebo využít Shortcuts Automation, kterou iOS k NFC tagům umí přivázat (ale to je téma na samostatný článek).

Gratuluji — máte první funkční NTAG.

The post NTAG čipy a jak je naprogramovat z iPhonu first appeared on Hard Wired.

15. dubna 2026 prolomil bezpečnostní výzkumník Paul Moore oficiální evropskou aplikaci pro ověřování věku za dvě minuty. Snímky obličejů z dokladů ukládala nešifrované. Biometrickou autentizaci šlo obejít přepnutím jednoho booleanu v config souboru. Francouzský výzkumník Baptiste Robert to nezávisle potvrdil.

O necelý měsíc později, 6. května, sdílela Výzkumná služba Evropského parlamentu na sociálních sítích lednový briefing o VPN. Označila je za „loophole in the legislation that needs closing". Tedy mezeru, kterou je třeba zacelit, protože děti přes VPN obcházejí ten samý systém ověřování věku, který jiný hacker prolomil v podivně krátkém čase.

A v tuhle chvíli česká média ztratila nervy.

Anatomie titulkové paniky

cnews.cz: „Konec anonymního surfování přes VPN". tiscali.cz: „EU jde po soukromém internetu". centrum.cz/cdr.cz: „Závažný útok na soukromí". V překladu: Brusel zítra zatne.

Reálně? EPRS je think-tank Evropského parlamentu. Píše analytické briefy pro poslance, ne zákony. Materiál ze 6. května není legislativní návrh, je to shrnutí debaty, ve které někdo nahodil tezi a publicistika ji zachytila jako fakt.

Nejstřízlivější hlas v ČR má v tomhle Petr Koubský v rozhlasovém Online Plus. „Orgán demokratické Evropy to udělat nemůže," říká k případnému zákazu. „Drtivá většina podobně radikálních návrhů skončí pod stolem."

Koubský má pravdu v jedné věci. Plošný zákaz VPN je v EU politicky neprůchodný. Naráží na DSA, GDPR, na ekonomický fakt, že VPN potřebují všechny korporace s remote workery. A pokud by k němu náhodou došlo, technicky by ho šlo vynutit jedině přes deep packet inspection na úrovni ISP. Což je infrastruktura, kterou dnes provozují Čína, Rusko a Írán. EU ne. A nikdo soudný nechce, aby ji EU začala stavět.

Jenže Koubský upozorňuje ještě na něco. Pracovní materiál Rady EU z roku 2025 zmiňuje, že členské státy zvažují přidat VPN na seznam služeb spadajících pod data retention. Čili povinné ukládání metadat o připojení. Kdo se kdy odkud kam připojil. Bez obsahu, ale s identitou.

A o tom by se mělo psát. Ne o zákazu, který nepřijde.

Goodhartův zákon pro internetovou regulaci

Když cíl regulace prochází přes proxy ukazatel, ten proxy ukazatel se sám stane cílem a celý smysl regulace se rozpadne. Britský Online Safety Act platí od července 2025. Měl chránit děti před pornografickým obsahem. Reálný výstup? Po jeho zavedení vyletěla stahování VPN aplikací v UK o 1 800 % během prvního měsíce. Proton VPN hlásil nárůst registrací o 1 400 až 2 000 procent v hodinách po zapnutí kontrol. Děti se nepřestaly dívat na porno. Naučily se obcházet věkové kontroly v devíti letech místo třinácti. A jejich rodiče si nainstalovali NordVPN spolu s nimi, protože měli pocit, že British Telecom je sleduje.

Britská Children's Commissioner Rachel de Souza na to v BBC Newsnight reaguje předvídatelně. VPN označuje za „absolutely a loophole that needs closing". Volá po věkovém ověřování pro samotné VPN služby. House of Lords v lednu odhlasoval 207 ku 159 dodatek k Children's Wellbeing and Schools Bill, který by zakázal poskytování VPN dětem. Vrátilo se to do Dolní sněmovny. Není to zákon.

Ale logika je tady jasná. Když ověřování věku funguje špatně, přidej další vrstvu ověřování. Když ani ta nefunguje, přidej třetí. Až nakonec stojí mezi devítiletým dítětem a kdejakým webem tři biometrické skeny, dva systémy national ID a jeden požadavek na verifikaci VPN klienta. Devítileté dítě mezitím používá Tor přes Tails na flash disku, který si vyrobilo podle YouTube návodu.

Goodhart by se bavil.

Děti budou.

Bezpečnost přes obscurantismus, jen obráceně

Co EU reálně řeší, není dětská pornografie. Je to nepříjemný fakt, že po dvou desetiletích politiky „internet pro všechny" se objevuje cosi jako digitální nepřehlednost. Lidé používají Signal. Šifrovaný DNS. WireGuard běžící na vlastní VPS za pět euro měsíčně. Self-hosted instance Nextcloudu. Místo Chromu Brave nebo Mullvad Browser. A státní aparát, který si zvykl, že webový provoz teče přes pět velkých korporací s funkčním legal interface, najednou neví, co se mu děje pod nosem.

Místopředsedkyně Evropské komise Henna Virkkunen to 29. dubna 2026 řekla na tiskové konferenci nahlas. VPN by neměly sloužit k obcházení age verification. Tečka. Že VPN ale slouží primárně k něčemu úplně jinému, třeba k tomu, abych se z hotelové WiFi v Bangkoku připojil bezpečně do firemní infrastruktury, to v jejím prohlášení nezaznělo. Já sám používám WireGuard denně pro připojení k vlastní laboratoři přes Tailscale. Sto procent provozu jde tunelem. A je mi naprosto jedno, jestli tam někde v paketu plave packet, který by někoho v Bruselu naštval.

Tedy bylo mi to jedno. Dokud jsem nečetl Council Working Paper, který Koubský zmiňuje.

Data retention je tichý jed

Logování metadat má jednu vlastnost, kterou plošný zákaz nemá: nedělá rozruch. NordVPN, Mullvad, Proton, všichni budou dál fungovat. Reklama bude dál slibovat anonymitu. Logo zámku v rohu obrazovky bude dál uklidňovat uživatele. Jenom v server room v Bukurešti nebo v Zürichu poběží daemon, který do databáze ukládá: IP X se v 14:23:11 připojila k serveru Y, který má ven adresu Z. Trvalo to 4 hodiny. Přeneslo se 12 GB.

Žádný obsah. Žádné dešifrované zprávy. Jen kdo, kdy, odkud, kam. Což je v digitální stopě často víc, než je obsah samotný. Metadata mají tu nepříjemnou vlastnost, že přežijí všechno end-to-end šifrování světa. Vědí to v NSA. Vědí to vyšetřovatelé. A teď to ví Rada EU.

Pro VPN poskytovatele to znamená dvě možnosti.

Buď vyhoví, a celá jejich marketingová narativa o no-logs policy se stane fikcí. Mullvad dnes hrdě tvrdí, že nezná IP svých uživatelů. V regulovaném scénáři by ji znát museli. Nebo se z EU stáhnou. Což udělá ten lepší kus z nich, jenže pak zbude uživateli volba mezi statně registrovaným provozovatelem s povinným logováním a turkmenstánskou společností s pochybným whois záznamem. Nebudu hádat, co si vybere medián českého uživatele.

A k tomu se přidá ještě jeden detail, který se v české debatě skoro neobjevuje. Open Dialogue Foundation prezidentka Lyudmyla Kozlovska upozorňuje, že přesně tímhle jazykem se argumentuje v autoritářských režimech. „VPN slouží k obcházení zákonů" je rétorická figura, kterou používá Roskomnadzor v Rusku, Ministerstvo informací v Bělorusku a regulátoři v Číně už dvacet let. Když ji začne používat Brusel, nezíská tím morální převahu. Ztrácí ji.

Co s tím

Devatenáct organizací (Mozilla, EFF, Proton, Tor Project, Mullvad a další) poslalo 5. května 2026 britským ministrům otevřený dopis. Cituji volně, protože stojí za to: omezení nástrojů pro ochranu soukromí podkopává schopnost uživatelů pohybovat se po síti bezpečně a budovat digitální gramotnost. Přeloženo do hardwired řeči: vyrobíte děti, které neumí používat HTTPS, ale umí obcházet státní DPI.

V Bruselu se zatím nic neděje. Formálně. EPRS briefing je analytický papír. Council Working Paper je interní pracovní materiál. Henna Virkkunen na jedné tiskovce vyslovila jednu větu. Komise zatím nepředstavila konkrétní návrh.

Jenže když se podíváš na vektory tlaku, na Online Safety Act v UK, Senate Bill 73 v Utahu, australský zákaz sociálních sítí pro děti do šestnácti let, French double-blind verification system, vidíš, že západní demokracie se v posledních dvou letech pomalu přesouvají od regulace obsahu k regulaci samotné infrastruktury anonymity. Není to konspirace. Je to inercie. Každý regulátor řeší svůj malý problém. Skleníkový efekt vznikne sám.

Pokud nás v ČR něco potká, nebude to oznámení „VPN je od dnešního dne zakázána". Bude to novela zákona o elektronických komunikacích, která rozšíří povinnost ukládání provozních a lokalizačních údajů na poskytovatele VPN služeb. Předloženo poslancem, kterého nikdo nezná. Schválena ve třetím čtení v pátek odpoledne. A v pondělí budeš mít metadata svého WireGuard tunelu uložená v centrální databázi po dobu šesti měsíců.

A teď zkus někomu na Twitteru vysvětlit, proč tě to štve.

The post EU nezakáže VPN. Donutí poskytovatele logovat metadata first appeared on Hard Wired.

Předmluva

• OS
  • Operační systém, software, na kterém bezi jiný software.
• Android
  • Operační systém od společnosti Google, Inc. pro chytré telefony.
• GOS
  • GrapheneOS, zkratka pro tento OS založený na OS Android
• LOS
  • LineageOS, zkratka pro tento OS založený na OS Android.
  • LineageOS je založený na AOSP.
• AOSP
  • Android Open Source Project, jedná se o Android, který je "očištěný" od služeb Google a má v sobě pouze licenčně svobodné programy.
• Raspberry Pi
  • Raspberry Pi je jednodeskový počítač, zaměřený hlavně pro kutily.
  • Tento počítač má tzv. GPIO pinout, ke kterému lze připojit čidla a ty poté přímo z OS programovat.
• DDNS
  • Dynamic DNS, neboli dynamická domena.
  • Jedná se o domenu, kterou vam přideli nejaky poskytovatel (třeba freedns.afraid.org), který vam doménu aktualizuje periodicky, což se hodi, kdyz mate dynamickou IP adresu.
• Desktop Mode
  • v kontextu OS Android se jedná o funkcionalitu operačního systému, který umožňuje ovládat telefon připojený k počítačovému monitoru (společně s periferiemi jako myš a klávesnice) jako klasicky stolni počítač, byť s jinou filozofií ovládání.
  • Telefon se tak chová jako klasický stolní počítač, ačkoliv si ponechává své rozhraní pro dodatečnou funkcionalitu.
  • Jinymi slovy lze říci, že telefon plní funkci stolniho počítače i telefonu zároveň.
  • Subjektivně si myslim, že budoucnost výpočetní techniky půjde i tímto směrem.

Co předcházelo

V květnu 2022 jsem se po delší době používání svého tehdejšího telefonu Nokia 5 (Čistý Android) rozhodl k zakoupení nového přístroje, jelikož Nokia přestávala stačit mým potřebam, stejně tak i co se velikosti displeje týče.
Volba tehdy padla na Xiaomi Mi 11 Lite 5G, verze 8G/128G v černé barvě.

Společně s tím jsem pořídil i ochranné prvky, jako je ochranné sklo, pouzdra. Jinymi slovy snaha o to, aby telefon vydržel užívání v dalších letech.

Nicméně, nebylo to pouze o pozitivech.

Pomerně rychle jsem si zvykl na nové prostředí, s ním však přišly i věci jinak mě neznámé a kolikrát i "podezřelé". Jelikož Xiaomi je čínského "návrháře" (rozlišuji zde, že produkt je vyrobený v Číně / ČLR, kdo jej však navrhuje je pro mě subjektivně další entita), byly zde i aplikace, které jsem k dispozici mít nechtěl, místy to bylo i podivné chování OS.

Je pravdou, že krátce po koupi přišla slíbená aktualizace na Android 13, nicméně tím jinak nedůležité aktualizace ze strany výrobce (v tomto případě považuji jak fyzicky výrobce HW, tak i dodavatel OS) ustaly. Vlastně jedinými aktualizacemi - dodám, že pouze akutními, řešícími konkrétní bezpečnostní problém - byly pouze bezpečnostní.

Příchod Garmin Pay

Časem jsem se rozhodl si pořídit i chyté hodinky, jelikož jsem v té době rozhodl vyzkoušet si placení právě chytrými hodinkami.

První pokus byl s Xiaomi Watch 2. Paradoxní volba pro tohoto výrobce byla pro "čistý" operační systém s možností Google Wallet/Pay přímo v hodinkách.
Nicméně nepovedlo se mi tohoto docilit, hodinky při pokusu nahlásily chybu a odmítly platební kartu přidat. Původní způsob užití bylo "zpohodlnit" placení (při nástupu do MHD, v obchodě...). Už v té době jsem se snažil najít myšlenku "Jak separovat platby od (relativně permanentně) k datům připojeného telefonu. Dá se říci, že o sledování fyzického pohybu bankovními institucemi jsem tušil, nicméně čím dál více jsem měl potřebu toto oddělit. V této době (duben 2025) mi "stačilo", kdyz na domácí Wi-Fi jednorázově sesynchronizuji peněženky.

Ač se mi Xiaomi Watch 2 líbily, vrátil jsem je zpět a rozhodl se jít cestou Garmin Forerunner 255, společně s Garmin Pay.

Záhy jsem zjistil, že hodinky od Garminu nejenže nabídly styl placení, který jsem hledal, ale také možnost si napsat vlastní program. Garmin jako takový má sice uzavřený systém, nicméně má k němu k dispozici SDK (Software Development Kit, sadu programu na vývoj softwaru pro daný produkt, zjednodušeno), což mi otevřelo cestu časem i k tomu si naprogramovat vlastní "statistiky" k jednomu mému oblíbenému sportu/relaxaci.

Lze tedy říci, že Garmin vyřešil nejen problém v té době pro mě aktuální, ale přidal mi do života i možnost žít aktivněji s možností si to sledovat.

Závěrem, mé současné hodinky mi doporucil člověk jménem Valentino Hesse, čímž mu za doporučení chci poděkovat i formou tohoto textu.

Nástup VPN

V pozdějších fázích, asi tak rok před změnou jsem ve zvýšeném měřítku začal užívat domácí VPN. Konkretne jsem na svoji Raspberry Pi 3. generace (verze B) nastavil WireGuard. Jelikož už v té době jsem měl na své DDNS i certifikát přes LetsEncrypt, vlastnictví VPN dávalo smysl, hlavně kvůli bezpečnosti týkající se bankovních aplikací.

S nástupem a nastavením VPN se trochu pojí i nová filozofie užívání telefonu. Na Xiaomi jsem si všiml tzv. "sekundárního prostoru", přeloženě jde o jiný profil/uživatele na stejném telefonu. Telefon s touto funkcionalitou se chová, jako kdyby byl právě čerstvě nainstalován / zapnut, de facto jde o stejné prostředí. Výhodou tohoto prostředí je možnost mít separované aplikace (takže třeba "normální" profil bez bankovních věcí a "bankovní" profil s bankovními aplikacemi různých bank, aplikace na nákup, popřípadě komunikátory se separovaným účtem).

S tímto se však pojí vyšší nároky na baterii telefonu, jelikož "klasický" Android / LineageOS / AOSP "neumí" ukončit profil, kdyz není potřebný. Znamená to tedy, že profil běží na pozadí i nadále (což není vždy nevýhoda). Nezřídka se stávalo, že i po jedné cestě do obchodu telefon dokázal "propálit" i 20 %. To sice na cestu tam i zpět stačilo, místy bylo však užívání s ohledem na maximální dostupnost náročné, což ne vždy bylo příjemné, zvláště při delších cestách.

Od ledna 2026 jsem začal řešit, čím Xiaomi Mi 11 Lite 5G nahradím.

Google Pixel 10 Pro XL

Postupne jsem začal zkoumat specifikace různých telefonu, co by daný přistroj měl umet. V zasade jsem měl tyto požadavky:

• Profiling (rozšířená forma "sekundárního prostoru" od Xiaomi, alespoň 2 profily), ideálně s možností daný profil ukončit,
• Always-On VPN (čili zablokování veškerého provozu, není-li VPN aktivní)
• Dual-SIM (historicky mám více SIM karet, které i do dnešního dne udržuji v "provozu")
• větší display (hodně dobré zkušenosti u Xiaomi Mi 11 Lite, který měl velký display)
• Na základě zkušeností u Xiaomi i dlouhodobá podpora výrobce/dodavatele OS.

Volbou po cca 4 měsících, rešeršovaného výzkumu i za pomocí jazykových modelů (Gemini, ChatGPT) v několika instancich (tímto mám na mysli opakované využití AI "Jaký telefon? Zde jsou mé požadavky"), tak i dotazování různých diskusních fór jsem dospěl ke konečnému závěru, kterým se stal Google Pixel 10. generace, verze Pro, velikost XL. Formalním jménem "Google Pixel 10 Pro XL 16/256 GB".

Telefon jsem se rozhodl po delším váhání objednat a jelikož jsem v té době měl i členství v jednom větším internetovém obchodě, definitivně jsem se rozhodl pro koupi, konkretně zelené verze "Jade", která mi "zapadala do korporatního stylu".

Lze říci, že další den mi byl telefon doručen a já se tak mohl začít radovat z nového stroje. Samozřejmě, pro maximalni ochranu nového stroje jsem i jako v případě Xiaomi Mi 11 Lite přiobjednal ochranné prvky.

GrapheneOS

Zjednoduším-li to, Pixel jsem si neobjednal pouze jako náhradu, ale i jako cilený důvod. Už asi 2 měsíce před koupí jsem měl povedomí o operačním systému "GrapheneOS", který oproti standardnímu Androidu nabízel i od základu přeimplementovanou funkcionalitu týkající se bezpečnosti a soukromí.

I to byla součást mého předchozího rešeršovaného vyhledavání, který OS chci použít. Ano, jinymi kandidaty byla i Motorola, nicméně některé funkce jako GrapheneOS nenabízela a byť s autory GrapheneOS uzavřela partnerství na oficiálního dodavatele hardware (tím rozumím telefony), první přístroje od Motoroly mající jako OS GrapheneOS nebudou k dispozici dříve, než v roce 2027.

Funkcionalita společná a rozdilná

Jednou z motivaci pro nový telefon byla i funkcionalita tzv. "Desktop Mode", která se předchozích verzích Androidu objevovala pouze od výrobce Samsung, tzv. "DeX". Jiná varianta - která hovořila i v prospěch dříve zmíněné Motoroly - byl "Smart Connect", nicméně důvodem pro Pixel (a později i GrapheneOS) byly aktualizace operačního systému samotného.

"Zakladní" Android

Desktop Mode

Základní Android - záleží zde i na hardwaru telefonu - funkcionalitu Desktop Mode umí. Předchůdcem jím bylo USB OTG (USB On-The-Go), což je možnost připojit USB flash do telefonu a zacházet s ním podobným stylem, jako kdyby šlo o počítač, stejně tak ovladaní přes klávesnici a myš.
Desktop Mode přidává DisplayPort Alt Mode přes USB-C, která vyjma datového/ovladacího přenosu přenáší i obrazové data možné zobrazit právě na externím monitoru. Je to umožněné tzv. propustností rozhranní, v tomto případě USB-C.

Aktualizce

Ač společnost Google má snahu o snižovaní tzv. e-waste (elektronický odpad), ne každý výrobce je tomu nakloneň. Ano, stále jde o výdělek, nicméně funguje-li telefon i po své moralní zastaralosti, výrobce zpravidla nechce poskytovat opravy jinak starým strojům.

Řada Pixel od Google má v tomto případě jinou filozofii, jelikož jde o "vlajkové lodě" pro Android, filozofie aktualizaci je zde jiná a mnohem otevřenější k tomu udržet stroj v aktuálním stavu, jelikož hardware je poměrně schopný.

Rozdíl GrapheneOS oproti "základu"

Co se GrapheneOS týče, většína funkcí je v tomto systému oproti zakladnímu OS Android zachována, nicméně GrapheneOS má zaměření hlavně na bezpecnost.
Velkým rozdilem je zde nejen Always-On VPN (formalně dostupná již od verze Androidu 7/8), nicméně společně s profilovaním (které oproti zakladu má funkci cíleného vypnutí) je možnost zablokovat veškerý síťový provoz, neběží-li VPN na pozadí.

Toto je především zajímavé, má-li uživatel domácí VPN.

Základní Android nabízí aplikacím tzv. "pískoviště", nicméně v GrapheneOS je této funckionalitě věnována mnohem větší pozornost po stránce zabezpečení a soukromí. Lze i v určitých ohledech aplikaci dovolit, kam bude moci pristupovat (což je hodně zajimavé u některých aplikací typu Messenger od Meta, stejně tak WhatsApp).

Dále je hodně zajimavé - především s užitím vypínatelného profilu - právě pro bankovní aplikace, kdy nejenže dovolíte této aplikací běžet explicitně pouze tehdy, kdy je potřeba, ale také donutíte její provoz jít třeba přes vaši domácí síť. Lze tak říci, že telefon máte elektronicky stále připojený přes síťový prvek, kterému důvěřujete (což o "datech" - datovému připojení přímo z telefonu platí dvojnásob).

Jinou variantou jsou i aplikace, které chcete mít "zamknuté" za specialním heslem a dostupné pouze a pouze majiteli přístroje.

Post Scriptum ke GrapheneOS

Mám-li v krátkosti udělat výtah, lze říci, že GrapheneOS jsem na svůj Pixel 10 Pro XL nainstaloval v podstatě hned druhý den po přijetí telefonu. Možnost vyzkoušet si zakladní OS přímo od Google jsem zde moc nevyužil, jelikož i přes vlastnictví nového telefonu (a s tím spojenym "WOW" efektem) jsem měl jasný záměr.

Nicméně musím dodat, že byl by nějaký závažnější problém s GrapheneOS, příručka, respektive postup pro instalaci "sériového" Androidu je velmi jednoduchá. V zásadě stačí upravený webový prohlížeč, USB kabel do počítače a trocha času. Je to tedy změna lehce zvrátitelná a dívám se tedy na GrapheneOS s "mentalitou" "Lze to vrátit, bude-li třeba".

Vedlejší efekt na předchozím telefonu

Ač jsem zmínil, že Pixel 10 Pro XL s GrapheneOS se stal hlavním "tažným koněm" mobilního života, otevřelo mi to možnost si "hrát" do té doby s "produkčním" telefonem od Xiaomi.

Měl jsem povědomí, že telefony od Xiaomi - nachází-li se na uzemí Evropské Unie - lze tzv. odemknout a nainstalovat jiný operační systém, v mem případě LineageOS / LOS. Je to forma AOSP, která v sobě nemá predinstalované aplikace od spolecnosti Google a i daného výrobce/návrháře. Jedná se tak o "De-Googled" software, místy i "de-bloated" systém.

Učinil jsem tak a telefon jsem začal užívat jako "záložní". Ač LineageOS podporu pro vypínání profilů nemá, Always-On VPN funkcionalita je zde také přitomna a lze ji užít podobným způsobem, jako na GrapheneOS.

Kdyz zmíním paradox, že Xiaomi Mi 11 Lite 5G po instalaci LineageOS "ožilo", nebudu daleko od pravdy. Pominu-li některé funkcionality řešitelné externě, telefon je plně funkční a stačilo by jej prodat s poznamkou "Toto nefunguje, je to záměr nikoliv můj, ale dodavatele systému".

Přislušenství k telefonum přidané

V kratkosti zde zminím i "obnovu" přislušenství pro oba přístroje. Puvodní, originální nabijecí adaptér pro Xiaomi postupně ztrácel na výkonu, rozhodl jsem se tedy - i s ohledem na pracovní Samsung Galaxy S25 - vyzkoušet si bezdrátové nabíjení, které jsem doteď neměl možnost využít.

Postupne volba padla na nejen GaN nabíjecí adaptér (vzhledem k dobrým referencím jsem užil "AlzaPower Ultímate X500 67W"), tak nabíjecí "puk" "AlzaPower WQT110" s podporou Qi2.

Jelikož jsem 3Dtiskař a 3Dmodelář, návrh a 3Dtisk stojánku přímo pro tento puk (zohledňuící proporce i slabší "MagSafe" u Samsungu Galaxy S25) byl logickym krokem.

Paradox s ohledem na bezpečnost aktualizovaného OS Android

Dostavám se tímto do poslední kapitoly, kde budu řešit a pokládat otázky, na které nejspíše nedostanu odpovědi.
Jakožto člověk IT-znalý (pro kontext, pracuji jako automation engineer, server administrator a on-call ve větší IT firmě) vnímám paradox, kdy výrobcem dodaný software má "certifikaci" pro určité funkce - v tomto případě třeba Google Wallet. Funkcionalitu Tap-n-Pay zde musím nahrazovat právě Garmin Pay.

Lze se na to i dívat z jiného úhlu pohledu, kdy platba hodinkami je paradoxně bezpečnější (NFC čip v hodinkách je jinak vypnut, zapíná se pouze, když uživatel funkci pro placení explicitně zapne v daný okamžik).

To platí jak pro GrapheneOS, tak pro LineageOS.

Telefony, obecně systémy (jak Android, tak i Debian, Arch Linux) se snažím držet v aktualním stavu a nezřídka si sám zajišťuji i aktualizace / opravy.

Otázka - kterou si kladu - je "Proc je alternativní systém jinak pravidelně aktualizovaný méně bezpečný, než zastaralý systém dodaný výrobcem, který nemá dalšího důvodu se o daný přistroj / hardware starat?"

Narážím tak na paradox, kdy i pravidelně aktualizovaný - ale necertifikovaný - software je bezpečnější, než jinak "certifikovaný" software od výrobce, který se rozhodl od určitého data aktualizace nedodavat. Pokud telefon nadále funguje, proč jeho funkcionalitu ořezávat, když by to samé mohl zvládat i dalších - dejme tomu - 5 let a tím tak ještě více "rozprostřít" náklady na iniciální pořízení?

Závěrem

GrapheneOS byl cílem snažení nejen o na to najít soukromí ve světě stále více a více připomínající 1984, ale také i tom, že jinak morálně zastaralé přístroje mají i nadále svůj důvod existovat.

Mým pohledem GrapheneOS - byť s určitými nedostatky, které jsem akceptoval - plní přesně to, co jsem od něj očekával, tedy nabídnout alespoň soukromí ve světě, kdy je každý krok monitorován.

Jako přidaným benefitem i nabídnout funkcionalitu, která by v roce rozmachu informačních technologií na začátku 21. stoleti mohla působit jako sci-fi - mít skoro plnohodnotný počítač ne v batohu, ale přímo v kapse.

Galerie

| Nabíjecí stojánek pro Qi2 wireless | "Dockovací" stanice s užitím 3Dtisku |
| | |

The post GrapheneOS, poznatky z užívání first appeared on Hard Wired.

Na střeše budovy Red Hatu v Brně-Medlánkách stojí krabička za pár tisíc, která dokáže to, co před dvěma lety zvládla jen profesionální infrastruktura: spolehlivě doručit zprávu přes půl republiky bez jediného mobilního operátora. Jmenuje se techpark.meshcore.cz a je to jeden z uzlů, na kterých teď stojí česká MeshCore síť.

V minulém článku jsme si vysvětlili, proč MeshCore existuje. Tohle je díl o tom, jak se do něj reálně připojit, co koupit, čeho se v české komunitě vyvarovat a proč není dobrý nápad nechávat na síti běžet vlastního pingovacího bota.

Co se za poslední čtyři měsíce změnilo

Když jsme o MeshCore psali loni v červenci, byla to spíš čerstvá zajímavost než infrastruktura. Mapa repeaterů byla řídká, návody chyběly, lidi tipovali, jestli se z toho stane další zaprášený meshtasticový pokus, nebo něco trvalejšího.

Stalo se to druhé. Mezi únorem a dubnem 2026 česká síť přerostla sama sebe. Jiří Eischmann, který má na blogu jeden z nejčtenějších českých textů o MeshCore, to popisuje jednoduše: sever Brna je tak hustě pokrytý, že mu na jednu zprávu odpoví klidně šest repeaterů najednou. Spojení Brno–Hradec Králové, které ještě v únoru chodilo jen přes jižní trasu Děvín–Hostýnské vrchy–Praděd, teď chodí severní cestou Babí lom–Orlické hory a zprávu i s potvrzením doručí během několika sekund. A když je někdo na Ještědu, dokáže paket skočit až přes Brdy – jeden hop na víc než sto kilometrů.

Síť se za tu dobu posunula i na úrovni firmwaru. Verze 1.15 vyšla 19. dubna 2026 a přinesla podporu pro Heltec V4.3, OTA aktualizace pro nRF52 desky přes mobilní aplikaci a pár změn chování, které stojí za přečtení, než člověk začne flashovat. Heltec V4.3 navíc umí ovládat FEM hardware, což komunitní buildy jako EasySkyMesh 14.1 dovedly až na 5,5 mA klidového proudu. Pro solární repeater je to zásadní detail.

A pak je tu jedna věc, která komunitu poslední tři měsíce zaměstnává nejvíc.

Kampaň 2-byte: proč si po prvním flashi musíš změnit jednu položku v menu

Když dva uzly v síti vygenerují klíče, jejichž první bajt náhodou koliduje, je problém. Cesty (path) v MeshCore se počítají z hashe veřejného klíče a jednobajtová verze umí adresovat jen 256 unikátních prefixů.

V březnu 2026 už v české síti žádné úplně volné prefixy nebyly. Síť rostla rychleji, než byl protokol původně navržený.

Řešení přišlo s firmwarem 1.14. Dvoubajtový hash sníží počet možných hopů (z 64 na 32), ale dá síti 65 535 unikátních prefixů – tedy řádově dost na to, aby kolize přestaly být problém. Česká komunita to vzala jako koordinovanou kampaň. Provozovatelé repeaterů jeden po druhém aktualizovali firmware a od konce dubna je 2B nastavení reálným standardem.

Pro koncového uživatele to znamená jednu položku v menu. Po prvním flashi otevřeš v aplikaci MeshCore Experimental Settings a Default Path Hash Size přepneš na 2 bytes. „V experimentálním nastavení si teď nastavte Výchozí velikost hashe cesty na 2b," stojí přímo na meshcore.cz. Když to zapomeneš, fungovat to bude, ale tvoje zprávy budou v menšině a u některých starších repeaterů by mohly zmizet úplně.

Takhle prozaicky se v praxi řeší škálování decentralizované sítě. Žádný governance token, žádné hlasování přes blockchain. Telegramová skupina, hlasování na Facebooku, postupný rollout.

Tři role, tři firmwary

Na rozdíl od Meshtasticu, kde přeposílá víceméně každý uzel, MeshCore strukturu sítě rozdělil na tři role. To je hlavní rozdíl mezi oběma sítěmi a důvod, proč se v reálném provozu chovají úplně jinak.

Companion je uzel, který si dáš do kapsy nebo na stůl. Přes Bluetooth (případně USB nebo WiFi, podle toho, jaký firmware nahraješ) ho spojíš s mobilem a posíláš a přijímáš zprávy. Provoz ostatních uživatelů nepřeposílá – pokud zpráva není určená tobě, companion ji ignoruje. Tím šetří éter i baterii.

Repeater je naopak součást infrastruktury, ne relé navíc. Jeho jediným úkolem je předávat pakety smysluplným směrem. Bez Bluetooth, bez displeje, často bez krytu kromě 3D tištěné krabičky. Patří na střechu, komín, vysílač nebo kopec. Solární panel, 18650 nebo LiFePO4 baterie, anténa s rozumným výhledem. Operátor si ho nakonfiguruje přes web config tool ještě před tím, než ho někam pověsí, protože jakmile je nahoře, není kam strčit USB-C.

Room Server je třetí typ. Něco jako lokální BBS pro region – uzel, který umí ukládat zprávy, sdružovat uživatele do tematických kanálů a fungovat jako store-and-forward, když je adresát zrovna mimo dosah sítě.

Role nejde přepnout konfigurací. Když chceš ze svého companionu udělat repeater, musíš ho znovu flashnout. To zní jako omezení, ale dává smysl: firmware pro každou roli je jinak optimalizovaný a komunita má jistotu, že když má někdo v síti repeater, je to opravdu repeater, a ne mobil, kterému zrovna umřela baterka.

Hardware: co reálně koupit v polovině roku 2026

Tabulka, kterou bych si přál mít, když jsem s MeshCore začínal.

K hardwaru pár poznámek z praxe, protože tabulka neřekne všechno.

Heltec V3 je pořád nejrozšířenější deska v české síti. Funguje, je levný, návodů na něj je plný Telegram. Pokud začínáš a nechceš řešit detaily, vezmi Heltec V3 nebo V4 v EU variantě (868 MHz, ne 915 MHz – ten je pro USA a v české síti nezachytí nic).

T-Deck je jiná liga. Pro lidi, co chtějí mít komunikaci úplně mimo telefon – na hory, do auta na dlouhé tahy, nebo prostě jako koncept „vlastní pager bez internetu". Pořád stojí kolem 3500 Kč, ale když k tomu přidáš baterii a pořádnou anténu, cena se snadno přehoupne přes pět litrů.

A SenseCAP Solar Node P1 Pro je teď v české komunitě nejcitovanější volba pro hotový repeater. Eischmann o něm píše: „Úplně se mi nechtělo bastlit vlastní řešení, takže jsem zvolil ověřené hotové řešení SenseCAP Solar Node P1 Pro." Pět tisíc je dost peněz na to, aby ses k nákupu rozhoupal, ale když jde o střechu rodinného domu, kde má mít spojení tvůj soused i ty, je to investice, která se vrátí.

BOM pro vlastní solární repeater (DIY varianta, ~1700 Kč)

Pro úplnost, kdyby ti to nedalo a chtěl bys ho postavit.

Zhruba takhle vypadá rozumný DIY repeater postavený na Heltecu, který přežije i bez sítě:

• Heltec V3 (EU 868 MHz) – 750 Kč
• LiFePO4 článek 18650, 1500 mAh – 250 Kč (pozor na firmware ≥ 1.12, kde byly s LFP/LTO články hlášené problémy s napěťovou křivkou)
• TP4056 modul s ochranou – 30 Kč
• 6V/5W solární panel – 200 Kč (zimní slunce v ČR je nízké a krátké, dimenzuj radši s rezervou)
• LoRa anténa 868 MHz, zisk 3–5 dBi – 200 Kč
• Pigtail SMA / IPEX – 60 Kč
• 3D tištěná krabička – pár desítek korun za filament
• IP65 průchodka pro anténní kabel – 80 Kč
• Spojovací materiál, dlaždice, držák – podle situace

Cena pohodlně pod dva tisíce, pokud máš tiskárnu doma. Když kupuješ všechno nové a tiskneš v servisu, přidej k tomu pár stovek za filament a držák antény.

Frekvence a nastavení regionu pro ČR

Tohle bývá první past pro lidi, co začínají. MeshCore v Evropě obecně jede na pásmu 868 MHz, ale česká komunita se sjednotila na konkrétním presetu, který se ne vždycky shoduje s výchozím nastavením „EU" v aplikaci. Konkrétně: frekvence 869,432 MHz, šířka pásma 62,5 kHz, spreading factor 7, coding rate 5, vysílací výkon 22 dBm.

Co to znamená v praxi: vysíláš na bezlicenčním pásmu, žádné poplatky, žádná registrace. Ale musíš respektovat duty cycle limit 1 % – tedy ze sta sekund vysílat nejvýš jednu. Firmware to hlídá sám, ale když si pustíš na síti bota, který každé tři minuty odešle status update, ten limit ti tiše vyžere a tvoje skutečné zprávy se přes něj nedostanou.

A teď k tomu botovi.

Etiketa: žádné automaty, žádné scrapery

Česká MeshCore komunita má jedno pravidlo, které visí přímo na úvodní stránce meshcore.cz a v každém druhém příspěvku na Telegramu. „Síť budujeme striktně pro komunikaci mezi lidmi (keyboard to keyboard). Vyvarujte se automatizovanému posílání zpráv, vyčítání repeaterů nebo jiné komunikaci, která není mezi lidmi!"

Důvod je matematický. LoRa síť má reálnou propustnost zhruba tří kilobitů za sekundu. To není opomenutí, to je fyzika daná modulací. Komunita po hlasování konstatovala, že 75 % generovaného provozu tvořili boti, což snižuje pravděpodobnost doručení skutečných zpráv. Vznikla z toho samostatná kampaň: provozovatelé botů se mají vypnout. Jediný, kdo tam má povolení zůstat, je El Pong – komunitní bot s AI a emailem, který si komunita schválně nechala jako experiment.

Když si tedy zapneš svůj první uzel a napadne tě napsat skript, který bude každou hodinu pingovat dosah, prostě to nedělej. Není to vůči nikomu fér.

Totéž platí pro scrapery a „monitory pokrytí". Existuje veřejná mapa i analyzer, oba běží na backendu, kde tu zátěž nese server, ne LoRa éter. Když si chceš zmapovat vlastní dosah, projdi se s companionem a koukej do aplikace. Žádný autopilot.

Krok za krokem: od krabičky k první zprávě

Předpokládejme Heltec V3 v EU 868 MHz verzi, Android telefon a Chrome v notebooku.

Připoj desku přes USB-C k počítači. Pozor na kabel – některé „nabíjecí" mají jen napájení a žádná data, a flasher se ti k čipu nedostane. Když to nepřipojí, zkus jiný kabel dřív, než začneš googlovat ovladače.

Otevři flasher.meshcore.co.uk v Chromu (nebo jiném prohlížeči postaveném na Chromiu – Edge funguje, Firefox bohužel ne, protože nemá Web Serial API). Po načtení vyber model desky. Pro Heltec V3 zvol Community Firmware a roli Companion Bluetooth. Stiskni Flash. Asi po půl minutě má deska firmware.

Stáhni si aplikaci MeshCore – existuje pro Android i iOS. Po spuštění klepni na „přidat zařízení" a aplikace najde tvůj uzel přes Bluetooth. Spárování chce PIN, který se ti zobrazí na OLED displeji.

První věc, kterou pak v aplikaci uděláš (ano, ještě před tím, než pošleš první zprávu): otevři Experimental Settings a přepni Default Path Hash Size na 2 bytes. To je ta kampaň, o které jsem psal výš. Pak nastav region – pro Česko buď použij preset EU Recommended, nebo manuálně nastav 869,432 MHz / BW 62,5 kHz / SF 7 / CR 5.

Teď klepni v aplikaci na ikonu vlny (advert) a pošli Flood Routed Advert. To je signál „jsem tady, kdo mě slyší". V Contacts by se ti během následujících sekund až minut měly začít objevovat repeatery a uživatelé v dosahu. Když ne, vystup na balkon nebo zkus jít k oknu. LoRa není WiFi a na úrovni ulice mezi paneláky se jí obvykle moc nedaří.

Pošli testovací zprávu do kanálu #test. Pokud uvidíš v aplikaci „Heard X repeat(s)", jsi v síti. Hotovo.

Linuxový klient Meshy: alternativa pro lidi, co nechtějí mobil

Pokud jsi typ člověka, co radši pracuje na notebooku než na mobilu, je tu pro tebe Meshy. Linuxový klient pro MeshCore, který od února 2026 píše Jiří Eischmann. Aplikace má dokonce funkce, které oficiální klient zatím nemá – třeba vykreslení trasy poslední úspěšné zprávy přímo na mapě v chatu.

Meshy se aktuálně distribuuje přes Flatpak repozitář a každý commit do gitu spouští nový build pro x86_64 i aarch64 (díky Roští.cz za poskytnutí builderu). Eischmann teď cílí na publikaci ve Flathubu – hlavní překážka prý je, že kvůli udev pravidlu pro připojení companionu přes USB potřebuje obejít sandbox pomocí flatpak spawn. Časem to vyřeší. Komunita kolem linuxového klienta roste a Meshy je teď nejstabilnější varianta, pokud chceš MeshCore používat z laptopu.

Pro lidi z radioamatérské scény, kteří už znají RTL-SDR, gpredict a další unixové utility, je Meshy přirozenější než přepínání mezi mobilem a notebookem. V brněnské komunitě je to čím dál jasnější volba.

Brno jako centrum české MeshCore scény

Když si zmapuješ aktivitu české komunity, jihomoravský trojúhelník vyčnívá. Většina nejaktivnějších provozovatelů sítě sedí v Brně. Jindřich Skácel měl v únoru 2026 přednášku na 216. srazu spolku OpenAlt na FIT VUT, ukazoval klientská zařízení a praktické nasazení repeateru, video je na vhsky.cz. Na budově Red Hatu v Medlánkách přímo běží repeater techpark.meshcore.cz, který kryje větší část severu Brna.

Není to náhoda. Brno má kombinaci, která MeshCore přeje: hustá technická komunita (Red Hat, FIT VUT, SUSE, NIC.CZ), aktivní open-source scéna kolem OpenAltu, prolínání ham a maker komunity a topologie s viditelností na okolní kopce (Babí lom, Děvín, Hostýn).

Eischmann to v jednom blogu trefil přirovnáním ke CZFree.Netu z přelomu nultých let – komunita, která bere infrastrukturu do svých rukou, protože ji to baví, ne protože musí.

Pokud bydlíš v Brně nebo okolí a chceš se připojit, je to teď nejjednodušší. Telegramová skupina meshcore_cz má aktivní topic Wiki a Repeatery, srazy OpenAltu v Red Hat Labu na FIT VUT chodí pravidelně každý třetí pátek v měsíci (i když ne každý je o MeshCore) a v Brně máš největší šanci potkat lidi, kteří síť reálně staví.

Jiné regiony pochopitelně taky fungují. Praha má pokrytí, Hradec a Liberec mají své sysopy, jižní Čechy mají svou skupinku. Ale hustota brněnské sítě v polovině roku 2026 je v republice unikum a kdyby ses chtěl podívat, jak vypadá MeshCore, když má kritickou masu, stojí za to si sem na jeden pátek vyrazit a vidět to z první ruky.

Co dál

Když máš companion v kapse a fungující spojení do sítě, je to první krok. Logické pokračování je vlastní repeater. Pokud bydlíš výš nebo máš střechu, je to nejspíš něco, co tvoje okolí ocení. Eischmannovi přes zimu umřely baterky na repeateru ivanovice.meshcore.cz, který byl 300 metrů od něj, a najednou byl bez spojení. Jeho ponaučení: „když závisíte na repeaterech ostatních, měli byste mít spojení alespoň na dva. Nebo mít vlastní." Síť odolnou proti blackoutu nepostavíš tím, že čekáš na sysopa o tři ulice dál.

Před tím, než si pořídíš hardware na repeater, vygeneruj si přes Key Generator vlastní prefix klíče. V březnu 2026 už volné jednobajtové prefixy nebyly. Při 2-byte hashi je situace lepší, ale stejně si zkontroluj v analyzeru, jestli zrovna tvůj generovaný prefix neběží už ten den někomu přes ulici.

A pokud chceš jít dál než ke klasickým textovkám – existuje GROUP_DATA, binární typ paketu, který firmware 1.15 přinesl pro pokročilejší aplikace. Telemetrie, řízení vzdálených zařízení, integrace s domácí automatizací. Část komunity tudy už šlape, v Brně víc, v ostatních městech méně.

Co MeshCore není a co se nestane: nikdy z toho nebude bezdrátový internet, nikdy nebude pohánět videohovory, nikdy nezvládne přenášet fotky v rozumném čase. To je v pořádku. Stačí, že umí to, co lidi v Karpatech, na chatě v Beskydech nebo v zatopeném Bohumíně skutečně potřebují: krátkou textovku, která projde, i když všechno ostatní leží.

A taková síť se buduje úplně stejně, jako se před třiceti lety budoval CZFree.Net. Po jednom uzlu, po jedné krabičce, po jedné neděli na střeše.

The post MeshCore v praxi: jak v Česku postavit vlastní LoRa uzel a nezapadnout first appeared on Hard Wired.

Představte si scénář: pošlete přes Telegram zprávu „dej mi vědět, když teplota čipu překročí 28 stupňů". Bot odpoví, že rozumí. Od té chvíle ESP32 hlídá teplotu sám. Bez cloudu, bez LLM volání, bez WiFi. Spadne vám internet? Hlídá dál. Restartujete ho? Po naběhnutí hlídá dál.

Tohle je WireClaw, open-source firmware od Maria Schallnera (na GitHubu M64GitHub), který vyšel poprvé veřejně 25. února 2026. Z hardware-first myšlení vznikla jedna z mála implementací AI agenta na MCU, která bere vážně otázku, co se stane, když AI selže. Tady si projdeme, jak to funguje, proč to vzniklo a kde to narazí.

Dvě smyčky, jeden čip

Klíčový designový trik: WireClaw na ESP32 logicky rozděluje práci na dvě nezávislé části.

Rule loop běží neustále a nedotýká se sítě. Čte senzory, vyhodnocuje uložená pravidla, spouští akce. Žádný HTTP request, žádná LLM inference. Když teplota přeleze práh, rozsvítí se LED nebo přijde Telegram zpráva, to celé v řádu milisekund, lokálně.

AI loop se probudí, jen když přijde zpráva přes Telegram, USB sériovku nebo NATS. Tehdy WireClaw udělá HTTPS na OpenRouter (nebo HTTP na lokální Ollamu), nechá LLM zformulovat odpověď a případně vytvořit nové pravidlo. Maximum je pět iterací s nástroji na jednu zprávu, pak se vše zabalí.

„The AI creates the rules. The rules run without the AI."

Tahle věta z dokumentace shrnuje celou filozofii. LLM se používá jako kompilátor lidského záměru do embedded logiky. Pravidlo, které vznikne, jde do flash paměti a od té chvíle žije svým životem. Reboot? Po načtení z flashe pokračuje, jako by se nic nestalo.

Pro někoho, kdo zkoušel postavit IoT s ChatGPT v hot loopu, je to úleva. Žádný API výpadek vám neshodí topení.

Co se vejde do ESP32

WireClaw potřebuje 4 MB flash a tři typy čipů: ESP32-C3, C6 nebo S3. Klasický ESP32 s Tensilica jádrem není podporován, kvůli OTA partition table requirementům. ESP8266 je mimo hru kvůli paměti.

Reálná spotřeba zdrojů podle oficiální dokumentace:

RAM:   59,7 %  (196 KB z 320 KB)
Flash: 51,4 %  (1,3 MB z 2,5 MB)

To je dost, ale ne na hraně. Zhruba 40 % RAM zbývá pro vaše vlastní rozšíření. Setup portal a webové GUI sedí v PROGMEM, takže RAM nežerou.

Doporučená volba je ESP32-C6 DevKit. Cena se v Číně pohybuje kolem 5–10 dolarů, RISC-V jádro je rychlé a WS2812B onboard LED rovnou slouží jako vestavěný actuator. ESP32-S3 dává smysl tam, kde plánujete složitější rule chains a chcete víc paměti.

Pravidla v praxi

Rule engine je dost expresivní. Pravidlo se skládá ze senzoru, podmínky (gt, lt, eq a další), prahu a akce. Vestavěných virtuálních senzorů je hned několik: chip_temp z interního čidla, clock_hour, clock_minute a chytrý clock_hhmm. Posledně jmenovaný kóduje čas jako hodina × 100 + minuta, takže 10:12 = 1012. Najednou jde plánovat přes prostou eq podmínku bez nutnosti řešit dvě pole zvlášť. Elegantní hack.

Akce zahrnují led_set (RGB LED), gpio_write, telegram, nats_publish a serial_send. V textových akcích funguje placeholder substituce: do zprávy můžete napsat "Teplota čipu: {chip_temp}°C" a engine to vyrenderuje z živých dat. Bez LLM, přímo v rule loopu.

Pokročilejší trik je rule chaining: jedno LLM volání může vytvořit multi-step sekvenci s non-blocking delays. Spustí se Telegram alert, po pěti sekundách se rozsvítí červená LED, po deseti se zhasne a publikuje se zpráva na NATS. Mezitím engine paralelně vyhodnocuje ostatní pravidla.

Co u všech těchto testovaných modelů funguje, a co ne, stojí za pozornost. Gemini 2.5 Flash zvládá chains excelentně za zhruba 4 sekundy. Claude Sonnet 4.5 taky, ale potřebuje 10 sekund. Qwen 2.5 7B selhává: chybějící kroky, špatné delays, někdy přímo syntax errors. Pokud vás zajímá cost/perf pro běžný hobby use, Gemini Flash přes OpenRouter je sweet spot.

NATS jako páteř

Tady WireClaw zachází dál než většina podobných projektů. NATS, lehký pub/sub broker, je integrovaný ve třech vrstvách.

První vrstva: virtuální senzory. Vytvoříte senzor typu nats_value se subscribe na subject, třeba home.room.temp. Cokoliv, co umí na NATS publishovat (Python skript, Home Assistant, jiný WireClaw, průmyslový PLC), najednou dodává data do rule enginu.

Druhá vrstva: tool-call protokol. Externí AI agent (nemusí to být OpenClaw, stačí jakýkoli NATS klient) může volat 19 dostupných nástrojů přímo na ESP32, bez nutnosti budit lokální LLM. Latence se podle landing page pohybuje kolem 30 milisekund. Číslo z marketingu, ale architekturou to dává smysl.

Třetí vrstva, HAL (Hardware Abstraction Layer), je nejnižší. Žádný LLM, žádný JSON. Pevně definované subjects typu {device}.hal.gpio.5.set s payloadem "1" a odpovědí "ok". Pro programy v Pythonu nebo Go, které potřebují deterministickou latenci, je tohle správná vrstva. Tight loop přes ESP32 z notebooku, žádný overhead.

A pak je tu remote_chat — tool, kterým se jeden WireClaw může ptát druhého, jako by si chatovali. Edge AI mesh s federovaným reasoningem. Trochu sci-fi, ale funkční.

Kde to narazí

Žádný projekt není bez háčků a u WireClawa stojí za to vědět o pár věcech předem.

Tu hlavní jsem už zmínil: klasický ESP32 ne. Pokud máte zásobu starších DevKitů, smůla. Buď port, nebo nákup nových C3/C6/S3 boardů.

Bezpečnost. Setup portal je captive portal bez autentizace. Web GUI po setup taky bez autentizace. Kdokoli v LAN si může změnit system prompt (čili jailbreak agenta), upravit persistent memory nebo smazat pravidla. API key sedí na flashi v plaintextu. Pro lab a hobby OK, pro produkci to chce VLAN izolaci a u Telegram bota strict spending limit na OpenRouter účtu.

Conversation history je čtyřtahový kruhový buffer plus 512 bytů persistent memory. Agent si nepamatuje hlubší kontext, jen poslední pár výměn. Pro chat o teplotě dobré, pro komplexnější dialog málo.

A poslední věc: rule loop běží "každou iterací loop()". Frekvence není v dokumentaci uvedená. Pro motorické řízení, audio nebo cokoli, kde záleží na sub-milisekundové determinističnosti, sáhněte po přímém low-level firmware. WireClaw je orchestrátor, ne real-time kontrolér.

Komu to dává smysl

WireClaw cílí na úzkou komunitu: bastlíře, kteří mají ESP32 v šuplíku a chtějí experimentovat s AI agenty bez nutnosti stavět cloudovou infrastrukturu. Pro lab automatizaci, kde Home Assistant je overkill, pro distribuovanou senzor mesh, pro vzdělávací demo.

Komunita je zatím malá. Patnáct hvězdiček, čtyři forky, žádné formální release. Záleží na jediném vývojáři. To se časem může změnit, ale dneska to ovlivňuje, jak hluboko se do toho pouštět.

Pokud máte ESP32-C6 v šuplíku a hodinu času, web flasher na wireclaw.io/flash.html udělá zbytek. Chrome nebo Edge kvůli WebSerial API, kabel, OpenRouter API key, a za pár minut si můžete přes Telegram říct prvnímu vlastnímu edge agentovi, co má sledovat.

The post WireClaw: ESP32 jako AI agent, který vám neshodí topení, když spadne internet first appeared on Hard Wired.

Jak mixed-signal SoC nechtěně vysílá kryptografická tajemství a jak to reprodukovat s HackRF za odpoledne

Sedíte v autě, zaparkovaní u továrny. Výrobní hala je dvacet metrů za zdí. Spustíte skript na laptopu, nasměrujete anténu a čekáte. Za pár hodin máte AES-128 klíč z komunikace zámkového modulu uvnitř.

Žádné hackování sítě. Žádný fyzický kontakt. Žádné stopy.

Tohle není filmový scénář - je to zdokumentovaný útok, publikovaný akademicky v roce 2018, rozšiřovaný výzkumy až do roku 2024, spustitelný na fakt běžném SDR hardware. Jmenuje se Screaming Channels a má přímou relevanci pro každý automotive modul, který na sobě nese BLE čip od Nordic Semiconductor.

Čip, který si sám zesílí vlastní únik

Mixed-signal SoC je čip, kde digitální logika a rádiový transceiver sdílejí jeden křemíkový die. Zní to jako detail z datasheetu. Ve skutečnosti je to bezpečnostní časovaná bomba.

Digitální logika při výpočtech generuje elektromagnetický šum. Na izolovaném mikrokontroléru to není velký problém - šum je slabý, slyšitelný jen z milimetrů. Ale na mixed-signal čipu se ten šum šíří do analogové části: přes sdílené napájení, substrátové vazby, kapacitní přeslech mezi bloky na die. A v analogové části je PA - výkonnostní zesilovač rádiového vysílače.

Čip si vlastní kryptografický únik zesílí a vyšle anténou do prostoru.

Giovanni Camurati a jeho kolegové z EURECOM tohle v roce 2018 pojmenovali "screaming channels" - v kontrastu ke klasickým EM side-channels, které "šeptají" z centimetrů. Tady čip doslova křičí.

Konkrétní cíl výzkumu: nRF52832 od Nordic Semiconductor. ARM Cortex-M4 na 64 MHz, integrovaný BLE/ANT transceiver na 2,4 GHz. Používaný v milionech zařízení - wearables, průmyslový IoT, smart home. A automotive.

Proč 2,464 GHz a ne 2,400 GHz

Tady je fyzika, která útok umožňuje.

CPU nRF52832 taktuje na 64 MHz. Při AES výpočtu generuje harmonické tohoto taktu - šum s komponentami na 64 MHz, 128 MHz, 192 MHz atd. Ten šum vstoupí do IQ mixeru v rádiovém řetězci, kde se amplitudově namoduluje na nosnou BT kanálu.

Výsledek: útočník neladí na 2,400 GHz (BT kanál 0), ale na 2,464 GHz:

f(screaming channel) = f(BT kanál) + f(CPU clock)
                     = 2,400 GHz  + 0,064 GHz
                     = 2,464 GHz

V spektrogramu to vypadá jako tenký proužek vedle hlavního BT signálu - vizuálně nenápadný, statisticky informativní. Každé jedno AES šifrování zanechá v zachyceném signálu "otisk" - trace. Jedna trace toho moc neřekne. Ale po 90 000 tracích jde z korelace vytáhnout celý 128bitový klíč.

Zpátky k tomu autu na parkovišti: útočník nepotřebuje dekódovat Bluetooth provoz. Jen passivně naslouchá vedlejšímu šumu. Zařízení ani netuší, že je sledováno.

Sedm let výzkumu v pěti minutách

Projekt Screaming Channels není jednorázová akademická kuriozita. Vyvíjí se.

CCS 2018 (Camurati et al., EURECOM): Původní demonstrace. Útok na tinyAES implementaci na nRF52832, vzdálenost 10 metrů v anechoické komoře, vzdálenost 1 metr v kancelářském prostředí. Korelační analýza, 180 000 traces. Tři místo na CSAW Europe 2018.

CHES 2020: Podrobnější analýza kanálu, útok na Google Eddystone beacony (reálný produkt, ne lab firmware), vzdálenost 15 metrů v kancelářské chodbě, spatial diversity s dvěma přijímači, reuse profilu postaveného na jiném zařízení měsíce předem.

ACSAC 2024 (BlueScream, Ayoub et al., EURECOM + Univ. Lille + CNRS + Inria): Útok na reálný BLE stack bez modifikace firmware. Útočník manipuluje BLE protokol tak, aby zařízení leaked Long Term Key při standardní komunikaci. Tohle je z mého pohledu nejzásadnější posun - předchozí práce vyžadovaly speciální firmware na target zařízení. BlueScream funguje na produkčním zařízení s factory firmware.

Musím ale říct, že "funguje na produkčním zařízení" je trochu zjednodušení. BlueScream stále potřebuje, aby útočník mohl ovlivnit BLE session - tedy aby byl v dosahu a mohl komunikovat. Vzdálený pasivní útok bez jakékoliv interakce to zatím není. Ale hranice se posouvají každý rok.

Mimochodem: vedle toho v roce 2025 publikovali Ji et al. ze Stockholm University útok na hardwarový AES akcelerátor (ne softwarovou implementaci) na stejném čipu, s ML-assisted analýzou a 90 000 traces z 1 metru. Hardwarový akcelerátor se dřív považoval za odolnější. Ukázalo se, že ne.

Jak to reprodukovat: hardware

Celý projekt je open-source. EURECOM zveřejnil firmware, kód, GNURadio bloky a naměřené datasety. Není potřeba nic vymýšlet od nuly.

Minimální setup pro laboratorní validaci:

PCA10040 má onboard J-Link debugger - žádný extra programátor nepotřebujete, stačí USB kabel.

HackRF zvládne útok z 1 až 3 metrů v tichém RF prostředí. Pro 10+ metrů (publikované výsledky) potřebujete USRP N210 s SBX daughterboard a paraboliku s 24 dBi - to je jiný cenový segment (~150 000 Kč za USRP). Pro automotive bezpečnostní testování v laboratoři ale 1 metr odpovídá realistickému scénáři technická diagnostiky u vozidla.

Jak to reprodukovat: software a postup

1. Instalace

sudo apt install gnuradio gr-osmosdr hackrf minicom gcc-arm-none-eabi

git clone https://github.com/eurecom-s3/screaming_channels
cd screaming_channels
git checkout ches20

cd experiments/src
python2 setup.py develop
pip3 install gatt==0.2.7 pyzmq==17.1.2

Repo obsahuje i Dockerfile pro izolované prostředí - doporučuji, závislosti jsou trochu starší:

docker build -t screaming docker/
docker run -it --privileged screaming

2. Flash firmware

cd screaming_channels/firmware

# mbedTLS varianta (doporučená pro první pokus)
make GNU_INSTALL_ROOT=$GCC_PATH/gcc-arm-none-eabi-7-2017-q4-major/bin/ \
  -C blenano2_mbedtls/blank/armgcc/

# Flashnout přes J-Link (automaticky při připojení PCA10040 přes USB)
cp blenano2_mbedtls/blank/armgcc/_build/nrf52832_xxaa.hex /media/$USER/DAPLINK/

Po flashnutí se připojte přes UART (minicom -b 115200 -D /dev/ttyACM0) a stiskněte h - uvidíte menu s dostupnými módy.

3. Vizualizace úniku - první krok

Než začnete sbírat traces, ověřte, že leak vůbec vidíte.

Naladíte HackRF na offset frekvenci:

# Přímý přístup přes hackrf_transfer (jen pro rychlý test)
hackrf_transfer -r /dev/null -f 2464000000 -s 8000000 -l 40 -g 40

Lépe otevřete GQRX nebo GNURadio Companion, nastavte:

• Frekvence: 2 464 MHz
• Sample rate: 8 MSPS
• FFT size: 4096
• Gain: začněte na 30 dB, dolaďte

Ve firmware spusťte AES smyčku: n (TinyAES mód), n2000 (2000 opakování), r (spustit). Ve spektrogramu by se měl objevit periodický proužek kolem +64 MHz offsetu od BT nosné. Když ho vidíte, jste na správné stopě.

4. Sběr traces

sc-experiment \
  --radio=HackRF \
  --device=/dev/ttyACM0 \
  collect \
  config/example_collection_plot.json \
  ../traces/ \
  --plot

--plot zobrazí live vizualizaci každé trace. Hledáte konzistentní tvar signálu korelovaný se šifrováním - pokud každá trace vypadá jinak a chaoticky, SNR je příliš nízké (zkuste zkrátit vzdálenost nebo zvýšit gain).

5. Analýza - bez vlastního hardware

Pokud chcete nejdřív ověřit celý analytický pipeline, EURECOM poskytl veřejné datasety:

• Small sample set (56 MB) - útok na 20 cm
• CCS18 traces (2,6 GB) - útok na 10 m v anechoické komoře, útok na 1 m v kanceláři
• CHES20 traces (15 GB) - vše od 55 cm doma přes 15 m v chodbě po T-test na 34 m

export TRACES_SAMPLE="/cesta/k/datum"

sc-attack \
  --norm \
  --plot \
  attack config/example_attack.json \
  $TRACES_SAMPLE/sample/

6. Dvě metody key recovery

Korelační analýza (CPA) - bez profilování, ~180 000 traces, deterministická. Dobrá pro první pokus, nevyžaduje referenční zařízení se známým klíčem.

Template attack s ML - vyžaduje profilování (traces se známým klíčem na tom samém modelu čipu), útok pak z ~90 000 traces. Přibližně dvakrát efektivnější.

# Profilování (coaxiální připojení, plný SNR, známý klíč)
sc-attack --norm \
  --data-path ./traces/profile \
  --num-traces 5000 \
  profile \
  --variable p_xor_k \
  --pois-algo r \
  --num-pois 1 \
  /tmp/profile_output/

# Útok (vzdálené traces, neznámý klíč)
sc-attack --norm \
  --data-path ./traces/attack \
  --num-traces 90000 \
  attack \
  --attack-algo pcc \
  --profile /tmp/profile_output/ \
  /tmp/attack_output/

Co s tím dělat: mitigace, která nestačí, a ta, která pomáhá

Softwarová oprava neexistuje. Problém je fyzický.

Maskovací schémata v AES implementaci (Rivain-Prouff a podobné) zvýší počet potřebných traces, ale útok neumožní - Ji et al. (2025) demonstrovali průlom i přes masking. Jitter v časování šifrování komplikuje synchronizaci traces. Žádná sláva.

Fakticky fungující opatření jsou hardwarová:

RF stínění modulu - faradayova klec kolem čipu ořízne leak na přijatelnou úroveň. Přidá ale hmotnost, rozměry a cenu.

Čipy s integrovanou ochranou - Nordic nRF54 série (nástupce nRF52) obsahuje dedikovanou side-channel leakage protection v kryptoakcelerátoru. Pokud navrhujete nový modul, tohle je relevantní volba.

Oddělit napájení - digitální a RF napájení na PCB oddělené ferritovými korálky a LC filtry sníží substrátovou vazbu, ale neodstraní ji úplně. Pomáhá SNR útoku poškodit, ale nestačí jako jediné opatření.

Pro firemní kontext: výsledky testování vlastních modulů zdokumentujte jako součást threat modelu a bezpečnostní dokumentace. Pokud modul projde CPA testem bez key recovery do 200 000 traces v laboratorních podmínkách, máte datový podklad pro rozhodování.

Zdroje

Akademické práce (primární zdroje):

• Camurati et al. (CCS 2018): Screaming Channels: When EM Side Channels Meet Radio Transceivers
• Camurati et al. (CHES 2020): Understanding Screaming Channels
• Ayoub et al. (ACSAC 2024): BlueScream: Screaming Channels on Bluetooth Low Energy
• Ji, Dubrova, Wang (IACR ePrint 2025): Is Your Bluetooth Chip Leaking Secrets via RF Signals?

Kód a datasety:

• github.com/eurecom-s3/screaming_channels - firmware, experimenty, datasety, Docker
• github.com/pierreay/bluescream - BlueScream (reálný BLE stack, ACSAC 2024)
• eurecom-s3.github.io/screaming_channels - dokumentace, download datasety

Prezentace:

• Black Hat USA 2018 - video
• CHES 2020 - video

Testování technik popsaných v tomto článku proveďte výhradně na vlastním hardware nebo s písemným souhlasem vlastníka zařízení. Útoky na cizí zařízení jsou trestné.

The post Váš Bluetooth čip křičí šifrovací klíče. Slyšet ho jde z parkoviště. first appeared on Hard Wired.

Multimodal Embedding & Reranker Models with Sentence Transformers

Sentence Transformers is a Python library for using and training embedding and reranker models for applications like retrieval augmented generation, semantic search, and more. With the v5.4 update, you can now encode and compare texts, images, audio, and videos using the same familiar API. In this blogpost, I'll show you how to use these new multimodal capabilities for both embedding and reranking.

Multimodal embedding models map inputs from different modalities into a shared embedding space, while multimodal reranker models score the relevance of mixed-modality pairs. This opens up use cases like visual document retrieval, cross-modal search, and multimodal RAG pipelines.

Table of Contents

• What are Multimodal Models?
• Installation
• Multimodal Embedding Models
• Loading a Model
• Encoding Images
• Cross-Modal Similarity
• Encoding Queries and Documents
• Multimodal Reranker Models
• Ranking Mixed-Modality Documents
• Predicting Pair Scores
• Retrieve and Rerank
• Input Formats and Configuration
• Supported Input Types
• Checking Modality Support
• Processor and Model kwargs
• Supported Models
• Additional Resources

What are Multimodal Models?

Traditional embedding models convert text into fixed-size vectors. Multimodal embedding models extend this by mapping inputs from different modalities (text, images, audio, or video) into a shared embedding space. This means you can compare a text query against image documents (or vice versa) using the same similarity functions you're already familiar with.

Similarly, traditional reranker (Cross Encoder) models compute relevance scores between pairs of texts. Multimodal rerankers can score pairs where one or both elements are images, combined text-image documents, or other modalities.

For example, you can compare a text query against image documents, find video clips matching a description, or build RAG pipelines that work across modalities.

Installation

Multimodal models require some extra dependencies. Install the extras for the modalities you need (see Installation for more details):

# For image support
pip install -U "sentence-transformers[image]"

# For audio support
pip install -U "sentence-transformers"

# For video support
pip install -U "sentence-transformers"

# Mix and match as needed
pip install -U "sentence-transformers[image,video,train]"

VLM-based models like Qwen3-VL-2B require a GPU with at least ~8 GB of VRAM. For the 8B variants, expect ~20 GB. If you don't have a local GPU, consider using a cloud GPU service or Google Colab. On CPU, these models will be extremely slow; text-only or CLIP models are better suited for CPU inference.

Multimodal Embedding Models

Loading a Model

Loading a multimodal embedding model works exactly like loading a text-only model:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

The revision argument is required for now because the integration pull requests for these models are still pending. Once they're merged, you'll be able to load them without specifying a revision.

The model automatically detects which modalities it supports, so there's nothing extra to configure. See Processor and Model kwargs if you want to control things like image resolution or model precision.

Encoding Images

With a multimodal model loaded, model.encode() accepts images alongside text. Images can be provided as URLs, local file paths, or PIL Image objects (see Supported Input Types for all accepted formats):

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images from URLs
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])
print(img_embeddings.shape)
# (2, 2048)

Cross-Modal Similarity

You can compute similarities between text embeddings and image embeddings, since the model maps both into the same space:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Encode text queries (one matching + one hard negative per image)
text_embeddings = model.encode([
 "A green car parked in front of a yellow building",
 "A red car driving on a highway",
 "A bee on a pink flower",
 "A wasp on a wooden table",
])

# Compute cross-modal similarities
similarities = model.similarity(text_embeddings, img_embeddings)
print(similarities)
# tensor([[0.5115, 0.1078],
# [0.1999, 0.1108],
# [0.1255, 0.6749],
# [0.1283, 0.2704]])

As expected, "A green car parked in front of a yellow building" is most similar to the car image (0.51), and "A bee on a pink flower" is most similar to the bee image (0.67). The hard negatives ("A red car driving on a highway", "A wasp on a wooden table") correctly receive lower scores.

You might notice that even the best matching scores (0.51, 0.67) aren't very close to 1.0. This is due to the modality gap: embeddings from different modalities tend to cluster in separate regions of the space. Cross-modal similarities are typically lower than within-modal ones (e.g., text-to-text), but the relative ordering is preserved, so retrieval still works well.

Encoding Queries and Documents

For retrieval tasks, encode_query() and encode_document() are the recommended methods. Many retrieval models prepend different instruction prompts depending on whether the input is a query or a document, similar to how chat models might apply different system prompts depending on the goal. Model authors can specify their prompts in the model config, and encode_query() / encode_document() automatically load and apply the correct one:

• encode_query() uses the model's "query" prompt (if available) and sets task="query".
• encode_document() uses the first available prompt from "document", "passage", or "corpus", and sets task="document".

Under the hood, both are thin wrappers around encode(), they just handle prompt selection for you. Here's what cross-modal retrieval looks like:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode text queries with the query prompt
query_embeddings = model.encode_query([
 "Find me a photo of a vehicle parked near a building",
 "Show me an image of a pollinating insect",
])

# Encode document screenshots with the document prompt
doc_embeddings = model.encode_document([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Compute similarities
similarities = model.similarity(query_embeddings, doc_embeddings)
print(similarities)
# tensor([[0.3907, 0.1490],
# [0.1235, 0.4872]])

These methods accept the same input types as encode() (images, URLs, multimodal dicts, etc.) and pass through the same parameters. For models without specialized query/document prompts, they behave identically to encode().

Multimodal Reranker Models

Multimodal reranker (CrossEncoder) models score the relevance between pairs of inputs, where each element can be text, an image, audio, video, or a combination. They tend to outperform embedding models in terms of quality, but are slower since they process each pair individually. The currently available pretrained multimodal rerankers focus on text and image inputs, but the architecture supports any modality that the underlying model can handle.

Ranking Mixed-Modality Documents

The rank() method scores and ranks a list of documents against a query, supporting mixed modalities:

from sentence_transformers import CrossEncoder

model = CrossEncoder("Qwen/Qwen3-VL-Reranker-2B", revision="refs/pr/11")

query = "A green car parked in front of a yellow building"
documents = [
 # Image documents (URL or local file path)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
 # Text document
 "A vintage Volkswagen Beetle painted in bright green sits in a driveway.",
 # Combined text + image document
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
]

rankings = model.rank(query, documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t(document {rank['corpus_id']})")
"""
0.9375 (document 0)
0.5000 (document 3)
-1.2500 (document 2)
-2.4375 (document 1)
"""

The reranker correctly identifies the car image (document 0) as the most relevant result, followed by the combined text+image document about a car in a European city (document 3). The bee image (document 1) scores lowest.

Keep in mind that the modality gap can influence absolute scores: text-image pair scores may occupy a different range than text-text or image-image pair scores.

You can also check which modalities a reranker supports using modalities and supports(), just like with embedding models:

print(model.modalities)
# ['text', 'image', 'video', 'message']

print(model.supports("image"))
# True

# Check if the model supports a specific pair of modalities
print(model.supports(("image", "text")))
# True

Predicting Pair Scores

You can also use predict() to get raw relevance scores for specific pairs of inputs:

from sentence_transformers import CrossEncoder

model = CrossEncoder("jinaai/jina-reranker-m0", trust_remote_code=True)

scores = model.predict([
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg"),
 ("A bee on a flower", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
])
print(scores)
# [0.9389156 0.96922314 0.46063158]

Retrieve and Rerank

A common pattern is to use an embedding model for fast initial retrieval, then refine the top results with a reranker:

from sentence_transformers import SentenceTransformer, CrossEncoder

# Step 1: Retrieve with an embedding model
embedder = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

query = "revenue growth chart"
query_embedding = embedder.encode_query(query)

# Pre-compute corpus embeddings (do this once, then store them)
document_screenshots = [
 "path/to/doc1.png",
 "path/to/doc2.png",
 # ... potentially millions of document screenshots
]
corpus_embeddings = embedder.encode_document(document_screenshots, show_progress_bar=True)

# Simple cosine similarity retrieval, viable as long as embeddings fit in memory
similarities = embedder.similarity(query_embedding, corpus_embeddings)
top_k_indices = similarities.argsort(descending=True)[0][:10]

# Step 2: Rerank the top-k results with a reranker model
reranker = CrossEncoder("nvidia/llama-nemotron-rerank-vl-1b-v2", trust_remote_code=True)

top_k_documents = [document_screenshots[i] for i in top_k_indices]
rankings = reranker.rank(query, top_k_documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t{top_k_documents[rank['corpus_id']]}")

Since the corpus embeddings are pre-computed, the initial retrieval is fast even over millions of documents. The reranker then provides more accurate scoring over the smaller candidate set.

Input Formats and Configuration

Supported Input Types

Multimodal models accept a variety of input formats. Here's a summary of what you can pass to model.encode():

Checking Modality Support

You can check which modalities a model supports using the modalities property and supports() method:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# List all supported modalities
print(model.modalities)
# ['text', 'image', 'video', 'message']

# Check for a specific modality
print(model.supports("image"))
# True
print(model.supports("audio"))
# False

The "message" modality indicates that the model accepts chat-style message inputs with interleaved content. In practice, you rarely need to use this directly. When you pass strings, URLs, or multimodal dicts, the model converts them to the appropriate message format internally. Sentence Transformers supports two message formats:

1. Structured (most VLMs, e.g. Qwen3-VL): Content is a list of typed dicts, e.g. [{"type": "text", "text": "..."}, {"type": "image", "image": ...}]
2. Flat (e.g. Deepseek-V3): Content is a direct value, e.g. "some text"

The format is auto-detected from the model's chat template.

Since all inputs get converted into the same message format internally, you can mix input types in a single encode() call:

embeddings = model.encode([
 # A text input
 "A green car parked in front of a yellow building",
 # An image input (URL)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 # A combined text + image input
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
])

Processor and Model kwargs

You may want to control image resolution bounds or model precision. Use processor_kwargs and model_kwargs when loading the model:

model = SentenceTransformer(
 "Qwen/Qwen3-VL-Embedding-2B",
 model_kwargs={"attn_implementation": "flash_attention_2", "torch_dtype": "bfloat16"},
 processor_kwargs={"min_pixels": 28 * 28, "max_pixels": 600 * 600},
 revision="refs/pr/23",
)

processor_kwargs controls how inputs are preprocessed (e.g., image resolution bounds). Higher max_pixels means higher quality but more memory and compute. These are

The post Multimodal Embedding & Reranker Models with Sentence Transformers first appeared on Hard Wired.

O čem je řeč

V únoru 2026 tým Samsung Research (Hyochan Chong, Dongkyu Kim, Changdong Kim, Minseop Choi) publikoval paper popisující NanoQuant — metodu post-training kvantizace (PTQ), která dokáže komprimovat váhy velkých jazykových modelů na 1 bit a méně. Ne jako marketingový trik s hvězdičkou a poznámkou pod čarou, ale jako funkční framework s měřitelnými výsledky na standardních benchmarcích.

Proč je to zajímavé: dosavadní PTQ metody (GPTQ, AWQ, QuIP, AQLM) fungují spolehlivě na 3–4 bitech na váhu. Pod touto hranicí se rozpadají. Kdo chtěl jít níže, musel sáhnout po QAT (quantization-aware training) metodách jako LittleBit nebo DBF, které ale vyžadují výrazně víc dat, výpočetního času a často i přístup k trénovacímu pipeline modelu. NanoQuant tuhle mezeru překlenuje — dosahuje komprese srovnatelné s QAT, ale s efektivitou a jednoduchostí PTQ.

NanoQuant jednoduše: 70B model na herní grafice

Co je sub-1-bit kvantizace a proč na tom záleží

Představ si, že máš knihu, která má 138 000 stránek. Je v ní všechno — umí odpovídat na otázky, překládat, psát texty. Problém je, že potřebuješ obrovskou knihovnu, aby se ti tam vešla. Normální člověk si ji domů nedá.

Kvantizace je v podstatě způsob, jak tu knihu přepsat menším písmem. Místo toho, aby každé číslo v modelu (a těch jsou miliardy) zabíralo 16 pozic přesnosti, řeknete — stačí mi 4. Nebo 2. Model je pak menší, ale pořád rozumně funguje. Tohle se dělá běžně a funguje to dobře až do určité hranice.

NanoQuant jde dál. Řekne — stačí mi méně než jedna pozice na číslo. To zní absurdně, protože jedna pozice znamená jen dvě možnosti: plus nebo minus. Méně než jedna pozice by znamenalo, že ani to plus/minus nemáte pro každé číslo zvlášť.

Jak to udělají? Místo toho, aby každé číslo komprimovali samostatně, vezmou celou tabulku čísel a rozloží ji na několik menších tabulek, kde jsou jen jedničky a minus jedničky. Ty menší tabulky se pak vynásobí a dají dohromady přibližně totéž co originál. A protože ty menší tabulky jsou menší než originál, průměrně vychází méně než jeden bit na původní číslo.

Výsledek: model, který normálně zabírá 138 GB a potřebuje dvě profesionální grafické karty za statisíce, se smrskne na 5,35 GB a běží na běžné herní grafice za pár tisíc. A pořád dává rozumné odpovědi.

Háček je v tom, že tohle zatím existuje jen jako vědecký článek. Kód není veřejný, nemůžete si to stáhnout a zkusit. Ale ukazuje to směr — modely, které dnes potřebují serverovnu, by za rok nebo dva mohly běžet na normálním počítači nebo i na telefonu.

Zdroj: NanoQuant — arxiv.org/abs/2602.06694

Problém: proč je sub-1-bit komprese těžká

Standardní kvantizace funguje tak, že se každá váha zaokrouhlí na nejbližší hodnotu z omezeného počtu úrovní. Při 4 bitech máte 16 úrovní, při 2 bitech 4 úrovně. Při 1 bitu máte dvě: +1 a −1. To je brutální ztráta informace.

Existující PTQ metody na tomhle selhávají ze dvou důvodů:

1. Nemají dostatečně sofistikovaný způsob, jak rozhodnout, která váha bude +1 a která −1, aby výsledný model stále dával smysl.
2. Některé metody technicky tvrdí, že komprimují na 1 bit, ale pak si "berou zpět" paměť přes pomocné struktury — škálovací faktory, lookup tabulky, metadata — takže skutečný paměťový otisk je výrazně vyšší.

QAT metody tenhle problém řeší přetrénováním modelu s kvantizačním šumem jako součástí tréninkového procesu. Funguje to, ale vyžaduje to stovky tisíc až miliony kalibračních tokenů, desítky GPU hodin a přístup k tréninkovému pipeline.

Jak NanoQuant funguje

NanoQuant reformuluje celý problém kvantizace. Místo zaokrouhlování jednotlivých vah na binární hodnoty rozkládá váhovou matici na součin nízko-rankových binárních matic a škálovacích faktorů. Matematicky: matice vah W se aproximuje jako součin binárních matic (obsahujících pouze +1 a −1) a diagonálních škálovacích vektorů.

Pokud má původní matice rozměr m×n a rank rozkladu je r, potřebujete r×(m+n) binárních hodnot plus škálovací parametry. Při dostatečně nízkém r klesne průměrný počet bitů na váhu pod 1.0.

Tříkrokový pipeline

Komprese probíhá po blocích modelu (transformer block po bloku) ve třech krocích:

Krok 1 — Mitigace propagace chyb. Kvantizační chyba se akumuluje, jak rekonstrukce postupuje sítí. Před kvantizací aktuálního bloku se jeho full-precision váhy doladí tak, aby kompenzovaly chyby zavedené kvantizací předchozích bloků. Tohle není nový nápad — podobný přístup používají i AQLM nebo QuIP — ale NanoQuant ho aplikuje na všechny lineární vrstvy v bloku, ne jen na vybrané.

Krok 2 — Inicializace binární faktorizace (LB-ADMM). Tady je jádro celé metody. NanoQuant používá ADMM (Alternating Direction Method of Multipliers) pro řešení kombinatorického problému: jaká kombinace binárních matic a škálovacích faktorů nejlépe aproximuje původní váhy? ADMM iterativně střídá řešení dvou podproblémů — optimalizaci spojitých škálovacích parametrů (uzavřená forma, least-squares) a projekci na binární omezení (sign operace). Celý postup je "Hessian-aware", tedy bere v úvahu citlivost výstupu na jednotlivé váhy.

Autoři experimentálně ukázali, že LB-ADMM inicializace překonává inicializační schémata z LittleBit i DBF. Jejich hypotéza: vyřešit kombinatorický problém binární faktorizace před fine-tuningem poskytuje stabilnější optimalizační krajinu než přístupy, které inicializaci řeší přibližně a spoléhají na to, že ji gradientová optimalizace dotáhne.

Po ADMM následuje magnitude balancing — vyrovnání škálovacích faktorů, aby binární matice měly vyvážený rozsah.

Krok 3 — Zpřesnění faktorizovaných komponent. Po inicializaci se binární matice a škálovací faktory dolaďují pomocí Straight-Through Estimatorů (STE). STE je standardní trik pro gradientovou optimalizaci přes diskrétní operace — při zpětném průchodu se gradient sign funkce nahradí identitou. Toto zpřesnění probíhá lokálně na úrovni bloku, ne globálně.

Na závěr celého procesu přichází model-level rekonstrukce: lehká kalibrace škálovacích faktorů přes celý model pro lepší globální zarovnání aktivací.

Co znamená "sub-1-bit"

Pojem sub-1-bit může znít jako protimluv — jak můžete mít méně než jeden bit informace na váhu? Odpověď je v tom, že nízko-rankový rozklad sdílí informaci mezi váhami. Binární matice v rozkladu jsou menší než původní váhová matice, takže celkový průměrný počet bitů na váhu (bits per weight, BPW) klesne pod 1.0.

NanoQuant demonstroval výsledky na 0.8 BPW, tedy méně než jeden bit na váhu v průměru. Při tomhle kompresním poměru samozřejmě dochází k degradaci kvality — ale ta je měřitelná a v kontextu 70B modelů stále překvapivě nízká.

Čísla

Tady to přestává být akademické cvičení a začíná to být prakticky relevantní:

• Llama2-70B: komprese ze 138,04 GB na 5,35 GB — kompresní poměr 25,8×
• Inference: kvantizovaný 70B model běží na spotřebitelské 8GB GPU rychlostí až 20,11 tokenů/s
• Kalibrace: 128 vzorků (~0,26M tokenů), 1 GPU
• Čas komprese: ~13 hodin na jednom H100 pro Llama2-70B
• CUDA kernely: autoři implementovali vlastní binární GEMV/GEMM kernely optimalizované pro datacenter, spotřebitelské i edge GPU

Pro srovnání: Llama2-70B v FP16 vyžaduje minimálně 140 GB VRAM, tedy dvě A100 80GB. NanoQuant ho nacpe na jednu RTX 4060 s 8 GB.

Autoři testovali na rodinách modelů Llama2, Llama3, Qwen3 a dalších. Napříč modely NanoQuant vytváří novou Pareto frontu v prostoru komprese vs. kvalita — tedy pro danou úroveň komprese dosahuje lepší kvality než kterákoliv jiná PTQ metoda.

Kontext: co existuje kolem

NanoQuant není v izolaci. Celá oblast sub-1-bit kvantizace LLM se v posledním roce výrazně zahustila:

LittleBit (Samsung Research / NeurIPS 2025) — QAT metoda, která jde až na 0.1 BPW. Používá SVD-inspirovanou latentní faktorizaci s multi-scale kompenzací. Dosahuje skvělých výsledků, ale vyžaduje přetrénování.

DBF / Double Binary Factorization (Boža & Macko, 2025) — Rozkládá váhové matice na součin dvou binárních matic s diagonálním škálováním. Inference je efektivní (jen sčítání místo násobení), ale škálovací parametry jsou příliš omezené — všechny rankové komponenty sdílejí stejný magnitudový profil.

MDBF / Multi-Envelope DBF (prosinec 2025) — Rozšíření DBF, které nahrazuje jednoduché škálování rank-l obálkou. Zlepšuje perplexitu i zero-shot přesnost oproti DBF při stejném BPW.

BTC-LLM (květen 2025) — Používá naučitelné transformace a binární codebooky místo přímé binarizace.

HBLLM — Waveletová dekompozice pro vylepšenou 1-bit kvantizaci s frekvence-aware seskupováním.

NanoQuant se od těchto metod odlišuje tím, že je čistě PTQ — nepotřebuje přetrénování — a přesto dosahuje konkurenceschopné kvality. To je prakticky zásadní rozdíl, protože PTQ můžete aplikovat na libovolný model bez přístupu k trénovacím datům nebo pipeline.

Současný stav projektu

Na rovinu: k dnešnímu dni (duben 2026) je NanoQuant čerstvý research paper bez veřejně dostupného kódu.

• Paper: publikován 6. února 2026 na arXiv, necelé dva měsíce starý
• Kód: zatím nevydaný. Autor na Hugging Face napsal: "We are working on open-sourcing the code, so please stay tuned!"
• Kvantizované modely / checkpointy: nejsou k dispozici. Na otázku po checkpointech autor zatím neodpověděl.
• Vlastní CUDA kernely: zmíněny v paperu, ale rovněž nejsou veřejné

Jde o výzkum Samsung Research, takže open-source release může trvat déle kvůli interním schvalovacím procesům. Autor Hyochan Chong se v únoru 2025 vrátil do Samsung Research po dokončení studia a NanoQuant je jeden ze dvou paperů, které publikoval v únoru 2026 (druhý je RaBiT — 2-bit QAT metoda).

Co to znamená pro praxi

Než se kód uvolní, NanoQuant zůstává akademický výsledek. Ale i jako takový naznačuje směr:

Pro edge nasazení: Pokud se sub-1-bit formáty dostanou do mainstreamových inference frameworků (llama.cpp, vLLM, TensorRT-LLM), otevírá se možnost provozovat modely třídy 70B na hardware, kde dnes sotva běží 7B. To je relevantní pro kohokoliv, kdo provozuje lokální LLM inference na omezeném hardware — Raspberry Pi, jednočipové GPU, mobilní zařízení.

Pro GGUF ekosystém: Zatím žádná podpora. NanoQuant vyžaduje vlastní binární CUDA kernely, takže integrace do llama.cpp by znamenala portovat tyhle kernely na CPU/Metal/Vulkan backendy. To není triviální, ale komunita kolem llama.cpp už v minulosti portovala i složitější formáty.

Pro kvalitu vs. komprese trade-off: NanoQuant ukazuje, že Pareto fronta se posouvá. Před rokem byl sub-1-bit režim terra incognita pro PTQ. Teď máme měřitelné výsledky, které říkají, že 70B model komprimovaný na 5,35 GB stále dává rozumné výstupy. To mění kalkulaci pro deployment.

Stojí za to sledovat autorův profil a Samsung Research na Hugging Face. Jakmile se kód uvolní, bude to jeden z nejzajímavějších frameworků k otestování.

Reference a zdroje

• NanoQuant paper (arXiv): arxiv.org/abs/2602.06694
• Hugging Face paper page: huggingface.co/papers/2602.06694
• Samsung Research na Hugging Face: huggingface.co/SamsungResearch
• Profil autora (Hyochan Chong): d7chong.github.io
• Blog-style summary (alphaXiv): alphaxiv.org/overview/2602.06694v1
• LittleBit (Samsung Research): research.samsung.com/blog/LittleBit-Ultra-Low-Bit-Quantization-via-Latent-Factorization
• DBF — Double Binary Factorization: arxiv.org/abs/2505.11076
• MDBF — Multi-Envelope DBF: arxiv.org/abs/2512.24545
• BTC-LLM: arxiv.org/abs/2506.12040
• RaBiT (další paper od stejného autora): huggingface.co/papers — RaBiT: Residual-Aware Binarization Training

Dokument vytvořen: Duben 2026

The post NanoQuant: Post-training kvantizace LLM pod hranici jednoho bitu first appeared on Hard Wired.

Phreaking: Vzpomínky ze zlaté éry analogových linek

Autor: 3qeX - Hesse Valentino

Jsou věci, co se prostě nevytratí. Ani po dvaceti letech. Vůně maziva z rozvaděče telefonní budky. Chlad kovu na šlicu. A ten moment, když po spojení žárovky s linkovými svorkami uslyšíš v improvizovaném sluchátku čistý oznamovací tón SPT Telecom.

Byl jsem phreaker. Tehdy jsem o tom věděl kulový - pár triků z pochybných webů s černým pozadím a bílým textem. Přesto to bylo dobrodružství, jaké dnešní generace asi nikdy nezažije.

Tohle není návod. Je to vzpomínka. Popis historických technik z doby, kdy analogová telefonní síť ještě žila a kdy výzvou bylo přelstít obří státní kolos jménem SPT Telecom.

Co je phreaking a kde se vzal

Phreaking je manipulace s telefonními sítěmi - zneužívání technických vlastností analogové infrastruktury za účelem bezplatného volání, odposlechu nebo průzkumu skrytých funkcí ústředen. Termín vznikl v USA někdy kolem roku 1957 a jeho kořeny jsou propojeny s postavami, které se staly legendami hackerské kultury.

První slavný phreaker byl Joe Engressia, přezdívaný Joybubbles - nevidomý kluk se schopností dokonalé výšky sluchu. Zjistil, že když zapíská tón 2600 Hz do telefonního sluchátka, resetuje dálkové linkové spoje. Na tohle navázal John Draper - Captain Crunch - který přišel na to, že plastová píšťalka z cornflakes kapsy generuje přesně ten tón. Dálkové volání zdarma kamkoliv po světě bylo najednou možné za cenu cereálií. Absurdní, ale fungovalo to.

Z toho se zrodily legendární "barevné krabičky" - phreakerské přístroje pojmenované podle barev. Systém zavedli američtí phreakeři v 60. a 70. letech. Barvy sloužily jako kódové označení funkce v textových souborech šířených tajně na disketách a přes BBS sítě. Jména jako Steve Wozniak nebo Steve Jobs se v phreakerském undergroundu pohybovala dávno před tím, než spoluzaložili Apple.

Česká scéna: SPT Telecom a divoké devadesátky

Do Česka phreaking přišel s jistým zpožděním, ale o to živěji. V 90. letech procházela naše telefonní síť schizofrenním stavem - část byla moderní digitální, ale obrovská část, zejména na menších městech a vesnicích, jela na starých analogových systémech Křemíková.

SPT Telecom vlastnil prakticky veškerou infrastrukturu a jeho ceny byly podle tehdejších standardů astronomické. Minuta hovoru do zahraničí stála majlant. Minuty na tehdy čerstvě spuštěné mobilní sítě NMT nebo GSM byly pro kluka ze základní školy naprosto nedostupné.

To byl živný půdorys pro phreaking. Fascinace systémem nebyla jen touha volat zadarmo - byl to pocit, že víte o síti něco, co by neměl vědět nikdo mimo telefonní techniky. Klíč k systému.

Za průkopníka české phreakerské scény se v undergroundu považoval "Subber", který kolem roku 2006 provozoval weby věnované problematice. Ještě dříve, na přelomu milénia, kolovala jména jako "Flash" nebo "Morpheus", kteří psali dlouhé manuály - tzv. Guides - formátem naprosto typickým pro dobu: bílý text na černém pozadí, spousta ASCII artu, žádné obrázky.

Zmínit se musí i Zdeněk Adamec, vystupující online pod nickem Satan nebo Satanic. Jeho webové stránky na tehdejším freehostingu byly rozcestníkem pro zájemce o "zakázané vědomosti" - ale jeho těžiště leželo primárně v darkingu, ne v phreakingu. O phreakingu publikoval jen několik málo článků, většinou překlady zahraničních manuálů.

Komunita se sdružovala v různě pojmenovaných skupinách - v undergroundu tehdy figurovala CIA (Czech Illegal Alliance) vedená Kill3rem a Subberem, ale i skupiny navázané na darkerskou scénu jako Darkers Group nebo RJ-11 Security Alliance. SOOM.cz pak od roku 2003 fungoval jako hlavní česky psaný portál věnující se bezpečnosti a phreakingu, a jeho fórum z roku 2005 je dnes historickým dokumentem živé komunity.

Boxy: barevná abeceda phreakingu

Ústředním nástrojem světového phreakingu byly tzv. boxy - malá elektronická zařízení pojmenovaná podle barev. V Česku se většina z nich přizpůsobovala místní síti, nebo zůstávala spíše teorií. Přesto stojí za to si je projít.

Blue Box (modrá krabička)

Nejslavnější phreakerský nástroj vůbec. Generoval tón 2600 Hz, který v americké síti Ma Bell signalizoval volnou dálkovou linku. Po vyslání tohoto tónu do sluchátka mohl phreaker linku "shodit" a pomocí dalších MF tónů řídit přepojení kamkoliv na světě - zdarma.

V Česku fungovalo modré krabičce analogicky na starých tranzitních ústřednách, zejména u mezinárodních hovorů. Vytočilo se bezplatné číslo (linka poruch, operátora), vysílal se tón - a otevřenou linku šlo dále řídit. Se začátkem digitalizace ústředen na systémech EWSD a S12 přestala tato technika fungovat definitivně.

Red Box (červená krabička)

Zatímco modrá krabička útočila na dálkové linky, červená mířila na mincovní automaty. Telefonní automat komunikoval s ústřednou sériemi tónů signalizujících vhozené mince - každá nominální hodnota mince měla svou frekvenční signaturu. Červená krabička tyto tóny emulovala.

V praxi stačilo přiložit malý reproduktor ke sluchátku a přehrát nahrávku odpovídajících tónů. Ústředna si myslela, že automat přijal mince, a hovor povolila. SPT Telecom tento problém řešil filtrací - signály z mincovníku přestaly být přenášeny přes sluchátkový okruh a šly přímou servisní linkou.

Black Box (černá krabička)

Černá krabička se instalovala u příjemce hovoru, ne u volajícího. Fungovala na principu manipulace s napětím na lince.

Analogové ústředny detekovaly zvednuté sluchátko poklesem napětí na lince: v klidu bylo napětí zhruba -48 V, po zvednutí sluchátka kleslo pod -10 V - to byl signál pro zahájení účtování. Černá krabička vkládala do série s linkou rezistor nebo Zenerovu diodu tak, aby napětí nekleslo pod práh účtování (udržovalo se kolem -36 V). Zvonění se zastavilo, hovor byl navázán, ale ústředna ho nevyhodnotila jako přijatý - volající neplatil nic.

Tato technika fungovala výhradně na ústřednách řízených mechanickými relé. V Česku a ve střední Evropě obecně černé krabičky přežívaly až hluboko do 90. let díky pomalejší digitalizaci sítě.

Beige Box (béžová krabička) - servisní sluchátko

Toto byl v českém undergroundu prakticky nejpoužívanější nástroj a ten, se kterým jsem měl osobní zkušenost. Beige box je v podstatě to, co telefonní technici nazývají lineman's handset - servisní sluchátko s krokosvorkami.

Konstrukce byla prostá: starý telefon (ideálně vykuchaný fax), dva krokodýlci připojeni na červený a zelený vodič. Někdy se přidával přepínač mikrofonu pro tichý odposlech. Výsledkem byl přístroj za cenu šrotu, který vám umožnil připojit se přímo na svorkovnici telefonní linky kdekoliv v rozvaděči - bez ohledu na to, co na lince viselo za přístroj.

Výhoda sluchátka z faxu oproti běžnému telefonu: faxy měly v sobě kompletní elektroniku pro vytáčení a přepínač mezi pulzní (analogovou) a tónovou (DTMF) volbou, což bylo v devadesátkách klíčové - mnoho přístrojů ještě umělo jen pulzní volbu, ale ústředny nebo bankovní automaty vyžadovaly DTMF.

Mauve Box (fialová krabička) - hudba do linky

Méně známý, ale technicky zajímavý byl tzv. mauve box. Sloužil k přimíchání externího audio signálu - hudby nebo jiného zvuku - do probíhajícího hovoru. Zapojoval se do série s linkou a obsahoval oddělovací transformátor zabraňující poškození elektroniky.

Praktické využití v českém undergroundu bylo dvojí: vytváření primitivních konferenčních hovorů přes propojení kazeťáku s linkou, nebo pouštění hudby do sluchátka volané osoby. Zvláštní využití spočívalo v maskování prostředí - přehrávání nahrávky hluku ulice mělo zakrýt, že voláte z místa, ze kterého volat nemáte.

Žárovka a šlic: technika z telefonní budky

Tohle byl trik, který mi nedal spát. Přečetl jsem o něm kdesi na webu a nedalo mi to, dokud jsem ho nevyzkoušel.

Spodní část telefonní budky SPT Telecom - tzv. šlic nebo rozvaděč - obsahovala svorkovnici, na které končily linkové vodiče budky ještě před samotným mincovním automatem.

Telefonní linka v klidu nesla stejnosměrné napětí přibližně 48 V. Ve chvíli, kdy ústředna zaregistrovala pokles napětí způsobený zdvižením sluchátka (off-hook stav), otevřela linku a poslala oznamovací tón. Mincovní automat přitom ale měl vlastní elektroniku, která řídila účtování - čekala na vhození karty nebo mince, teprve pak povolila vytáčení.

Trik spočíval v připojení žárovky na 24 V přímo na svorky a a b linky v rozvaděči. Proč zrovna 24V žárovka? Žhavicí vlákno takové žárovky má při provozu odpor přizpůsobený napájení 24 V - při 48 V na telefonní lince jím protéká proud, který způsobí pokles napětí do rozmezí přibližně 20-30 V. Tento pokles byl pro starší analogové ústředny dostačující k detekci off-hook stavu, takže ústředna linku otevřela a zaslala oznamovací tón.

Klíčový detail: automat zůstával fyzicky zavěšen. Jeho vlastní elektronika vůbec nevěděla, že na lince cosi probíhá. Žárovka simulovala zátěž "pro ústřednu" - ale mincovní mechanismus zůstával zcela mimo hru.

Žárovka navíc poskytovala velmi praktickou vizuální zpětnou vazbu: ve chvíli, kdy se linka správně otevřela, začala mírně svítit. To byl váš signál připojit beige box - servisní sluchátko s krokosvorkami - přímo ke svorkám vedle žárovky. Oznamovací tón v sluchátku potvrdil, že máte přístup k lince a můžete vytáčet libovolné číslo. Volal jste přímo přes ústřednu SPT Telecom - na účet té konkrétní linky budky.

Tato technika zanikla s přechodem ústředen na digitální přepínaní (EWSD, S12). Digitální ústředny nestačí oklamat pouhým poklesem napětí - aktivně monitorují stav linky a rozlišují typ připojeného zařízení. Navíc fyzická ochrana šliců se v pozdějších 90. letech výrazně zlepšila.

DTMF dialery a další triky

Paralelně s hardwarovými boxy existovaly i jednodušší, ale neméně užitečné nástroje.

DTMF dialer - malý kapesní přístroj s klávesnicí - byl původně legální pomůcka pro dálkové ovládání záznamníků. Phreakeři ho přeložili ke sluchátku a pomocí tónové volby ovládali hlasová menu ústředen nebo systémy, které vyžadovaly DTMF, ale dostupný telefon uměl jen pulzní volbu.

Telefonní karty SPT Telecom přinesly vlastní podmnožinu phreakingu. Čipové karty byly terčem pokusů o obejití zápisového kontaktu - fyzickým naříznutím nebo přelepením určitého kontaktu na čipu se znemožnil zápis spotřeby, zatímco čtení jednotek fungovalo normálně. Pokročilejší varianta: mikrokontrolerové emulátory na bázi PIC čipů, schopné simulovat chování originální karty s neomezeným kreditem.

Přesměrování přes firemní ústředny (PBX hacking) bylo kapitolou pro sebe. Špatně zabezpečené firemní ústředny - zejména ty staršího data - umožňovaly přístup z veřejné linky přes servisní tónové příkazy. Phreaker se "vloupat" do ústředny a skrze ni volat na libovolné zahraniční číslo - na účet dané firmy.

Darking: ryze česká odnož

Phreaking v České republice nelze vyprávět bez zmínky o darkingu - fenoménu, který je ryze českou specialitou a v okolních zemích prakticky neexistoval.

Darking vznikl kolem roku 2001 v prostředí, kde se phreaking prolínal s průzkumem technické infrastruktury. Darkeři se zaměřovali na rozvaděče elektrického vedení, vypínání veřejného osvětlení, průzkum podzemních prostor a obecně na technický vandalismus v hraničních zónách zákona. Výraznou postavou byl Zdeněk Adamec (online alias Satan), jehož web byl komunitním rozcestníkem.

Darkerská komunita se sdružovala ve skupinách jako Darkers Group No. 1 (s buňkami v Ústí nad Labem a Kutné Hoře) nebo RJ-11 Security Alliance. Adamcova tragická smrt v březnu 2003 - sebevražda upálením u Národního muzea jako protest proti stavu světa - symbolicky uzavřela nejintenzivnější kapitolu tohoto hnutí.

Zánik scény a právní aspekty

Konec tradičního phreakingu přišel ze dvou stran najednou.

Za prvé: technologie. Digitalizace ústředen na systémech EWSD a S12 postupně eliminovala techniky závislé na analogovém chování linek. Čipové telefonní karty s kryptografickým zabezpečením nahradily starší zranitelné typy. Mobilní telefony s předplacenými kartami (Twist, Go, Oskarta) udělaly z hledání funkčních budek naprostou zbytečnost - proč trávit hodinu u rozvaděče, když máte předplacenou kartu za stokorunu?

Za druhé: legislativa. Phreaking je v České republice trestná činnost. Podle §230 trestního zákoníku se jedná o neoprávněný přístup k počítačovému systému a nosiči informací, v širším smyslu pak pod porušení tajemství dopravovaných zpráv (§182). Přesto je zajímavé, že dle dostupných informací nebyl v ČR nikdo za phreaking formálně odsouzen - scéna byla příliš malá (Subber odhadoval počet aktivních phreakerů na cca 50), příliš rozptýlená a způsobené škody nikdy nedosáhly astronomických čísel.

Závěr: klíč, který přestal pasovat

Pamatuji si ten pocit. Stát u telefonní budky, v kapse mít sluchátko vyrobené ze starého faxu, v druhé ruce žárovku s dvěma vodiči zakončenými krokosvorkami. Celá situace vypadala absurdně - a přece fungovala.

Fascinace phreakingem nikdy nebyla jen o bezplatném volání. Byl to průzkum systému, touha pochopit, jak věci skutečně fungují pod povrchem toho, co běžný uživatel vůbec nevidí. Telefonní síť tehdy působila jako černá skříňka - a přijít na to, jak se dovnitř podívat, byl svým způsobem malý triumf.

Dnes ta síť neexistuje. Měděné páry v zemi stále jsou, ale hovory dávno cestují jako datové pakety přes optiku a internet. Žárovka na 24 V by v šlicu moderní budky způsobila leda poplach v monitorovacím centru operátora. SPT Telecom se proměnil v O2, budky z ulic prostě zmizely.

Zůstávají jen vzpomínky. A možná tenhle článek.

— 3qeX

Poznámka: Tento článek popisuje historické techniky z dob analogové telefonní sítě. Phreaking je v České republice nelegální činnost dle §230 a §182 trestního zákoníku. Veškeré popisované techniky jsou dnes nefunkční nebo obtížně aplikovatelné na moderní digitální infrastrukturu.

The post Phreaking: Vzpomínky ze zlaté éry analogových linek first appeared on Hard Wired.