963,Ve středu 28. října zemřel v Los Angeles sir Patrick Stewart. Kluk z Yorkshiru, který vyrůstal v domě bez koupelny, zahrál nejlidštějšího kapitána sci-fi a pro celou generaci techniků se stal velitelem, kterého by si přáli mít nad sebou. Vzpomínka na herce, jenž lodi velel hlasem, ne pěstí.

„Make it so.“ Tři slova, kterými kapitán Jean-Luc Picard posílal posádku Enterprise do práce. Patrick Stewart si je později půjčil i do názvu svých pamětí. A dnes večer, když jsem dočetla zprávu o jeho smrti, mi došlo, že ta věta patří i nám, co něco pájíme, ladíme a kompilujeme. Rozhodni se, řekni to nahlas a pak to udělej.

Stewart zemřel ve středu doma v Los Angeles, v péči své ženy Sunny. Bylo mu 86 let. Podle prohlášení rodiny prošel krátkou a těžkou cestou Alzheimerovy choroby a demence s Lewyho tělísky, informují TV Insider a ČTK.

Kluk bez koupelny

Narodil se 13. července 1940 v Mirfieldu, dělnickém městečku v západním Yorkshiru. Doma neměli záchod ani koupelnu. Otec, vyznamenaný voják, se z války vrátil s traumatem, o víkendech pil a bil matku, která pracovala v textilce. Stewart to bez obalu popsal v pamětech Making It So z roku 2023. Deníku The Guardian tehdy řekl, že pochopit otcův vliv na sebe mu trvalo 25 až 30 let terapie.

Únik našel na jevišti. U Shakespeara si jako školák umínil, že jednou bude hrát v Royal Shakespeare Company. V roce 1966 se tam dostal a zůstal čtrnáct let. Hrál Macbetha, Othella, Prospera i Shylocka, píše Guardian.

Hollywood si ho našel, až když mu bylo 47.

Kapitán, který nejdřív poslouchal

Picard nebyl Kirk. Neskákal po každém mimozemšťanovi na planetě z papírmaše. Sedl si do zasedačky, vyslechl Data, Geordiho i doktorku Crusherovou, a teprve pak rozhodl. Kdo kdy pracoval v technickém týmu, ten typ zná jen z vyprávění: šéf, který technikovi věří, ale odpovědnost za rozhodnutí si nechá u sebe.

Star Trek: Nová generace běžela sedm sezon, od roku 1987 do roku 1994, a Stewart v ní natočil 176 epizod. Přidal čtyři celovečerní filmy a v letech 2020 až 2023 tři řady seriálu Star Trek: Picard, u kterého byl i výkonným producentem.

Ze 176 epizod si každý fanoušek nese svou. Moje je The Inner Light, kde Picard během jediného dílu prožije celý cizí život a na konci mu zůstane jen flétna. A pak „There are four lights!“ z dvojdílu Chain of Command. Lepší lekci o tom, že pravda se nemění podle toho, kdo zrovna drží ovladač, televize nenatočila.

Tablet z rozpočtové nouze

Na palubě Enterprise-D se pracovalo s PADDy, tenkými dotykovými deskami, které vypadaly podezřele jako dnešní tablety. Vznikly ze šetření. Art director seriálu Michael Okuda vysvětloval pro Ars Technica, že nakreslit ovládání jako grafiku vyšlo štábu levněji než kupovat elektroniku. A když se ho někdo ptal, kde je tlačítko pro akci, se kterou nepočítal, odpověděl, že je v softwaru. To bylo v roce 1987.

Doug Drexler, který na trekových rekvizitách pracoval desítky let, o prvním iPadu prohlásil, že je to „pravý startrekový sen“, píše Time.

Mimochodem, Picard nosil PADDy po hromadách. Tvůrci tak divákům ukazovali, že má práce nad hlavu, připomíná Inverse. Dnes by stačil jeden tablet a tři nedočtené kanály na Slacku (pokrok je pokrok).

LeVar Burton, seriálový Geordi La Forge, k tomu pro Adweek řekl, že věří v jednoho konkrétního kluka: ten koukal na původní Star Trek, vyrostl, stal se inženýrem a navrhl véčkový telefon. Kolik takových kluků a holek vyrostlo u Nové generace, nikdo nespočítá. Pár jich čte tenhle web.

Hlas, který znáte, i když nevíte odkud

V roce 2000 nasedl Stewart do vozíku Profesora X a ve filmové sérii X-Men si podmanil další generaci. Proti němu stál jeho blízký přítel Ian McKellen jako Magneto. Roli si zopakoval mimo jiné v Loganovi a objeví se v ní ještě jednou, ve filmu Avengers: Doomsday, který jde do kin 18. prosince.

Hráči ho znají z The Elder Scrolls IV: Oblivion, kde jako císař umírá hned v úvodu, a z Castlevania: Lords of Shadow. Picarda namluvil v zhruba deseti trekových hrách, uvádí Game Informer. V roce 2010 ho královna Alžběta II. pasovala na rytíře za zásluhy o drama.

Rodinné prohlášení, které citoval server Variety, připomíná i to, o čem se v nekrolozích mluví méně. Stewart celý život podporoval oběti domácího násilí, uprchlíky, péči o duševní zdraví válečných veteránů a ochranu zvířat, hlavně svých adoptovaných pitbulů. Kdo zná jeho dětství, tomu první položka na seznamu nepřijde náhodná.

Jonathan Frakes, jeho první důstojník Riker, sdílel nekrolog s jedinou větou: „Rest in peace my friend.“ Marvel Studios o něm napsali, že byl jedinečný talent, velkorysý kolega a skutečný gentleman.

Picard by teď nejspíš řekl, ať se vrátíme k práci. Tak dobře, kapitáne.

S úctou a pokorou
Valentino Hesse

Make it so.

The post Sbohem, kapitáne. Patrick Stewart odešel ve věku 86 let first appeared on Hard Wired.

Třetí díl série o klonování DESFiru. V prvních dvou jsme rozebrali teorii a praxi zálohy. Teď je na stole skutečný dump pravé Mifare DESFire karty z Flipper Zero a projdeme ho řádek po řádku: co z karty vypadlo, kde se čtečka zastavila a co o zabezpečení systému prozradí i to málo, co jde přečíst bez klíče. A protože Flipper umí DESFire i víc než jen přečíst obálku, přidávám detailní rozbor a návod k aplikaci DFC. UID v ukázce je anonymizovaný, změnil jsem jeho poslední bajt.

Teoretický rozbor je jedna věc, reálný výpis z karty druhá. Vzal jsem pravou DESFire kartu, ke které mám přístup, přiložil ji na Flipper Zero a nechal ji přečíst. Výsledkem je soubor .nfc, který se vejde na jednu obrazovku a který ilustruje obě předchozí části líp než jakýkoli diagram.

Ukazuje totiž přesně to rozhraní, o kterém byla celou dobu řeč: hranici mezi tím, co z DESFiru dostaneš zadarmo, a tím, co je zamčené za kryptografií.

Rozeberme ho.

Co máme na stole

Tady je celý dump. UID jsem anonymizoval změnou posledního bajtu, jinak je přesně takový, jak ho Flipper vyčetl.

Filetype: Flipper NFC device
Version: 4
# Device type can be ISO14443-3A, ISO14443-3B, ISO14443-4A, ISO14443-4B, ISO15693-3, FeliCa, NTAG/Ultralight, Mifare Classic, Mifare Plus, Mifare DESFire, SLIX, ST25TB, NTAG4xx, Type 4 Tag, EMV
Device type: Mifare DESFire
# UID is common for all formats
UID: 04 80 C4 1A 28 25 00
# ISO14443-3A specific data
ATQA: 03 44
SAK: 20
# ISO14443-4A specific data
T0: 75
TA(1): 77
TB(1): 81
TC(1): 02
T1...Tk: 80
# Mifare DESFire specific data
PICC Version: 04 01 01 33 00 1A 05 04 01 01 03 00 1A 05 04 80 C4 1A 28 25 00 21 52 59 30 30 91 26
PICC Free Memory: 8032
PICC Change Key ID: 00
PICC Config Changeable: true
PICC Free Create Delete: true
PICC Free Directory List: true
PICC Key Changeable: true
PICC Flags: 00
PICC Max Keys: 01
PICC Key 0 Version: 00
Application Count: 1
Application IDs: A1 70 F4
Application a170f4 Change Key ID: 00
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Flags: 00
Application a170f4 Max Keys: 00

Na první pohled nic dramatického. Na druhý pohled učebnice.

Co karta prozradila o sobě

Než se dostaneme k tomu, co Flipper nepřečetl, projděme to, co přečetl. Už z hlaviček se dá karta přesně zařadit.

Device type: Mifare DESFire potvrzuje, že jde o pravou DESFire, ne o magic kartu, která by se za Classic jen vydávala. UID: 04 80 C4 1A 28 25 00 je sedmibajtové a začíná bajtem 04, což je výrobní kód NXP. UID je pevné a čitelné, takže Random ID tahle karta zapnuté nemá a je sledovatelná podle svého čísla.

SAK: 20 je drobnost, na které stojí půlka prvního článku. Hodnota 0x20 znamená, že karta podporuje ISO 14443-4, tedy že jede přes RATS a ATS do přenosového protokolu T=CL, a ne jen přes antikolizi jako Mifare Classic. Řádky ATS pod tím (T0: 75, TA(1): 77 a dál) jsou právě ta odpověď na RATS, kde se dohodne rámcování a rychlost. Tohle je ta vrstva -4 černé na bílém.

Z PICC Version se dá vyčíst generace a velikost. Bajt velikosti úložiště 1A odpovídá osmi kilobajtům, což sedí na PICC Free Memory: 8032. Hlavní verze hardwaru 33 ukazuje na generaci EV3 (0x01 je EV1, 0x12 EV2, 0x33 EV3); pro stoprocentní jistotu stačí kartu hodit do NXP TagInfo, ale vychází to na EV3. Konec řetězce Version nese UID znovu a za ním výrobní dávku a datum.

Shrnuto: osmikilová DESFire EV3 od NXP, bez Random ID.

To všechno Flipper zjistil, aniž by znal jediný klíč.

Kde se Flipper zastavil

A tady přichází pointa.

Všimni si, kde výpis končí.

Application IDs: A1 70 F4
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Max Keys: 00

Seznam aplikací Flipper dostal, je tam jedna s AID a170f4. Ale uvnitř té aplikace nevidíš nic. Žádné soubory, žádný obsah, žádné klíče. Max Keys: 00 neznamená, že aplikace nemá klíče, ale že se k nim Flipper nedostal. Narazil na hranici aplikace a bez autentizačního klíče neprošel.

Proč vůbec dostal ten seznam aplikací? Kvůli jednomu nastavení o pár řádků výš, PICC Free Directory List: true, které listing aplikací bez autentizace povoluje. Kdyby bylo false, neviděl by ani AID.

A přesně tohle je závěr druhého článku na živém vzorku. Stock NFC aplikace přečetla obálku, dovnitř dopisu se nepodívala. Soubor .nfc není klon a funkčním klonem se nestane. Kdybys to UID zapsal na sedmibajtovou magic kartu, projdeš jedině u systému, který věří pouhému UID a nic neověřuje. U skutečné DESFire autentizace magic karta mlčí, protože nemá čím odpovědět na výzvu.

Co z toho čte bezpečák

Teď to zajímavé, protože i ta neautentizovaná hlavička dokáže o nasazení hodně napovědět. Podívej na nastavení na úrovni celé karty.

PICC Key 0 Version:       00
PICC Config Changeable:   true
PICC Free Create Delete:  true
PICC Free Directory List: true
PICC Key Changeable:      true

Nejsilnější signál je verze master klíče. PICC Key 0 Version: 00 skoro vždy znamená, že master klíč nikdo nerotoval a sedí tam pořád výchozí hodnota, tedy samé nuly. K tomu Free Create Delete: true, což dovoluje zakládat a mazat aplikace bez autentizace master klíčem. Dohromady je úroveň PICC měkká: výchozí master klíč a volná správa aplikací. Kdo se autentizuje tím výchozím klíčem, může na kartě aplikace přidávat nebo rovnou mazat. Data v uzamčené aplikaci a170f4 sice nepřečte, na to potřebuje aplikační klíč, ale integrita a dostupnost celé karty na tom stojí vratce.

Kontrast se samotnou aplikací je přitom poučný. Aplikace a170f4 je zamčená slušně:

Application a170f4 Config Changeable:  false
Application a170f4 Free Create Delete:  false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable:      false

Config neměnný, klíče neměnné, listing i create/delete zakázané. Kdo tu aplikaci personalizoval, udělal na její úrovni hygienu správně. Jenže PICC kolem ní nechal rozvolněný. A to je přesně ten mismatch z prvního dílu: kryptografie čipu drží, slabina je v personalizaci, ne v křemíku.

DESFire tady nechybuje. Obrany, které karta nabízí, musí někdo zapnout a nastavit. Random ID je vypnuté, master klíč nerotovaný, správa aplikací volná. Žádná z těch věcí není porucha karty, všechny jsou rozhodnutím při nasazení.

Jenže Flipper umí DESFire i víc: aplikace DFC

Dump výš vylezl ze stock NFC aplikace, která se u DESFiru zastaví na obálce. To ale není poslední slovo Flipperu. V katalogu je komunitní aplikace DFC (DESFire-compatible) od autora cindersocket, fork seos_compatible od Erica Bettse, která mluví nativním DESFire command setem a jde dál. S jedním velkým ale, na které si dej pozor, než si z toho uděláš falešný obrázek.

DFC neláme. Nerecovruje klíče, nekrákuje AES, žádný nested útok jako u Classic. Klíč si musíš přinést. Buď ho máš, protože čteš svou kartu, nebo credential napíšeš ručně ze známých klíčů. Emulace jede výhradně s klíči, které do credentialu vložíš. Je to nástroj pro práci s vlastními kartami, ne bypass cizích, a na kartu bez klíče se nedostane o nic víc než stock appka. Na náš uzamčený a170f4 by si DFC bez jeho klíče taky vylámal zuby.

Co tedy DFC s klíči umí:

• Čte DESFire karty. Autentizuje se v režimech legacy DES, ISO 3DES, AES i EV2 a na straně čtečky sáhne klíčem 0 do primární aplikace a přečte její nakonfigurované soubory.
• Emuluje uloženou credential, takže se Flipper vydává za DESFire kartu. K emulaci použije jen klíče uložené přímo v té credentialu.
• Emuluje prázdný DESFire (režim Blank Card). Když do něj čtečka při zápisu něco pošle, po odchodu z emulace tě to vyzve uložit zachycená data jako credential.

Credential je textový soubor .dfc (nebo předkompilovaný binární .dfcb) a nese UID, AID, key settings, autentizační mód a klíče i soubory po slotech. To je přesně ta logická struktura z druhého dílu, jen v jiném kabátě: místo abys obsah zapsal zpět na prázdnou kartu, necháš ho emulovat Flipper.

Tím se zpřesňuje jedna věta z celé série. Psal jsem ve smyslu „Flipper DESFire nedá“. Teď přesněji: Flipper DESFire nenaláme, ale s aplikací DFC a se znalostí klíčů ho přečte i emuluje. Hranice se neposunula o kousek dál k prolomení, posunula se jen o to, co dovede handheld, když klíče už máš v ruce. Jedno upozornění k aktuálnosti: DFC staví na EV1 a EV2 příkazech, pokrytí EV2 a EV3 hardwaru se teprve ověřuje na fyzických čtečkách a radiová kompatibilita není zaručená. Není to oficiální nástroj NXP a autor sám nedává záruku funkčnosti.

DFC krok za krokem

Takhle s tím zacházíš, když chceš číst nebo emulovat vlastní kartu.

Instalace. Nejjednodušší je nainstalovat DFC přímo z katalogu přes Flipper Lab (lab.flipper.net/apps/dfc). Kdo chce stavět ze zdrojáku, naklonuje repozitář, dotáhne submoduly a sestaví přes ufbt:

git submodule sync --recursive
git submodule update --init --recursive
ufbt

Čtení vlastní karty. Přilož kartu na Flipper a nech DFC přečíst primární aplikaci. Aplikace se autentizuje klíčem 0 a stáhne nakonfigurované soubory. Přečtená karta se uloží jako credential i se svým AID, key settings, autentizačním módem a klíči a soubory po slotech. Soubory credentialů patří na kartu do SD Card/apps_data/dfc/.

Emulace. Vyber uloženou credential a Flipper se začne vydávat za tu kartu. K autentizaci vůči čtečce použije jen klíče, které credential obsahuje; žádné jiné nemá odkud vzít. Tohle je ten „funkční klon“, který na magic kartě z principu nejde, ale na emulátoru se správnými klíči ano.

Blank Card. Když chceš vidět, co ti do karty zapíše cizí čtečka, zvol Blank Card. Flipper bude emulovat zapisovatelný prázdný DESFire (ve výchozím stavu s nulovým DES klíčem na úrovni PICC, AID 00 00 00). Pokud čtečka během emulace zapíše data, po odchodu z emulačního okna tě to vyzve uložit je jako .dfc.

Formát a limity credentialu. Textový .dfc se při načtení zkompiluje do binárního tvaru, případně rovnou podáš .dfcb. UID musí mít 7 bajtů a začínat 04. Jedna credential pojme nejvýš 4 aplikace, 16 souborů, 3 KiB dat celkem, 2 KiB v jednom souboru a 512 bajtů na klíče; samotný soubor .dfc nebo .dfcb nesmí přesáhnout 16 KiB. U velkých textových credentialů hrozí, že kompilace na zařízení vyčerpá heap, takže je zkompiluj radši na počítači:

python3 tests/compile_dfcb.py path/to/card.dfc path/to/card.dfcb

Ověření na hostu. Repozitář má k tomu dva testovací skripty. probe_dfcb.py pustí .dfcb proti virtuální kartě jádra přímo na počítači, nahlásí nepodporované credentials a vypíše APDU odpovědi; netestuje UI, NFC listener ani radiové časování, jen logiku. Výchozí APDU přečtou verzi a seznam aplikací, další hex APDU můžeš doplnit a proběhnou v pořadí v jedné relaci:

python3 tests/probe_dfcb.py path/to/card.dfcb
python3 tests/probe_dfcb.py path/to/card.dfcb 9060000000 90AF000000

Druhý skript, probe_pcsc_mac_read.py, je manuální hardwarová zkouška na macOS s PC/SC čtečkou a vyžaduje pythoní knihovnu cryptography. Nejdřív na Flipperu rozjeď emulaci credentialu, pak probe vybere aplikaci 0, autentizuje se ISO 2K3DES klíčem 1, přečte celý soubor 0 a ověří data i MAC v odpovědi. Aplikaci, soubor, klíč a čtečku přepíšeš přepínači --application, --file, --key a --reader:

python3 tests/probe_pcsc_mac_read.py path/to/card.dfc

Ber to jako experimentální nástroj. U EV2 a EV3 karet si funkčnost ověř na své konkrétní čtečce, protože hardwarové pokrytí se teprve dolaďuje.

Co si z toho vzít

Tenhle jeden výpis uzavírá celou sérii, protože v něm je vidět obojí najednou. Pevná část i měkká část DESFiru v jednom souboru.

Pevná část: stock NFC aplikace se k ničemu zabezpečenému nedostala a bez klíčů by aplikaci a170f4 neotevřel ani DFC. AES a tříprůchodová autentizace odvedly svoje, zamčená aplikace zůstala zamčená, naklonovat obsah na magic kartu nejde. Pokud systém kontroluje víc než UID, tahle karta je proti nástrojům bez klíčů tichá.

Měkká část: i tak výpis prozradil, že nasazení není dotažené. Verze master klíče 00 a volné create/delete jsou věci, které si v auditu přístupového systému přečteš jako první, a ani k tomu nepotřebuješ klíče. Útočník je čte stejně snadno jako ty.

A DFC do toho vnáší třetí rovinu. Se svými klíči Flipper DESFire přečte i emuluje, takže patří do výbavy na práci s vlastními kartami vedle Proxmarku a hostových knihoven z druhého dílu. Co nedokáže ani on, je dostat se do karty bez klíče. Přesně v tom je celá pointa série.

Flipper tu kartu nenaklonoval a bez klíčů ji nenaklonuje ani s DFC. Ale přečetl dost na to, aby ukázal, kde by se v nasazení dalo zatlačit, a s DFC zase dost na to, aby se tvoje vlastní karty daly emulovat. Kde končí jedno a začíná druhé, rozhoduje jediná věc: jestli ten klíč máš.

The post Rozbor reálného DESFire dumpu: co Flipper vyčte a co ne first appeared on Hard Wired.

Navazující díl k rozboru klonování DESFiru. V minulém článku padlo, že funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ. Tady je přesně ten postup: logický dump přes Proxmark3 a python-desfire, bezpečné odložení klíčů a obnova struktury i dat na čistý čip. Včetně toho, co tahle záloha není a kdy ti nepomůže.

Rovnou na úvod: je to runbook na zálohu a obnovu karty, ke které máš klíče, protože je tvoje. Žádné klonování cizích karet. Počítej s hodinou práce u první karty, pak už to jde rychleji. Co budeš na konci umět: přečíst celou strukturu DESFiru, uložit ji i s daty do souboru, založit ji znovu na prázdném čipu a nastavit zpět klíče.

Než se do toho pustíš, přečti si sekci o hranicích. Ušetří ti to zklamání, že „záloha“ nefunguje tam, kde fungovat ani nemůže.

Co budeš potřebovat

Hardware: čtečku, která umí ISO 14443-4 a autentizaci k DESFiru, a dvě karty. Zdrojovou DESFire kartu se svými klíči a prázdnou (blank) DESFire kartu stejné nebo vyšší generace a aspoň stejné paměti. Blank znamená kartu ve výrobním stavu, kde jsou všechny klíče na samých nulách; prodávají se jako „DESFire EV1/EV2/EV3 blank“.

Software podle toho, co preferuješ. Buď Proxmark3 s firmwarem Iceman (fork RfidResearchGroup), kde je celá rodina příkazů hf mfdes. Nebo PC/SC čtečku (ACR122U, ACR1252U, Omnikey) a Python s knihovnou python-desfire. Obojí umí jak čtení, tak personalizaci, takže si vyber podle toho, co máš po ruce.

A hlavně klíče. Bez klíčů s právem číst se k obsahu nedostaneš a žádný z dále popsaných kroků nemá smysl. To je vlastnost, ne chyba.

Hranice, které musíš znát předem

Záloha DESFiru má tři tvrdá omezení a je lepší je vědět teď než po hodině práce.

UID se nepřenese. Pravá DESFire karta má sedmibajtové UID zapečené z výroby a nejde přepsat. Prázdná karta má svoje vlastní. Obnovená karta tedy ponese jiné UID než originál, a to nezměníš. Magic DESFire s přepisovatelnou identitou neexistuje, jak padlo v minulém díle.

Systém s diverzifikací klíčů ti obnovenou kartu nevezme. Pokud přístupový systém odvozuje klíče z UID (diverzifikace podle AN10922), čtečka si pro nové UID spočítá jiný klíč, než jaký má tvoje obnovená karta. Autentizace selže. Obejít to jde jedině tak, že vlastníš site klíč celého systému a dopočítáš diverzifikované klíče pro nové UID, což dává smysl jen u systému, který sám provozuješ. Pro cizí přístupový systém tohle není cesta.

Přečteš jen to, na co máš právo. Každý soubor má přístupová práva navázaná na konkrétní klíče. Když tvůj klíč smí číst jen některé soubory, zbytek zůstane skrytý, i když kartu „otevřeš“.

Z toho plyne, k čemu záloha reálně slouží: k archivaci obsahu tvé vlastní karty, k migraci nebo havarijní obnově v systému, který si personalizuješ sám, a k laboratorní práci. Ber ji jako zálohu dat a struktury, ne jako výrobu náhradní přístupové karty do cizí budovy.

Jedna věc k bezpečnosti ještě předtím, než začneš sypat příkazy. Klíče drž mimo dump. Data a struktura můžou do obyčejného souboru, klíče patří do šifrovaného trezoru. Dump s klíči v plaintextu je ta nejhorší možná poznámka pod čarou.

Krok 1: Inventura karty

Napřed si kartu zmapuj, ať víš, co vůbec zálohuješ. Přilož zdrojovou kartu na Proxmark a projdi ji shora dolů.

hf mfdes info
hf mfdes getuid

info vypíše generaci, velikost paměti a volné místo, getuid skutečné UID (u karty se zapnutým Random ID ho vydá až po autentizaci, takže případně přidej secure channel a klíč). Dál si nech vypsat aplikace a soubory:

hf mfdes lsapp --files
hf mfdes lsfiles --aid 123456 -t aes

lsapp --files ukáže všechny aplikace podle jejich tříbajtového AID i s jejich soubory. Pokud jsou klíče nestandardní, autentizuj se jimi; --no-auth zkusí listing bez autentizace, pokud to karta v nastavení dovolí. U každého souboru si zjisti jeho nastavení, protože bez něj kartu věrně neobnovíš:

hf mfdes getfilesettings --aid 123456 --fid 01

Zapiš si typ souboru (Standard, Backup, Value, Linear Record, Cyclic Record), komunikační režim (Plain, MACed, plně šifrovaný), přístupová práva a velikost. Tohle je kostra, kterou budeš na prázdné kartě stavět znovu. U Value souboru si navíc poznamenej dolní a horní limit a aktuální hodnotu, u záznamových souborů počet a velikost záznamů.

Když klíče neznáš celé a chceš je dohledat ze slovníku, pomůže detekce, ale u vlastní karty bys klíče měl mít:

hf mfdes detect --save --dict mfdes_default_keys

Krok 2: Logický dump

Teď vyčteš obsah. Nejjednodušší je dump po aplikaci:

hf mfdes dump --aid 123456

dump projde soubory v aplikaci a vypíše jejich obsah. Pro jednotlivý soubor nebo pro přesnou kontrolu použij read s typem souboru:

hf mfdes read --aid 123456 --fid 01
hf mfdes read --aid 123456 --fid 02 --type record
hf mfdes read --aid 123456 --fid 03 --type value

read bez typu se pokusí typ odhadnout, u záznamových a hodnotových souborů ale radši typ uveď. Výstup si ulož do strukturovaného souboru, ideálně JSON, kde každý soubor nese svoje AID, FID, typ, komunikační režim, práva, velikost a surová data v hexu. Klíče do tohohle souboru nepatří, ty jdou zvlášť.

Takhle vznikne tvoje záloha: popis struktury plus obsah. Co s ní uděláš dál, je obnova na prázdný čip.

Krok 3: Příprava prázdné karty

Prázdnou kartu uveď do známého stavu. Pokud v ní něco je, naformátuj ji, a pamatuj, že k formátu potřebuješ PICC master klíč (u čisté karty samé nuly):

hf mfdes auth -n 0 -t aes -k 00000000000000000000000000000000
hf mfdes formatpicc

Po formátu máš čistý PICC s jednou prázdnou kořenovou aplikací a výchozími klíči. Na téhle základně postavíš kopii struktury.

Krok 4: Obnova struktury a dat

Teď znovu založíš aplikace a soubory podle toho, cos zapsal v kroku 1, a naliješ do nich data z kroku 2. Konkrétní vlajky příkazů createapp a createfile se mezi verzemi firmwaru liší, takže si u své verze vždy ověř přesný tvar přes hf mfdes createapp -h a hf mfdes createfile -h. Orientačně to vypadá takhle:

hf mfdes createapp --aid 123456 --dfname hesse --ks1 0B --ks2 AE
hf mfdes createfile --aid 123456 --fid 01 --amode encrypt --size 000020

--ks1 a --ks2 kódují nastavení klíčů aplikace, tedy počet klíčů, jejich typ a oprávnění; --amode je komunikační režim souboru, --size velikost v bajtech. Hodnoty musí sedět na to, cos vyčetl z originálu, jinak nedostaneš věrnou kopii. Value a záznamové soubory se zakládají vlastními příkazy s limity a počtem záznamů.

Když struktura stojí, zapiš data:

hf mfdes write --aid 123456 --fid 01 -d 0102030405060708...
hf mfdes write --aid 123456 --fid 02 --type record -d 0102030405 --updaterec 0
hf mfdes write --aid 123456 --fid 01 --type data -d 01020304 --commit

U Backup souborů nezapomeň na --commit, bez něj zůstane zápis jen v dočasném bufferu a po odpojení karty se ztratí. U Value souborů se hodnota nenastavuje přímo, ale přes počáteční hodnotu při založení, případně přes credit a debit.

Krok 5: Nastavení klíčů

Tohle je nejchoulostivější krok celé obnovy, protože tady si můžeš kartu zamknout. Dokud jsi pracoval s výchozími nulovými klíči, šlo všechno hladce. Teď je vyměníš za ty původní.

hf mfdes changekey --aid 123456 -n 1 -t aes -k 00000000000000000000000000000000 --newkey 00112233445566778899AABBCCDDEEFF --newver 01

Drž se tří pravidel. Klíče měň odspodu, aplikační klíče před aplikačním master klíčem, a aplikační master klíč před PICC master klíčem; jakmile změníš klíč, kterým ses autentizoval, musíš se autentizovat znovu tím novým. Verzi klíče (--newver) nastav na stejnou hodnotu jako na originálu, jinak ti pozdější autentizace nemusí projít. A než přepíšeš poslední master klíč, dvakrát si ověř, že ho máš zapsaný správně, protože špatně zadaný master klíč znamená kartu, do které se už nedostaneš.

Jemnější nuance: změna klíče číslo 0 (master klíč aplikace) používá jiné krypto než změna ostatních klíčů a může zároveň měnit nastavení aplikace. Proto ji nech až úplně nakonec a odděleně.

Celý cyklus v Pythonu

Kdo nechce ťukat do Proxmarku ručně, zvládne totéž skriptem přes python-desfire na PC/SC čtečce. Knihovna umí čtení i personalizaci, takže pokryje obě fáze. Čtecí část vypadá v jádru takhle:

from desfire import DESFire, PCSCDevice
from smartcard.System import readers

conn = readers()[0].createConnection()
conn.connect()
card = DESFire(PCSCDevice(conn.component))

card.authenticate(0x000000, picc_master_key)   # PICC master
dump = {"uid": card.get_real_uid(), "apps": []}

for aid in card.get_application_ids():
    card.select_application(aid)
    card.authenticate(aid, app_keys[aid])
    app = {"aid": aid, "files": []}
    for fid in card.get_file_ids():
        settings = card.get_file_settings(fid)
        data = card.read_file_data(fid)
        app["files"].append({"fid": fid, "settings": settings, "data": data})
    dump["apps"].append(app)
# dump ulož do JSON; klíče (app_keys) drž mimo tenhle soubor

Obnova na prázdnou kartu je zrcadlový postup. Autentizuješ se výchozím nulovým klíčem, založíš aplikaci, přepneš se do ní, vytvoříš soubory podle uložených nastavení, zapíšeš data a nakonec vyměníš klíče:

blank.authenticate(0x000000, default_key)
blank.create_application(aid, key_settings, num_keys, DESFireKeyType.DF_KEY_AES)
blank.select_application(aid)
blank.authenticate(aid, default_app_key)
blank.create_standard_file(fid, comm_mode, access_rights, file_size)
blank.write_file_data(fid, 0, comm_mode, data)
blank.change_key(key_no, new_key, old_key, key_version)

Přesné signatury metod se mezi verzemi knihovny trochu liší, takže si je ověř v její dokumentaci; logika kroků ale zůstává stejná jako u Proxmarku. Knihovna staví na EV1, pro specifické funkce EV2 a EV3 počítej s tím, že je nemusí pokrývat.

Když něco nefunguje

Nejčastější zádrhel je selhání autentizace. Zkontroluj tři věci: správný typ klíče (-t des, 2tdea, 3tdea nebo aes), správné číslo klíče (-n) a správný secure channel (-s d40, ev1, ev2). Když nesedí byť jen jedno, karta tě odmítne, i když máš klíč správně.

Když čtení projde, ale vrátí nesmysl, nejspíš čteš ve špatném komunikačním režimu. Plně šifrovaný soubor čtený jako Plain vrátí šifrovaný balast, ne data. Ověř si režim z nastavení souboru.

Když se obnovená karta tváří hotově, ale originální systém ji nevezme, vrať se k sekci o hranicích. Buď systém diverzifikuje klíče podle UID, které se změnilo, nebo kontroluje jen UID a tvoje nové mu nesedí. Ani jedno nespravíš na straně karty.

A nejbolestivější případ: autentizace k aplikaci najednou nejde ani tobě. Nejspíš sedí špatná verze klíče nebo ses při změně master klíče přepsal. U vlastní testovací karty z toho ven vede jen formát přes PICC master klíč, pokud ho ještě znáš. Pokud ne, karta je pro tebe ztracená. Proto se master klíče mění jako poslední a s rozmyslem.

Co sis vlastně zazálohoval

Na konci máš dvě věci. Soubor s popisem struktury a daty, který přežije kartu, a schopnost tu kartu znovu postavit na čistém čipu. Co nemáš, je identický klon s původním UID, protože ten na pravém DESFiru neexistuje.

A přesně v tom je ta záloha užitečná i poctivá zároveň. Archivuje obsah, umožní migraci ve tvém vlastním systému a zachrání tě, když fyzická karta doslouží. Jen si pamatuj, čím tenhle postup je a čím není, a nebudeš čekat zázrak tam, kde ho DESFire z principu neslíbil.

The post Jak si zálohovat DESFire kartu a obnovit ji na prázdnou first appeared on Hard Wired.

Proč DESFire nenaklonuješ, i když Mifare Classic jde

Magic karty s přepisovatelným UID udělají kopii obyčejné Mifare Classic za pár minut. DESFire stejný trik nedonese, a není to kvůli tajnému klíči, ale kvůli tomu, jak je karta postavená. Podrobný rozbor: jak DESFire funguje, jak ověřuje, čím se brání útokům a proč celé zabezpečení nakonec stojí a padá se systémem kolem něj.

Máš svůj vlastní klíč k DESFire kartě, chceš si ji zálohovat, a po ruce zrovna není prázdný DESFire. Jenom magic karta. Zní to jako banalita.

Přitom se právě na tomhle scénáři nejlíp ukáže, proč jde jedna karta zkopírovat za pár minut a druhá vůbec. Obkreslit UID je málo. Klon musí zreplikovat celé chování karty vůči čtečce, kryptografii nevyjímaje. Projdeme to od začátku: proč je Mifare Classic odsouzená ke klonování, jak je naproti tomu postavený DESFire, jak probíhá jeho ověřování krok za krokem, čím se brání útokům, kde ho jednou v historii zlomili a proč dnešní průšvihy nemají s čipem nic společného.

Magic karta a otevřený blok 0

U běžné Mifare Classic je blok 0 uzamčený z výroby. Sedí v něm UID, jednobajtový kontrolní součet BCC a výrobní data, a normální čtečka ho nepřepíše. Magic karty tenhle zámek obcházejí. Způsob obcházení dělí jednotlivé generace a není to jen akademické dělení, protože rozhoduje o tom, jestli tě klon prozradí.

Nejstarší „UID karty“ (Gen1a) poslouchají nestandardní backdoor příkazy. Karta se uspí a pak reaguje na dvojici příkazů (0x40 v sedmibitovém rámci jako buzení, následně 0x43), které odemknou čtení i zápis libovolného bloku včetně nultého, a to bez znalosti jakéhokoli klíče. Na Proxmarku to obsluhují příkazy csetblk, cgetblk a spol. Háček je v tom, že ta samá ochota reagovat na backdoor kartu odhalí: čtečka pošle odemykací sekvenci, karta odpoví, a je jasno.

Gen2 (CUID) backdoor nemá. UID se u ní mění přímým zápisem do bloku 0 jako do kteréhokoli jiného, přes standardní wrbl s vynuceným zápisem. Pozor na BCC: když ho spočítáš špatně, část čteček kartu odmítne nebo rovnou zablokuje. CUID má proti Gen1a výhodu, že na backdoor nereaguje, takže ji sken backdoorem neodhalí. Zrádný je ovšem přístup, kdy se čtečka sama pokusí přepsat blok 0, protože běžná Classic to nedovolí a CUID ano, čímž se prozradí. Na to je FUID, který se po prvním zápisu zamkne natvrdo a od té chvíle je k nerozeznání od pravé Classic. UFUID je mezistupeň: chová se jako CUID, dokud mu nepošleš zamykací sekvenci, a teprve pak ztuhne.

Špičkou je dnes Gen4, prodávaný jako „Ultimate Magic Card“. Funguje jako konfigurovatelná platforma, ne jako jedna pevná emulace. Umí se vydávat za libovolnou Classic (1K, 4K, Mini), za Ultralight i za NTAG, se čtyř-, sedmi- i desetibajtovým UID, a svou konfiguraci chrání heslem. Má takzvaný shadow mode, kdy se po přiložení jednou ukáže jako klon a pak jako zapsaná data, čímž umí obejít i otravnější anti-copy kontroly.

Všechny tyhle karty mají společné jedno. Emulují Mifare Classic, Ultralight nebo NTAG, tedy typy postavené na prolomené šifře Crypto1 nebo rovnou bez autentizace. A Classic je rozbitá na několika úrovních zároveň. Crypto1 padla akademicky už kolem roku 2008 (Nohl, Garcia a další), útoky Darkside, Nested a HardNested vytáhnou klíče z běžné karty v řádu sekund až minut. Loni to dostalo ještě jeden rozměr: Philippe Teuwen z Quarkslabu v srpnu 2024 popsal hardwarový backdoor ve Fudan FM11RF08S, tedy v „tvrzené“ variantě s šifrovaným statickým nonce, která měla nested útokům odolávat. Backdoor umožňuje autentizovat se neznámým klíčem společným všem těm kartám a vyčíst z karty během pár minut všechny klíče i bez jediného známého klíče. Nástroje skončily v Proxmarku. Jinými slovy: žádná karta z rodiny Classic není bezpečný nosič identity, ať je magic nebo ne.

DESFire mezi nimi nenajdeš.

A to je jádro věci.

Jak DESFire funguje

DESFire a Classic spojuje leda ta frekvence 13,56 MHz. Jinak to jsou dva odlišné světy, a začíná to už u komunikační vrstvy. Norma ISO/IEC 14443 má čtyři části: fyziku karty, rádiové rozhraní, inicializaci s antikolizí (část -3, kde se řeší ATQA, SAK a výběr UID) a konečně přenosový protokol (část -4). Mifare Classic končí u části -3 a dál jede proprietární Crypto1, žádný standardní protokol nad tím není. Právě proto „čtení“ Classic znamená jen antikolizi plus Crypto1 a právě proto ji magic karta tak snadno napodobí.

DESFire jede až po vrstvu -4. Po antikolizi pošle čtečka příkaz RATS, karta odpoví svým ATS a tím se dohodne half-duplexní protokol T=CL s datovými rychlostmi od 106 až po 848 kbit/s. Nad ním se posílají APDU podle ISO/IEC 7816-4, stejné stavební kameny jako u kontaktních čipových karet a pasů. Nativní příkazy DESFiru se dají balit do ISO 7816 APDU (wrapped mode, s hlavičkou 0x90), takže s kartou umí mluvit i obyčejná PC/SC čtečka přes standardní rozhraní.

Paměť je hierarchická, jako malý šifrovaný souborový systém. Na nejvyšší úrovni je PICC, tedy celá karta, s master klíčem a globální konfigurací. Pod ním sedí aplikace, každá se svým tříbajtovým identifikátorem AID a vlastní sadou až čtrnácti klíčů. V každé aplikaci je až 32 souborů, a souborů je šest druhů: Standard Data pro statická data, Backup Data s transakční ochranou, Value pro čítače a peněženky, Linear Record a Cyclic Record pro záznamové logy a konečně Transaction MAC, který přibyl v EV3 a podepisuje transakce. Každý soubor má vlastní přístupová práva navázaná na konkrétní klíče, takže čtení může vyžadovat jiný klíč než zápis.

Klíče jsou AES-128, nebo starší DES, 2K3DES a 3K3DES, vždy s verzí klíče. Generace jdou za sebou a drží zpětnou kompatibilitu. D40 je původní z roku 2002, dnes dožilá. EV1 přišel v roce 2008 s certifikací Common Criteria EAL4+ a pamětí 2, 4 nebo 8 kB. EV2 z roku 2016 zvedl laťku na EAL5+, zrušil limit počtu aplikací, přidal rolling keys a sadu obranných mechanismů, ke kterým se dostaneme. EV3 z roku 2020 drží EAL5+, přidává Secure Dynamic Messaging i konfigurovatelné ATS a nabízí paměť až 32 kB. V defaultním stavu se EV3 chová jako EV2 nebo EV1, nové funkce se aktivují až při personalizaci, takže integrátor musí vědomě zapnout, co chce používat.

Jak DESFire ověřuje

Tohle je srdce celé věci, a proto se u toho zastavíme podrobně. DESFire používá tříprůchodovou vzájemnou autentizaci (three-pass mutual authentication). Jde o to, že si karta i čtečka navzájem dokážou znalost sdíleného klíče, aniž by klíč nebo jeho prostá podoba kdy proletěly éterem. Zjednodušeně to běží takhle:

1. Čtečka řekne, kterým klíčem se chce autentizovat. Karta vygeneruje náhodné číslo RndB, zašifruje ho klíčem a pošle zpět. Útočník odposlechem dostane jen šifrovaný balast.
2. Čtečka balast dešifruje, získá RndB, vygeneruje vlastní náhodné RndA, číslo RndB cyklicky posune o bajt (RndB') a dvojici RndA a RndB' zašifruje zpět kartě. Posunutím dokazuje, že RndB rozluštila, tedy že klíč zná.
3. Karta dešifruje, zkontroluje, že její RndB' sedí, čímž má ověřenou čtečku. Pak posune RndA, zašifruje a pošle zpět. Čtečka ověří, že sedí její RndA, a tím má ověřenou kartu.

Z úlomků obou náhodných čísel se nakonec na obou stranách odvodí stejný dočasný session klíč, kterým se šifruje zbytek relace. Odposlech celé výměny útočníkovi nedá nic použitelného, protože náhodná čísla jsou pokaždé jiná a klíč sám se nikdy neposílá.

Varianty se liší kryptem a detaily. Legacy autentizace běží na DES a 3DES, ISO varianta přidává delší náhodná čísla, AES autentizace jede na AES-128. EV2 to posunul k příkazu AuthenticateEV2First: při navázání relace se dohodne transakční identifikátor (TI) a čítač příkazů (CmdCtr), vzniknou oddělené session klíče pro šifrování a pro MAC a každý další příkaz nese narůstající čítač. Tím padá možnost přehrát odposlechnutou výměnu i proskládat cizí příkazy do běžící relace.

Nad samotnou autentizací stojí tři komunikační režimy souborů. V režimu Plain jdou data nechráněně. V režimu MACed se ke každé zprávě připojí CMAC, který hlídá integritu a původ. V plně šifrovaném režimu je obsah zašifrovaný a navíc podepsaný CMAC. Který režim platí, se nastavuje u každého souboru zvlášť, takže veřejný údaj může jet Plain a citlivý plně šifrovaně na stejné kartě.

A právě tady je pointa k tvé záloze. Magic karta nemá kryptoengine. Nemá čím RndB vygenerovat, zašifrovat ani posunout. Ve chvíli, kdy čtečka zahájí tříprůchodovou výměnu, karta mlčí, a tvůj legitimní klíč na tom nic nezmění, protože klíč je klíč k DESFiru, ne něco, čím rozchodíš cizí křemík. Zazálohovat umíš data a strukturu (logický dump po autentizaci), ale funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ.

Čím se DESFire brání útokům

Samotná šifra je jen začátek. DESFire od EV1 výš nese vrstvu obran, které cílí přesně na způsoby, jakými se contactless karty reálně napadají.

Proti postranním útokům stojí hardwarové protiopatření certifikované na úrovni EAL4+ u EV1 a EAL5+ u EV2 a EV3. Common Criteria na téhle úrovni znamená, že se čip musel ubránit i neinvazivnímu měření spotřeby a vyzařování, tedy přesně tomu, co zabilo původní D40. EV2 a EV3 k tomu přidávají LRP (Leakage Resilient Primitive), alternativní režim AES navržený tak, aby z každé operace unikalo do spotřeby co nejméně informace. Útok měřením stop je proti LRP mnohem dražší.

Soukromí řeší Random ID spolu s architekturou virtuální karty (VCA). Se zapnutým Random ID hlásí karta při každém přiložení jiné náhodné číslo místo pevného UID, takže ji nelze sledovat napříč čtečkami. Skutečné UID vydá teprve po úspěšné autentizaci. VCA pak umožňuje, aby se správná aplikace vybrala a identifikovala, aniž by se to zvenčí dalo zneužít ke sledování nositele.

Proti relay útokům, kdy útočník natáhne komunikaci mezi vzdálenou kartou a čtečkou přes dvojici zařízení, stojí Proximity Check. Čtečka pošle kartě sérii výzev a měří, za jak dlouho přijde odpověď. Když je zpoždění větší, než dovoluje rychlost světla na krátkou vzdálenost, relay se prozradí a kontrola selže. Má to jeden háček, ke kterému se vrátím: funguje jen tehdy, když ho někdo v systému zapne.

Transaction MAC dává kartě schopnost podepsat každou transakci kryptografickým otiskem, takže se zpětně pozná neoprávněný zápis, třeba dobití peněženky mimo oficiální terminál. Rolling keys, tedy až šestnáct sad klíčů na aplikaci s rychlým přepínáním, zase dovolují vyměnit klíče v celém systému bez výměny karet. Když se jedna sada zkompromituje, přepne se na další, aniž by lidé museli odevzdat kartičky.

Žádná z těch obran ale neběží sama od sebe. To je přesně ten důvod, proč DESFire padá častěji na nasazení než na matematiku.

Jediné reálné prolomení za dvacet let

DESFire padl v historii jednou, a ne přes šifru. Původní MF3ICD40 byl uvnitř asynchronní osmibitový procesor řady 8051 s 3DES jádrem a takzvanou glue logikou, uvedený Philipsem kolem roku 2002, tedy v době, kdy se postranní útoky na čipy ještě nebraly jako běžná hrozba. V říjnu 2011 předvedli David Oswald a Christof Paar z Porúrské univerzity v Bochumi na konferenci CHES, co to znamená. Nešli po matematice 3DES, šli po fyzice čipu: měřili spotřebu a elektromagnetické vyzařování během šifrování (differential power analysis a šablonové útoky). Z řádově 250 tisíc naměřených stop zrekonstruovali tajný klíč, celé asi za sedm hodin, s vybavením za pár tisíc eur.

NXP útok uznal a připomněl, že MF3ICD40 stejně plánoval ukončit ke konci roku 2011. EV1, uvedený už o tři roky dřív, byl proti stejnému postrannímu útoku odolný, a právě proto ta certifikace EAL. Od té doby se žádné veřejné prolomení kryptografie EV1, EV2 ani EV3 neobjevilo. Těžiště se nepřesunulo na kartu.

Přesunulo se na systém kolem ní.

Co musí umět čtečka

Častý omyl zní: „přečetl jsem kartu“ u DESFiru neznamená skoro nic. Vyčíst náhodné UID zvládne každá čtečka podle ISO 14443-3. Dostat se k zabezpečenému obsahu je úplně jiná operace a čtečka k ní potřebuje tři věci.

Zaprvé protokol. Musí umět ISO/IEC 14443-4, tedy projít přes RATS a ATS do režimu T=CL, a posílat APDU, ne jen řešit antikolizi. Zadruhé kryptografii. Buď má bezpečnostní modul SAM, kde leží klíče v hardwaru a který provede autentizaci za čtečku, nebo kryptografii dělá host či backend softwarově a klíče jsou uložené v key store řadiče. NXP k tomu dodává moduly MIFARE SAM AV2 a AV3; AV3 pojme až 128 položek pro symetrické klíče, umí offline diverzifikaci klíčů, chráněný kanál mezi hostem a SAM a v takzvaném X-módu i výkonovou spolupráci s čtecím čipem. Zatřetí samotné klíče, bez nich čtečka k šifrovaným souborům prostě nepustí.

V praxi to vypadá takhle. PC/SC čtečky jako ACR122U, postavená na čipu PN532, zvládají APDU passthrough a autentizaci k DESFiru jde dělat softwarově, například přes knihovny python-desfire, libfreefare, TapLinx nebo projekty AndroidCrypto. Novější ACR1252U a ACR1255U nebo čtečky Omnikey míří na DESFire EV1 a EV2 přímo. Proxmark3 má celou rodinu příkazů hf mfdes. V přístupových systémech se klíče často drží v řadiči a čtečka běží v transparentním režimu, typicky přes OSDP. Co nikde nekoupíš, je magic DESFire. Prázdnou kartu k personalizaci ano, ale „otevřenou“ DESFire s přepisovatelnou identitou ne.

A ještě jedna věc, protože se na ní láme většina reálného zabezpečení. Pokud přístupový systém DESFire kartu jen přečte podle UID a dál se spokojí, že se karta ozvala, celá kryptografie je k ničemu. Takový systém pak podvede i obyčejná sedmibajtová magic karta se stejným UID. DESFire reader a UID čtečka jsou dvě různé věci, i když se navenek tváří stejně.

Kde DESFire přesto padá

Neprůstřelná karta ještě není neprůstřelný systém. Většina reálných průšvihů s DESFirem se šifrou vůbec nesouvisí.

Nejčastější je výchozí klíč. Čerstvá DESFire aplikace má všechny klíče nastavené na samé nuly. Když je integrátor nezmění, útočník se autentizuje výchozím klíčem a má vystaráno, přečte i přepíše obsah. Druhá klasika je chybějící diverzifikace klíčů. NXP v aplikační nótě AN10922 popisuje, jak z jednoho site klíče odvodit jedinečný klíč pro každou kartu, pomocí AES-CMAC nad UID, AID a číslem klíče. Když to systém neudělá a sype do všech karet stejný klíč, stačí vytáhnout klíč z jediné karty nebo z jediné čtečky a padne celá instalace naráz. A přesně tím směrem dnešní útoky jdou, po extrakci klíčů ze čtečky nebo po kompromitaci site klíče, ne po prolomení čipu.

Nad tím vším visí lidský faktor nasazení. Proximity Check proti relay útokům je skvělá obrana, pokud ji někdo zapne. Random ID chrání soukromí, pokud se aktivuje. Rolling keys umožní rotaci, pokud má systém proceduru, jak ji provést. NXP to sepsal do systémové nóty AN10969, kde kromě diverzifikace doporučuje i detekci podvodných karet, černé a bílé listiny a stínové účty, tedy obranu, která nestojí na kartě, ale na backendu. Školní příklad z praxe: londýnská Oyster přešla na DESFire, zatímco řada jiných dopravních karet zůstala na prolomené Classic, a rozdíl v bezpečnosti nedělá jen čip, ale celý návrh systému.

Bezpečnost DESFire nebydlí v kartě. Bydlí v tom, jak je nasazená.

A proto ti magic karta zálohu neudělá, ne proto, že by byl klíč tak tajný, ale proto, že na magic kartě není co s tím klíčem provést.

The post Proč DESFire nenaklonuješ, i když Mifare Classic jde first appeared on Hard Wired.

V 1:31 moskevského času, v noci na 8. října, se na stavové stránce Yandex Cloudu objevila nenápadná zpráva. V zóně dostupnosti ru-central1-b vypadlo napájení a zákazníci mají podle možností přesunout zátěž do jiných zón, informoval server Lenta.ru. Rjazaňský gubernátor Pavel Malkov o pár hodin později mluvil jen o tom, že v Sasovském okrese chytla střecha „jednoho z podniků", píše Kommersant.

Tím podnikem bylo datacentrum Yandexu. A „jiné zóny" vydržely přesně tři dny.

Do 11. října zasáhly ukrajinské drony tři z velkých datacenter firmy: Sasovo v noci ze 7. na 8. října, Kalugu ráno 9. října a Vladimir v noci na 11. října. Yandex Cloud pak zákazníkům oznámil, že běží v nouzovém režimu, a doporučil jim, ať sáhnou po vlastních plánech obnovy po havárii, uvádí Help Net Security. Válečnou stránku věci nechám jiným. Mě zajímá, co se stane s cloudem, když selže fyzická vrstva, kterou v architektonických diagramech kreslíme jako obláček.

Co stálo v Sasovu

Datacentrum v Sasovu běží od roku 2014 v části bývalého závodu Sasta, píše Meduza. Nebyla to žádná okrajová lokalita. Stály tu dva ze tří superpočítačů, na kterých Yandex trénuje neuronové sítě: Červoněnkis s nominálním výkonem 29,42 PFLOPS a Ljapunov s 20,03 PFLOPS. Třetí stroj, Galuškin (20,64 PFLOPS), stojí ve Vladimiru, uvádí server Militarnyi s odvoláním na ruský web T-Invariant.

Podle T-Invariant jsou teď mimo provoz všechny tři. Slovo „zničené" bych zatím nepoužívala. Yandex sám řekl stanici CNBC, že nedokáže potvrdit, jestli jde vybavení v Sasovu obnovit. Satelitní snímky z 12. října ukazují poškozenou zhruba třetinu budovy, píše ukrajinský 24tv. (Moscow Times mimochodem tvrdí, že Galuškina vyřadil už úder na Kalugu. Ostatní zdroje ho drží ve Vladimiru, takže tady se reportéři rozcházejí.)

Zajímavý detail přidal server CNews: datacentrum v Sasovu napájejí dvě nezávislé linky 110 kV. Proti výpadku sítě je to slušná redundance. Proti dronu na střeše žádná.

Zóna dostupnosti není region

Tady je jádro celé věci pro každého, kdo kdy kreslil architekturu v cloudu.

Zóny dostupnosti (availability zones) jsou oddělená datacentra s vlastním napájením a chlazením. Vymyslely se proto, aby výpadek jedné budovy nepoložil celou službu. Kdo nasadí aplikaci do dvou nebo tří zón, udělal přesně to, co radí každá certifikace. Úder na Vladimir ale podle Moscow Times shodil zónu ru-central1-a, tedy druhou ze zón Yandex Cloudu během tří dnů. Zbytek infrastruktury firma označila za „nestabilní".

Model zón dostupnosti počítá s nekorelovanými poruchami: blesk, porucha transformátoru, bagr přes optiku. Útočník, který si vybírá cíle podle mapy, poruchy koreluje schválně. Jeden ze zdrojů Meduzy to popsal až bolestně prakticky: v Rjazaňské, Kalužské ani Vladimirské oblasti se nečekají zemětřesení, takže nikoho nenapadlo platit fyzickou ochranu budov.

Ruský ministr pro digitální rozvoj označil útok za bezprecedentní a jeho úřad teď s ministerstvem obrany řeší, jak datacentra krýt, píše rádio Echo. Protivzdušná obrana jako součást SLA. To v žádném ceníku cloudu zatím nenajdete.

Kdo všechno visel na Yandexu

Výpadek vyhledávače nebo hudební služby by byl nepříjemný, ale přežitelný. Horší je, kolik cizích webů má Yandex zašitý uvnitř. Vypadly vestavěné služby jako Yandex ID pro přihlašování, Metrika a AppMetrica, reklamní síť, mapy na cizích webech, SmartCaptcha, Yandex Pay, odložené platby Split a firemní pošta Yandex 360, vyjmenovává Echo.

Po úderu na Sasovo měly problémy weby Ruských drah, operátora MegaFon a několika médií, uvádí ukrajinský server ua.news. Meduza přidává aplikaci řetězce Vkusno i točka, letiště Pulkovo a služby pro kontinuální monitorování glukózy u lidí s diabetem.

Ten poslední příklad stojí za chvilku ticha. Senzor na paži funguje dál, jen data nemají kam odtéct.

Yandex Pro mezitím radil taxikářům, ať jezdí podle Google Maps nebo Waze, a firma omezila stahování z Yandex Disku, aby ušetřila kapacitu pro ostatní služby, píše Meduza. Řízené vypínání méně důležitých funkcí (load shedding) je přesně to, co se v takové chvíli dělat má. Jen to obvykle nevidíte tak naplno.

Data doma, služba jinde

Nejlíp mi celou situaci shrnul případ Kazachstánu. Yandex tvrdí, že osobní data kazašských uživatelů zůstala uložená v Kazachstánu. Řidiči přesto nedostávali zakázky a cestující si nemohli objednat taxi, upozorňuje The Times of Central Asia. Problémy hlásili i uživatelé v Arménii, Bělorusku, Gruzii a Srbsku, uvádí Meduza.

Lokalizace dat a lokalizace služby jsou dvě různé věci. Databáze může ležet v Almaty, ale pokud řídicí vrstva (control plane) běží v Rjazaňské oblasti, máte v Almaty jen velmi bezpečně uložený archiv.

Kam utéct, když nesmíte za hranice

Ukrajina v únoru 2022, těsně před invazí, narychlo změnila zákon a státní registry přestěhovala do zahraničních cloudů. Rusko tuhle cestu zavřelo samo sobě. Zákon o lokalizaci osobních dat platí od roku 2015 a data ruských občanů musí zůstat na ruských serverech. Yandex se proto domluvil na urychleném přesunu klientských dat a služeb k domácí konkurenci: VK Cloud, Selectel a K2 Cloud, píše Meduza. Záložní plán tedy existuje, jen vede do datacenter, která leží ve stejném dosahu dronů.

Druhý problém je železo. Výměna poškozeného vybavení má podle Meduzy trvat až půl roku. Tom's Hardware upozorňuje, že část komponent už pod sankcemi nemusí jít vůbec sehnat a Yandex může být pro trénink dalších modelů odkázaný na čínskou infrastrukturu. A financovat to bude za klíčovou sazbu centrální banky 14 %, kterou regulátor v září podržel, uvádí server retail.ru.

Sberbank: další na řadě

V noci na 14. října zasáhly drony datacentrum Sberbanku v Balakovu v Saratovské oblasti, víc než 650 km od ukrajinských hranic. Komplex byl stále ve výstavbě, část kapacit už ale běžela. Plánovaný příkon je 82 MW, kapacita až 3 000 racků a přes 120 000 serverů a datacentrum mělo hostit i státní platformu GosTech, píše web www1.ru. Sberbank tvrdí, že všechny služby fungují normálně. Uživatelé přesto hlásili nefunkční bankovnictví a platby, informuje Meduza, i když souvislost s útokem nikdo nepotvrdil.

Pro kontext: tohle všechno je odveta. Od 23. září ruské útoky poškodily nebo zničily datacentra nejméně osmi ukrajinských firem, mezi nimi MiroHost, DataGroup a CityHost, uvádí Tom's Hardware.

A co ty boty?

Na sítích se rychle rozšířila teorie, že po úderech utichly ruské trollí farmy. Opírá se o graf z Cloudflare Radar, který ukazuje propad automatizovaného provozu ze sítě Yandexu (AS13238). Ilja Lozovskij z OCCRP ale upozornil, že graf měří automatizovaný webový provoz, třeba roboty vyhledávače, a ne boty na sociálních sítích, píše Help Net Security. Když vám spadnou datacentra, crawler vyhledávače přestane crawlovat. To je fyzika, ne kontrarozvědka.

Yandex mezitím na vlastních mapách rozmazal všechna svá cloudová datacentra, píše UNITED24 s odvoláním na web Verstka. Ochrana by fungovala skvěle, kdyby drony navigovaly podle Yandex Map.

Zdroje

• Lenta.ru: https://lenta.ru/news/2026/10/08/long-yandeks-soobschil-o-masshtabnom-sboe-v-rabote-servisov-iz-za-ataki-vsu-chto-izvestno/
• Kommersant: https://www.kommersant.ru/doc/9008807
• Help Net Security: https://www.helpnetsecurity.com/2026/10/13/ukraine-drone-strikes-yandex-data-centers/
• Meduza (EN, 8. 10.): https://meduza.io/en/feature/2026/10/08/ukraine-strikes-yandex-data-center-housing-two-of-the-company-s-supercomputers
• Meduza (EN, 15. 10.): https://meduza.io/en/feature/2026/10/15/ukrainian-strikes-on-yandex-s-data-centers-could-set-back-russia-s-ai-development-by-years-never-a-rival-to-the-u-s-or-china-in-ai-russia-may-now-fall-behind-kazakhstan-too
• Meduza (RU, 12. 10.): https://meduza.io/feature/2026/10/12/kak-yandeks-spravlyaetsya-s-posledstviyami-udarov-ukrainy-po-svoim-data-tsentram
• Meduza (Sberbank): https://meduza.io/en/news/2026/10/14/users-start-reporting-outages-in-sberbank-services-after-ukrainian-drone-attack-on-company-s-data-center
• Militarnyi: https://militarnyi.com/en/news/drone-strikes-may-have-knocked-out-all-three-yandex-supercomputers/
• CNBC: https://www.cnbc.com/2026/10/08/russia-yandex-ukraine-drone-strike-data-center.html
• 24tv.ua (satelitní snímky): https://24tv.ua/ru/povrezhdenija-data-centra-jandeksa-v-sasovo-sputnikovye-snimki_n3161081
• The Moscow Times: https://themoscowtimes.com/2026/10/15/from-wildberries-to-yandex-ukraine-is-turning-russian-business-giants-dominance-into-a-liability-a93976
• CNews: https://www.cnews.ru/news/top/2026-10-08_sklady_nadoelibombim_data-tsentry
• Echo: https://echofm.online/stories/vsu-atakovali-tri-data-czentra-yandeksa-za-nedelyu-chto-proishodit-s-servisami-kompanii-i-svyazannymi-s-nej-resursami
• ua.news: https://ua.news/en/war-vs-rf/tri-data-tsentri-za-tizhden-iak-udari-po-iandeksu-ogolili-zalezhnist-rosiyi-vid-tsifrovoyi-infrastrukturi
• The Times of Central Asia: https://timesca.com/drone-strikes-on-russian-data-centers-disrupt-yandex-services-across-central-asia/
• Tom's Hardware: https://www.tomshardware.com/tech-industry/data-centers/ukrainian-drones-hit-russias-yandex-data-centers-housing-two-top-supercomputers-major-outage-follows-retaliatory-strike
• retail.ru (klíčová sazba): https://www.retail.ru/news/tsb-rf-sokhranil-klyuchevuyu-stavku-na-urovne-14-godovykh-12-sentyabrya-2026-282051/
• www1.ru (Sberbank Balakovo): https://www1.ru/en/news/2026/10/14/bespilotniki-atakovali-krupneisii-data-centr-sberbanka-v-rossii-stoimostiu-v-desiatki-milliardov-rublei.html
• Ukrainska Pravda: https://www.pravda.com.ua/eng/news/2026/10/14/8057949/
• UNITED24 Media: https://united24media.com/war-in-ukraine/ukraine-struck-yandex-data-centers-russian-bots-went-silent-now-questions-are-mounting-23339
• Inspirace: InfoTalks s Jiřím Justem, info.cz: https://www.info.cz/podcasty/infotalks/utoky-na-ruska-datacentra-yandex-jiri-just

The post Tři datacentra za čtyři dny: co drony udělaly s Yandex Cloudem first appeared on Hard Wired.

Autor vystupující jako Dumpling lab nahrál 13. srpna na GitHub podklady ke svému toolchangeru YUDX pro 3D tiskárny. Balík obsahuje deset STL souborů, tři sestavy ve formátu STEP, čtyři G-kód makra, 42stránkový montážní návod a kusovník v Excelu. Licence je GPL-3.0, repozitář za týden nasbíral 205 hvězd a 39 forků.

Projekt sám o sobě novinka není. Poprvé ho autor ukázal ve videu z 2. prosince 2025 s popiskem, že je vysokoškolák a inspiroval se toolchangerem INDX od Bondtechu. Mezi tou ukázkou a otevřením zdrojáků uplynulo osm měsíců. Prázdný repozitář vznikl 5. srpna, soubory do něj přibyly ve třech commitech 13. srpna, poslední z nich přidal kusovník.

Zveřejněné podklady jsou zajímavější, než by se z ohlasů zdálo – a taky děravější. Prošel jsem repozitář soubor po souboru a porovnal ho s kusovníkem i s montážním návodem. Následující text popisuje, co v balíku je, co v něm není a proč se první lidé, kteří stavbu zkusili, zastavili hned na začátku.

Retrakce místo serva

Mechanika YUDX stojí na jednom nápadu, který autor v návodu nazývá metamorfní soukolí. Odjištění nástrojové hlavy nepohání servo ani druhý motor. Obstará ho krokový motor extruderu, tedy stejný, který podává filament.

Uvnitř podávacího kolečka sedí jednosměrné ložisko. Při běžné práci se protáčí a extruder se chová normálně. Když motor zatáhne filament hlouběji, ložisko se zablokuje, pastorek zabere do ozubeného hřebenu vyrobeného drátovým řezáním a celé soukolí se vykývne do strany proti pružině. Podávací kolečka se rozevřou a hlava se uvolní. Chiptron.cz, který o projektu psal 15. srpna, uvádí práh kolem 3 mm retrakce; v makru tfree0.g autor zatahuje ve dvou krocích celkem 7 mm, takže reálná hodnota bude záležet na kalibraci.

Celé odjištění nemá vlastní pohon ani řídicí signál.

Nástrojová hlava obsahuje jen hotend a chlazení. Podávání zůstává na tiskárně a je společné pro všechny hlavy. Tím se YUDX liší od Prusa XL i Snapmakeru U1, kde má každá hlava vlastní motor. Hlavu drží 32 neodymových magnetů 15 × 5 × 3 mm a 32 ocelových kuliček o průměru 4 mm. Návod věnuje celou stranu tomu, jak magnety lepit: úhlopříčně stejné póly, aby se siločáry uzavřely a magnety samy nevypadávaly.

Tři chybějící STL

Kusovník uvádí třináct tištěných dílů. Ve složce STLs jich je deset.

Chybí přesně ty tři, které tvoří extruder: outer_shell_of_extruder, gear_container_plastic_part a rack_below_part.

Kdo je chce vytisknout, musí si je vytáhnout ze sestavy YUDX Extruder.STEP. Jenže ta byla exportována ze SolidWorksu 2022 ve schématu AP214 a všechny entity v ní nesou označení NONE. Názvy dílů se do exportu nepřenesly, takže se v CAD hledají ručně podle tvaru.

Podobně skromný je software. Ve složce Gcode leží čtyři soubory. Dva z nich, offest.g a disoffest.g, obsahují osm řádků s nulovými offsety pro nástroje P0 až P7, tedy prázdnou šablonu, kterou si každý musí naměřit sám. Zbylá dvě makra, tfree0.g a tpost0.g, řeší výhradně nástroj číslo nula a nesou komentář, že pro ostatní nástroje si má uživatel upravit hodnotu X. Definice nástrojů pro RepRapFirmware, soubor config.g ani schéma zapojení v repozitáři nejsou. Návod přitom na straně 30 radí dokončit kabeláž a udělat testovací tisk, aniž by kabeláž kdekoli popisoval.

Montážní návod vznikl v PowerPointu 2021 a je to v podstatě fotoseriál se stručnými popisky. Místy je poctivý až odzbrojujícím způsobem: u instalace pružiny autor přiznává, že pružina není v SolidWorksu namodelovaná a na obrázku ji dokreslil ručně. Strana 39 nese jen číslo kroku a jinak je prázdná.

Na německém fóru drucktipps3d.de shrnul uživatel lixtop 17. srpna svůj dojem tak, že stavba zatím možná není. Informace se prý musí skládat z kusovníku, návodu, STEP souborů a videa dohromady, chybí závity a není jasná délka hřídele motoru ani specifikace malého ozubeného kola. Sedí to s tím, co v repozitáři vidím.

Zakázkové díly za 375 dolarů, hotendy zvlášť

Nejtvrdší překážkou nejsou chybějící soubory, ale kusovník. YUDX potřebuje tři typy vlastních ozubených kol, šest CNC obráběných dílů, hřeben z drátové řezačky a jednosměrné ložisko označené jako zakázkové. Když sečtu ceny, které autor u těchto položek uvádí, vyjde 375 dolarů, zhruba 7 900 korun. A to je jen extruder, bez hotendů.

Hotendy jsou v kusovníku uvedené jako osmikusová položka značky Bambu Lab za 160 dolarů. Stojánků pro hlavy je ale sedm, stejně jako čističů trysky a vzduchových vodítek. Mikrospínačů typu dveřní zámek je šestnáct. Souhlas mezi počty položek nesedí a bez videa nebo dotazu na Discordu se z kusovníku skutečný počet hlav neodvodí.

Zvláštní kapitolou je poznámka, kterou autor umístil do hlavičky kusovníku: odkazy na Amazon prý našel Claude Code a mohou být chybné, zpětná vazba vítána. Namátková kontrola mu dává za pravdu, odkaz u magnetů vede na jiný rozměr, než jaký je uvedený v položce i v návodu. Ta otevřenost je sympatická, praktickou použitelnost kusovníku ovšem sráží. Autor tamtéž píše, že v příštích měsících by mohla vyjít hotová stavebnice extruderu.

Sekunda, kterou nikdo neměřil

Video, kterým autor zdrojáky ohlásil, se jmenuje „What's Inside the YUDX Extruder? 1S Tool Change System, Now Open Source“. Jedna sekunda na výměnu je autorovo číslo a nezávisle ho zatím nikdo nepotvrdil.

Srovnání je k dispozici jen orientační. Snapmaker U1 slibuje pět sekund, uživatelská měření zveřejněná na fóru Bambu Labu ale mluví o šesti až třinácti sekundách podle toho, jak často se hlavy střídají a jestli se stihnou nahřát. Právě nahřívání řeší YUDX přímo v makrech: tfree0.g končí příkazem G10 R205, který odloženou hlavu drží na 205 °C, a tpost0.g ji před nasazením zvedá na 220 °C. Zaparkovaná tryska nechladne a start po výměně nebrzdí ohřev.

Chiptron dále píše, že autor zmiňuje test dvou tisíc výměn v řadě, test na stringování a tisk válce. Ta čísla pocházejí z autorovy prezentace, ne z nezávislého měření.

Patent visí ve vzduchu

Systém INDX, kterým se autor otevřeně inspiroval, vyvinul a patentoval Bondtech; ochrannou známku INDX si firma přihlásila v dubnu 2025. Na Redditu se ve vlákně k YUDX objevila úvaha o možném porušení patentu. Přímo do vlákna jsem se nedostal, odkazuje na něj zmíněné německé fórum.

Protiargument, který tam padl, zní, že Prusa sama vytvořila podmínky pro napodobení. V červenci 2026 vyšlo najevo, že v propagačním modelu INDX pro tisk na stůl zůstala použitelná CAD geometrie pod licencí CC BY-SA 4.0, a maker s přezdívkou NoDoubt424 z ní sestavu rekonstruoval. Prusa soubor později stáhla, jenže tuhle licenci odvolat nelze.

U YUDX ten argument nesedí. Autorovo první video je z prosince 2025, sedm měsíců před únikem, a jeho mechanika nepoužívá indukční ohřev ani bezdrátovou komunikaci, na kterých INDX stojí.

Shoda je na úrovni konceptu, ne řešení.

Licence GPL-3.0 navíc řeší autorská práva ke zveřejněným souborům, patentovou otázku za stavitele nezodpoví.

Co je od 13. srpna venku, není návod ke stavbě, ale doklad, že mechanika existuje a funguje. Mezi tím a stavitelným projektem stojí tři chybějící STL, konfigurace RepRapFirmwaru a někdo, kdo vyrobí ozubená kola.

Zdroje: github.com/dumplinglab/YUDX-tool-changer — stav k 21. srpnu 2026, včetně montážního návodu, kusovníku a G-kód maker; chiptron.cz; forum.drucktipps3d.de; 3druck.com; Tom's Hardware; Notebookcheck; fórum Bambu Labu.

The post Toolchanger YUDX je na GitHubu. Postavit ho zatím nejde first appeared on Hard Wired.

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.

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.