Przejdź do głównej zawartości

Chameleon Ultra na testach: twarde ograniczenia i pytanie o sens dalszego rozwoju projektu

· 8 min aby przeczytać
Przemysław Majdak
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Chameleon Ultra bywa opisywany jako „scyzoryk szwajcarski" do RFID/NFC — urządzenie, które w kieszeni ma zastąpić Proxmark3 i pół arsenału pentestera fizycznego. Po serii testów na realnych kartach i tagach różnych technologii ten obraz mocno się kruszy: część z reklamowanych możliwości działa tylko na papierze, a branża kart zbliżeniowych migruje dokładnie w stronę zabezpieczeń, których to urządzenie nie ma szans przełamać.

Teza artykułu​

Chameleon Ultra jest realnie użyteczny w bardzo konkretnej, kurczącej się niszy: kartach i tagach bez właściwego uwierzytelnienia albo z fabrycznymi/domyślnymi kluczami. Poza tą niszą — czyli tam, gdzie faktycznie liczyłby się jako narzędzie pracy w profesjonalnym audycie bezpieczeństwa fizycznego — jego skuteczność jest w najlepszym razie przypadkowa, a w najgorszym: żadna. Poniżej opisuję, na czym to twierdzenie się opiera, i dlaczego uważam, że ta luka będzie się tylko powiększać.

Co faktycznie działa (i trzeba to uczciwie przyznać)​

Na kartach MIFARE Classic 1K z fabrycznymi kluczami transportowymi (FFFFFFFFFFFF na wszystkich sektorach) urządzenie sprawdza się świetnie. Komenda autopwn w kilka sekund wykrywa podatność, łamie komplet kluczy i zapisuje pełny dump karty gotowy do emulacji. Podobnie sprawa wygląda z tagami EM410X (LF, 125 kHz) — tam żadnego uwierzytelnienia w ogóle nie ma, więc odczyt i klonowanie to formalność, oraz z niezabezpieczonymi NTAG/Ultralight.

Problem w tym, że to wszystko są technologie, których producenci już dawno przestali polecać do nowych wdrożeń. Crypto1 (szyfr MIFARE Classic) został złamany kryptoanalitycznie w 2008 roku, co jest jednym z powodów, dla których NXP od lat kieruje nowe projekty w stronę DESFire (rfid-pro.com). Innymi słowy: Chameleon Ultra jest bardzo dobry w łamaniu zamków, które producent zamków też uważa za złamane od siedemnastu lat.

Gdzie kończy się użyteczność — testy na realnych technologiach​

Poniższe obserwacje pochodzą z bezpośrednich testów na sprzęcie, na kartach/tagach opisanych wyłącznie przez typ technologii (nie źródło czy właściciela).

1. Karta EMV (kontaktless, chip zgodny z DESFire/MIFARE Plus wg SAK/ATS)​

Dedykowana komenda emv scan poprawnie przechodzi PPSE i SELECT AID — rozpoznaje markę aplikacji płatniczej. Dalej jednak odpowiedź FCI, deklarowana na ok. 106 bajtów, jest ucinana po ~45 bajtach. Przyczyna jest udokumentowana wprost w kodzie firmware: czytnik RC522 ma sztywny 64-bajtowy bufor FIFO, a łańcuchowanie ISO14443-4 przy pierwszym błędzie w sekwencji po cichu akceptuje niepełne dane zamiast zgłosić błąd. Nawet ręczne sterowanie ramkami APDU z obsługą żądania czasu S(WTX) nie pomaga — okno czasowe (Frame Waiting Time), w którym karta oczekuje odpowiedzi, jest krótsze niż realny round-trip przez USB do hosta. PAN i data ważności nigdy nie zostały odczytane. To nie jest brak dopracowania firmware — to fizyczne ograniczenie zastosowanego czytnika RFID, którego żadna aktualizacja nie zmieni.

2. MIFARE Classic z kluczami innymi niż domyślne — czy „łamanie" to faktycznie łamanie?​

Żeby sprawdzić realną siłę kryptoanalityczną (nie tylko sprawdzanie słownika), na tej samej rodzinie kart uruchomiono ręcznie trzy klasyczne ataki: nested, darkside i hardnested.

  • darkside zakończył się natychmiastowym błędem protokołu komunikacyjnego.
  • nested w sześciu powtórzeniach nie zwrócił ani jednego zweryfikowanego klucza.
  • hardnested przeszedł pełne 3 próby po 200 rund akwizycji (łącznie ok. 37 minut) i za każdym razem złapał tylko 1 z 256 możliwych unikalnych wartości MSB nonce'a — atak wymaga dużej różnorodności nonce'ów, więc przy takiej próbce nie miał w ogóle szansy zebrać potrzebnych danych.

Wniosek jest nieprzyjemny dla marketingu tego typu urządzeń: to, co jest reklamowane jako „łamanie MIFARE Classic", w praktyce sprawdza się dobrze tylko jako automatyczne sprawdzenie słownika domyślnych kluczy. Prawdziwa kryptoanaliza (nested/hardnested/darkside), potrzebna wobec karty z niestandardowym, dobrze dobranym kluczem, w testach zawiodła na każdym z trzech frontów.

3. Proprietarne technologie HF/LF — całkowita ślepota​

Napotkany w testach tag HF, niewykrywalny standardowymi metodami (najprawdopodobniej z rodziny Legic Prime/Advant — popularnej w europejskich systemach kontroli dostępu i rejestracji czasu pracy), dał zero odpowiedzi na polu 13,56 MHz w trybie ISO14443-A, zero na sześciu przetestowanych protokołach LF, i — co istotne — zero również dla telefonu z pełnym stosem NFC (ISO14443A/B, FeliCa, ISO15693). To potwierdza, że chodzi o zupełnie inną warstwę fizyczną niż cokolwiek, co Chameleon Ultra (czy jakikolwiek czytnik zgodny z ISO14443/15693) w ogóle jest w stanie zaadresować. Podobnie proprietarne rozwiązania typu HID iCLASS/PicoPass pozostają poza zasięgiem — złamanie ich wymaga specjalistycznego sprzętu i wiedzy wykraczającej poza generyczny czytnik RFID.

4. Kanał towarzyszący (BLE) — niestabilny nie tylko na papierze​

Kontrola urządzenia z poziomu aplikacji mobilnej przez Bluetooth Low Energy okazała się w testach niewidoczna/niestabilna mimo prawidłowej konfiguracji (parowanie włączone, ustawienia trwale zapisane, bondy wyczyszczone). To nie jest odosobniona obserwacja — oficjalna dokumentacja projektu wprost wymienia problemy z synchronizacją parowania BLE jako znany temat w sekcji troubleshooting (RRG troubleshooting). Niezależny blog praktyka fizycznego pentestingu opisuje podobne doświadczenia z niezawodnością samego przycisku klonowania w terenie: „wouldn't rely on it in the field when you may not get a second try" (Covert Access Team).

5. Regresja firmware — jedna aktualizacja i urządzenie jest martwe​

Podczas testów wersji v2.2.0 — najnowszej stabilnej gałęzi firmware w momencie pisania tego tekstu — trafiono na kod wprowadzający bezterminową pętlę oczekiwania na start wewnętrznego zegara — wykonywaną jeszcze przed uzbrojeniem watchdoga. Efekt: całkowite zawieszenie urządzenia, zero reakcji na USB i fizyczne przyciski, bez żadnego mechanizmu odzyskiwania poza pełnym resetem sprzętowym przez DFU. Przyczynę udało się ustalić dopiero przez ręczną analizę różnic w kodzie źródłowym między wersjami (74 zmienione pliki) i testy A/B bezpośrednio na sprzęcie — żadnego oficjalnego ostrzeżenia ani advisory nie było. Dla narzędzia, które miałoby być używane w jednorazowej, ograniczonej czasowo sytuacji terenowej, to poważny sygnał: pojedyncza aktualizacja firmware potrafi z dnia na dzień zamienić sprawne urządzenie w bezużyteczną cegłę, bez ostrzeżenia i bez łatwej ścieżki powrotu dla kogoś, kto nie jest gotów samodzielnie grzebać w kodzie źródłowym.

Dlaczego ta luka będzie rosła, nie maleć​

Powyższe ograniczenia nie są przypadkowym zbiegiem okoliczności — pokrywają się z kierunkiem, w którym cała branża kart zbliżeniowych już idzie:

  • MIFARE DESFire EV3 — obecny standard NXP dla nowych wdrożeń kontroli dostępu, transportu publicznego i sektora rządowego — oferuje wzajemne uwierzytelnienie, bezpieczną transmisję i certyfikację Common Criteria EAL5+ (HID Global, NXP).
  • Klucze dywersyfikowane (unikalne dla każdej karty, wyprowadzone z jej numeru seryjnego) stają się standardem, a nie wyjątkiem — nawet gdyby jeden egzemplarz karty padł ofiarą ataku, reszta wdrożenia pozostaje bezpieczna.
  • EMV od dawna opiera się na kryptogramie generowanym osobno dla każdej transakcji (SDA/DDA/CDA) — sam odczyt PAN-u i daty ważności (gdyby się udał) nie pozwala sklonować karty do terminala, więc nawet teoretyczne ominięcie limitu FIFO RC522 nie dawałoby realnego ataku klonowania.

Krótko mówiąc: dokładnie ta klasa zabezpieczeń, której Chameleon Ultra strukturalnie nie jest w stanie przełamać (mutual authentication, klucze dywersyfikowane, kryptogram per-transakcja, proprietarne warstwy fizyczne), jest tą, w którą branża świadomie inwestuje od lat, a proces ten w 2026 roku jedynie przyspiesza.

Przyszłość projektu — pytania bez dobrej odpowiedzi​

Projekt RfidResearchGroup jest aktywnie rozwijany — kolejne wersje firmware regularnie dodają nowe protokoły LF, komendy EMV, obsługę Flipper Zero .nfc. To dobra wiadomość dla community, ale rodzi realne pytania o sens dalszej inwestycji w ten kierunek:

  1. Czy sprzęt w ogóle na to pozwala? Limit 64-bajtowego FIFO w RC522 to nie błąd firmware do naprawienia w kolejnym patchu — to fizyczne ograniczenie zastosowanego chipu czytnika. Pełna obsługa DESFire EV2/EV3 czy bardziej złożonych struktur APDU może wymagać zmiany sprzętu, a nie kolejnej wersji oprogramowania.
  2. Czy tempo rozwoju nie odbywa się kosztem stabilności? Poważna regresja prowadząca do całkowitego zawieszenia urządzenia, opisana wyżej, trafiła do głównej, „stabilnej" gałęzi wydania bez wykrycia w testach producenta. Dla narzędzia mającego wspierać jednorazowe, nieodwracalne decyzje w terenie (np. czy dany fizyczny dostęp jest podatny) to nie jest kosmetyczny detal.
  3. Czy warto gonić technologie, których i tak nie da się złamać generycznym czytnikiem? Legic, iCLASS w twardszych konfiguracjach, DESFire z prawidłowo wdrożonymi kluczami dywersyfikowanymi — żadna z tych technologii nie padnie od dodania kolejnej komendy CLI. Ich złamanie wymaga albo materiału kryptograficznego wydawcy, albo zupełnie innej klasy sprzętu badawczego.

Realistyczny scenariusz na najbliższe lata to taki, w którym Chameleon Ultra pozostaje świetnym narzędziem edukacyjnym i demonstracyjnym — pokazującym, jak łatwo (wciąż) sklonować przestarzałe wdrożenia — ale traci sens jako uniwersalne narzędzie profesjonalnego audytu bezpieczeństwa fizycznego, w miarę jak liczba realnych wdrożeń podatnych na jego możliwości będzie z roku na rok maleć.

Wnioski praktyczne​

  • Nie traktuj pozytywnego wyniku autopwn jako dowodu na ogólną podatność organizacji — to sygnał, że konkretna karta ma słaby/domyślny klucz, nic więcej. Brak wyniku nie oznacza, że karta jest bezpieczna — równie dobrze może używać technologii, której to urządzenie w ogóle nie widzi.
  • Nie planuj audytu fizycznego wyłącznie wokół tego jednego narzędzia — udokumentowana podatność na regresje firmware i ograniczenia czytnika oznaczają realne ryzyko, że urządzenie zawiedzie akurat w jednorazowej sytuacji terenowej.
  • Traktuj deklarowane wsparcie protokołów sceptycznie — „obsługa EMV" czy „obsługa DESFire" w opisie produktu nie oznacza pełnego, użytecznego odczytu danych karty; w praktyce może kończyć się na etapie rozpoznania aplikacji, bez dostępu do właściwej treści.

Źródła​

  1. MIFARE DESFire EV3 vs MIFARE Classic: Security Differences for Access Control, XIUCHENG RFID — https://rfid-pro.com/mifare-desfire-ev3-vs-mifare-classic/
  2. MIFARE® DESFire® EV3 + iCLASS, HID Global — https://www.hidglobal.com/documents/mifare-desfire-ev3-iclass
  3. MIFARE DESFire, NXP Semiconductors — https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-desfire:MC_53450
  4. troubleshooting, RfidResearchGroup/ChameleonUltra (dokumentacja oficjalna) — https://rfidresearchgroup.github.io/ChameleonUltra/troubleshooting.html
  5. Issues of LF emulation, Issue #175, RfidResearchGroup/ChameleonUltra — https://github.com/RfidResearchGroup/ChameleonUltra/issues/175
  6. RFID Cloning Arsenal: A Detailed Review, Covert Access Team — https://covertaccessteam.substack.com/p/rfid-cloning-arsenal-a-detailed-review
  7. RfidResearchGroup/ChameleonUltra, releases i kod źródłowy — https://github.com/RfidResearchGroup/ChameleonUltra