W skrócie. To niezależna, kontradyktoryjna analiza statyczna i dynamiczna dokładnie tej samej produkcyjnej wersji 4.87.2. Kod DEX i zasoby zestawiono z zachowaniem zalogowanej aplikacji na fizycznym urządzeniu Xiaomi z Androidem 16. Testy potwierdziły ochronę obrazu przez FLAG_SECURE, brak trybu debuggable oraz rzeczywistą lukę walidacji jawnego Intentu institutions: klient przyjął obcy schemat i host, po czym dopiero dalsza warstwa odrzuciła fikcyjny kod. Nie wykazano obejścia autoryzacji. Krytyczne hipotezy CMS, KDF, klucza UNIVERSITY, CT i starszego OAuth pozostają jawnie nierozstrzygnięte do chwili wykonania kontrolowanych testów wejściowych.

Werdykt. Główny grzech to asymetria: nowoczesną ochronę sprzętową (Keystore) i biblioteki Google Tink zastosowano do błahych preferencji i odcisku palca, podczas gdy najcenniejszy zasób — cyfrowa tożsamość obywatela — spoczywa w przestarzałym formacie (mDoki_0.10) opartym o czysto programowe PBKDF2 bez sprzętowego klucza, z solą, której wszystkie składniki są odczytywalne na urządzeniu, podatnym na natychmiastowy atak offline po zrzucie danych. Ani 1/10 (bo transmisja i sesja są chronione poprawnie), ani 7/10 (bo serce systemu nie spełnia standardu, jakiego wymaga tożsamość) nie oddawałoby prawdy.

1. Najpierw istotne ograniczenie materiału publicznego

Publicznie udostępniony materiał, który można przypisać projektowi Android, zawiera 192 pliki Kotlin. Przegląd drzewa wykazał, że jest to przede wszystkim warstwa interfejsu i system komponentów wizualnych. W tym materiale nie znaleziono:

• plików Gradle ani settings.gradle;
• AndroidManifest.xml;
• implementacji warstwy sieciowej, walidacji TLS i mechanizmu przejrzystości certyfikatów (Certificate Transparency, CT);
• implementacji kryptografii, Android Keystore i przepływów uwierzytelniania;
• kompletnej konfiguracji produktu pozwalającej zbudować i odtworzyć oficjalny APK.

Oznacza to, że publiczny materiał nie wystarczał do przeprowadzenia audytu zachowania aplikacji produkcyjnej. Pozostałą część trzeba było odtworzyć z kodu DEX i zasobów podpisanego APK. Jest to uczciwe i użyteczne źródło informacji o wykonywanej binarce, ale nie jest odpowiednikiem pełnego kodu źródłowego: dekompilator traci nazwy, typy i część struktury sterowania, a niektóre funkcje Kotlin/coroutines rekonstruuje błędnie.

W konsekwencji:

• fakty z manifestu, zasobów, stałych i prostych ścieżek są zwykle wysoce pewne;
• złożone ścieżki sterowania były potwierdzane drugim trybem dekompilacji lub dowodem wykonaniowym;
• nie przypisano aplikacji podatności tylko dlatego, że niebezpieczna klasa występuje w pliku APK;
• nie uznano aplikacji za bezpieczną tylko dlatego, że ustawienie produkcyjne ma poprawną wartość domyślną.

Publikacja części interfejsu użytkownika może wspierać przejrzystość wzornictwa, lecz nie umożliwia niezależnej kontroli właściwości bezpieczeństwa produktu. Jest to ograniczenie audytowalności, a nie samo w sobie dowód podatności.

Zamknięcie pozostałej części implementacji nie jest kontrolą bezpieczeństwa. Uniemożliwia ono zewnętrznym badaczom sprawdzenie założeń, odtworzenie kompilacji i szybkie wykrywanie regresji. Równocześnie sama niejawność kodu nie stanowi dowodu, że znajduje się w nim konkretna podatność — taki zarzut nadal wymaga śladu technicznego. W niniejszej pracy brak przejrzystości traktowany jest więc jako obniżenie poziomu niezależnego zapewnienia, a nie jako zamiennik analizy.

2. Streszczenie wykonawcze

W obiegowej ocenie tego artefaktu pojawia się kilka realnie niebezpiecznych konstrukcji obecnych w APK; częściej jednak przypisuje się im wpływ i dostępność, których kod nie potwierdza. Najczęstsze nadinterpretacje to:

1. utożsamienie wyjątku HTTP dla gstatic.com z możliwością podmiany fontów, JavaScriptu i dowolnych zasobów;
2. uznanie prywatnej flagi aplikacji i nieosiągalnego w produkcji ekranu deweloperskiego za zdalnie dostępny mechanizm wyłączenia TLS;
3. błędna interpretacja ksRandomizer jako losowania aliasu klucza;
4. zalecenie android:autoVerify dla własnego schematu URI, mimo że weryfikacja Android App Links dotyczy adresów HTTP/HTTPS;
5. potraktowanie obecności bibliotek AndroidX/Tink jako dowodu, że chronią one konkretną bazę i krytyczne dane aplikacji.

Jednocześnie zwykle pomijana jest rzeczywista słabość mechanizmu przejrzystości certyfikatów (CT):

Lista dzienników CT jest pobierana po HTTP i wprawdzie poprawnie weryfikowana podpisem Google, ale aplikacja nie egzekwuje jej świeżości, wersji, stanu dziennika ani przedziału czasowego. Aktywny napastnik sieciowy może więc ponownie podawać starszą, nadal poprawnie podpisaną listę.

Wpływ jest warunkowy. Samo ponowne podanie starszej listy nie przełamuje TLS i nie pozwala wstrzyknąć dowolnej treści. Może jednak osłabić dodatkową kontrolę CT w scenariuszu, w którym napastnik dysponuje już certyfikatem akceptowanym przez system oraz SCT pochodzącym z dziennika, któremu aplikacja nie powinna już ufać. Oceniono to jako ryzyko średnie dotyczące obrony warstwowej; nie jest to samodzielne przejęcie sesji.

Poza tym potwierdzono:

• oficjalny certyfikat podpisujący base.apk, zgodny z odciskiem opublikowanym przez domenę mobywatel.gov.pl;
• bezpieczne wartości domyślne TLS, przypinania certyfikatów, CT, obsługi SSL w WebView i FLAG_SECURE w wariancie produkcyjnym;
• niebezpieczne ścieżki TrustAll, permisywny HostnameVerifier oraz SslErrorHandler.proceed() pozostawione w produkcyjnym APK, lecz bez wykazanego przełącznika dostępnego zwykłej aplikacji trzeciej, użytkownikowi lub napastnikowi sieciowemu;
• starszy wariant autoryzacji OAuth e-Doręczeń, wybierany serwerową flagą funkcjonalną, który nie generuje ani nie porównuje state i wymienia kod z code_verifier=null; równolegle obecna nowsza implementacja stosuje losowy state oraz PKCE S256, co stanowi zarówno dobry wzorzec, jak i dowód realnej luki regresyjnej między wariantami;
• na Androidzie 8–9 nazwa załącznika z serwerowego Content-Disposition może zostać włączona bezpośrednio do ścieżki w pamięci współdzielonej, bez normalizacji i kontroli pozostania w katalogu Downloads; daje to warunkowy zapis nowego pliku poza katalogiem docelowym, ale kod nie nadpisuje pliku już istniejącego, a rzeczywistą kontrolę nazwy przez innego użytkownika należy potwierdzić testem;
• poprawne odrzucanie listy CT o błędnym podpisie i zachowanie ostatniej znanej poprawnej listy;
• rozsądne zabezpieczenia manifestu: wyłączone kopie danych, Safe Browsing, prywatny FileProvider i uprawnienia systemowe na eksportowanych komponentach bibliotek;
• produkcyjne włączenie FLAG_SECURE, potwierdzone statycznie i dynamicznie na Androidzie 16; regresja na Androidzie 8 i 14 pozostaje do wykonania;
• dynamiczne działanie FLAG_SECURE na Androidzie 16: czarny zrzut aktywnej aplikacji, pusty podgląd jej karty w ostatnich aplikacjach i brak treści w próbie nagrania ekranu;
• przyjęcie przez eksportowaną MainActivity jawnego Intentu institutions z obcym schematem i hostem; fikcyjny kod został przekazany do weryfikacji, lecz poprawnie odrzucony jako WRONG_QR_CODE;
• ściślejszą obsługę eqsig: obcy schemat nie uruchomił parsera, natomiast fikcyjny token w poprawnym mobywatel://eqsig został bezpiecznie odrzucony na dekodowaniu Base64.

Inwentaryzacja łańcucha dostaw ujawniła 324 zadeklarowane moduły Maven, w tym 28 artefaktów oznaczonych alpha lub beta. Trzy spakowane moduły Bouncy Castle 1.83 są objęte znanymi poprawkami bezpieczeństwa; automatyczne zapytanie OSV wskazało trzy komunikaty, a ręczna kontrola not projektu źródłowego ujawniła dalsze pozycje pominięte przez to źródło danych. Poprawiona wersja 1.84 była dostępna od 28 kwietnia 2026 r., czyli około trzy miesiące przed badanym wydaniem. Aplikacja rzeczywiście rejestruje dostawcę kryptograficznego BC i używa CMS, PKCS#12 oraz ASN.1, więc nie jest to martwa zależność.

Nie znaleziono wywołania konkretnych mechanizmów GOST, LDAP, Composite Signature ani FrodoKEM poza kodem biblioteki. Jest to potwierdzony dług aktualizacyjny i potencjalna powierzchnia podatności, ale nie dowód osiągalnej eskalacji tymi czterema CVE. Znaleziono natomiast odrębny wzorzec aplikacyjny: klient tworzy i zapisuje obiekty CMSSignedData, a następnie odczytuje getSignedContent() bez znalezionej lokalnej weryfikacji podpisujących. Brak obejmuje więc zidentyfikowane punkty przyjęcia i wykorzystania danych, a nie tylko ekran prezentacji. Wpływ zależy od tego, czy napastnik może dostarczyć lub zmienić kontener, ale hipoteza wymaga testu P0, ponieważ treść zasila modele dokumentów.

Ocena procesu inżynierskiego jest krytyczna. W produkcie przetwarzającym państwową tożsamość nie powinno być konieczne tłumaczenie, dlaczego kod TrustAll nie może trafić do wydania produkcyjnego, dlaczego aktywnie używany dostawca kryptograficzny z opublikowaną od kwietnia aktualizacją nie powinien pozostać w lipcowym wydaniu ani dlaczego SignedData musi być zweryfikowane przed użyciem treści. Każdy z tych problemów osobno może mieć warunkowy wpływ; razem świadczą o braku wystarczająco twardych bram jakości artefaktu. Publiczne udostępnienie wyłącznie warstwy interfejsu użytkownika dodatkowo uniemożliwia społeczną weryfikację, czy bramy takie istnieją i działają.

Nie ma podstaw do oceny, ile środków finansowych zostało zmarnowanych ani kto personalnie odpowiada za decyzje — badany materiał nie zawiera budżetów, umów, historii przeglądów ani wyjątków ryzyka. Można natomiast uczciwie stwierdzić, że rezultat techniczny i zakres publikacji nie odpowiadają poziomowi audytowalności oczekiwanemu od krytycznej aplikacji publicznej.

Nie ma podstaw do ogólnego komunikatu „aplikacja jest bezpieczna”. Wynik jest migawką analizy statycznej i rozpoczętej analizy dynamicznej wersji 4.87.2. Część tez została rozstrzygnięta na fizycznym urządzeniu, lecz najważniejsze testy CMS, KDF, klucza UNIVERSITY, CT i starszego OAuth nadal wymagają kontrolowanych danych lub warstwy sieciowej opisanych w sekcji 12.

3. Identyfikacja i pochodzenie badanego artefaktu

Weryfikator Android apksig 9.3.2 potwierdził integralność base.apk:

verified = true
v1 = false
v2 = true
v3 = true
v4 = false

Certyfikat podpisujący:

Subject/Issuer: CN=Android, OU=Android, O=Google Inc.,
                L=Mountain View, ST=California, C=US
SHA-256: CB:4F:1E:A4:F0:BE:4A:91:EA:80:34:97:DD:A6:9F:31:
         84:5C:9A:98:F4:39:03:C5:60:17:CF:4A:B8:77:D8:9F

Sam ogólny podmiot O=Google Inc. nie dowodzi autentyczności aplikacji. Rozstrzygający jest fakt, że identyczny odcisk dla pakietu pl.nask.mobywatel publikuje oficjalny plik Digital Asset Links. Potwierdza to użycie klucza autoryzowanego przez domenę mObywatel. Nie dowodzi natomiast, że plik o podanym hashu jest obecnie identyczny z egzemplarzem pobieranym z każdego kanału dystrybucji; do takiego twierdzenia potrzebne byłoby bezpośrednie porównanie artefaktów.

4. Metoda, skala pewności i model zagrożeń

4.1. Zakres wykonany

• inwentaryzacja APKM i metadanych manifestu;
• kryptograficzna weryfikacja podpisu APK i powiązania z oficjalną domeną;
• dekompilacja DEX i zasobów za pomocą JADX;
• ponowna dekompilacja problematycznej funkcji CT w trybie zapasowym (fallback);
• analiza konfiguracji sieci, TLS, przypinania certyfikatów, CT, WebView, obsługi odnośników kierujących do aplikacji, magazynu kluczy, logowania, komponentów eksportowanych, kopii danych i ścieżek zapisu plików;
• pobranie bieżącej listy CT, weryfikacja jej podpisu kluczem osadzonym w aplikacji i analiza schematu danych;
• regresyjna kontrola publicznie opisanego CVE-2025-11598;
• testy na fizycznym urządzeniu z Androidem 16: identyfikacja zainstalowanego pakietu, pobranie split APK, ponowna weryfikacja podpisu i skrótów, run-as, zrzut ekranu, ostatnie aplikacje, screenrecord, logi procesu oraz statystyki sieciowe UID;
• kontradyktoryjne testy jawnych Intentów skierowanych do eksportowanej MainActivity dla ścieżek institutions i eqsig, z jednoznacznie fikcyjnymi znacznikami audytowymi;
• weryfikacja każdej materialnej tezy o bezpieczeństwie aplikacji.

4.2. Poza zakresem tego audytu

• testy na emulatorach Android 8, 9, 14 oraz na drugim urządzeniu;
• kontrolowane logowanie w dwóch równoległych sesjach i pełna ocena autoryzacji po stronie serwera;
• testowanie mutacyjne parserów i interfejsów Binder/JNI;
• analiza infrastruktury serwerowej i procedur operacyjnych;
• pełny przegląd bibliotek natywnych;
• porównanie ze źródłami, które nie zostały jeszcze udostępnione audytorowi.

4.3. Znaczenie ocen

Ocena zakłada przede wszystkim zwykłego napastnika sieciowego lub złośliwą aplikację bez uprawnień administratora systemu (root). Uzyskanie takich uprawnień, instrumentacja Frida, modyfikacja prywatnego katalogu aplikacji i przepakowanie APK są omawiane osobno, ponieważ napastnik o takich możliwościach może bezpośrednio przechwytywać dane procesu i omijać kontrolę TLS bez używania flag aplikacji.

4.4. Granice dowodu i zaufania

5. Zestawienie ustaleń

Nie nadano osobnych identyfikatorów dla rzekomego wstrzykiwania czcionek/JavaScriptu, zdalnej zmiany flagi TLS, „losowania aliasu” przez ksRandomizer ani programowego przejścia na słabszy wariant bez StrongBox jako CWE-326, ponieważ te tezy są odpowiednio obalone lub nieudowodnione.

Identyfikator MOB-A-07 obejmuje ścieżkę podpisu kwalifikowanego mobywatel://eqsig. Test dynamiczny (24.2) potwierdził, że klient przyjmuje ten deep link od dowolnej aplikacji bez walidacji nadawcy i — dla poprawnego Base64 — przekazuje token wprost do produkcyjnego API (.../qualified-signature-process/start-authentication), które odrzuca sfałszowaną wartość (400 INVALID_DEEPLINK). Potwierdza to tę samą klasę otwartej granicy wejściowej co MOB-A-03; nie wykazano obejścia autoryzacji — obrona spoczywa wyłącznie po stronie serwera.

Potencjalne ustalenie formułowane jako „WebView akceptuje połączenie mimo błędu TLS i zezwala na dostęp do plików” zostało scalone z wcześniejszym MOB-A-02, ponieważ opisuje tę samą klasę granicy WebView i nie powinno sztucznie zwiększać liczby wyników. Identyfikator MOB-A-09 w niniejszym raporcie oznacza niezależną wadę transakcyjnego wiązania OAuth opisaną w sekcji 8.2.

Ustalenia dotyczące jakości i architektury opublikowanego kodu interfejsu prowadzone są w odrębnym ciągu MOB-Q-xx i zebrane w sekcji 20.3. Rozdział ten jest celowy: tamte ustalenia opisują rzemiosło programistyczne warstwy pozbawionej mechanizmów bezpieczeństwa i pozostają poza klasyfikacją podatności.

6. MOB-A-01 — możliwość podstawienia starszej, prawidłowo podpisanej listy dzienników CT

Ocena: średnia, mechanizm obrony w głąb
Atakujący: aktywny napastnik na ścieżce sieciowej
Warunki wpływu: dodatkowo certyfikat akceptowany przez system oraz SCT z dziennika, który po wydaniu starszej listy utracił zaufanie albo zmienił dopuszczalny przedział
Pewność: potwierdzona akceptacja starszej listy; wpływ eksploatacyjny zależny od PKI i historii dzienników

6.1. Dowód

Konfiguracja zezwala na HTTP do gstatic.com:

<domain-config cleartextTrafficPermitted="true">
    <domain includeSubdomains="true">gstatic.com</domain>
</domain-config>

Dowód: network_security_config.xml.

Jedyny aktywny literał HTTP do tej domeny znaleziony w zasobach aplikacji to:

http://www.gstatic.com/ct/log_list/v3/log_list.zip

Dowód: strings.xml.

Kod pobiera ZIP profilem NonCTRaw, wyodrębnia log_list.json i log_list.sig, ograniczając ich wielkość odpowiednio do 1 MiB i 512 B. Następnie weryfikuje podpis kluczem publicznym osadzonym w APK. Dowody: iy3/c.java, iy3/c.java, iy3/c.java.

Pierwsza standardowa dekompilacja funkcji weryfikującej była błędna i sugerowała akceptację nieważnego podpisu. Dekompilacja tej samej klasy w trybie zapasowym (fallback) wykazała przeciwnie:

• brak klucza publicznego → odrzucenie;
• błędny podpis → odrzucenie;
• poprawny podpis → akceptacja.

Bieżący ZIP pobrany podczas badania miał SHA-256:

164e3b2368fcb84763bbb6fb4c3839d53d69c2ca469515365bd0e762613b50ce

Weryfikacja log_list.sig kluczem z APK dała Verified OK. To obala hipotezę, że napastnik może podmienić listę dowolną treścią.

Problem dotyczy świeżości. DTO zawiera pola version i log_list_timestamp, ale w badanej implementacji nie znaleziono ich użycia do kontroli monotoniczności ani maksymalnego wieku. Dowód: LogListDto.java. Model pojedynczego dziennika pomija ponadto pola bieżącego formatu, takie jak stan dziennika i przedział czasowy; przechowuje głównie identyfikator i klucz. Dowód: LogDto.java.

Po poprawnej weryfikacji aplikacja zapisuje lokalny czas pobrania jako cacheTime. W efekcie historyczny, lecz prawidłowo podpisany dokument dostarczony ponownie po HTTP wygląda lokalnie jak świeżo pobrany. Dowód: iy3/c.java.

6.2. Przepływ

6.3. Czego ten błąd nie oznacza

• Nie pozwala podpisać własnej listy dzienników CT.
• Nie pozwala podmieniać czcionek, JavaScriptu ani innych zasobów aplikacji; nie znaleziono takiego odbiorcy dla tego wyjątku HTTP.
• Nie omija samodzielnie systemowej walidacji łańcucha certyfikatu.
• Nie jest dowodem ujawnienia informacji wrażliwych przez HTTP — pobierana lista jest publiczna.

6.4. Zalecenie

1. Zmienić punkt końcowy na HTTPS i usunąć zezwolenie na ruch nieszyfrowany dla całej domeny gstatic.com.
2. Zachować podpis aplikacyjny jako niezależną warstwę ochrony.
3. Egzekwować maksymalny wiek log_list_timestamp oraz monotoniczny wzrost version.
4. Odczytywać i egzekwować stan dziennika oraz jego temporal_interval względem czasu SCT/certyfikatu.
5. Dopuszczać ostatnią znaną poprawną listę tylko przez jawnie ustalony okres awaryjny.
6. Dodać testy: ponowne podanie starszej podpisanej wersji, wersja cofnięta, znacznik czasu z przyszłości, dziennik wycofany, błędny podpis i uszkodzony ZIP.

7. MOB-A-02 — niebezpieczne ścieżki TLS/WebView w produkcyjnym APK

Ocena: niska jako higiena i odporność produktu
Pewność: istnienie kodu potwierdzone; dostępność dla zwykłego napastnika niepotwierdzona i w standardowej konfiguracji zaprzeczona

7.1. Co rzeczywiście znajduje się w APK

Konfiguracja klienta HTTP pobiera podczas działania flagę HTTP_CLIENT_SSL. Jeżeli jest fałszywa, fabryka ustawia permisywny HostnameVerifier i TrustAllX509TrustManager. Dowód: pl/gov/coi/common/network/o.java.

Wspólny WebViewClient wywołuje SslErrorHandler.proceed(), gdy odpowiadająca mu konfiguracja SSL jest wyłączona. Dowód: t80/h.java.

Ten klient jest wspólny dla wielu ekranów. Ustawia parametry dokładnie z obiektu konfiguracji: dostęp do plików, JavaScript, pamięć DOM, treść mieszaną i pamięć podręczną: t80/l.java. Domyślna klasa bazowa ma restrykcyjne wartości: JavaScript false, pamięć DOM false, allowFileAccess=false oraz mixedContentMode=1, czyli MIXED_CONTENT_NEVER_ALLOW: t80/p.java. Konkretne ekrany świadomie rozszerzają te uprawnienia.

Ścieżka usług internetowych pobiera zdalny URL, obsługuje POST, pobieranie plików oraz systemowy wybór pliku, a konfiguracja ustawia allowFileAccess=true: f43/b.java, e43/u.java. Samo to ustawienie nie przełamuje zasady wspólnego pochodzenia i w tym materiale nie wykazuje odczytu lokalnego pliku przez zdalną stronę. Jest jednak niepotrzebnym uprawnieniem dla komponentu przetwarzającego treść z sieci. Należy je wyłączyć i testować nawigacje file://, content://, przekierowania oraz systemowy wybór pliku.

Wspólny klient buduje komunikaty diagnostyczne z pełnego URL i po onPageFinished pobiera całe document.body.outerHTML: t80/h.java. W badanym wariancie produkcyjnym nie jest to potwierdzony wyciek: wywołania trafiają na poziom diagnostyczny do q00.a, którego metody debug/info odrzucają treść, a dopiero błąd jest przekazywany do Sentry: q00/a.java. To pozytywny wynik dla badanego odbiornika logów, ale kod powinien przestać konstruować pełny DOM i URL, ponieważ podmiana implementacji mechanizmu logowania w innym wariancie natychmiast zmieni tę właściwość bezpieczeństwa.

Przypinanie certyfikatów jest także zależne od flag, a profil NonCTRaw ma dodatkową ścieżkę akceptacji mimo błędu: jeśli nie uda się utworzyć oczekiwanego menedżera zaufania, używa wariantu permisywnego. Dotyczy to danych podpisanych na poziomie aplikacji, m.in. listy CT; nie należy automatycznie przenosić wpływu na główne API.

7.2. Dlaczego to ryzyko bywa zawyżane

Wartości produkcyjne są bezpieczne:

HTTP_CLIENT_SSL          = true
CERTIFICATE_TRANSPARENCY = true
HTTP_CLIENT_CERT_PINNING = true
WEB_VIEW_SSL             = true
WEB_VIEW_DEBUGGING       = false

Dowód wartości domyślnych: a04/c.java.

Lokalne nadpisania trafiają do prywatnych SharedPreferences. Manifest wyłącza backup, a reguły ekstrakcji wykluczają dane. Zwykła aplikacja trzecia i napastnik sieciowy nie mogą zapisać tego pliku.

Repozytorium flag składa wartości domyślne z lokalnymi wpisami i nie pobiera WEB_VIEW_SSL z listy flag serwerowych: e04/b.java. Rozgałęzienie f04.e ma osobne wyjątki dla NURSE_CARD, ale dla WEB_VIEW_SSL po sprawdzeniu profilu audytowego/testowego odczytuje właśnie lokalne repozytorium. Co istotne, profile isSecurityAudit i isAutomaticTest wymuszają dla tej flagi false; jest to celowe ułatwienie testów MITM, a nie zdalny przełącznik produkcji. Taki wyjątek nadal powinien istnieć wyłącznie w osobnym artefakcie testowym.

Kod ekranu deweloperskiego istotnie jest skompilowany, ale produkcyjny graf zależności wstrzykuje implementację modułu zarządzającego, której isAvailable() zwraca false i która nie wykonuje nawigacji. Główna aktywność nie eksportuje osobnego ekranu deweloperskiego. Sama obecność oq1.m nie dowodzi osiągalności interfejsu.

Stąd klasyfikacja Wysokie/CWE-295 jako zdalnie sterowalnego obejścia zabezpieczeń jest nieuzasadniona. Konstrukcja nadal jest zła z perspektywy obrony warstwowej: błąd wariantu, błędne wstrzyknięcie zależności lub przyszła regresja może aktywować kod akceptujący połączenie mimo błędu.

7.3. Zalecenie

• usunąć klasy TrustAll, permisywny HostnameVerifier i SslErrorHandler.proceed() z wariantu produkcyjnego przez rozdzielenie zestawów źródeł;
• dla hostów produkcyjnych bezwzględnie odrzucać połączenie przy błędzie: wyłączenie TLS powinno kończyć inicjalizację niepowodzeniem;
• nie utrzymywać lokalnie nadpisywalnych flag bezpieczeństwa w wariancie produkcyjnym;
• ustawić allowFileAccess=false we wszystkich WebView sieciowych oraz dodać jawne listy dozwolonych schematów i hostów dla nawigacji uprzywilejowanych;
• usunąć pobieranie pełnego DOM i usuwać parametry zapytania oraz fragment adresu przed utworzeniem komunikatu logowania, nawet jeżeli obecny produkcyjny odbiornik odrzuca poziom diagnostyczny;
• dodać test artefaktu wydania, który wykrywa obecność sygnatur klas TrustAll i wywołania SslErrorHandler.proceed();
• przetestować końcowy podpisany pakiet, a nie tylko wariant pośredni z ciągłej integracji (CI).

8. MOB-A-03 — własne schematy URI i tokeny

8.1. Eksportowana aktywność i walidacja URI

Manifest eksportuje MainActivity dla:

• mobywatel://app/institutions;
• mobywatel://eqsig;
• zweryfikowanego https://api.mobywatel.gov.pl/application/diia_confirmed.

Dowód: AndroidManifest.xml.

Procedura obsługi institutions odczytuje parametr qrCode. Wewnątrz aplikacji sprawdza akcję VIEW, obecność URI i wyłącznie to, czy ostatni segment ścieżki jest równy institutions; nie porównuje ponownie schematu ani hosta: bk3/e.java. Filtr manifestu ogranicza zwykłe rozpoznanie niejawnego Intentu do mobywatel://app/institutions, lecz dowolna aplikacja może skierować jawny Intent do eksportowanej MainActivity z innym schematem lub hostem i pasującym ostatnim segmentem. To nie dowodzi przejęcia procesu: qrCode uruchamia przebieg weryfikacji/logowania i nie znaleziono lokalnego pominięcia autoryzacji. Jest jednak konkretną luką walidacji granicy wejściowej, którą trzeba zamknąć przed analizą jednorazowości tokenu po stronie serwera.

Procedura obsługi podpisu kwalifikowanego jest pod tym względem lepsza: sprawdza oczekiwany schemat i host, odczytuje token i rozpoczyna proces potwierdzenia tożsamości. Nie wykazano, aby samo dostarczenie wartości omijało logowanie, zgodę użytkownika lub walidację po stronie serwera.

Ryzyka własnego schematu są dwa:

1. inna aplikacja może zarejestrować ten sam schemat i próbować przechwycić odnośnik wychodzący;
2. inna aplikacja może jawnie uruchomić eksportowaną MainActivity z przygotowanym URI.

android:autoVerify nie rozwiązuje tego dla mobywatel://, ponieważ mechanizm zweryfikowanych linków aplikacyjnych Android App Links obejmuje domeny HTTP/HTTPS. Bywa więc zalecany środek technicznie niedopasowany.

Zalecenie: przenieść przebiegi zawierające tokeny do zweryfikowanych linków HTTPS, stosować token jednorazowy z krótkim czasem ważności (TTL), wiązaniem z odbiorcą, stanem i sesją (audience/state/session) oraz walidacją po stronie serwera. Do czasu testu z aplikacją kolidującą nie należy przedstawiać tego jako potwierdzonego przejęcia konta lub podpisu.

8.2. MOB-A-09 — starszy wariant OAuth e-Doręczeń bez state i PKCE

Ocena: średnia, warunkowa
Pewność: brak mechanizmów po stronie klienta potwierdzony; aktywność wariantu i skuteczność ataku wymagają testu P0
Klasa skutku: CSRF podczas logowania, wstrzyknięcie kodu autoryzacyjnego lub pomylenie sesji, bez statycznie wykazanego przejęcia konta

APK zawiera starszą implementację autoryzacji e-Doręczeń oraz nowsze mechanizmy autoryzacyjne. Starsza ścieżka y12.t uruchamia URL edorUrl bez dodania transakcyjnego state ani code_challenge: y12/t.java. Wywołanie zwrotne akceptuje każdy URL o schemacie mobywatel, którego ścieżka zaczyna się od /edelivery, pobiera sam parametr code i przekazuje go do wymiany tokenów; host, state i powiązanie z rozpoczętą transakcją nie są sprawdzane: y12/t.java.

Łańcuch nie urywa się na warstwie interfejsu użytkownika. Stara ścieżka tworzy sn0.x.Params(tokenUrl, code, null), więc codeVerifier jest jawnie pusty: y12/t.java. Repozytorium przekazuje tę wartość do pola formularza code_verifier punktu końcowego tokenów: zn0/y.java, tn0/h.java. Nie znaleziono alternatywnej wartości jednorazowej (nonce) ani lokalnego sekretu transakcyjnego w tym wariancie.

Nowszy moduł Keycloak obecny w tej samej aplikacji pokazuje wzorzec, który powinien obowiązywać wszędzie: generuje sekrety transakcji, dopisuje state, code_challenge i code_challenge_method=S256, porównuje zwrócony state, a do punktu końcowego tokenów przekazuje codeVerifier: vs3/p.java, vs3/p.java, vs3/p.java. Jest to dobra implementacja oraz silny dowód, że brak w y12.t nie wynika z ograniczenia platformy. Analiza statyczna nie pozwala utożsamić każdego wywołania vs3.p z następcą konkretnego ekranu y12.t, dlatego porównanie dotyczy własności zabezpieczeń, a nie deklaracji pełnej równoważności tras.

Wybór między starszym WebView a nowym modułem natywnym odbywa się przez serwerową flagę NATIVE_LOGIN_EDOR_MODULE_ANDROID: przypadek użycia zwraca false, jeżeli flagi brakuje albo jest nieaktywna, a interfejs użytkownika wybiera wtedy właśnie y12.t: xy1/i0.java, i64/c6.java. Analiza statyczna nie ujawnia bieżącej wartości flagi dla konkretnego użytkownika, regionu lub grupy wdrożeniowej. Dlatego nie wolno pisać, że wszyscy użytkownicy produkcyjni są obecnie podatni; równie nieuczciwe byłoby uznanie starego wariantu za martwy tylko dlatego, że istnieje nowszy.

Aktualne dobre praktyki OAuth (BCP) wymagają ochrony klienta przed CSRF i wstrzyknięciem kodu. Klient publiczny powinien używać PKCE, a gdy ochrona CSRF nie wynika z poprawnie związanego PKCE/OIDC nonce, powinien stosować jednorazowy state związany z przeglądarką lub innym programem pośredniczącym użytkownika. Źródło normatywne: RFC 9700, sekcja 2.1 i 2.1.1.

Warunek podniesienia oceny: w teście P0 należy wymusić starszy wariant flagą serwerową, rozpocząć dwie równoległe transakcje na kontrolowanych kontach i sprawdzić, czy kod z transakcji A można wstrzyknąć do wywołania zwrotnego B lub dostarczyć przez kontrolowaną nawigację WebView. Należy także potwierdzić dokładne dopasowanie zwrotnego URI po stronie serwera, jednorazowość kodu, wiązanie kodu z klientem oraz zachowanie przy braku lub powtórzeniu state. Do tego czasu raport stwierdza brak wymaganych zabezpieczeń klienta, a nie udane przejęcie sesji.

Korekta: usunąć starszy wariant albo nadać mu ten sam generator sekretów i walidator co nowej ścieżce; wymusić PKCE S256 bez możliwości obniżenia zabezpieczeń, jednorazowy state, dokładną kontrolę schematu, hosta i ścieżki, jedną aktywną transakcję na przebieg oraz atomowe zużycie wywołania zwrotnego.

9. Dalsze ustalenia i obserwacje wymagające rozstrzygnięcia

9.1. MOB-O-01 — pełne URL w logowaniu zdalnym

Przechwytywacz dla części profili zewnętrznych przekazuje do zdalnego mechanizmu logowania pełny URL, potencjalnie wraz z parametrami zapytania. Konfiguracja produkcyjna włącza zdalne logowanie HTTP. Nie znaleziono jednak jeszcze potwierdzonego wywołania, w którym sekret lub dane osobowe przechodzą tą konkretną ścieżką. Jest to hipoteza do testu przepływowego, a nie gotowa podatność.

Zalecenie: globalnie usuwać parametry zapytania, fragment adresu, nagłówki autoryzacyjne i identyfikatory z telemetrii; utrzymywać listę dozwolonych pól diagnostycznych.

9.2. MOB-O-02 — szeroki zakres FileProvider

Dostawca treści nie jest eksportowany i wymaga jawnego nadania uprawnienia do URI, co jest poprawną granicą Androida: AndroidManifest.xml. Jego konfiguracja deklaruje jednak external-path path=".", czyli korzeń współdzielonej pamięci zewnętrznej, zamiast wydzielonego podkatalogu: provider_paths.xml. Sam wpis nie udostępnia plików bez przyznania uprawnienia i nie jest dowodem wycieku. Powoduje natomiast, że błąd w miejscu budującym URI lub nadającym czasowe uprawnienie może mieć znacznie większy zasięg niż potrzebny.

Zalecenie: zawęzić ścieżki dostawcy do wydzielonych katalogów i typów plików oraz zinwentaryzować wszystkie miejsca wywołujące getUriForFile, grantUriPermission i FLAG_GRANT_*_URI_PERMISSION. Test negatywny powinien potwierdzić, że nie da się utworzyć ani skutecznie nadać URI dla pliku spoza katalogu eksportu.

9.3. MOB-O-03 — zakres telemetrii Sentry i zdarzeń bezpieczeństwa

Produkcja inicjalizuje Sentry własnym kodem; automatyczna inicjalizacja manifestowa jest wyłączona. Konfiguracja nadaje zdarzeniom między innymi tagi:

• wersja Google Play Services i poziom poprawek bezpieczeństwa;
• wersje OpenGL i Vulkan, program uruchamiający i język aplikacji;
• rozmiar czcionki, TalkBack, eksploracja dotykiem i animacje;
• stan sieci komórkowej, Wi-Fi, GPS, NFC i biometrii systemowej;
• X_SESSION_ID, poziom StrongBox, obciążenie CPU i wykryte zagrożenia.

Dowód: q00/d.java. Mechanizm logowania przyjmuje także komunikaty, wyjątki i ślady zdarzeń. Zestaw programistyczny (SDK) zawiera integracje pomiarowe dla uruchomienia aplikacji, Compose, baz danych, plików, Logcat i OkHttp. Sama obecność integracji w metadanych nie dowodzi, że każda jest włączona ani że przesyła treść danych. Biblioteka odtwarzania sesji (Session Replay) również znajduje się w pakiecie, lecz nie znaleziono konfiguracji aplikacyjnej potwierdzającej aktywne rejestrowanie sesji; nie przypisano go więc aplikacji.

Moduł wykrywania zagrożeń przekazuje do mechanizmu logowania zdarzenia dotyczące uprawnień root, emulatora i podatności BlueBorne oraz nazwę i identyfikator pakietu wykrytego złośliwego oprogramowania. Dowód: h83/c.java. Dane te mogą być uzasadnione ochroną przed nadużyciami, ale stanowią osobną granicę prywatności i powinny być objęte minimalizacją, retencją, kontrolą dostępu oraz jawną dokumentacją celu.

Nie znaleziono dowodu, że wrażliwa treść dokumentów jest wysyłana do Sentry. Jednocześnie przechwytywacz opisany w MOB-O-01 zapisuje pełny URL, dlatego brak wycieku musi zostać potwierdzony testem ruchu i zdarzeń, a nie założony na podstawie intencji implementacji.

9.4. MOB-O-04 — ochrona ekranów potwierdzenia przed atakiem przez zasłanianie interfejsu

Pełne przeszukanie źródeł i manifestu nie znalazło filterTouchesWhenObscured, setFilterTouchesWhenObscured, obsługi FLAG_WINDOW_IS_PARTIALLY_OBSCURED, Window.setHideOverlayWindows() ani deklaracji android.permission.HIDE_OVERLAY_WINDOWS. Produkcyjne FLAG_SECURE ogranicza przechwytywanie obrazu, ale nie jest kontrolą przyjmowania dotyku przez zasłonięte okno. Oficjalne zalecenie Androida rozróżnia pełne i częściowe zasłonięcie: nowszy system ogranicza część pełnych nakładek, lecz dla częściowego zasłonięcia nie ma ochrony domyślnej. Android Developers — ataki przez zasłanianie interfejsu (Tapjacking).

W aplikacji zawierającej potwierdzenia związane z tożsamością i podpisem jest to brak obrony warstwowej. Analiza statyczna nie dowodzi jednak, że nakładka potrafi uruchomić konkretną operację bez czytelnej zgody, biometrii, PIN-u lub walidacji serwera. Dlatego MOB-O-04 pozostaje obserwacją do testu, a nie stwierdzoną podatnością.

Zalecenie: dla całego okna czynności wrażliwych na Androidzie 12+ zadeklarować HIDE_OVERLAY_WINDOWS i użyć setHideOverlayWindows(true); niezależnie od wersji odrzucać dotknięcia oznaczone pełnym lub częściowym zasłonięciem na przyciskach potwierdzenia. Testy muszą objąć pełną nakładkę, przezroczystą nakładkę poniżej progu systemowego, częściowe zasłonięcie i umieszczenie aktywności między oknami napastnika (activity sandwich), z kontrolą dostępności dla prawidłowych narzędzi asystujących.

9.5. MOB-A-10 — nienormalizowana nazwa zdalnego załącznika w ścieżce Downloads na API 26–28

Ocena: Niskie–Średnie, warunkowe
Atakujący: nadawca lub inny podmiot mogący wpłynąć na nazwę pobieranego załącznika; alternatywnie przejęte zaplecze serwerowe
Warunki: Android 8–9 (API 26–28), zgoda na zapis w pamięci zewnętrznej oraz zaakceptowanie przez usługę nazwy zawierającej segmenty ścieżki
Pewność: potwierdzony brak walidacji po stronie klienta; zdalna sterowalność nazwy i skuteczność wobec produkcyjnej usługi wymagają testu

Łańcuch zaczyna się w odpowiedzi HTTP. Parser Content-Disposition wybiera filename= albo dekoduje filename*=, lecz nie usuwa separatorów katalogów, .. ani znaków sterujących: q10/a.java. Repozytorium e-Doręczeń przekazuje wynik bez zmiany do FileDto, a następnie DomainFile; w razie braku nagłówka używa bezpiecznej nazwy domyślnej: wn0/d.java, un0/a.java. Wspólny przypadek użycia rozdziela nazwę wyłącznie wokół ostatniej kropki i nie przeprowadza normalizacji ścieżki: ww3/l.java.

Standardowy przebieg JADX pominął główną metodę zapisu w ww3/m.java; ponowna dekompilacja tej samej klasy z --show-bad-code odtworzyła jawny warunek Build.VERSION.SDK_INT >= 29. Na API 29+ aplikacja używa MediaStore z relative_path=Downloads: r20/e.java. Na API 26–28 — które nadal mieszczą się w deklarowanym minSdkVersion=26 — buduje natomiast ścieżkę tekstową i otwiera ją przez FileOutputStream: ww3/m.java, AndroidManifest.xml, r20/e.java. Bazą jest publiczny katalog Downloads: r20/b.java. Funkcja składa go operatorem tekstowym jako Downloads + "/" + fileName + "." + extension, bez getCanonicalFile() i sprawdzenia prefiksu: ww3/c.java.

Przykładowa nazwa ../Pictures/probe.pdf prowadzi więc w starszej gałęzi do ścieżki równoważnej Download/../Pictures/probe.pdf. Manifest żąda WRITE_EXTERNAL_STORAGE, a przypadek użycia poprzedza zapis prośbą o to uprawnienie: AndroidManifest.xml, ww3/l.java. Kod sprawdza istnienie celu i dodaje przyrostek (n), zatem w przeanalizowanym przebiegu nie potwierdzono nadpisywania istniejącego pliku. Potwierdzona własność ogranicza się do możliwości utworzenia nowego pliku w innym istniejącym katalogu pamięci współdzielonej, w granicach uprawnień starego Androida. Nie oznacza zapisu do prywatnego obszaru innej aplikacji ani wykonania kodu.

Test P1: na emulatorach API 26 i 28 wysłać w kontrolowanym środowisku załączniki o nazwach zwykłych oraz ../Pictures/probe.pdf, ..%2FPictures%2Fprobe.pdf w filename*=, z wieloma segmentami ../, separatorem odwrotnym i nazwą już istniejącą. Należy zapisać zarówno odpowiedź serwera, jak i rzeczywistą ścieżkę pliku. Test rozstrzyga, czy serwer zachowuje nazwę nadawcy, normalizuje ją lub odrzuca przed zwróceniem klientowi. Na API 29+ trzeba osobno potwierdzić zachowanie _display_name; nie należy automatycznie przenosić wyniku ze starej gałęzi.

Naprawa: potraktować nazwę z sieci wyłącznie jako etykietę. Odrzucać /, \\, segmenty ./.., NUL, znaki sterujące i nieakceptowane rozszerzenia; ograniczyć długość i zastosować listę dozwolonych znaków. Dla gałęzi plikowej obliczyć kanoniczny katalog bazowy i cel, a następnie wymagać, by cel pozostawał jego potomkiem. Najlepiej usunąć starszą gałąź bezpośredniego budowania ścieżki wraz z końcem wsparcia API 26–28 albo użyć bezpiecznego API systemowego również tam. Walidację trzeba wykonać niezależnie po stronie serwera i klienta.

9.6. MOB-O-05 — numer IMEI jako materiał wiążący kontener starszego magazynu

Klasa pl/gov/coi/mobywatel/feature/legacy/storage/j.java zawiera metodę c(String, Context), która przy ustawionej fladze isContainerBuiltByImei buduje wartość ośmiobajtową z numeru IMEI: łańcuch identyfikatora poprzedzany jest cyfrą 1, zamieniany na BigInteger, a z jego reprezentacji bajtowej pobieranych jest osiem pierwszych bajtów, uzupełnianych od końca znakami samego identyfikatora (wiersze 105–125). Gałąź alternatywna kieruje do metody b(String), niezwiązanej z identyfikatorem sprzętowym.

Numer IMEI nie jest sekretem: bywa nadrukowany na obudowie, odczytywany przez sieć operatora i widoczny w wielu procesach obsługi urządzenia. Wiązanie kontenera taką wartością nie wnosi entropii i nie zastępuje materiału klucza. Od Androida 10 dostęp do trwałych identyfikatorów sprzętowych jest dla zwykłych aplikacji zamknięty, wobec czego ścieżka ta nie może obsługiwać kontenerów zakładanych na bieżących wydaniach systemu.

Ustalenie zgłaszam jako dług techniczny w kodzie archiwalnym, nie jako czynną podatność. Wykazania wymaga, czy kontenery zbudowane w tym trybie nadal występują u użytkowników po migracjach oraz czy wartość ta bierze udział w wyprowadzaniu klucza wspólnie z materiałem opisanym w MOB-A-06, czy wyłącznie w rozpoznaniu urządzenia. Do czasu takiego rozstrzygnięcia ośmiobajtowa zbieżność z solą opisaną w MOB-A-06 pozostaje obserwacją, a nie wykazanym powiązaniem.

Zalecenie: wycofać tryb wiązania po identyfikatorze sprzętowym, wymusić migrację istniejących kontenerów na materiał z generatora kryptograficznego przechowywany w magazynie kluczy oraz usunąć gałąź wraz z flagą po zakończeniu migracji.

9.7. Model zaufania do wyświetlanego dokumentu

Odrębnej uwagi wymaga to, na czym opiera się wiarygodność dokumentu prezentowanego na ekranie. Wizualne cechy „autentyczności" — animowana, falująca flaga oraz układ karty — nie są kontrolą kryptograficzną, lecz elementem interfejsu. Animacja flagi to sekwencja sześćdziesięciu statycznych klatek WebP (zob. 24.4.2), a cały system komponentów wizualnych opublikowano na licencji MIT (zob. 20.3). Wygląd karty można więc odtworzyć co do piksela z materiałów jawnych i legalnie dostępnych, bez inżynierii wstecznej. Ochrona FLAG_SECURE (zob. 24.2) zabezpiecza obraz okna prawdziwej aplikacji, lecz z zasady nie odróżnia jej od aplikacji-sobowtóra malującej identyczny ekran.

Płynie stąd wniosek o modelu zaufania, nie o kryptografii: obejrzenie ekranu nie jest weryfikacją. Zapewnienie autentyczności daje wyłącznie kontrola kryptograficzna — sprawdzenie podpisu dokumentu narzędziem weryfikującym (mWeryfikator lub kontrola online), nie zaś ocena wzrokowa. Wszędzie tam, gdzie w praktyce dokument bywa „sprawdzany" rzutem oka na telefon — od kontroli w terenie po sytuacje o wysokiej stawce, w których do potwierdzenia tożsamości dopuszcza się okazanie aplikacji, jak przy głosowaniu — warstwa wizualna nie daje żadnego zabezpieczenia, a ruchome, autorytatywnie wyglądające elementy mogą wręcz budować fałszywą pewność weryfikującego.

Szczegółów operacyjnych — jak konkretnie złożyć przekonującą imitację i ile „łatek" do tego potrzeba — świadomie nie ujawniam. Nie dlatego, że są trudne, lecz dlatego, że to jest problem do rozwiązania po stronie Państwa i wystawcy dokumentu, a nie gotowiec dla naciągacza. Zgodnie z linią całego raportu opisuję klasę słabości i jej naprawę; nie dostarczam narzędzia do podszywania się pod tożsamość drugiego człowieka.

Zalecenie. W każdym scenariuszu, w którym okazanie dokumentu ma wywoływać skutek prawny, weryfikacja musi przebiegać kryptograficznie po stronie sprawdzającego (mWeryfikator albo kontrola online), a procedury i szkolenia muszą wykluczać „uznanie na oko". Sama aplikacja nie powinna prezentować cech sugerujących poziom zapewnienia wyższy niż faktycznie dostarcza.

Na koniec obserwacja szersza niż ten jeden dokument, bo wzorzec się powtarza. Problem systemowy polskiego publicznego IT jest prosty i przewidywalny: zamówienie idzie do najtańszego oferenta, najtańszy oferent płaci najniższą krajową, i w aplikacji tożsamości państwowej dostajesz Bouncy Castle 1.83 trzy miesiące po tym, jak wyszła łatka (MOB-A-04), albo globalną, stałą sól PBKDF2 w pakiecie kryptograficznym legitymacji studenckiej (MOB-A-06). Gorzka pointa jest taka, że przy takich przetargach nawet oszczędność bywa pozorna — a jakość i tak wychodzi, jaka wychodzi.

9.8. Wspólny model błędu — strona kliencka i serwerowa

Publiczna analiza firmy SecuRing, opisująca współpracę przy zabezpieczaniu systemu tożsamości, ujawniła po stronie serwera błąd należący do tej samej klasy co MOB-A-05 po stronie klienta. Serwer weryfikujący sprawdzał podpis żądania użytkownika oraz państwowy podpis kontenera CMS, lecz nie weryfikował wiązania tożsamości (identity binding) między podmiotem certyfikatu użytkownika (CN=MTMid…) a danymi osobowymi wewnątrz kontenera. Umożliwiało to podstawienie cudzego, prawidłowo podpisanego kontenera i podszycie się pod dowolnego obywatela. Ustalenie zostało odpowiedzialnie zgłoszone i naprawione; przywołuję je za publicznym opracowaniem autorów — nie odtwarzam.

Zestawienie obu stron jest wymowne:

Obie podatności wynikają z tego samego założenia: PKCS#7 SignedData traktowany jest jak odseparowany blob danych, a nie jako kryptograficzne wiązanie tożsamości na twardej granicy „zweryfikuj, zanim odczytasz". Klient ufa podpisanej treści, której nie zweryfikował; serwer ufa kontenerowi, którego nie związał z tożsamością okaziciela. To nie zbieg okoliczności, lecz systemowy wzorzec w modelu zaufania do dokumentu — i najsilniejszy argument za tym, że wiązanie tożsamości musi być egzekwowane po obu stronach naraz, nigdy tylko na jednej.

10. Kontrola regresji wcześniejszego incydentu

CERT Polska opisał CVE-2025-11598 jako błąd wersji iOS starszych niż 4.71.0, w których dane mogły pozostać widoczne w systemowym przełączniku aplikacji po zakończeniu sesji. NVD klasyfikuje problem jako CWE-359 i niski poziom CVSS 4. Nie jest to CVE Androida i nie wolno przedstawiać statycznego sprawdzenia Androida jako potwierdzenia naprawy błędu iOS.

W Androidzie 4.87.2 znaleziono jednak właściwy wzorzec ochronny:

• SECURE_WINDOW ma wartość produkcyjną true;
• obserwator cyklu życia aktywności dodaje flagę o wartości 8192, czyli WindowManager.LayoutParams.FLAG_SECURE;
• mechanizm jest dołączony do głównej aktywności.

Dowód: a04/c.java, y10/x.java.

Pozostaje rozszerzyć macierz o Androida 8 i 14 oraz pełny cykl: aktywna sesja → tło → wylogowanie → wymuszone zamknięcie → ponowne uruchomienie. Obecny wynik zamyka przypadek aktywnej sesji, zrzutu, nagrania i przełącznika aplikacji na Androidzie 16.

Podczas szybkiego minimalizowania i przywracania system utrzymywał równocześnie dwa odrębne zadania mObywatela (task #4003 i task #4001), każde wskazujące tę samą MainActivity. Potwierdza to anomalię zarządzania zadaniami, ale bez wykazanego wpływu na poufność lub autoryzację nie otrzymuje ona obecnie odrębnej oceny podatności.

11. Magazyn kluczy — stan rzeczywisty

Potwierdzone dobre praktyki:

• użycie AndroidKeyStore;
• AES-GCM i operacje RSA w odpowiednich ścieżkach;
• możliwość związania klucza z uwierzytelnieniem urządzenia lub biometrią;
• możliwość unieważnienia po zmianie biometrii;
• żądanie StrongBox dla wybranych kluczy tożsamości;
• inspekcja faktycznego KeyInfo.securityLevel i raportowanie poziomu.

Korekty:

• pole ksRandomizer jest przekazywane do setRandomizedEncryptionRequired(). Nie losuje aliasu klucza;
• StrongBox.PREFERRED celowo dopuszcza ponowienie generacji bez StrongBox po ProviderException;
• odczyt rzeczywistego poziomu zabezpieczenia jest widoczny, ale nie znaleziono ogólnej blokady funkcji przy poziomie SOFTWARE;
• obecność klas AndroidX Security i Tink w APK nie dowodzi, że konkretna baza dokumentów jest nimi chroniona;
• programowe wykonanie zastępcze nie jest automatycznie CWE-326. To decyzja o poziomie zapewnienia, którą należy zestawić z wymaganiami protokołu i modelem urządzeń.

Zalecenie: formalnie określić, które klucze wymagają co najmniej TEE, które StrongBox, a które mogą działać programowo. Warunek powinien być egzekwowany w punkcie emisji/użycia klucza, jeżeli bezpieczeństwo protokołu faktycznie od tego zależy.

12. Plan testów dynamicznych przed zamknięciem audytu

Testy powinny być wykonane na dokładnie tym samym certyfikowanym artefakcie wydania, dla którego zostaną opublikowane skrót kryptograficzny i versionCode. Wyniki negatywne także należy zachować w raporcie — brak powodzenia określonej hipotezy jest istotnym wynikiem audytu.

13. Macierz rozstrzygnięcia tez

14. Dobre wzorce, które należy odnotować

Uczciwy audyt obejmuje również kontrole działające poprawnie:

• android:allowBackup="false" i reguły tworzenia kopii oraz ekstrakcji wykluczające dane aplikacji;
• globalne android:usesCleartextTraffic="false", z jednym jawnie opisanym wyjątkiem;
• ochrona Safe Browsing dla WebView włączona w manifeście;
• poprawna kryptograficzna weryfikacja listy CT i ograniczenia rozmiaru elementów ZIP;
• zachowanie ostatniej znanej poprawnej wersji zamiast przyjęcia danych o błędnym podpisie;
• pin podstawowy i zapasowy dla głównego API;
• FLAG_SECURE domyślnie aktywne w produkcji;
• brak aplikacyjnego addJavascriptInterface w przejrzanym kodzie;
• restrykcyjne ustawienia bazowe WebView (allowFileAccess=false, zablokowana treść mieszana) oraz twarde sslEnabled=true w ekranach płatności;
• produkcyjny odbiornik komunikatów debug/info nie utrwala treści pełnego URL ani DOM budowanego przez wspólny WebView; nie znaleziono zdalnej wysyłki tych komunikatów;
• nowszy moduł autoryzacyjny implementuje transakcyjny state oraz PKCE S256 i odrzuca wywołanie zwrotne z niezgodnym state;
• niemutowalne PendingIntent we własnych powiadomieniach i sprawdzonych przebiegach interfejsu; odziedziczona funkcja pomocnicza rejestracji Google tworzy osobny mutowalny token do fikcyjnego pakietu, dlatego nie zaliczono całej powierzchni bezwarunkowo do dobrych wzorców;
• komponenty bibliotek eksportowane tylko z właściwymi uprawnieniami systemowymi;
• FileProvider nieeksportowany;
• użycie Android Keystore, żądanie StrongBox dla wybranych kluczy i inspekcja realnego poziomu zabezpieczenia.

Te elementy zmniejszają ryzyko, ale nie unieważniają ustaleń MOB-A-01, MOB-A-02 ani rozbieżności między wariantami opisanej jako MOB-A-09.

15. Odtwarzalność kluczowych sprawdzeń

Przykładowe polecenia:

sha256sum mObywatel.apkm decompiling/base.apk

apksigner verify --verbose --print-certs decompiling/base.apk

curl --fail --silent --show-error \
  https://api.mobywatel.gov.pl/.well-known/assetlinks.json

rg -n 'http://[^" ]+' src/resources src/sources

rg -n 'getVersion\(|getLogListTimestamp\(' src/sources

rg -n 'filterTouchesWhenObscured|setFilterTouchesWhenObscured|\
FLAG_WINDOW_IS_PARTIALLY_OBSCURED|setHideOverlayWindows|HIDE_OVERLAY_WINDOWS' \
  src/sources src/resources/AndroidManifest.xml

jadx --single-class iy3.c \
  --single-class-output /tmp/iy3_c_fallback.java \
  --decompilation-mode fallback decompiling/base.apk

unzip -p log_list.zip log_list.json > log_list.json
unzip -p log_list.zip log_list.sig > log_list.sig
openssl dgst -sha256 -verify gstatic_public_key.pem \
  -signature log_list.sig log_list.json

Należy zapisać wersje narzędzi, pełne dane wyjściowe, czas UTC pobrania zasobu zdalnego oraz skróty kryptograficzne wszystkich plików dowodowych. Plik z kluczem publicznym w ostatnim poleceniu powinien być zbudowany bezpośrednio z wartości gstatic_public_key badanego APK.

16. Łańcuch dostaw i podatności zależności

16.1. Inwentaryzacja

Metadane Sentry w APK zawierają listę 324 dokładnych współrzędnych Maven. Jest to użyteczny substytut wykazu składników oprogramowania (SBOM), lecz nie pełny dokument CycloneDX/SPDX: nie podaje relacji bezpośrednia/przechodnia, zakresu użycia, skrótów plików JAR ani modułów własnych. Dowód: sentry-external-modules.txt.

Wśród składników odnotowano między innymi:

Lista zawiera 28 artefaktów alpha/beta, głównie Compose 1.11.0-beta02, Material3 1.5.0-alpha18, Navigation3 1.1.0-alpha01 i ODML Image beta. Wersja przedprodukcyjna nie jest podatnością sama w sobie. W aplikacji państwowej powinna jednak wymagać jawnego wyjątku ryzyka, testów regresji i terminu przejścia na wydanie stabilne.

16.2. MOB-A-04 — Bouncy Castle 1.83

Wersję biblioteki potwierdza sam artefakt: klasa dostawcy deklaruje łańcuch "BouncyCastle Security Provider v1.83" i rejestruje się z numerem 1.83d (org/bouncycastle/jce/provider/BouncyCastleProvider.java:60,106). Ustalenie wersji opiera się zatem na samoopisie kodu w pakiecie, a nie wyłącznie na dopasowaniu współrzędnych Maven przez skaner składu.

Zapytania do OSV dla wszystkich 324 współrzędnych, wykonane 25 sierpnia 2026 r., zwróciły trzy wpisy dotyczące dwóch z trzech spakowanych modułów Bouncy Castle:

Ręczna kontrola oficjalnej noty 1.84 wykazała, że pojedyncze źródło danych było niepełne. Projekt źródłowy wymienia także CVE-2026-3505 oraz CVE-2026-5598:

• CVE-2026-3505 dotyczy OpenPGP AEAD; moduł bcpg i pakiet org.bouncycastle.openpgp nie występują w badanym APK, więc ten wpis nie jest przypisywany aplikacji. Odnotowuję dla ścisłości, że przeszukiwanie po samym łańcuchu „openpgp” trafia w org/bouncycastle/crypto/modes/OpenPGPCFBBlockCipher.java — klasę warstwy trybów szyfru w module bcprov, niezwiązaną z modułem OpenPGP i nieprzesądzającą o przypisaniu tego wpisu;
• CVE-2026-5598 dotyczy różnic czasowych przy dekapsulacji FrodoKEM. Kod Frodo znajduje się w bcprov, lecz nie znaleziono referencji aplikacyjnej do Frodo/FRODO/frodokem; osiągalność nie została wykazana.

Przeszukanie 45 452 zdekompilowanych plików Java wykazało symbole GOST, LDAP, Composite Signature i Frodo wyłącznie pod org/bouncycastle/**. Jest to negatywny wynik osiągalności kodu na poziomie jawnych odwołań, a nie matematyczny dowód nieosiągalności: dostawca JCA może być wybierany nazwą algorytmu, refleksją albo przez dane wejściowe.

Nie wolno natomiast uznać całej zależności za martwą. Aplikacja tworzy i rejestruje BouncyCastleProvider, generuje oraz odczytuje CMS, używa magazynu PKCS12 dostawcy BC i bezpośrednio odczytuje ASN.1. Przykłady: y10/d0.java, kh0/m.java, dh2/a.java, ez/e0.java. Oznacza to, że dla błędów CMS/PKIX/PKCS#12/ASN.1 sama obecność aktywnego odbiorcy jest potwierdzona, a rozstrzygnięcie musi zejść do konkretnych metod i danych wejściowych.

Bazowa ocena CVE opisuje najgorsze użycie wadliwego komponentu; nie jest automatycznie oceną badanej aplikacji. W szczególności krytyczna ocena CVE-2025-14813 wymaga rzeczywistego użycia trybu GOST CTR z warunkami ponownego użycia strumienia; takiego przebiegu nie wykazano. Z drugiej strony pozostawienie znanego podatnego dostawcy kryptograficznego w aplikacji tożsamościowej jest nieakceptowalnym długiem, ponieważ przyszłe lub słabo widoczne miejsce użycia może uczynić kod osiągalnym.

Wersja 1.84, która naprawiała powyższe problemy, została wydana 28 kwietnia 2026 r. Badana aplikacja trafiła do dystrybucji około 23–29 lipca 2026 r. Pozostawienie 1.83 nie może więc zostać wyjaśnione tym, że poprawka pojawiła się dopiero po zamknięciu kompilacji. To co najmniej niewystarczająca dyscyplina aktualizacji komponentu kryptograficznego albo brak wykazanego procesu akceptacji ryzyka.

Projekt źródłowy opublikował następnie 28 lipca 2026 r. Bouncy Castle 1.85, którego nota wymienia 32 dalsze poprawki CVE w całym produkcie, a 7 sierpnia poprawki dostawcy 1.85.2. Nie oznacza to, że wszystkie wpisy dotyczą użytych modułów albo przebiegów mObywatela. Ponieważ aplikacja używa CMS, PKCS#12 i ASN.1, priorytetowego rozpoznania wymagają między innymi klasy błędów CMS, walidacji RSA/certyfikatów, limitów ASN.1 i kosztu KDF. Nota wydania Bouncy Castle 1.85, bieżące pliki i noty wydania.

Osiągalność tych podatności nie sprowadza się jednak wyłącznie do poszukiwania jawnych wywołań w kodzie aplikacji. Ścieżka deszyfrowania CMS EnvelopedData nie ogranicza dozwolonego algorytmu treści: wywołuje recipientInformation.getContent(...) bez sprawdzenia identyfikatora algorytmu, a Bouncy Castle odczytuje ten identyfikator (OID) wprost z przetwarzanego, niezaufanego kontenera (wywołanie w dh2/a.java:274, wewnątrz metody rozpoczynającej się w wierszu 265). Ponieważ zarejestrowany jest pełny dostawca Bouncy Castle, a w pakiecie obecne są moduły pqc (617 klas, w tym 19 klas rodziny Frodo), gost (71 klas), composite (jcajce/provider/asymmetric/CompositeSignatures.java oraz COMPOSITE.java) i ldap (jce/provider/X509LDAPCertStoreSpi.java wraz z czterema magazynami X509StoreLDAP*), spreparowany kontener z identyfikatorem wskazującym choćby na algorytm rodziny GOST skieruje przetwarzanie do odpowiedniej implementacji biblioteki. Płynie stąd istotne rozróżnienie: nieobecność jawnego wywołania w kodzie aplikacji jest faktem, lecz nie dowodzi nieosiągalności podatnego kodu. Zwinność algorytmiczna tej ścieżki sprawia, że implementacje wrażliwych mechanizmów pozostają osiągalne przez dane, warunkowo i tą samą bramą dostarczenia, którą opisano dla MOB-A-05.

Rzetelność wymaga odnotowania zabezpieczenia obecnego na tej samej ścieżce. Odbiorca budowany w dh2/a.java:232-244 ustawia setKeySizeValidation(true) (wiersz 242), przez co Bouncy Castle odrzuca kontener, w którym długość odzyskanego klucza treści rozmija się z długością wynikającą z zadeklarowanego algorytmu. Kontrola ta zawęża zbiór kontenerów możliwych do spreparowania. Listy algorytmów dozwolonych nie zastępuje: algorytm o zgodnej długości klucza nadal zostanie rozwiązany przez dostawcę i uruchomiony. Osobno odnotowuję, że odbiorca pozostaje typu JceKeyTransRecipient, co ogranicza warstwę transportu klucza do RSA. Ograniczenie to dotyczy wyłącznie sposobu dostarczenia klucza treści i pozostaje bez wpływu na algorytm szyfrowania samej treści, którego dotyczy niniejsze ustalenie; obie warstwy koperty CMS deklarowane są niezależnie.

Rozstrzygnięcie, czy dostarczony kontener spełni szczegółowe warunki konkretnej podatności — na przykład ponowne użycie strumienia w trybie GOST CTR z CVE-2025-14813 — pozostaje hipotezą wymagającą testu dynamicznego. Sam mechanizm osiągalności jest natomiast potwierdzony statycznie i przenosi ustalenie z kategorii długu aktualizacyjnego bez wykazanej osiągalności do kategorii ścieżki osiągalnej przez dane, warunkowej na dostarczeniu kontenera.

Zalecenie: wprowadzić na granicy deszyfrowania i weryfikacji CMS listę algorytmów dozwolonych, docelowo ograniczoną do AES-256, z odrzuceniem nieoczekiwanych identyfikatorów algorytmów; przejść na najnowszy zgodny zestaw stabilnych artefaktów po testach współdziałania; usunąć nieużywane moduły i algorytmy przez minimalizację; generować podpisany SBOM dla każdego wydania; uruchamiać analizę składu oprogramowania (SCA) przy budowie i ponownie codziennie dla już wydanych wersji; łączyć co najmniej OSV/GHSA, NVD i komunikaty producenta; dla każdego CVE zapisywać decyzję „osiągalny / nieosiągalny / nierozstrzygnięty” wraz z dowodem. Samo podbicie numeru wersji bez testów nie zamyka ustalenia.

16.3. MOB-A-05 — treść CMS przyjmowana i odczytywana bez lokalnej weryfikacji podpisu

W wielu ścieżkach aplikacja tworzy CMSSignedData z danych binarnych i natychmiast pobiera getSignedContent().getContent(). Globalne wyszukanie nie znalazło poza kodem biblioteki wywołań getSignerInfos(), SignerInformation.verify(), verifySignatures() ani budowy SignerInformationVerifier. Najprostszy dekoder domenowy wykonuje wyłącznie:

return UTF_8.decode(ByteBuffer.wrap(
    (byte[]) new CMSSignedData(byteArray).getSignedContent().getContent()
)).toString();

Dowód: y10/f0.java. Ten dekoder zasila repozytoria dokumentów. Analogiczny wzorzec występuje w ih2/a.java oraz starszym magazynie storage/g.java. Wprost odczytywane w ten sposób są między innymi zakresy prawa jazdy i legitymacji studenckiej: d64/l.java, d64/l.java. Inna ścieżka najpierw odszyfrowuje CMSEnvelopedData kluczem użytkownika, a następnie tylko odczytuje wewnętrzne obiekty CMSSignedData: d64/l.java.

Brak nie ogranicza się do ścieżki odczytu. Publiczna metoda repozytorium b0(...) przekazuje otrzymany ciąg do K1(...); zależnie od trybu B0(...) albo A0(...) odszyfrowuje CMS EnvelopedData, tworzy wewnętrzne CMSSignedData, a następnie zapisuje ich getEncoded() do kontenera. Sprawdzana jest liczba elementów albo dozwolona nazwa zakresu (scope), lecz nie podmiot podpisujący. Dowody: d64/l.java, d64/l.java, d64/l.java. Analiza statyczna oznacza tu brak weryfikacji zarówno na zidentyfikowanej granicy przyjęcia danych, jak i później przy budowaniu modeli. Nie przesądza natomiast, kto może wywołać tę granicę z kontrolowaną treścią.

Osobny, istotny wariant dotyczy aktywacji legitymacji studenckiej. Pakiet pochodzi z punktu końcowego FrontSrv/rs/post/getPackage: uo0/b.java, yo0/b.java. Flaga MOB_DB_CONTAINERS, której wartości domyślne w artefakcie wynoszą false/false, przełącza całą implementację aktywacji pomiędzy ey3.a i wy3.a: a04/c.java, u54/y5.java. W starszej ścieżce packageData jest dekodowane i odszyfrowywane hasłem, po czym A1(...) wyciąga fullStudentData jako CMSSignedData i porównuje PESEL bez weryfikacji podpisu: d64/l.java, d64/l.java. Alternatywna implementacja również tworzy obiekty CMSSignedData z mapy pakietu bez znalezionej kontroli podpisujących: ey3/b.java. Flaga zmienia więc zaplecze magazynu i wykonanie aktywacji, ale w zbadanych wariantach nie usuwa omawianego braku.

CMSSignedData jest parserem i kontenerem; konstruktor ani getSignedContent() nie ustanawiają zaufania do podpisu. Dokumentacja projektu źródłowego pokazuje osobne pobranie getSignerInfos() i wywołanie signer.verify(...); zaznacza też, że nawet taki prosty przykład nie sprawdza jeszcze ważności certyfikatu. Bouncy Castle API — CMSSignedData. Prawidłowa walidacja wymaga co najmniej obecności oczekiwanej liczby podpisujących, weryfikacji kryptograficznej, budowy i polityki łańcucha certyfikatów, EKU/OID polityki, czasu, unieważnienia oraz związania podpisującego z typem dokumentu i środowiskiem.

Potwierdzone: klient przyjmuje i zapisuje w zidentyfikowanych przebiegach oraz odczytuje treść oznaczoną jako CMS SignedData bez znalezionej lokalnej weryfikacji podpisujących. Globalny wynik negatywny obejmuje również brak getSignerInfos(), SignerInformation.verify(), verifySignatures() i budowy SignerInformationVerifier poza biblioteką.

Niepotwierdzone: zwykły napastnik może samodzielnie dostarczyć taki kontener do repozytorium. Dane są chronione przez izolację aplikacji, TLS i w części przebiegów CMS EnvelopedData. Ta koperta kryptograficzna używa AES256_CBC i certyfikatu odbiorcy: bh2/a.java, dh2/a.java. Zapewnia poufność, lecz nie uwierzytelnia nadawcy ani nie jest trybem AEAD. Podmiot, który pozyska publiczny certyfikat odbiorcy, może technicznie zbudować skierowaną do niego kopertę; APK nie dowodzi jednak, że podmiot nieufny może pozyskać właściwy certyfikat i dostarczyć wynik do b0(...).

Nie należy mieszać tego z zewnętrzną warstwą pakietu aktywacyjnego legitymacji: w starszej implementacji C0/G0 używa hasła i AES/CBC/PKCS5Padding, a kod dopina IV na końcu szyfrogramu i nie pokazuje znacznika uwierzytelniającego: d64/l.java, d64/l.java, ch2/a.java, ch2/c.java. Niezależny ślad w nowej implementacji prowadzi od packageData i hasła przez generator klucza PBE do odszyfrowania wariantem z IvParameterSpec, a następnie do utworzenia CMSSignedData: ey3/b.java, ey3/b.java, y10/k.java, ey3/b.java. Jest to drugi rodzaj mechanizmu poufności bez potwierdzonej integralności kryptograficznej, obecny w obu implementacjach aktywacji; praktyczna modyfikacja nadal wymaga spełnienia formatu, dopełnienia, znajomości hasła lub kontrolowanej zmiany szyfrogramu oraz warunków dostarczenia pakietu. Dlatego błąd może stać się istotny przy przejęciu kanału, błędzie serwera, podatnym imporcie lub zapisie lokalnym, lecz nie wykazano samodzielnego zdalnego wektora.

Parametry KDF zewnętrznego pakietu aktywacyjnego, w tym potwierdzoną stałą sól PBKDF2, wydzielono jako niezależne ustalenie MOB-A-06. Nie są one dowodem braku weryfikacji CMS i nie należy sztucznie sumować obu wad, choć w jednym przepływie mogą wpływać na ten sam pakiet danych.

Aplikacja ma ogólny weryfikator Signature.initVerify()/verify() w y10/c.java, ale znaleziony odbiorca używa go do podpisu listy dzienników CT: iy3/c.java. Nie jest to gotowa implementacja polityki CMS: nie buduje łańcucha ani nie sprawdza EKU/OID, czasu i unieważnienia. Pokazuje jednak niespójność architektoniczną: podpis zewnętrznego artefaktu CT jest jawnie weryfikowany, podczas gdy podpisane dane dokumentów są jedynie odczytywane.

Test P0: w kontrolowanym środowisku sprawdzić na granicy przyjęcia danych i ponownie przy odczycie: (a) SignedData z uszkodzonym podpisem, (b) SignedData bez podpisujących, (c) podpis poprawny, ale wykonany nieufnym certyfikatem, (d) poprawny podpis niewłaściwego typu dokumentu/OID, (e) kopertę zbudowaną poza oczekiwanym producentem do publicznego certyfikatu testowego użytkownika i zawierającą jeden z nieufnych wariantów a–d oraz (f) bezpośrednie wstrzyknięcie wariantów a–e do b0(...) i pakietu aktywacyjnego. Należy osobno zmierzyć zachowanie obu stanów MOB_DB_CONTAINERS. Warianty a–f muszą zostać odrzucone przed zapisem i przed zbudowaniem modelu interfejsu użytkownika, a log ma wskazać konkretną przyczynę bez ujawnienia danych dokumentu. Koperta utworzona przez inny podmiot, ale przenosząca autentyczny, zaufany i świeży CMS, jest odrębnym przypadkiem ponownego podania danych i ustalania ich pochodzenia — sama koperta nie zawiera dowodu nadawcy.

Naprawa: jedna, centralna funkcja verifyThenDecode, wywoływana na granicy przyjęcia danych przed getEncoded() i zapisem; ponowna walidacja przy odczycie jako obrona warstwowa; brak publicznego API decode odczytującego niezweryfikowaną treść; testy negatywne dla braku podpisujących, złej sygnatury, obcego certyfikatu, złego OID i czasu; oddzielne typy UntrustedCmsBytes oraz VerifiedDocumentPayload. Dla nowych formatów należy zastąpić nieuwierzytelnione AES-CBC trybem AEAD lub poprawną konstrukcją „najpierw szyfrowanie, potem MAC” (encrypt-then-MAC). Nie należy jednak traktować tego jako zamiennika podpisu wystawcy dokumentu.

16.4. MOB-A-06 — globalna stała sól PBKDF2 w pakiecie aktywacyjnym legitymacji

Pakiet aktywacyjny legitymacji studenckiej jest szyfrowany kluczem wyprowadzanym z kodu aktywacyjnego. Śledzenie danych rozdziela dwa elementy przekazywane użytkownikowi: State.getActivationCode() jest argumentem hasłowym operacji deszyfrowania packageData, natomiast setupData.getQrCode() trafia osobno do operacji oznaczenia pakietu jako pobranego: z63/n.java, z63/n.java. Zasoby interfejsu również mówią osobno o kodzie QR i kodzie aktywacyjnym oraz deklarują ich jednorazowe użycie: strings.xml. Nie ma więc podstaw, aby nazywać hasło „kodem QR”; z APK nie odtworzono natomiast alfabetu, długości ani procesu losowania kodu aktywacyjnego.

Parametr 0 widoczny przy tworzeniu PBEKeySpec jest fałszywym tropem dekompilacyjnym. Wywołanie korzysta z maski argumentu domyślnego Kotlina, a konstruktor syntetyczny podstawia PKIFailureInfo.notAuthorized, czyli 65 536: lz/d.java, PKIFailureInfo.java. Generator przekazuje tę wartość do javax.crypto.spec.PBEKeySpec; algorytm to PBKDF2-HMAC-SHA256, a długość klucza wynosi 256 bitów: e20/g.java. Zarzut „zero iteracji” byłby nieprawdziwy.

Potwierdzonym problemem jest sól. saltStudentID to wpisana w kod, ośmiobajtowa stała {-73, 116, 33, -84, 127, -116, -18, -103} obecna w obu implementacjach: d64/p.java, ey3/b.java. Funkcja przedstawiona przez dekompilator jako łączenie trzech wartości wykonuje cykliczny XOR, a nie konkatenację ani KDF: hh2/a.java. Wszystkie trzy argumenty są identyczne, więc wynik algebraicznie pozostaje tą samą ośmiobajtową stałą: salt XOR salt XOR salt = salt. Nowa ścieżka przekazuje je jawnie w ey3/b.java; starsza ścieżka robi to przez funkcję pomocniczą w bh2/a.java, wywołaną z tym samym stałym argumentem trzykrotnie w d64/l.java. Nie należy zatem przedstawiać tej funkcji pomocniczej jako dowodu użycia losowej soli dla legitymacji studenckiej.

Skutek kryptograficzny jest precyzyjny: sól nie zapewnia rozdzielenia użytkowników ani pakietów, a identyczny kod aktywacyjny i te same parametry PBKDF2 prowadzą do identycznego klucza AES. Napastnik posiadający wiele szyfrogramów może amortyzować przygotowanie słownika między celami. Jednorazowość kodu ogranicza jego ponowne użycie w legalnym protokole, lecz sama nie usuwa ataku słownikowego poza aplikacją po pozyskaniu pakietu. AES-CBC z dopełnieniem i przewidywalnie ustrukturyzowanym wynikiem może dostarczyć sposobu rozpoznania poprawnego odgadnięcia, ale jego praktyczność — podobnie jak kanał pozyskania packageData — wymaga potwierdzenia laboratoryjnego. Nie wykazano odzyskania kodu ani danych użytkownika.

Liczba 65 536 iteracji jest znacznie niższa od współczesnego punktu odniesienia OWASP wynoszącego 600 000 dla PBKDF2-HMAC-SHA256. Jest to porównanie z zaleceniem dotyczącym przechowywania haseł; nie stanowi automatycznego dowodu naruszenia normy tego protokołu ani samodzielnej podatności. Właściwy koszt należy dobrać do entropii sekretu, wydajności urządzeń i modelu zagrożeń. OWASP Password Storage Cheat Sheet.

Ocena: Niskie–Średnie, warunkowe. Stała globalna sól i parametry KDF są potwierdzone statycznie. Podniesienie oceny wymaga wykazania, że kod ma małą przestrzeń, zaszyfrowany pakiet jest dostępny napastnikowi i istnieje wiarygodny sposób sprawdzania zgadywanego kodu poza aplikacją. Brak uwierzytelnienia AES-CBC z MOB-A-05 zwiększa wagę całego przebiegu, ale pozostaje odrębną własnością kryptograficzną i nie powinien być liczony drugi raz jako skutek stałej soli.

Test P0: pozyskać w autoryzowanym środowisku co najmniej dwa pakiety testowe dla różnych kont i kontrolowanego tego samego kodu, potwierdzić powtarzalność soli oraz wyprowadzonego klucza, udokumentować alfabet, długość, rozkład, sposób generowania, TTL, jednorazowość i kanał przekazania kodu, a następnie zmierzyć koszt kontrolowanego słownika poza aplikacją dla rzeczywistego formatu. Osobno sprawdzić, czy dopełnienie, parser JSON/CMS lub komunikaty błędów tworzą niezawodny sposób potwierdzenia odgadnięcia. Wyniki należy zachować także wtedy, gdy hipoteza praktycznego ataku zostanie obalona.

Naprawa: generować kryptograficznie losową, unikalną sól co najmniej 16-bajtową dla każdego pakietu i przechowywać ją jawnie w uwierzytelnionym nagłówku; przejść na AEAD; wersjonować parametry KDF oraz format i jawnie odrzucać przejście do słabszego wariantu ze stałą solą. Koszt KDF należy dobrać pomiarem na wspieranych urządzeniach i zapisać jako politykę aktualizowalną bez zmiany kodu. Jeżeli kod aktywacyjny ma małą entropię, sama większa liczba iteracji nie zastąpi projektu protokołu odpornego na zgadywanie poza aplikacją.

16.5. MOB-A-08 — eksportowalny klucz prywatny w pakiecie aktywacyjnym i bazie aplikacji

MOB-A-06 określa koszt zaatakowania zewnętrznej warstwy pakietu. Analiza tekstu jawnego po jej odszyfrowaniu rozstrzyga, co stanowi chroniony zasób. StudentPackageData zawiera trzy pola typu String: pkcs12Pass, pkcs12Data oraz signedDataList: StudentPackageData.java. Implementacja aktywacji dekoduje Base64 obu pierwszych pól, zamienia hasło na char[] i wywołuje moduł zarządzający PKCS#12 z aliasem mlWork: ey3/b.java. Moduł ten ładuje magazyn Bouncy Castle PKCS#12, pobiera certyfikat X.509 i odpowiadający mu PrivateKey, po czym zwraca CertKeyPair: y10/b.java.

Hasło PKCS#12 i chroniony nim magazyn są współlokowane w tym samym zaszyfrowanym obiekcie. Hasło może wykrywać błędne odszyfrowanie i chronić sam plik PKCS#12 po jego przypadkowym oddzieleniu, ale nie stanowi niezależnej granicy poufności wobec podmiotu, który odszyfruje cały pakiet. Taki podmiot otrzymuje jednocześnie pkcs12Data i pkcs12Pass. Ochroną sieciową pozostają TLS i przypinanie certyfikatów; raport nie twierdzi, że szyfrogram jest dostępny pasywnemu napastnikowi internetowemu. Na poziomie formatu aplikacyjnego zewnętrzną granicą jest jednak PBKDF2 ze stałą solą oraz AES-CBC bez widocznego znacznika AEAD/MAC. Wewnętrzna integralność PKCS#12 nie obejmuje osobnego pola signedDataList, którego obiekty CMS są następnie jedynie odczytywane, jak opisano w MOB-A-05.

Po imporcie klucz nie jest zachowywany jako nieeksportowalny uchwyt AndroidKeyStore. saveUserCertificateUC otrzymuje typ UNIVERSITY, pustą starą frazę oraz CertKeyPair: ey3/b.java. Repozytorium serializuje getPrivateKey().getEncoded() bezpośrednio do pola privateKey encji certyfikatu: xx3/a.java, CertificateEntity.java. Jest to eksportowalna reprezentacja PKCS#8, a nie alias nieeksportowalnego klucza sprzętowego.

Baza nie jest przy tym jawnym SQLite. Jest otwierana przez SQLCipher z kluczem przekazanym do SupportOpenHelperFactory: o20/c.java. Produkcyjny dostawca pobiera klucz z masterKeyProvider: p20/d.java, u54/j2.java. Materiał klucza głównego jest utrzymywany w pamięci procesu, a szersza ścieżka zarządzania kluczami obsługuje klucze AndroidKeyStore: v14/a.java, co1/z.java. Oznacza to sensowną warstwę ochrony przechowywanych danych przed prostym skopiowaniem pliku bazy. Nie zmienia jednak podstawowej właściwości: po otwarciu bazy aplikacja odtwarza pełne bajty prywatnego klucza, a ich poufność zależy od klucza SQLCipher i bezpieczeństwa procesu, zamiast od sprzętowo egzekwowanej nieeksportowalności samego klucza.

Klucz UNIVERSITY nie jest martwym artefaktem. Warstwa tożsamości pobiera właśnie ten CertKeyPair dla legitymacji studenckiej: u54/h2.java. Wspólna infrastruktura używa prywatnych kluczy CertKeyPair do podpisywania JWS oraz CMS i do odszyfrowywania kluczy danych: j01/a.java, m0.java, nw0/h.java. Analiza statyczna pozwala więc nazwać go aktywnym prywatnym kluczem certyfikatu tożsamości aplikacyjnej. Nie dowodzi natomiast, że jest to klucz kwalifikowanego podpisu elektronicznego ani że samodzielnie umożliwia wykonanie czynności prawnej; takiego sformułowania raport celowo nie używa.

Higiena pamięci i ryzyko diagnostyczne

W ey3/b.java nie znaleziono Arrays.fill ani równoważnego czyszczenia. Odszyfrowany JSON, pkcs12Data, pkcs12Pass, char[], klucz AES, bufory PKCS#12 i obiekt PrivateKey powstają jako kolejne kopie oraz są utrzymywane w polach stanu korutyny. Sekrety zapisane jako niemutowalne String nie mogą zostać deterministycznie wyzerowane przed pracą mechanizmu odśmiecania pamięci (GC). Nie jest to samodzielny zdalny wektor, ale zwiększa skutki zrzutu pamięci, narzędzia diagnostycznego, podatności procesu albo analizy urządzenia po aktywacji.

Dwa automatycznie wygenerowane toString() są szczególnie niebezpiecznym wzorcem: StudentPackageData.toString() wypisuje całe pkcs12Pass, pkcs12Data i signedDataList, a CertificateEntity.toString() wypisuje tablice certyfikatu i prywatnego klucza bajt po bajcie: StudentPackageData.java, CertificateEntity.java. Nie znaleziono bezpośredniego miejsca wywołania, które zapisywałoby te obiekty w logach w analizowanej ścieżce, dlatego raport klasyfikuje to jako potencjalny wyciek diagnostyczny, a nie potwierdzoną eksfiltrację do Sentry.

Wpływ, model ataku i ocena

Jeżeli napastnik uzyska szyfrogram packageData i rzeczywista polityka kodów umożliwi atak słownikowy poza aplikacją, poprawne odgadnięcie odsłoni nie tylko dane dokumentu, lecz również plik PKCS#12, jego hasło i eksportowalny klucz prywatny. Możliwe następstwa zależą od rozszerzeń certyfikatu, akceptowanych operacji, ważności, unieważnienia oraz kontroli serwera. Mogą obejmować odtwarzanie aplikacyjnych podpisów lub uwierzytelnień albo odszyfrowywanie danych przeznaczonych dla tego certyfikatu, ale nie zostały jeszcze wykazane na produkcyjnym zapleczu serwerowym.

Atak na kopię bazy ma inną granicę: sam plik SQLCipher nie wystarcza bez klucza bazy. Po zdobyciu klucza SQLCipher pełny PKCS#8 jest jednak odzyskiwalny, ponieważ aplikacja nie przechowuje wyłącznie aliasu sprzętowego. Uprawnienia root lub pełna kontrola procesu dają już szerokie możliwości i nie powinny sztucznie podnosić CVSS; właściwym pytaniem jest odporność na kradzież kopii, lukę w procesie, zrzut po odblokowaniu oraz zakres skutków po utracie jednego urządzenia.

Ocena: Średnie, warunkowo Wysokie po P0. Potwierdzone są współlokacja klucza i hasła, eksportowalna postać PKCS#8, brak deterministycznego czyszczenia oraz brak izolacji klucza w AndroidKeyStore. Ocena Wysoka wymaga jednoczesnego wykazania praktycznego odzyskania kodu poza aplikacją z dostępnego szyfrogramu i skutecznego użycia odzyskanego klucza wobec nadal akceptującego go systemu. Bez tych dowodów określenie „przejęcie podpisu” byłoby nadinterpretacją.

Test P0: w wydzielonym środowisku i na własnych danych testowych: (a) zachować wyłącznie szyfrogram pakietu i przeprowadzić pomiar rzeczywistej przestrzeni kodów; (b) po kontrolowanym odzyskaniu kodu wyodrębnić PKCS#12, zweryfikować hasło i zgodność klucza z certyfikatem; (c) ustalić KeyUsage, ExtendedKeyUsage, wystawcę, okres ważności i wszystkie protokoły akceptujące certyfikat; (d) wykonać nieszkodliwy test podpisu i odszyfrowania w środowisku testowym; (e) unieważnić certyfikat i potwierdzić odrzucenie starego klucza w każdym punkcie końcowym; (f) po aktywacji wykonać kontrolowany zrzut sterty oraz inspekcję logów/Sentry pod kątem obu DTO i buforów; (g) skopiować bazę przed i po odblokowaniu, wykazać granicę SQLCipher oraz potwierdzić odzyskiwalność PKCS#8 dopiero po zdobyciu klucza bazy. Wyniki muszą rozdzielać przejęcie zawartości pakietu, procesu i bazy.

Naprawa: preferowany projekt generuje parę kluczy na urządzeniu wewnątrz AndroidKeyStore, wysyła wyłącznie CSR lub klucz publiczny i przechowuje alias zamiast PKCS#8. Polityka powinna wymagać TEE albo StrongBox tam, gdzie model zagrożeń tego wymaga, z jawnym zachowaniem na urządzeniu niespełniającym wymagań. Jeżeli import klucza wystawionego zewnętrznie jest nieunikniony, należy natychmiast importować go do AndroidKeyStore z restrykcyjnym KeyProtection, zweryfikować rzeczywisty poziom zabezpieczenia i usuwać wszystkie kopie importowe; sam import nie gwarantuje sprzętowej ochrony na każdym urządzeniu. Pakiet trzeba chronić AEAD, losową solą dla każdego pakietu, wysoką entropią sekretu oraz związaniem z użytkownikiem, urządzeniem, sesją i wersją protokołu. Hasło PKCS#12 przesłane obok magazynu nie może być przedstawiane jako dodatkowa bariera. Typy zawierające sekrety nie mogą generować toString(), equals() ani hashCode() operujących na pełnym materiale; bufory należy ograniczyć do byte[]/char[], czyścić w finally, a rotację i natychmiastowe unieważnienie klucza traktować jako element procedury incydentowej.

16.6. Ograniczenia skanu zależności

Analiza składu oprogramowania obejmowała komponenty o współrzędnych Maven. Dla bibliotek natywnych .so wykonano przegląd utwardzenia ELF oraz identyfikację pochodzenia opisane w sekcji 19, nie przeprowadzono natomiast pełnej korelacji z bazami CVE opartej na wersji i build-id. Ta korelacja, wraz z usługami Google dostarczanymi poza APK, kodem zaplecza serwerowego oraz komponentami bez współrzędnych Maven, pozostaje poza zakresem tego etapu. Bazy podatności są opóźnione i niekompletne, dlatego wynik „zero trafień” nie jest dowodem braku błędów, a „trafienie” nie jest jeszcze dowodem osiągalności.

17. Detekcja zagrożeń — rzeczywista konfiguracja i jej granice

APK zawiera rozbudowany model raportu SDK BotSense, który teoretycznie przewiduje dane urządzenia, sieci, lokalizacji, integralności i klienta. Analiza samego modelu prowadziłaby do fałszywego wniosku o szerokim zbieraniu danych. Konfiguracja aplikacyjna jest znacznie węższa:

• wyłącza większość raportów urządzenia i usług;
• pozostawia aktywny test emulacji;
• uruchamia osobno RootBeer;
• kwalifikuje poziom poprawki sprzed 1 września 2017 r. jako ryzyko BlueBorne;
• przekazuje SDK literal testUserID i nie wskazuje w tej ścieżce zdalnego URL konfiguracji;
• przekazuje wykryte wyniki do zdalnego loggera jako THREAT_DETECTED.

Dowody: h83/c.java, h83/c.java, h83/c.java.

Odrębnie od heurystyk RootBeer/BotSense w APK znajduje się rzeczywista ścieżka Play Integrity. Konfiguracja niesie projectNumber, klient generuje 16 losowych bajtów przez SecureRandom, koduje je jako wartość jednorazową (nonce) i wywołuje requestIntegrityToken; wynik oraz ta wartość trafiają do raportu: c74/i.java, w64/l4.java, w64/g4.java. Generator kluczy AndroidKeyStore obsługuje także setAttestationChallenge, ale wyłącznie dla ścieżki EC i tylko wtedy, gdy wyzwanie jest niepuste: e20/m.java. Są to poprawne mechanizmy obronne i należy je odnotować. Analiza statyczna klienta nie pokazuje jednak, jak serwer weryfikuje token, wartość jednorazową, wiek werdyktu, licencję i rozpoznanie urządzenia ani jakie decyzje od nich zależą. Obecność API nie może więc zostać przekształcona w ogólne zapewnienie integralności urządzenia.

RootBeer i BotSense zwiększają koszt prostych modyfikacji, ale nie powinny stanowić jedynej przesłanki autoryzacji. Lokalny klient jest kontrolowany przez właściciela urządzenia; decyzje o wydaniu dokumentu, podpisie lub zmianie stanu muszą opierać się na kryptograficznie związanej sesji, świeżości, poświadczeniu integralności urządzenia o jasno opisanej polityce i walidacji serwera. Wykrycie uprawnień root nie naprawia błędu autoryzacji, a ich niewykrycie nie może oznaczać zaufania absolutnego.

18. Dziennik hipotez, ślepych uliczek i korekt

Wzorem analiz SKCI i EFITool zachowano nie tylko wynik końcowy, ale również ścieżki, które wyglądały obiecująco i zostały odrzucone. Pozwala to odtworzyć rozumowanie i zapobiega ponownemu przedstawianiu obalonych tez jako odkryć.

Ta tabela nie „broni” produktu. Oddziela to, co można zaatakować dowodem, od tego, co jedynie źle wygląda. Pozwala dzięki temu ostrzej sformułować potwierdzone zarzuty bez rozcieńczania ich błędami.

18.1. Macierz kompletności przeglądu klas zagrożeń

Poniższa macierz określa, co rzeczywiście sprawdzono w artefakcie. Wynik „brak potwierdzonego wektora” nie znaczy „niemożliwe”; oznacza, że przeszukanie miejsc wywołań nie wykazało przepływu z niezaufanego wejścia do niebezpiecznej operacji w dostępnej analizie statycznej.

19. Kod natywny i pozostała nieprzejrzysta powierzchnia

Pakiety dzielone dla arm64-v8a, armeabi-v7a, x86 i x86_64 zawierają po 11 bibliotek natywnych:

Kontrola nagłówków plików i nagłówków programu wszystkich 11 bibliotek w pakiecie ARM64 przyniosła wynik pozytywny:

Jedynym plikiem bez odwołania do __stack_chk_fail jest liczący około 10 KiB libdatastore_shared_counter.so. Eksportuje krótkie operacje JNI na liczniku, mmap i ftruncate; brak symbolu nie dowodzi globalnego wyłączenia ochrony, ponieważ kompilator wstawia ochronę stosu tylko do funkcji spełniających jego kryteria. Dlatego nie utworzono z tego pozornej podatności. Uczciwy wniosek brzmi: konfiguracja podstawowego utwardzenia ELF dla ARM64 jest dobra, ale sam zestaw flag nie dowodzi bezpieczeństwa logiki ani parserów. Zestawienie wszystkich jedenastu bibliotek z ich pochodzeniem prowadzi do wniosku odrębnego od samego utwardzenia: każda odpowiada znanemu komponentowi zewnętrznemu — Google i AndroidX (ścieżki graficzne, DataStore, ML Kit OCR, Barhopper, przetwarzanie obrazu i powierzchni), Conscrypt nad BoringSSL, SQLCipher firmy Zetetic, SDK Sentry oraz otwartoźródłowy RootBeer. Pochodzenie tego ostatniego potwierdza sama warstwa Java: RootBeerNative.java ładuje bibliotekę wywołaniem System.loadLibrary("toolChecker"), co wiąże przemianowany plik libtoolChecker.so z pakietem com.scottyab.rootbeer. W badanym zestawie nie zidentyfikowano ani jednej biblioteki natywnej wytworzonej przez COI lub PWPW; cała logika własna aplikacji — e-dowód, kryptografia tożsamości, przepływy uwierzytelniania i interfejs — pozostaje w bajtkodzie JVM. Ma to dwojaki skutek: z jednej strony powierzchnia natywna nie kryje autorskiej kryptografii ani parserów, które wymagałyby osobnej inżynierii wstecznej; z drugiej — jedyny natywny mechanizm bezpieczeństwa aplikacji, detekcja roota, jest niezmienioną biblioteką otwartoźródłową o znanym i trywialnie obchodzalnym zachowaniu.

Jedyna pozycja w grupie „detekcja środowiska”, libtoolChecker.so, nie jest komponentem własnym. Analiza symboli i ciągów znakowych wskazała przemianowaną natywną część otwartoźródłowego RootBeera: biblioteka eksportuje Java_com_scottyab_rootbeer_RootBeerNative_checkForRoot oraz Java_com_scottyab_rootbeer_RootBeerNative_setLogDebugMessages, importuje jedynie fopen, fclose i __android_log_print, a jej działanie sprowadza się do sprawdzania obecności znanych binarek roota po ścieżkach (ciąg „LOOKING FOR BINARY: %s”). Nie zawiera ptrace, kontroli antydebugowej ani innych mechanizmów. Zmiana nazwy pliku ukrywa pochodzenie, lecz nie zmienia zachowania. Potwierdza to wcześniejszą ocenę: wykrywanie roota podnosi koszt prostych modyfikacji, ale pozostaje heurystyką, a nie granicą zaufania.

Zestaw kontroli RootBeera jest jawny i dobrze udokumentowany. Sprawdzane są: obecność binarki su w typowych ścieżkach oraz busyboxa i artefaktów Magiska; zainstalowane pakiety menedżerów roota i aplikacji maskujących; znacznik test-keys w ro.build.tags; niebezpieczne właściwości systemu, na przykład ro.debuggable i ro.secure; a także zamontowanie partycji systemowych w trybie do zapisu. Część natywna ogranicza się do fopen po ścieżkach przekazanych z warstwy Java.

Wszystkie te kontrole operują na stanie widzianym przez proces aplikacji, dlatego poprawnie skonfigurowany Magisk je neutralizuje. Mechanizm DenyList wraz z Zygiskiem działa w przestrzeni nazw montowań konkretnej aplikacji: odmontowuje nakładki i moduły, tak że partycje systemowe są widziane jako tylko do odczytu, a binarka su oraz pliki Magiska pozostają niewidoczne dla tego procesu. Ukrycie i przepakowanie menedżera pod losową nazwą pakietu omija wykrywanie po nazwie, a przywrócenie właściwości systemu do wartości domyślnych usuwa sygnały test-keys oraz niebezpiecznych property. Po tej stronie wszystkie heurystyki zwracają wynik negatywny.

Niezależnie od Magiska sama lokalizacja kontroli w procesie klienta czyni ją podatną na instrumentację: przechwycenie metod narzędziem takim jak Frida lub moduł LSPosed sprawia, że wynik isRooted() jest zawsze negatywny, bez jakiejkolwiek modyfikacji systemu plików. Płynie stąd wniosek spójny z resztą raportu: rozstrzygający sygnał integralności środowiska musi pochodzić z mechanizmu poświadczanego sprzętowo i weryfikowanego po stronie serwera, takiego jak Play Integrity, a nie z heurystyki wykonywanej przez badany proces.

Przegląd wszystkich bezpośrednich konstrukcji PendingIntent.get* również nie wykazał mutowalnej akcji należącej do aplikacji. Własne powiadomienia używają wartości 201326592, czyli FLAG_IMMUTABLE | FLAG_UPDATE_CURRENT: FirebaseService.java, x54/c.java. Funkcja pomocnicza Google Play Services wybiera flagę niemutowalności dla przebiegu interfejsu: s5/r.java. Wyjątkiem jest odziedziczona funkcja pomocnicza rejestracji Google, która od Androida 12 tworzy mutowalny PendingIntent do pakietu com.google.example.invalidpackage: fg/c.java, wg/a.java. Jest on przekazywany jako identyfikator pochodzenia, lecz nie wskazuje uprzywilejowanej akcji aplikacji i w badanym śladzie nie daje odbiorcy kontroli nad funkcją mObywatela. Pozostaje długiem bibliotecznym: należy potwierdzić aktualność zależności i usunąć mechanizm, jeżeli współczesny protokół rejestracji go nie wymaga.

Obecny etap nie objął kompletnej inżynierii wstecznej, symbolicznego śledzenia wejść ani testowania mutacyjnego JNI. Szczególnie istotne są parsery obrazu i kodów, SQLCipher, Conscrypt oraz granice Java↔JNI, ponieważ błędy pamięci w kodzie natywnym mogą zmienić obserwację biblioteczną w wykonanie kodu lub eskalację wewnątrz procesu aplikacji.

Niezbędne uzupełnienie: skróty kryptograficzne każdej biblioteki dla każdej ABI, identyfikacja wersji i build-id, powtórzenie kontroli utwardzenia dla pozostałych ABI, kontrola CFI/PAC/BTI, mapowanie eksportów JNI, testowanie mutacyjne danych wejściowych i porównanie z komunikatami projektu źródłowego. Brak pełnej analizy kodu natywnego jest jawną luką zakresu, a nie przemilczanym zapewnieniem bezpieczeństwa.

20. Publiczny kod, licencja i niezależny demonstrator C++23/WinAPI

20.1. Co rzeczywiście opublikowano

Sprawdzona kopia publicznego repozytorium wskazywała zmianę d39d2f947b1078332d758de086cb3cb7dd163940 z 4 stycznia 2026 r. i zawierała 192 pliki Kotlin. Zakres odpowiada systemowi wzornictwa i interfejsowi użytkownika, a nie pełnej aplikacji. Pliki COI są objęte dołączoną licencją MIT; licencję kopii repozytorium i prawa do innych składników należy rozpatrywać oddzielnie. Licencja na kod nie udziela automatycznie prawa do znaków, nazwy, urzędowych symboli ani sugerowania autoryzacji państwowej.

Oficjalny komunikat z 29 grudnia 2025 r. mówi o publikacji „kodu źródłowego aplikacji”. Technicznie dostępny zakres nie umożliwia zbudowania aplikacji ani audytu warstw bezpieczeństwa. To uzasadnia precyzyjną krytykę braku przejrzystości, ale nie uprawnia do twierdzenia, że każda brakująca część jest wadliwa. Komunikat Ministerstwa Cyfryzacji.

20.2. Pochodzenie badanej kopii kodu

Ustalenia tej i następnej części opierają się na kopii, której pochodzenie wymaga osobnego opisu, ponieważ wpływa ono na zakres ważności wniosków.

Oficjalna publikacja ma postać strony https://www.mobywatel.gov.pl/kod-zrodlowy-mobywatel-mobilny, dostępnej po potwierdzeniu tożsamości aplikacją mObywatel, profilem zaufanym, bankowością lub eID. Komunikat BIP Ministerstwa Cyfryzacji wywodzi ten wymóg z opinii CSIRT MON i uzasadnia go „zapewnieniem kryterium rozliczalności użytkowników”. Strona udostępnia kod w przeglądarce galerii, z numerami wierszy wplecionymi w wyświetlany tekst i zablokowanym prawym przyciskiem myszy. Środowisko kontroli wersji, historia zmian, mechanizm zgłaszania błędów i możliwość porównania wydań pozostają poza tą publikacją.

Praktyczną konsekwencją takiej formy jest to, że pozyskanie kodu do analizy wymaga skryptu użytkownika do pobrania plików, skryptu do odtworzenia drzewa katalogów i skryptu do usunięcia numerów wierszy. Narzędzia te powstały w społeczności i są dostępne wraz z kopiami lustrzanymi. Licencja MIT zezwala na redystrybucję, więc kopie te działają legalnie — i to one, a nie kanał urzędowy, stanowią realne źródło dla niezależnego badacza.

Materiał badany w tej sekcji. Kopia lokalna obejmuje 192 pliki Kotlin systemu wzorniczego i jest identyczna bit w bit z kopią lustrzaną neziw/mObywatel-mirror: zgadza się 192 z 192 sum kontrolnych blobów Gita, przy zerowej liczbie plików nadmiarowych i brakujących. Kopia lustrzana została utworzona 29 grudnia 2025 r. i zamrożona 30 grudnia 2025 r.

Druga kopia lustrzana, fajfer/mObywatel, zamrożona 4 stycznia 2026 r. na zmianie d39d2f947b1078332d758de086cb3cb7dd163940 przywołanej w sekcji 20.1, zawiera ten sam zbiór 192 plików. Porównanie treści wykazało różnice w 10 plikach, ograniczone wyłącznie do białych znaków na końcach wierszy, usuniętych przez opiekuna tej kopii. Dwa niezależne zgrania tej samej publikacji dają zatem zgodny kod źródłowy, co pozwala traktować badany materiał jako wierny oryginałowi.

Rozgraniczenie czasowe. Kod źródłowy stanowi zrzut z przełomu grudnia 2025 i stycznia 2026 r., badany we wrześniu 2026 r., a więc po ośmiu miesiącach. Analiza binarna opisana w pozostałych sekcjach dotyczy pakietu 4.87.2 pobranego i rozłożonego w sierpniu i wrześniu 2026 r. Ustalenia jakościowe z sekcji 20.3 zachowują ważność dla tego zrzutu i wymagają ponownej weryfikacji wobec bieżącego stanu publikacji. Ustalenia dotyczące bezpieczeństwa opierają się na binarce i pozostają od tego rozgraniczenia niezależne. Ponieważ kanał urzędowy nie udostępnia historii zmian, ustalenie, które z opisanych usterek naprawiono w międzyczasie, wymaga ponownego zalogowania się i ręcznego porównania plików.

20.3. Jakość opublikowanego kodu — przegląd statyczny

Publikacja na licencji MIT czyni ten przegląd uprawnionym i odtwarzalnym. Kod powstał ze środków publicznych, a warunki licencji zezwalają na jego badanie, kopiowanie i modyfikowanie z zachowaniem noty licencyjnej. Otwarcie kodu oznacza więc przyjęcie stałej kontroli zewnętrznej: od dnia publikacji każda usterka w tej warstwie pozostaje sprawdzalna przez dowolnego czytelnika.

Ocena obejmuje wyłącznie rzemiosło programistyczne i architekturę opublikowanej warstwy interfejsu. Materiał ten pozbawiony jest warstw rozstrzygających o bezpieczeństwie (zob. sekcja 1), wobec czego ustalenia oznaczone MOB-Q-xx mają charakter jakościowy i pozostają poza klasyfikacją podatności. Numerację wydzielono z ciągów MOB-A-xx i MOB-O-xx celowo, aby granica ta pozostała czytelna także po wyrwaniu tabeli z kontekstu.

Zakres i metoda. 192 pliki Kotlin, 18 885 wierszy. Z tego 4 894 wiersze (25,9%) w 33 plikach dostawców danych podglądowych pełnią funkcję materiału poglądowego dla środowiska programistycznego; realny kod komponentów obejmuje około 14 tysięcy wierszy. Przegląd objął wzorce Compose, stabilność rekompozycji, trwałość stanu interfejsu, spójność systemu tokenów wzorniczych, granicę publicznego API, warstwową strukturę zależności oraz dostępność. Każde ustalenie wskazuje plik i numer wiersza, co pozwala je zweryfikować niezależnie na kopii opisanej w sekcji 20.2. Ustalenia tej sekcji poddano niezależnej kontroli krzyżowej z użyciem odrębnego zestawu narzędzi analitycznych, prowadzonej na tej samej kopii materiału. Kontrola potwierdziła ustalenia zachowane poniżej, doprowadziła do wycofania jednego zarzutu dotyczącego lokalizacji tekstów — opisanego w części poświęconej warsztatowi — oraz wniosła cztery ustalenia grupy A i D. Tezy zgłoszone w toku tej kontroli, których nie potwierdziło czytanie kodu źródłowego, odrzucono i nie ujęto ich w zestawieniu.

Zestawienie ustaleń jakościowych

Ustalenia pogrupowano tematycznie, ponieważ dopiero zestawione razem oddają charakter materiału. Grupa A gromadzi defekty dostępności, grupa B usterki implementacyjne, grupa C decyzje architektoniczne, grupa D spójność i utrzymanie.

Grupa A — dostępność

Warstwa dostępności wymaga omówienia w pierwszej kolejności, ponieważ łączy najbogatszą infrastrukturę w całym materiale z największym skupieniem defektów. Wielkość nakładu opisano niżej, w części poświęconej warsztatowi; tutaj zebrano miejsca, w których ten nakład zawodzi.

MOB-Q-01 — komunikat o błędzie zapowiadany etykietą sukcesu

Plik alert/AlertData.kt definiuje cztery warianty komunikatu, każdy z domyślną etykietą dostępności przycisku zamknięcia. Trzy pierwsze zachowują konsekwencję, czwarty powiela etykietę wariantu trzeciego:

Użytkownik czytnika ekranu zamykający komunikat o błędzie usłyszy zapowiedź przypisaną komunikatowi o powodzeniu. Wartość ta pełni rolę domyślnej, wobec czego zachowanie ujawnia się wszędzie tam, gdzie strona wywołująca pozostawia parametr bez zmiany. Zawartość dostawcy CommonUILabelProvider pozostaje poza publikacją, wobec czego istnienie odrębnej etykiety dla wariantu błędu wymaga potwierdzenia po stronie wykonawcy; sama asymetria wobec trzech pozostałych wariantów wynika wprost z kodu.

MOB-Q-14 — niema etykieta zamknięcia banera

Bliźniaczy komponent rozwiązuje ten sam problem inaczej i z gorszym skutkiem. Wszystkie cztery warianty w banner/BannerData.kt przyjmują jako wartość domyślną etykietę pustą:

closeIconContentDescription: Label = Label.EMPTY   // wiersze 46, 63, 80, 106

Wartość ta trafia wprost do contentDescription ikony zamknięcia (banner/BannerData.kt:29,95,121). Czytnik ekranu napotyka przycisk pozbawiony nazwy i zapowiada go opisem zastępczym systemu. Zestawienie z AlertData, gdzie każdy wariant dostarcza etykietę rzeczywistą, pokazuje dwa różne standardy dostępności w obrębie jednego systemu wzorniczego dla dwóch komponentów o tej samej funkcji.

MOB-Q-15 — akcja dostępnościowa zgłaszana jako nieobsłużona

custom/clickabletext/CustomClickableText.kt:38-41:

.semantics {
  role = Role.Button
  onClick { false }
}

Wartość zwracana przez procedurę onClick w semantyce informuje usługę dostępności o powodzeniu akcji. Zapis { false } deklaruje akcję trwale nieobsłużoną, przy jednoczesnym ogłoszeniu elementu jako przycisku. Właściwa obsługa dotknięcia realizowana jest przez ClickableText na poziomie zdarzeń wskaźnika, a więc poza ścieżką akcji dostępnościowych, co pozbawia ten element drogi zastępczej. Komponent nosi adnotację @Deprecated odsyłającą do Link i ButtonText (zob. MOB-Q-19), co ogranicza zasięg ustalenia do miejsc, w których pozostaje w użyciu.

MOB-Q-16 — wyłączone wymuszanie minimalnego celu dotykowego

button/Button.kt:341-346 opakowuje każdy przycisk systemu w dostawcę wyłączający platformowy mechanizm minimalnego pola dotykowego:

CompositionLocalProvider(LocalMinimumInteractiveComponentEnforcement provides false) {
  content()
}

Mechanizm ten istnieje w Material 3 po to, aby gwarantować cel dotykowy o wymiarach 48×48 dp niezależnie od rozmiaru rysowanego elementu. Wyłączenie obejmuje wszystkie przyciski systemu, w tym warianty ButtonSize.Small o wysokości spacing400 (button/Button.kt:322) oraz przyciski ikonowe o wymiarze spacing400 (button/Button.kt:334, :289). Wartości liczbowe AppTheme.dimensions należą do nieopublikowanego pakietu theme, wobec czego wynikowy rozmiar w jednostkach dp wymaga potwierdzenia po stronie wykonawcy. Rozstrzygnięty pozostaje natomiast sam fakt: zabezpieczenie ustanowione dla spełnienia kryteriów WCAG 2.5.5 i 2.5.8 zostało świadomie i globalnie wyłączone, a odpowiedzialność za rozmiar celu przeniesiona na wywołującego.

Wykorzystane API nosi ponadto status wycofanego w nowszych wydaniach Material 3 na rzecz LocalMinimumInteractiveComponentSize.

MOB-Q-17 — wymóg WCAG zrealizowany jako oznaczony hack

topappbar/TopAppBarUtil.kt:10-28 zawiera funkcję opatrzoną adnotacją, która sama opisuje swój charakter:

@Deprecated(
  "This is hack for WCAG requirements to focus titles on every screen enter." +
    " Should be deleted with task MOB-72178",
)
@Composable
fun forceFocusOnStart(forceFocusTrigger: Boolean?): FocusHost {
  ...
  LaunchedEffect(forceFocusTrigger) {
    delay(1L)
    focusManager.clearFocus(true)
    delay(1L)
    focusHost.requestFocus()
  }

Przeniesienie ogniska uwagi na nagłówek ekranu — wymóg wynikający z kryteriów WCAG — oparto na dwóch opóźnieniach o długości jednej milisekundy, sekwencjonujących wyczyszczenie i zażądanie ogniska. Konstrukcja tego rodzaju zależy od czasu wykonania kompozycji i zachowuje się różnie na urządzeniach o odmiennej wydajności. Funkcja pozostaje w czynnym użyciu we wszystkich czterech wariantach paska: topappbar/large/LargeTopAppBar.kt:43, medium/MediumTopAppBar.kt:42 oraz small/SmallTopAppBar.kt:49 i :75.

Adnotacja przewiduje usunięcie funkcji zadaniem MOB-72178. Zgodność z wymogiem dostępności opiera się zatem na rozwiązaniu, które zespół autorski zakwalifikował jako tymczasowe, a mimo to wydał publicznie i utrzymuje we wszystkich ekranach aplikacji.

Grupa B — usterki implementacyjne

MOB-Q-02 — literalny $ w identyfikatorze

textinput/TextField.kt:363:

.let { tag -> "$tag${indexTag?.let { "_$$indexTag" } ?: ""}" }

Zapis "_$$indexTag" daje wynik _$5 zamiast _5: pierwszy znak $ poprzedza kolejny $, wobec czego pozostaje znakiem dosłownym. Ta sama klasa dwie funkcje wyżej, w wierszu 311, zawiera zapis poprawny — "_$indexTag". Różnica jednego znaku między dwoma niemal identycznymi fragmentami wskazuje na powielenie kodu bez ponownego przeczytania. Skutek obejmuje identyfikator wykorzystywany przez testy automatyczne oraz warstwę dostępności przycisku odsłaniającego hasło.

MOB-Q-03 — łańcuch null w identyfikatorze

textinput/TextField.kt:104-106:

testTag = data.testTag ?: data.label?.tag
  .let { tag -> "${tag}EditText" }
  .let { tag -> "$tag${data.indexTag?.let { "_${data.indexTag}" } ?: ""}" }

Wywołania .let wiążą się z wyrażeniem data.label?.tag, pozostawiając poza swoim zasięgiem człon poprzedzający operator ?:. Bezpieczny dostęp zabezpiecza wyłącznie odczyt właściwości tag, natomiast następujące po nim .let wykonuje się również dla wartości pustej. Gdy testTag oraz label przyjmują wartość null — oba pozostają opcjonalne z domyślnym null (textinput/model/TextInputData.kt:16,29) — identyfikator przybiera dosłowną postać nullEditText. Poprawny zapis wymaga ujęcia całego wyrażenia w nawias albo użycia ?.let.

MOB-Q-04 — wywołanie zwrotne ze stanem sprzed zmiany

textinput/TextField.kt:233-234:

changePasswordVisibility(!isPasswordVisible)
data.onPasswordVisibilityChanged(isPasswordVisible)

Pierwszy wiersz przełącza widoczność hasła, drugi przekazuje na zewnątrz wartość sprzed przełączenia. Odbiorca onPasswordVisibilityChanged otrzymuje zatem informację odwrotną wobec stanu faktycznego. Jeżeli warstwa nadrzędna opiera na tym sygnale rejestrowanie zdarzeń, zasłanianie zrzutu ekranu albo decyzję o maskowaniu pola, zachowanie ulegnie odwróceniu. Warstwa konsumująca ten sygnał pozostaje poza publikacją, wobec czego ustalenie zgłaszam jako wadę poprawności o nieokreślonym zasięgu.

MOB-Q-18 — wiersz przełącznika pomijający własność enabled

Model switchcomponent/SwitchData.kt:11 udostępnia własność val enabled: Boolean, a oba komponenty przekazują ją do samego przełącznika (SwitchWithExtras.kt:157, SwitchWithText.kt:86). Obszar dotykowy całego wiersza pomija ją natomiast w obu, i to w przeciwnych kierunkach:

SwitchWithExtras.kt:85    .toggleable(role = Role.Switch, value = data.checked, enabled = true,  …)
SwitchWithText.kt:52      .toggleable(role = Role.Switch, value = data.checked, enabled = false, …)

W SwitchWithExtras przełącznik przedstawiony użytkownikowi jako wyłączony pozostaje czynny: dotknięcie dowolnego miejsca wiersza wywołuje onCheckedChange i zmienia stan. Jest to wada funkcjonalna, obserwowalna dla każdego użytkownika, a nie wyłącznie dla korzystających z technologii wspomagających. W SwitchWithText wartość przeciwna wygasza obszar dotykowy wiersza niezależnie od ustawienia modelu. Dwa bliźniacze komponenty wpisały zatem przeciwne wartości tego samego parametru, żaden nie odczytuje własności modelu, a rozbieżność wskazuje, że nikt nie zestawił ich ze sobą.

Grupa C — architektura

MOB-Q-05 — komponenty zamknięte na kompozycję

Spośród 58 publicznych funkcji komponujących najwyższego poziomu — z pominięciem podglądów i funkcji rozszerzających — parametr modifier przyjmuje 8. Pozostałe 50 obejmuje między innymi button/Button.kt:49, accordion/Accordion.kt:46, dialog/Dialog.kt:31 i topappbar/TopAppBar.kt:18. Gniazda treści (content: @Composable) występują w pięciu komponentach publicznych.

Wytyczne API dla Compose traktują modifier jako pierwszy parametr opcjonalny każdej funkcji emitującej interfejs. Jego pominięcie odbiera stronie wywołującej możliwość nadania odstępu, rozmiaru, wagi w układzie nadrzędnym oraz własnego identyfikatora bez opakowania komponentu w dodatkowy kontener. W zamian przyjęto wzorzec pojedynczego obiektu Data jako jedynego parametru, co dodatkowo wyklucza wartości domyślne dla poszczególnych właściwości i wymusza przebudowę całego obiektu przy zmianie jednej z nich.

Powtarzalność tego rozwiązania — 50 przypadków na 58 — nadaje mu rangę przyjętej konwencji. Konwencja ta obsługuje wygodnie zespół autorski, znający wszystkie miejsca użycia, i utrudnia ponowne wykorzystanie biblioteki każdemu zespołowi zewnętrznemu. Publikacja systemu wzorniczego zakłada odbiorcę zewnętrznego, wobec czego przyjęty wzorzec pozostaje w sprzeczności z celem samej publikacji. Uznaję to ustalenie za najpoważniejsze architektonicznie w całej sekcji.

MOB-Q-06 — system wzorniczy związany z dziedziną aplikacji

Typ Label z pakietu pl.gov.coi.common.domain.label występuje w 75 ze 192 plików, czyli w 39% materiału. Obok niego warstwa interfejsu sięga po ValidationState z domain.validators (15 plików) oraz Mapper z domain (4 pliki). Komponent textinput/TextField.kt:88 rozgałęzia wygląd obramowania wprost na typie ValidationState.Invalid, a więc na typie dziedzinowym aplikacji.

System wzorniczy z założenia pozostaje niezależny od dziedziny i operuje typami własnymi albo typami platformy. Przyjęta struktura wiąże bibliotekę z konkretną aplikacją na poziomie typów, przez co przeniesienie jej do innego produktu wymaga przeniesienia również warstwy dziedzinowej. Tezę tę wzmacnia obecność gotowych ekranów usługowych w materiale: servicewelcomepage/ServiceWelcomePage.kt oraz supportpage/SupportPage.kt budują pełny ekran wraz z rusztowaniem, paskiem górnym i mechanizmem odświeżania przeciągnięciem. Materiał opisany jako system wzorniczy stanowi zatem warstwę interfejsu jednej aplikacji.

MOB-Q-07 — modele danych przenoszące prezentację

Spośród 56 plików o nazwie zawierającej Data 18 zawiera kod komponujący oznaczony @Composable, 13 odwołuje się do identyfikatorów zasobów rysunkowych, a 16 do typu Color. Plik alert/AlertData.kt łączy wszystkie trzy właściwości naraz: definiuje warianty komunikatu wraz z przypisanymi im ikonami (R.drawable.c1_info, c2_warning_mark, c4_success, c3_error_mark), kolorami oraz domyślnymi etykietami dostępności.

Rozwiązanie takie umieszcza decyzje wzornicze w warstwie modelu, przez co zmiana ikony albo koloru wariantu wymaga zmiany klasy danych. Testowanie modelu wymaga wówczas środowiska Android wraz z zasobami. Podział na Komponent i KomponentData zachowuje w tej sytuacji formę rozdziału warstw, pozostawiając odpowiedzialności po obu stronach wymieszane. Ustalenia MOB-Q-01 i MOB-Q-14 pokazują koszt praktyczny: etykiety dostępności obu komponentów żyją w klasach danych, gdzie powielenie wywołania między wariantami przechodzi bez śladu.

MOB-Q-08 — teksty ze statycznego dostawcy globalnego

Materiał zawiera zero użyć stringResource. Teksty pochodzą z obiektu CommonUILabelProvider, wywoływanego statycznie wewnątrz funkcji komponujących (accordion/Accordion.kt:73-75, bottomsheet/ModalBottomSheet.kt:144) oraz w wartościach domyślnych parametrów konstruktorów (alert/AlertData.kt:43,47,63,67,83,87,106,110).

Zastrzeżenie dotyczy sposobu dostępu, nie samego istnienia warstwy dostawcy etykiet. Warstwa taka bywa wyborem uzasadnionym, gdy teksty pochodzą ze wspólnego modułu albo z zaplecza serwerowego; badany materiał nie zawiera jednak przesłanek wskazujących na projekt wieloplatformowy, a człon common występuje tu jako nazwa modułu. Dostęp statyczny wprowadza natomiast zależność globalną, ukrytą przed sygnaturą funkcji: test jednostkowy komponentu wymaga zainicjowania dostawcy, podmiana tekstów w teście pozostaje niemożliwa bez ingerencji w stan globalny, a mechanizm Compose odpowiadający za reagowanie na zmianę języka i konfiguracji pozostaje nieużyty. Ten sam dostawca przekazywany przez CompositionLocal albo parametr zachowałby swoje zalety, usuwając wymienione skutki.

Grupa D — spójność i utrzymanie

MOB-Q-09 — dwa systemy komponentów jednocześnie

Szesnaście plików korzysta z Material 2 (androidx.compose.material.Card, Divider, RadioButton), dwadzieścia jeden z Material 3, a custom/documentrow/SingleCardDocumentRow.kt importuje oba naraz. Komponent Divider z Material 2 pozostaje wycofany na rzecz HorizontalDivider.

Rozkład ten odpowiada obrazowi migracji prowadzonej etapami i stanowi dług migracyjny, a nie zaniedbanie. Konsekwencja pozostaje jednak niezależna od przyczyny: system wzorniczy powołany do ujednolicania wyglądu opiera się na dwóch zestawach domyślnych kolorów, kształtów i wysokości cienia, czytających własne źródła wartości. Rozbieżności wynikające z tego podziału pozostają poza zasięgiem korekty na poziomie tokenów. Wydanie publiczne utrwala stan pośredni i przenosi go na każdego odbiorcę zewnętrznego.

MOB-Q-10 — adnotacje stabilności poza miejscem działania

Na 113 klas data class adnotację stabilności noszą dwie, obie w progressbar/ProgressBarData.kt:10,16. Obejmują one klasy złożone z typów Int i String?, uznawanych przez kompilator Compose za stabilne z samej definicji. Modele niosące funkcje zwrotne pozostają bez adnotacji, w tym button/ButtonData.kt:14 z właściwością onClick: () -> Unit.

Rozmieszczenie adnotacji wskazuje, że wprowadzono je w reakcji na pojedyncze zgłoszenie, bez przeglądu pozostałych modeli. Skala wynikającego stąd narzutu rekompozycji zależy od tego, czy typy dziedzinowe — przede wszystkim Label — pochodzą z modułu kompilowanego z wtyczką Compose; materiał nie obejmuje tego modułu, wobec czego rozstrzygnięcie wymaga raportów metryk kompilatora po stronie wykonawcy.

MOB-Q-11 — stan gubiony przy zmianie konfiguracji

Materiał zawiera zero użyć rememberSaveable przy dziewięciu miejscach przechowujących stan przez remember { mutableStateOf(...) }, w tym accordion/Accordion.kt:70, textinput/TextField.kt:68, chatbubble/ChatBubble.kt:233 oraz switchcomponent/SwitchWithExtras.kt:53.

Rozwinięcie sekcji, odsłonięcie hasła i rozwinięcie listy źródeł powracają do stanu wyjściowego po obrocie ekranu, zmianie rozmiaru czcionki systemowej, przejściu w tryb wielookienny oraz po odtworzeniu procesu. Dla użytkownika oznacza to cofnięcie formularza w trakcie wypełniania — zachowanie odczuwalne szczególnie przy zmianie rozmiaru czcionki, z której korzystają osoby słabowidzące.

MOB-Q-12 — kolory poza systemem tokenów

Dziewięć miejsc kodu produkcyjnego definiuje kolor wprost. Osiem posługuje się zapisem szesnastkowym: alert/Alert.kt:35, alert/AlertData.kt:96, badge/Badge.kt:27, bottomnavigation/BottomNavigation.kt:98, chatbubble/ChatBubble.kt:50-51, custom/bulletpoint/BulletPoint.kt:38, singlecard/SingleCardStatusBadgeData.kt:254. Wartość #EEFAE1 występuje dwukrotnie, w dwóch plikach, pod dwiema różnymi nazwami lokalnymi. Dziewiąte miejsce sięga po stałą nazwaną: controllers/ControllerSwitch.kt:76 ustawia selectedContentColor = Color.Blue, czyli czysty #0000FF, w przełączniku zakładek.

Szczególnie wymowny pozostaje alert/AlertData.kt:96. Trzy warianty komunikatu czerpią kolor ikony z palety tokenów — supportBlue100, supportOrange100, supportRed100 — natomiast wariant Success deklaruje zmienną lokalną z wartością Color(0xFF427639), po czym natychmiast ją zwraca. Zieleń powodzenia pozostaje więc nieobecna w palecie tokenów, a lukę wypełniono wartością wpisaną wprost. Każdy taki kolor wypada poza obsługę motywu i ustawień kontrastu.

MOB-Q-19 — komponenty przestarzałe i odsyłacze do kodu nieopublikowanego

Adnotację @Deprecated nosi siedem z pięćdziesięciu ośmiu publicznych komponentów, czyli 12% opublikowanego systemu:

Trzy z tych odesłań kierują poza opublikowany materiał. Komponent BaseScaffold, wskazany jako następca dwóch pełnych ekranów, nie ma w publikacji ani jednej definicji; pakiet ui.unmapped, wskazany jako następca SingleCard, należy do zbioru pakietów przywoływanych, lecz nieudostępnionych. Czytelnik otrzymuje zatem instrukcję migracji do komponentów, których nie może obejrzeć.

Zestawienie to nakłada się na MOB-Q-14 i MOB-Q-15: dwa spośród opisanych defektów dostępności dotyczą komponentów już oznaczonych jako przestarzałe, co ogranicza ich zasięg, a zarazem pokazuje, że wycofywanie zatrzymało się na adnotacji.

MOB-Q-13 — publiczne API i pozostałości robocze

Spośród 50 funkcji @Preview 49 pozostaje publicznych; żadna nie została ograniczona modyfikatorem private ani wydzielona do zestawu źródeł przeznaczonego dla kompilacji rozwojowej. Wraz z nimi publiczne API obejmuje 33 dostawców danych podglądowych z treściami zastępczymi oraz cztery wywołania println (checkbox/group/GroupCheckBoxPPP.kt, checkbox/single/CheckBoxSinglePPP.kt). Występują kolizje nazw: trzy funkcje ButtonPreview i dwie StatusBadgePreview w różnych pakietach.

W kodzie pozostawiono ponadto trzy odrębne numery zgłoszeń wewnętrznych w sześciu wystąpieniach: MOB-49304 w komentarzach TODO REMOVE (singlecard/SingleCardStatusBadge.kt:34, SingleCardStatusBadgeData.kt:13, provider/SingleCardStatusBadgePreviewProvider.kt:9), MOB-60795 przy nierozstrzygniętej wątpliwości dotyczącej strefy czasowej (datepicker/DatePickerDataVMS.kt:19,29) oraz MOB-72178 w adnotacji opisanej w MOB-Q-17. Identyfikatory te ujawniają fragment numeracji systemu śledzenia zadań wykonawcy.

Osobno odnotowuję brak not licencyjnych w plikach źródłowych: żaden ze 192 plików nie zawiera nagłówka Copyright ani SPDX. Licencja MIT wymaga zachowania noty przy kopiach i istotnych częściach oprogramowania, wobec czego pojedynczy skopiowany komponent traci informację o pochodzeniu i warunkach. Porządek ten uzupełnili opiekunowie kopii lustrzanych, dodając pliki licencji i konfigurację REUSE we własnym zakresie. Uwagę zgłaszam jako porządkową.

Ustalenia po stronie warsztatu

Rzetelność wymaga odnotowania ustaleń przeciwnych, opartych na tych samych pomiarach.

W 18 885 wierszach nie występuje ani jedno wymuszenie niepustości (!!), brakuje również konstrukcji lateinit oraz odwołań do GlobalScope. Wyciszenie ostrzeżeń analizatora zastosowano jednokrotnie w całym materiale. Wcięcia pozostają jednolite, bez znaków tabulacji. Modelowanie danych opiera się na 53 klasach i interfejsach zapieczętowanych, co wymusza kompletność rozgałęzień when. System tokenów istnieje i pozostaje w realnym użyciu: 971 odwołań do AppTheme wobec 9 kolorów wpisanych wprost.

Osobnej uwagi wymaga lokalizacja. Kontrola wszystkich łańcuchów zawierających znaki diakrytyczne języka polskiego, przeprowadzona z rozróżnieniem zasięgu funkcji oznaczonych @Preview, wykazała 69 wystąpień, z których wszystkie należą do materiału podglądowego — 68 w plikach dostawców, jedno w funkcji QrCodeCustomSingleCardPreview (custom/singlecard/labelbuttonimage/LabelButtonImageSingleCard.kt:76). Kod produkcyjny nie zawiera żadnego twardo wpisanego łańcucha polskiego. Rozdział tekstów od komponentów został zatem utrzymany konsekwentnie, mimo zastrzeżeń do sposobu dostępu opisanych w MOB-Q-08.

Warstwa dostępności dysponuje infrastrukturą rzadko spotykaną w produktach tej wielkości: 150 użyć contentDescription, 469 identyfikatorów testowych, 16 deklaracji role, 6 oznaczeń nagłówka, 5 opisów stanu, 4 obszary aktywne (liveRegion) służące ogłaszaniu błędów walidacji, 2 użycia invisibleToUser, własne akcje dostępności w komponentach przełącznika oraz odrębny mechanizm zarządzania ogniskiem uwagi (FocusHost, 85 odwołań). Nakład ten jest realny i wykracza poza minimum wymagane ustawą o dostępności cyfrowej.

Zestawienie tego nakładu z grupą A prowadzi jednak do wniosku ostrożniejszego niż sama liczba wywołań. Pięć defektów dostępności — pomylona etykieta błędu, niema etykieta zamknięcia banera, akcja zgłaszana jako nieobsłużona, globalnie wyłączone wymuszanie celu dotykowego oraz wymóg WCAG oparty na opóźnieniach czasowych — leży w warstwie najstaranniej rozbudowanej. Infrastruktura powstała; kontrola jej działania nie nadążyła za jej rozmiarem.

Ocena

Rzemiosło w opublikowanej warstwie interfejsu oceniam jako nierówne. Dyscyplina utrzymuje się w obszarach poddających się kontroli narzędziowej: brak wymuszeń niepustości, jednolite formatowanie, typy zapieczętowane, konsekwentne użycie tokenów, rozdział tekstów od komponentów. Braki układają się we wzorzec charakterystyczny dla zespołu pracującego pod presją terminu, pozbawionego systematycznego przeglądu kodu przez drugą osobę: dwa systemy komponentów obok siebie, adnotacje stabilności postawione poza miejscem działania, stan gubiony przy obrocie ekranu, narzędzia deweloperskie w publicznym API oraz 12% komponentów oznaczonych jako przestarzałe, częścią odsyłających do kodu, którego nie opublikowano.

Warstwa dostępności wymaga oceny osobnej, ponieważ wypada w tym materiale zarówno najlepiej, jak i najgorzej. Rozmiar nakładu opisano wyżej i pozostaje on niekwestionowany. Równocześnie pięć defektów z grupy A dotyczy tej samej warstwy, a dwa z nich — wyłączenie wymuszania celu dotykowego oraz oparcie wymogu ogniska nagłówka na dwóch opóźnieniach jednomilisekundowych — mają charakter decyzji, nie przeoczenia. Zgodność z kryteriami WCAG opiera się w tych miejscach na rozwiązaniach, które zespół autorski sam zakwalifikował jako tymczasowe albo świadomie wyłączył. Dla aplikacji podlegającej ustawie o dostępności cyfrowej, używanej przez blisko jedenaście milionów osób, jest to obszar wymagający przeglądu w pierwszej kolejności.

Warstwa architektoniczna wymaga oceny surowszej. Cztery ustalenia grupy C opisują wybory konsekwentne, powtórzone w dziesiątkach plików, a więc świadome. Komponenty pozbawione parametru modifier i gniazd treści, typy dziedzinowe aplikacji obecne w 39% plików biblioteki, decyzje wzornicze przeniesione do klas danych, teksty pobierane statycznie z obiektu globalnego oraz pełne ekrany usługowe wewnątrz biblioteki składają się na warstwę interfejsu jednej aplikacji, opisaną jako system wzorniczy. Zespół autorski, znający wszystkie miejsca użycia, pracuje w takiej strukturze sprawnie. Odbiorca zewnętrzny, dla którego publikacja została przeznaczona, otrzymuje bibliotekę wymagającą przeniesienia warstwy dziedzinowej, pozbawioną możliwości ułożenia komponentów we własnym układzie i związaną z globalnym dostawcą tekstów. Deklarowany cel publikacji i przyjęta architektura rozchodzą się w tym punkcie wyraźnie.

Wniosek dla całości raportu pozostaje ostrożny. Jakość warstwy wystawionej na widok publiczny rozstrzyga o warstwach zamkniętych w stopniu ograniczonym i wymaga traktowania jako przesłanka, nie dowód. Uprawnia natomiast do wniosku węższego: skoro w części przygotowanej do publikacji przetrwało pięć usterek implementacyjnych i pięć defektów dostępności, w tym pomylone wywołanie między sąsiadującymi wariantami jednej klasy oraz dwa bliźniacze komponenty z przeciwnymi wartościami tego samego parametru, założenie o istnieniu systematycznego przeglądu kodu w częściach nieopublikowanych pozostaje bez oparcia w dowodach. Ciężar wykazania jakości spoczywa po stronie wykonawcy i wymaga otwarcia warstw rozstrzygających o bezpieczeństwie — zgodnie z linią przyjętą w sekcjach 1 i 20.1.

20.4. Granice niezależnej implementacji

Poniższa część ma charakter techniczny. Ocenę prawną planowanego sposobu wykorzystania należy powierzyć prawnikowi właściwej specjalności.

Polska ustawa o prawie autorskim stanowi, że ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia, natomiast idee i zasady leżące u podstaw jego elementów — w tym u podstaw interfejsów (łączy) — ochronie nie podlegają. Osoba uprawniona do korzystania z egzemplarza może obserwować, badać i testować jego działanie. Dekompilacja ma węższą podstawę: musi być konieczna do interoperacyjności niezależnie stworzonego programu i spełniać warunki art. 75 ust. 2 pkt 3. Uzyskanej informacji nie wolno używać do programu o istotnie podobnej formie wyrażenia ani innych naruszeń. Co istotne, ogólnego dozwolonego użytku osobistego z art. 23 nie stosuje się do programów komputerowych. Ustawa o prawie autorskim, art. 74–77.

Z tego wynika bezpieczniejszy profil prywatnego demonstratora:

• własny kod C++23, architektura, układ ekranów, nazwa i grafika;
• funkcjonalna inspiracja i interoperacyjność, bez kopiowania zdekompilowanych fragmentów;
• własny wzór Windows 11: Mica, tryb ciemny i Per-Monitor V2 dodatkowo odróżniają formę wyrażenia;
• wyłącznie fikcyjne dane i stałe oznaczenie DEMO — nie jest dokumentem ani aplikacją państwową;
• brak oficjalnych kluczy, certyfikatów, kont produkcyjnych i podszywania się pod autoryzowanego klienta;
• oddzielny dziennik pochodzenia wymagań: publiczna dokumentacja/obserwacja → neutralna specyfikacja → własna implementacja.

Niezależna aplikacja nie staje się przez podobną funkcjonalność aplikacją mObywatel ani dokumentem elektronicznym wywołującym skutki ustawowe. Przed dystrybucją, użyciem realnych protokołów lub danych i integracją z systemami państwowymi potrzebna jest pisemna autoryzacja oraz przegląd prawnika od prawa autorskiego, znaków i systemów teleinformatycznych.

20.5. Czy WinAPI oznacza mniejszą powierzchnię ataku

WinAPI i niewielka liczba zależności mogą zmniejszyć ryzyko łańcucha dostaw, rozmiar SBOM oraz liczbę parserów i środowisk wykonawczych. „Zero zależności” nie jest jednak celem bezpieczeństwa samym w sobie: Windows, biblioteki systemowe, sterowniki i kompilator nadal są zależnościami, a własny parser, kryptografia lub TLS prawdopodobnie zwiększą ryzyko.

Zalecana konfiguracja bazowa: /std:c++23, ostrzeżenia jako błędy, /permissive-, /sdl, /guard:cf, ASLR/DEP, CET tam, gdzie są dostępne, Control Flow Guard, podpisywanie binarki, analiza MSVC/clang-tidy, testowanie mutacyjne parserów, testy Application Verifier i brak sekretów w logach oraz małych zrzutach pamięci. WebView2 należy dodać tylko wtedy, gdy wymaganie rzeczywiście wymusza HTML; wnosi oddzielne, szybko aktualizowane środowisko wykonawcze.

20.6. Deklaracja autorska — kierunek niezależnej implementacji referencyjnej

Ustalenia tego raportu nie mają charakteru wyłącznie krytycznego; wyznaczają zarazem wzorzec, według którego zamierzam zbudować niezależną aplikację referencyjną o zbliżonej funkcjonalności. Przepływ danych i model działania znam na tyle dokładnie, by odtworzyć go samodzielnie w języku C++23, w oparciu o natywne WinAPI, bez pośrednictwa rozbudowanego stosu kilkuset bibliotek. Rezygnacja z tej powłoki nie jest celem samym w sobie, lecz świadomą decyzją inżynierską: każda zbędna zależność to dodatkowy parser, kolejne środowisko uruchomieniowe i wydłużenie łańcucha dostaw, a zatem realny przyrost powierzchni potencjalnego ataku. Rdzeń mniejszy i przejrzysty łatwiej poddaje się higienie kodu, przeglądowi oraz utrzymaniu. Wybór natywnego WinAPI nie zamyka przy tym drogi na inne systemy: ta sama zasada — niewielki rdzeń, minimum zależności i kryptografia powierzona zaudytowanym mechanizmom platformy — przenosi się na Linuksa z nowoczesnym, natywnym zestawem narzędzi (GTK4/libadwaita), czego dowodzi mój edytor rejestru RegEdLin zbudowany dokładnie w tym duchu.

Nie piszę tego z pozycji teoretyka. Pracuję na co dzień poniżej warstw, które niniejszy raport traktuje jako gwarancje: wymuszania podpisu sterowników, HVCI, zabezpieczeń opartych na wirtualizacji i Bezpiecznego Jądra, aż po fazę UEFI — mechanizmów, w które Microsoft inwestuje ogromne środki, a które w moich narzędziach badawczych (zob. github.com/wesmar) potrafię obejść lub odtworzyć na każdym poziomie: od modyfikacji g_CiOptions i przekierowania SeCiCallbacks, przez uzyskanie uprawnień SYSTEM jeszcze przed ekranem logowania — bez zapisu na dysk i bez sterownika jądra — po własny sterownik systemu plików NTFS działający w środowisku UEFI. Kto rozumie te warstwy od tej strony, inaczej rozkłada zaufanie w aplikacji tożsamości: nie rozważa, czy wykrywanie roota jest dostatecznie pomysłowe, lecz przyjmuje, że urządzenie bywa w pełni kontrolowane, i przenosi rozstrzygnięcia tam, dokąd klient nie sięga. Po trzydziestu latach tej praktyki architektura takiej aplikacji powstałaby zupełnie inaczej — nie dlatego, że dysponuję większą liczbą bibliotek, lecz dlatego, że mam ich znacznie mniej i wiem, której warstwy trzeba naprawdę pilnować.

Prace prowadzę w reżimie clean-room i na licencji MIT: własny kod, własna architektura, własny interfejs, własna nazwa i grafika — bez przejmowania znaków, symboli urzędowych czy sugerowania autoryzacji państwowej. Bezpieczeństwo opieram nie na zaufaniu do klienta, lecz na dyscyplinie protokołu: pojedynczej granicy „zweryfikuj, zanim odczytasz" dla treści podpisanej, uwierzytelnionym szyfrowaniu w miejsce trybów pozbawionych kontroli integralności, kluczach nieeksportowalnych osadzonych w sprzęcie zamiast materiału przenoszonego do klienta oraz serwerze rozstrzygającym o każdej istotnej decyzji. Świadomie nie piszę przy tym własnej kryptografii ani własnego TLS — sięgam po zweryfikowane mechanizmy systemowe, ponieważ to one, a nie sama liczba zależności, przesądzają o rzeczywistym poziomie zapewnienia.

Nie jest to zapowiedź „aplikacji doskonałej", lecz zobowiązanie do warsztatu, w którym opisane w tym raporcie słabości granicy zaufania nie mają prawa się pojawić.

21. Macierz korekt, odpowiedzialności i kryteriów zamknięcia

Ustalenie nie jest zamknięte komunikatem prasowym, zmianą w repozytorium ani deklaracją zespołu. Zamknięcie dotyczy konkretnego podpisanego artefaktu i wymaga dowodu testowego możliwego do niezależnego powtórzenia.

22. Referencja naprawcza (pseudokod)

Poniższe wzorce są neutralne językowo i mają charakter referencyjny, nie stanowią pełnej implementacji. Ilustrują kierunek naprawy ustaleń, nie zawierają kodu ofensywnego.

Pojedyncza granica „zweryfikuj, zanim odczytasz" dla treści podpisanej (MOB-A-05):

function verifyThenDecode(cms: UntrustedCmsBytes, policy) -> VerifiedPayload:
    signed  = parseCms(cms)                     // tylko parsowanie
    signers = signed.getSignerInfos()
    require(signers.count == policy.expectedSignerCount)
    for s in signers:
        cert = resolveFromTrustStore(s)
        require(s.verify(cert.publicKey))                    // podpis
        require(buildAndValidateChain(cert, policy.anchors)) // łańcuch
        require(cert.hasEku(policy.requiredEku))             // EKU / OID
        require(policy.validAt(now(), cert))                 // czas
        require(not isRevoked(cert, policy.revocation))      // revocation
        require(policy.bindsDocType(cert, expectedDocType))  // związanie
    return VerifiedPayload(signed.getSignedContent())        // dopiero teraz
// Brak publicznego decode() zwracającego treść z pominięciem tej ścieżki.

Lista dozwolonych algorytmów przy deszyfrowaniu CMS EnvelopedData (MOB-A-04):

const ALLOWED = { AES_256_GCM }                 // docelowo AEAD, bez zwinności
function decryptEnvelope(env: CMSEnvelopedData, key):
    require(env.contentEncryptionOid in ALLOWED)  // odrzuć nieoczekiwany OID z blobu
    r = env.recipientFor(key); require(r != null)
    return r.getContent(key)

Typ sekretu redagowany i nieobecny w dziennikach (MOB-A-08, EDO-05):

final class Secret:                             // char[] w środku, nie String
    toString() -> "Sensitive value, redacted"   // nigdy wartość
    equals()/hashCode() -> nie nad materiałem
    close(): zeroize(buffer)                     // jawne czyszczenie
// PIN/CAN/PUK/hasło zawsze jako Secret; nigdy składnik komunikatu dziennika.

Import klucza prywatnego do magazynu sprzętowego zamiast przechowywania PKCS#8 (MOB-A-08):

function onboardKey(p12, pass: Secret):
    kp = loadPkcs12(p12, pass)
    importToHardwareKeystore(kp.privateKey, alias,
        { nonExportable: true, strongBoxPreferred: true })
    wipe(kp.privateKey); pass.close()           // brak kopii w bazie i pamięci

22.1. Konkretyzacja w C++23/WinAPI (demonstrator z sekcji 20.4)

Powyższe wzorce, zinstancjonowane na platformie Windows w niezależnym demonstratorze, sprowadzają się do jednej zasady: weryfikuj i wiąż tożsamość, zanim odczytasz. Krytyczny jest krok, którego brakuje po obu stronach systemu (sekcja 9.8) — twarde wiązanie podmiotu certyfikatu z tożsamością w kontenerze. Dodany do verifyThenDecode, domyka MOB-A-05 (klient) i lukę serwerową opisaną w 9.8 tym samym mechanizmem. Krypto i TLS powierza się zaudytowanym mechanizmom systemu (CNG, WinHTTP), bez własnych implementacji.

// C++23 / WinAPI — verifyThenDecode z twardym wiązaniem tożsamości (referencyjnie)
VerifiedDoc verifyThenDecode(std::span<const std::byte> cms, const Policy& pol) {
    auto signed_ = parseCms(cms);                     // samo parsowanie, bez zaufania
    // 1. Podpis + łańcuch przez CNG — bez własnej kryptografii
    require(CryptVerifyMessageSignature(signed_));    // NCrypt/CNG
    auto cert = resolveTrusted(signed_, pol.anchors);
    require(chainValid(cert, pol.anchors));           // CertGetCertificateChain
    require(cert.hasEku(pol.requiredEku) && pol.validAt(now(), cert));
    require(!revoked(cert, pol.revocation));
    // 2. TWARDE WIĄZANIE TOŻSAMOŚCI — domyka MOB-A-05 i lukę serwerową (9.8)
    auto payload = decode(signed_.content());         // dopiero po weryfikacji podpisu
    require(bindsIdentity(cert.subject(), payload.identity()));  // Subject certu <-> dane kontenera
    return VerifiedDoc{std::move(payload)};
}

Odwzorowanie ustaleń na mechanizmy platformy:

Wniosek jest inżynierski, nie ideologiczny: mniejsza liczba zależności i oparcie na zaudytowanych prymitywach platformy zawężają powierzchnię ataku, ale to jeden dodany warunek — wiązanie tożsamości — likwiduje najcięższą klasę błędu po obu stronach naraz. Reszta to higiena, nie rewolucja.

23. Konkluzja

Najistotniejszym potwierdzonym problemem wersji 4.87.2 nie jest dowolne wstrzyknięcie treści przez gstatic.com, lecz możliwość cofnięcia podpisanej listy zaufanych dzienników CT, ponieważ podpis chroni integralność i pochodzenie, ale implementacja nie chroni świeżości. Jest to precyzyjny, naprawialny błąd obrony warstwowej o warunkowym wpływie.

Niebezpieczne implementacje TrustAll, permisywnej weryfikacji nazwy hosta oraz SslErrorHandler.proceed() są obecne w artefakcie wydania i powinny z niego zniknąć. Dostępny materiał nie potwierdza jednak, aby zwykły napastnik mógł przełączyć produkcyjną aplikację na tę ścieżkę. Klasyfikowanie tego jako zdalnej podatności wysokiej wagi byłoby nierzetelne.

Przegląd WebView potwierdził jednocześnie, że nie wszystkie warianty są jednakowe. Płatności mają SSL wymuszone na stałe, bazowe ustawienia treści mieszanej i dostępu do plików są restrykcyjne, a nie znaleziono addJavascriptInterface; to należy pochwalić. Z drugiej strony usługi internetowe włączają allowFileAccess, a wspólny klient nadal zawiera proceed() oraz kod budujący pełny DOM i URL dla mechanizmu logowania. Badany produkcyjny odbiornik odrzuca poziomy debug/info, więc nie ogłoszono wycieku treści WebView. Jest to jednak konfiguracja krucha: bezpieczeństwo zależy od właściwego wariantu i konkretnej implementacji mechanizmu logowania, zamiast od niezmiennych ograniczeń komponentu.

Odrębny problem dotyczy starszej autoryzacji e-Doręczeń. y12.t rozpoczyna przebieg kodu autoryzacyjnego bez state i PKCE, akceptuje wywołanie zwrotne na podstawie schematu oraz początku ścieżki, a następnie wysyła code_verifier=null. Nowszy moduł obecny w APK implementuje state i PKCE S256, zatem luka wynika z niespójności między wariantami, a nie z braku możliwości technicznej. Ponieważ dostępność y12.t zależy od serwerowej flagi NATIVE_LOGIN_EDOR_MODULE_ANDROID, raport ocenia MOB-A-09 jako średnie i warunkowe oraz wymaga testu P0 zamiast bezpodstawnie deklarować aktywne przejęcie sesji.

W tej samej domenie funkcjonalnej znaleziono warunkowy błąd zapisu załączników na wspieranych nadal Androidach 8–9. Nazwa z Content-Disposition dociera bez normalizacji do ścieżki opartej na publicznym Downloads, a ../ może skierować nowy plik do innego katalogu pamięci współdzielonej. Kod nie nadpisuje istniejącego celu i gałąź Androida 10+ używa MediaStore, dlatego nie jest to uniwersalny dowolny zapis ani zdalne wykonanie kodu (RCE). Jest to jednak klasyczny brak egzekwowania granicy katalogu po stronie klienta, którego nie wolno usprawiedliwiać oczekiwanym oczyszczaniem danych na serwerze. MOB-A-10 wymaga testu P1 z nazwą kontrolowaną przez nadawcę.

Drugi obszar wymagający pilnego działania to łańcuch dostaw. Bouncy Castle 1.83 zawiera kod objęty znanymi CVE, a projekt źródłowy wydał już 1.84 i następnie linię 1.85.x z szerokim zestawem korekt. Nie znaleziono odwołań aplikacyjnych do GOST, LDAP, Composite Signature ani FrodoKEM, dlatego raport nie twierdzi, że tymi mechanizmami osiągnięto eskalację. Brak dowodu wykorzystania nie jest jednak argumentem za pozostawieniem podatnej wersji aktywnie używanego dostawcy kryptograficznego.

Jeszcze poważniejszego rozstrzygnięcia wymaga sposób wykorzystywania CMS. Analiza statyczna potwierdziła tworzenie i zapis CMSSignedData na wejściu oraz liczne odczyty getSignedContent() bez znalezionej lokalnej weryfikacji podpisujących; uzyskane dane zasilają modele dokumentów. Osobny pakiet aktywacyjny legitymacji przychodzi z FrontSrv, jest chroniony hasłowym AES-CBC bez widocznego znacznika uwierzytelniającego i w obu implementacjach prowadzi do konstrukcji CMSSignedData bez znalezionego verify. Nie wykazano jeszcze zwykłego zdalnego kanału dostarczenia podrobionego kontenera, dlatego nie ogłoszono przełamania integralności dokumentów. Jednak w produkcie tożsamościowym przyjmowanie obiektu nazwanego i zaprojektowanego jako SignedData bez jawnego verify wymaga natychmiastowego testu P0 i korekty, a nie kosmetycznego zalecenia.

W tym samym pakiecie aktywacyjnym potwierdzono niezależny błąd KDF: globalną, ośmiobajtową sól PBKDF2. Widoczne w dekompilacji zero iteracji jest artefaktem; rzeczywista wartość to 65 536, dlatego raport nie powiela efektownego, ale fałszywego zarzutu. Stała sól usuwa rozdzielenie kluczy między pakietami i umożliwia amortyzowanie słownika, lecz bez znajomości entropii kodu oraz kanału dostępu do szyfrogramu nie dowodzi jeszcze praktycznego odzyskania danych.

Analiza tekstu jawnego domknęła wpływ tego wątku: pakiet zawiera plik PKCS#12 z aktywnym prywatnym kluczem certyfikatu UNIVERSITY oraz hasło do tego pliku. Po aktywacji klucz jest zapisywany jako eksportowalny PKCS#8 w bazie SQLCipher, a nie jako nieeksportowalny uchwyt AndroidKeyStore. SQLCipher i magazyn kluczy zapewniają rzeczywistą ochronę przechowywanych danych i zostały w raporcie odnotowane; nie przywracają jednak nieeksportowalności samego klucza. Praktyczne odzyskanie poza aplikacją i użycie klucza pozostają testem P0, dlatego raport klasyfikuje MOB-A-08 jako Średnie, warunkowo Wysokie po potwierdzeniu, zamiast ogłaszać bez dowodu przejęcie podpisu kwalifikowanego.

Publiczne 192 pliki Kotlin nie obejmują warstw, które przesądzają o bezpieczeństwie. Dlatego obecny raport jest analizą binarną, a nie audytem źródłowym. Po otrzymaniu pełnego kodu należy powiązać wydanie z konkretną zmianą źródłową, odtworzyć kompilację, porównać artefakty i ponownie przejrzeć te same ustalenia na źródłach. Do czasu wykonania testów P0 nie należy wydawać zbiorczego zapewnienia o bezpieczeństwie ani alarmistycznego komunikatu o przełamaniu aplikacji.

24. Weryfikacja dynamiczna na fizycznym urządzeniu

Data testu: 30 sierpnia 2026 r.
Urządzenie: Xiaomi 23078PND5G, Android 16 (API 36)
Pakiet: pl.nask.mobywatel, 4.87.2 (6426), versionCode 56416, targetSdk 36
Stan aplikacji: produkcyjna instalacja zalogowanego użytkownika; pobieranie mDowodu i mPrawa Jazdy działało bez błędu bezpośrednio przed testem.

24.1. Tożsamość badanego artefaktu

Z urządzenia pobrano dokładnie zainstalowany zestaw APK. apksigner potwierdził podpisy v2 i v3 oraz SourceStamp. Certyfikat podpisującego ma odcisk SHA-256 cb4f1ea4f0be4a91ea803497dda69f31845c9a98f43903c56017cf4ab877d89f.

Część dynamiczną prowadzono początkowo na powyższym urządzeniu fizycznym (30 sierpnia). W dalszym toku dołączyło drugie, kontrolowane środowisko — Windows Subsystem for Android z rootem (Magisk/Zygisk) — na którym wykonano patch detekcji środowiska (24.5), ekstrakcję kontenerów w spoczynku (24.7) oraz pomiar metadanych protokołu (24.6). Pełne parametry i wersje obu środowisk podano w karcie na początku raportu.

24.2. Wyniki bezinwazyjnych testów

• run-as pl.nask.mobywatel został odrzucony komunikatem package not debuggable. Działa ADB i obserwacja dynamiczna urządzenia, ale produkcyjnego procesu nie można podłączyć do debuggera aplikacyjnego Android Studio bez modyfikacji artefaktu.
• Zrzut ekranu aktywnej aplikacji zwrócił czarny obszar treści, a karta mObywatela w widoku ostatnich aplikacji nie ujawniła zawartości. Potwierdza to działanie FLAG_SECURE wobec przechwytywania programowego na Androidzie 16 dla obu sprawdzonych ścieżek — jest to spełnione minimum, klasyka jak w REVOLUT, iPKO, mbank - żaden wyróżnik; granice wobec roota opisuje 24.8.
• Testy dynamiczne potwierdziły skuteczne blokowanie cyfrowego przechwytywania chronionej treści na badanym Androidzie 16. Materiały obrazowe nie są publikowane, ponieważ nie wnoszą czytelnej wartości dowodowej dla odbiorcy raportu.
• Systemowy rejestr ostatnich zadań potwierdził jednoczesną obecność dwóch zadań mObywatela, #4003 i #4001, z tą samą MainActivity; wpływ bezpieczeństwa pozostaje niewykazany.
• W bieżącym logcat procesu nie znaleziono pełnych adresów URL, tokenów ani błędów TLS/WebView. Widoczne błędy dotyczyły mechanizmów optymalizacyjnych HyperOS/MIUI i nie stanowią dowodu błędu mObywatela.
• Dynamiczne statystyki systemowe potwierdziły ruch sieciowy UID aplikacji przez Wi-Fi. Bez przechwycenia ruchu w kontrolowanym punkcie VPN/proxy nie rozstrzyga to treści żądań, ochrony TLS ani hipotez CT.
• Jawny Intent skierowany bezpośrednio do eksportowanej MainActivity, z URI audit-invalid://untrusted.example/institutions?qrCode=AUDIT_INVALID_7fcb7d9c, został przyjęty mimo błędnego schematu i hosta. Aplikacja przekazała fikcyjny kod do przebiegu weryfikacji, który zakończył się kontrolowanym błędem domenowym WRONG_QR_CODE i komunikatem „Niepoprawny kod QR”. Wynik dynamicznie potwierdza brak ponownej walidacji schematu i hosta opisany w MOB-A-03, ale równocześnie nie potwierdza obejścia autoryzacji: niepoprawny kod został odrzucony przez dalszą warstwę.
• Dla ścieżki podpisu kwalifikowanego jawny Intent z błędnym schematem audit-invalid://eqsig nie uruchomił przetwarzania tokenu. Intent kontrolny z oczekiwanym mobywatel://eqsig dotarł do parsera, a fikcyjna wartość zakończyła się błędem Failed to decode Base64. Pogłębiony test z poprawnym Base64 (token=dGVzdA==) pokazał jednak, że klient nie waliduje treści tokenu: przekazuje go wprost do produkcyjnego API (POST .../digital-signature/mobile/api/qualified-signature-process/start-authentication), a dopiero serwer odrzuca sfałszowaną wartość (400, INVALID_DEEPLINK, „Niepoprawny kod QR"). Koryguje to wcześniejsze wrażenie, jakoby ścieżka była „ściślejsza" niż institutions — to ta sama klasa otwartej granicy wejściowej: klient przyjmuje deep link od dowolnej aplikacji bez walidacji nadawcy i przepycha go do rządowego API, a cała obrona jest serwerowa. Nie wykazano zmiany stanu ani obejścia logowania (MOB-A-07).

Materiały dowodowe i pobrane APK zachowano lokalnie, poza publikacją. Zrzuty zawierające dane osobowe lub karty innych aplikacji nie są udostępniane bez uprzedniej anonimizacji.

Powyższe wyniki zamykają na Androidzie 16 część P0 dotyczącą zrzutów, nagrywania i widoku ostatnich aplikacji. Nie rozstrzygają testów CMS, KDF, klucza UNIVERSITY, starszego OAuth ani cofnięcia listy CT; te wymagają kontrolowanych danych wejściowych lub kontrolowanej warstwy sieciowej.

24.3. Kontynuacja testów wykonaniowych na nowszym wydaniu (4.89.0)

Kolejną sesję dynamiczną przeprowadzono po tym, jak urządzenie zaktualizowało aplikację. Zainstalowane wydanie to 4.89.0 (6488), versionCode 56478, z datą aktualizacji 2 września 2026 r., na Androidzie 16 (API 36). Wersja ta zastąpiła audytowany pakiet 4.87.2 (6426). Odcisk SHA-256 certyfikatu podpisującego pozostał zgodny z podanym w podrozdziale 24.1, a run-as pl.nask.mobywatel nadal kończy się komunikatem package not debuggable, co potwierdza autentyczną, nie-debugowalną instalację produkcyjną. Ustalenia statyczne raportu pozostają zakotwiczone w 4.87.2; poniższe obserwacje wykonaniowe dotyczą wprost 4.89.0 i są tak oznaczone. Zainstalowany na urządzeniu numer wydania zmienia się co kilka–kilkanaście dni, wobec czego kontrola dynamiczna śledzi cel ruchomy, a niniejszy podrozdział dokumentuje, że opisana niżej granica utrzymała się mimo aktualizacji.

Stan weryfikacji odsyłaczy sprawdzono poleceniem pm get-app-links pl.nask.mobywatel oraz zrzutem dumpsys package. System zwrócił stan verified dla hosta api.mobywatel.gov.pl ze ścieżką /application/diia_confirmed, a odpowiadający filtr intencji nosi w zrzucie AutoVerify=true. Oznacza to, że ruch HTTPS do tego adresu Android kieruje wyłącznie do oficjalnej aplikacji, bez okna wyboru i bez udziału użytkownika — mechanizmem Android App Links opartym na kryptograficznym powiązaniu z plikiem assetlinks.json domeny.

Weryfikacja ta nie obejmuje — i z założenia nie może obejmować — dwóch pozostałych filtrów o schemacie niestandardowym, które zrzut potwierdza jako obecne bez atrybutu weryfikacji: mobywatel:// ze ścieżką /institutions oraz mobywatel://eqsig. Struktura ta odpowiada dokładnie manifestowi audytowanej wersji 4.87.2 (filtr HTTPS z autoVerify w wierszach 118–125; schematy własne w wierszach 114–116 i 132–133), co czyni wynik potwierdzeniem międzywersyjnym: granica pozostała niezmieniona między 4.87.2 a 4.89.0. Schematy inne niż HTTP/HTTPS nie mają systemowego mechanizmu potwierdzania pochodzenia, wobec czego dowolna inna aplikacja może zadeklarować ten sam schemat, wywołując systemowe okno wyboru obsługi albo przejmując intencję. Test wykonaniowy potwierdza więc wprost architektoniczną granicę opisaną w MOB-A-03 i MOB-A-09: ścieżka poświadczana kryptograficznie działa tam, gdzie ją zastosowano, natomiast tokeny przenoszone schematem własnym pozostają poza tą ochroną. Wynik wzmacnia zalecenie migracji przepływów tokenowych na App Links HTTPS wraz z jednorazowością, czasem ważności oraz wiązaniem stanu i odbiorcy.

Kontrola potwierdziła również, na tej samej sesji i na wydaniu 4.89.0, działanie FLAG_SECURE na ekranach dokumentów oraz brak flagi debuggable w procesie produkcyjnym — zgodnie z ustaleniami z podrozdziału 24.2 poczynionymi na 4.87.2.

24.4. Obserwacje wykonaniowe poza modelem zagrożeń — wydajność i higiena pamięci

Sesja dynamiczna ujawniła dwie usterki niezwiązane z bezpieczeństwem, które odnotowuję osobno, aby nie mieszać ich z ustaleniami o wpływie na poufność lub integralność. Obie potwierdzono w kodzie audytowanej wersji 4.87.2 i zaobserwowano w działaniu na wydaniu 4.89.0 obecnym wówczas na urządzeniu; klasyfikuję je jako dług jakości i wydajności.

24.4.1. Wyciek instancji Activity przez pole statyczne

Klasa nawigacji starszego modułu og2/a.java przechowuje aktywność w polu statycznym private static androidx.appcompat.app.c activity; (wiersz 21) i przypisuje je w metodzie j(...) przez activity = activity2 (wiersz 172). W całym pliku nie znaleziono przypisania activity = null ani metody czyszczącej to pole. Pole statyczne żyje tak długo jak proces, wobec czego przechowywana w nim aktywność wraz z całym drzewem widoków i obiektami kompozycji nie może zostać zwolniona po zniszczeniu ekranu. Przy każdej zmianie konfiguracji — obrocie ekranu, przełączeniu motywu jasny/ciemny, zmianie rozmiaru czcionki — powstaje nowa aktywność, a poprzednia pozostaje uwięziona. Obserwacja wykonaniowa na 4.89.0 jest z tym spójna: dumpsys meminfo wykazał dwie aktywności (Activities: 2) przy jednym korzeniu widoku (ViewRootImpl: 1) w architekturze pojedynczej aktywności. Jest to klasyczny wyciek kontekstu aktywności, defekt higieny pamięci bez wpływu na bezpieczeństwo. Zalecenie: zerować pole w onDestroy lub, lepiej, zrezygnować z przechowywania aktywności w polu statycznym na rzecz przekazywania jej zasięgiem świadomym cyklu życia.

24.4.2. Animacja flagi jako pętla dekodowania rastrowego

Powiewająca flaga na ekranie mDowodu nie jest zasobem wektorowym ani pojedynczą animacją, lecz sekwencją sześćdziesięciu odrębnych plików WebP (flag_pl_0.webp–flag_pl_59.webp, każdy 64×44 px), zebranych w tablicy coi_common_ui_poland_flag_resources (res/values/arrays.xml). Komponent animacji w d30/e.java liczy opóźnienie klatki jako 1000 / maxFramesPerSecond, z częstotliwością ograniczoną do przedziału 1–60 (wiersz 243 i dalsze gałęzie dekompilacji), po czym inkrementuje indeks klatki i wywołuje painterResource dla kolejnego zasobu. Przy częstotliwości przekazywanej przez wywołującego — w obserwacji wykonaniowej około 15 klatek na sekundę — systemowy dekoder odtwarza nową bitmapę z zasobów mniej więcej co 66 ms, w pętli działającej przez cały czas wyświetlania karty. W logach HWUI widać odpowiadające temu wpisy ImageDecoder_nDecodeBitmap: width = 64, height = 44, a profil pamięci graficznej sięgał około 100 MB warstwy GL. Poza narzutem procesora i układu graficznego pętla ta utrzymuje wątek interfejsu w stanie czynnym, co uniemożliwia jego przejście w spoczynek i zakłóca narzędzia automatyzacji oczekujące na stan bezczynności. Zalecenie: zastąpić sekwencję sześćdziesięciu rastrów pojedynczym zasobem wektorowym animowanym lub animacją poza wątkiem kompozycji.

Żadna z tych obserwacji nie zmienia oceny bezpieczeństwa aplikacji. Odnotowano je, ponieważ dotyczą jakości wydania produkcyjnego i dają się potwierdzić zarówno w kodzie, jak i w pomiarze wykonaniowym.

24.5. Empiryczne obejście detekcji środowiska przez modyfikację pakietu

Aby sprawdzić, czy klient-side wykrywanie środowiska stanowi realną granicę bezpieczeństwa, czy jedynie próg zwalniający (teza sekcji 19), przeprowadzono kontrolowaną modyfikację audytowanego pakietu 4.87.2 i uruchomiono go w środowisku z rootem. Test wykonano na kopii legalnie redystrybuowanej (licencja MIT), na koncie i urządzeniu wirtualnym należącym do badacza, wyłącznie w celu weryfikacji mechanizmu obronnego.

Metoda i narzędzie. Całość zautomatyzowałem w jednym skrypcie PowerShell, który wraz z jego analizą dołączam do tego opracowania (przycisk pobierania na górze strony). Przebieg jest w pełni jawny: skrypt wykrywa lokalne narzędzia (java, adb, zipalign, apksigner), w razie potrzeby pobiera apktool z oficjalnego repozytorium, tworzy jednorazowy keystore, po czym odnajduje najnowszą paczkę instalacyjną. Paczkę .apkm — będącą zestawem split-APK w formacie dystrybucyjnym APKMirror, a nie Android App Bundle — rozpakowuje i dobiera właściwe składniki split_config.* według architektury i gęstości ekranu odczytanych z urządzenia przez adb. Sedno zmiany to pojedynczy punkt: base.apk jest rozkładany do postaci smali, a trzy metody klasy com.scottyab.rootbeer.RootBeer orzekające o zrootowaniu (isRooted, isRootedWithBusyBoxCheck, isRootedWithoutBusyBoxCheck) zwracają odtąd stałą wartość „urządzenie nie jest zrootowane". Pakiet jest składany ponownie, wyrównywany (zipalign) i podpisywany jednym własnym kluczem — plik bazowy oraz oba splity — a następnie instalowany jako aktualizacja (install -r tym samym kluczem), co zachowuje aktywowany profil. Na koniec skrypt uruchamia aplikację i sprawdza w dzienniku, że nie pojawia się już żadne orzeczenie RootBeera ani ekran ostrzeżenia.

Publikuję tę procedurę świadomie. Nie dostarcza ona narzędzia do podszywania się pod tożsamość ani nie forsuje żadnej kontroli po stronie serwera: zdejmuje wyłącznie sprawdzenie wykonywane w procesie, który właściciel urządzenia i tak w pełni kontroluje. Nie fałszuje dokumentu, nie odszyfrowuje danych pobieranych z usługi i nie omija atestacji egzekwowanej serwerowo — pokazuje jedynie, że klient-side detekcja środowiska nie jest barierą. To jest sedno ustalenia, a nie środek do nadużycia.

Wynik. Przed modyfikacją aplikacja kończyła start ekranem threat_detection_security_alert_screen („Nie masz dostępu do aplikacji mObywatel — urządzenie działa w trybie, w którym ze względów bezpieczeństwa nie możesz korzystać z aplikacji"), a w dzienniku widoczne było RootBeer: com.topjohnwu.magisk ROOT management app detected. Po modyfikacji ten sam pakiet uruchamia się do ekranu głównego: dziennik nie zawiera już żadnego orzeczenia RootBeera ani ekranu ostrzeżenia. Odnotowano przy tym, że usługa atestacji Google (gms.unstable / DroidGuardService) nadal się wykonywała — jej uruchomienie samo w sobie nie zatrzymało przebiegu aplikacji po stronie klienta.

Nagranie demonstracyjne. Powyższy przebieg utrwaliłem na nagraniu ekranu. Widać na nim kolejno: uruchomienie skryptu patchującego, ponowną instalację pakietu tym samym kluczem (install -r) bez utraty aktywnego logowania oraz przejście po interfejsie aplikacji działającej na Windows Subsystem for Android. W tle, przełączane skrótem Alt+Tab, pozostają aplikacja Magisk i Termux z uprawnieniami roota (uname -a, Midnight Commander z konta użytkownika) — potwierdzenie, że środowisko jest rzeczywiście zrootowane. Całość uruchomiono na Windows 11 (26H2), a samo WSA — przy użyciu autorskiej łatki WSAPatch, napisanej w asemblerze. Dane osobowe w nagraniu zanonimizowano. Samo nagranie umieściłem na początku strony.

Znaczenie. Cała klient-side warstwa rozpoznania środowiska — RootBeer wraz z modułem threat_detection — została zdjęta zmianą w jednym miejscu kodu, przy użyciu ogólnodostępnych narzędzi, w czasie liczonym w minutach. Potwierdza to wprost wniosek sekcji 19: detekcja roota i emulatora jest heurystyką, nie granicą zaufania. Modyfikacja nie narusza żadnej właściwości kryptograficznej i nie „łamie" zabezpieczeń serwera; pokazuje wyłącznie, że decyzja podejmowana w procesie klienta jest w całości pod kontrolą właściciela urządzenia. Poprawne, choć podstawowe, działanie FLAG_SECURE wobec przechwytywania programowego pozostaje po stronie plusów (zob. 24.2), z zastrzeżeniem jego granic wobec roota (24.8).

Powtarzalność. Procedura nie jest jednorazowym trikiem — daje się w pełni zautomatyzować i pozostaje niezależna od wersji. Ponieważ punkt cięcia to niezmienne, nieobfuskowane nazwy metod biblioteki RootBeer, ten sam zabieg stosuje się do każdego kolejnego wydania: rozłożenie pakietu, neutralizacja trzech metod orzekających o zrootowaniu, ponowne złożenie, podpis i instalacja jako aktualizacja tym samym kluczem (co zachowuje aktywowany profil). Automatyzacja całości w jednym skrypcie i jej wielokrotne uruchomienie na kolejnych wersjach usuwa ostatnią wątpliwość co do charakteru tej warstwy: kontrola, którą da się zdjąć bezobsługowo i powtarzalnie, nie jest granicą bezpieczeństwa. Skrypt automatyzujący całość wraz z jego analizą dołączam jako materiał do pobrania (przycisk na górze strony); nagranie przebiegu dojdzie osobno.

Rozgraniczenie i pytanie otwarte. Zakres potwierdzony to obejście bramy startowej i uruchomienie interfejsu. Czy po zdjęciu tej bramy wrażliwe dokumenty są renderowane na podstawie danych świeżo pobranych z serwera na urządzeniu o naruszonej integralności, czy jedynie ze stanu lokalnego, wymaga osobnej, ostrożnej weryfikacji i nie jest tu przesądzane. To rozgraniczenie wyznacza zarazem kryterium naprawy.

Zalecenie. Wykrywanie środowiska po stronie klienta należy traktować jako sygnał telemetryczny i element komfortu, nigdy jako kontrolę dostępu. Rozstrzygające zapewnienie integralności urządzenia musi pochodzić z atestacji poświadczanej sprzętowo i egzekwowanej po stronie serwera (np. werdykt sprzętowy Play Integrity jako twardy warunek wydania danych), a udostępnienie dokumentu tożsamości nie może zależeć od wyniku kontroli wykonywanej w procesie, który atakujący w pełni kontroluje. Wynik ten jest empirycznym uzupełnieniem MOB-A oraz sekcji 19 i 17.

24.6. Protokół pobierania dokumentów

Ścieżkę komunikacji zrekonstruowano z kodu i potwierdzono wykonaniowo na poziomie metadanych połączeń, bez przechwytywania ani odszyfrowywania treści — ruch pozostaje chroniony przypinaniem certyfikatu, a jego zawartość nie była przedmiotem tego testu.

Endpointy (z c64/a.java:163). Aplikacja korzysta z pojedynczej bramy API pod hostem api.mobywatel.gov.pl. Pobranie dokumentu przebiega jako sekwencja wyzwanie–odpowiedź oparta na JWT: authentication/mobile/api/challenge oraz authentication/mobile/api/authentication/challenge (pobranie wyzwania), authentication/mobile/api/jwt (wymiana na token), a następnie authentication/mobile/api/source-documents/download-async — asynchroniczne pobranie dokumentu źródłowego. Odświeżanie listy zaufanych certyfikatów idzie przez mobile-settings/mobile/api/trusted-certificates.

Potwierdzenie wykonaniowe (metadane). Na patchowanym wydaniu uruchomionym w WSA odnotowano, że operacje „Aktualizuj dane" dokumentu, wgląd w dane pojazdu oraz pobranie punktów karnych łączą się z tym samym hostem — api.mobywatel.gov.pl, rozwiązywanym na 185.41.93.206, port 443. Potwierdza to, że poszczególne usługi nie mają osobnych backendów, lecz korzystają ze wspólnej bramy. Zarejestrowano wyłącznie adres i port połączenia; zawartości nie przechwytywano.

Transport i krypto. Warstwa transportowa to HTTPS z przypinaniem certyfikatu i przejrzystością certyfikatów (zob. MOB-A-01). Ładunek aplikacyjny jest dodatkowo opakowany w CMS: żądanie jako CMSEnvelopedData szyfrowane do certyfikatu użytkownika (dh2/a.java), odpowiedź jako CMSSignedData. Istotne dla oceny: odpowiedź jest dekodowana i parsowana do modelu dokumentu bez lokalnej weryfikacji podpisu podpisującego — czyli ustalenie MOB-A-05 dotyczy tej samej, wspólnej ścieżki source-documents/download-async, a więc każdego pobieranego dokumentu (mDowód, dowód rejestracyjny, punkty karne i pozostałe), nie zaś pojedynczego typu. To rozszerza zasięg MOB-A-05 z konkretnego dokumentu na cały mechanizm dystrybucji dokumentów.

Granica testu. Zakres celowo ograniczono do rekonstrukcji z kodu i metadanych połączeń. Nie prowadzono przechwytywania treści ani deszyfrowania ruchu produkcyjnego — wymagałoby to złamania przypinania i operowania na realnych danych tożsamości oraz tokenach uwierzytelniających, co wykracza poza autoryzację posiadacza konta i poza zakres tego audytu.

Topologia i parametry TLS (metadane). W osobnej sesji, na koncie badacza, zarejestrowano metadane ruchu (tcpdump, bez deszyfrowania treści TLS 1.3). Ruch tożsamościowy zamyka się w zakresach IP COI: api.mobywatel.gov.pl (185.41.93.206, AS199953) obsługuje pobieranie dokumentów przez TLS 1.3 (krzywe X25519/secp256r1; szyfry TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256; ALPN h2), a telemetria trafia do sentry.puch.coi.gov.pl (185.32.48.239:3000, AS200244). Zarejestrowano wyłącznie adresy, porty i parametry sesji; zawartości nie przechwytywano.

Weryfikacja wykonaniowa dokumentów. Na koncie badacza sprawdzono wykonaniowo trzy aktywne dokumenty — mDowód, mPrawo jazdy i mPojazdy — odwzorowując dane wykonaniowe na klasy modelu z dekompilacji: MobileIdCardContainerDto / MobileIdCardPersonalDataContainerDto, DrivingLicenceScopeDto / DrivingLicenceDataContainerDto oraz VehicleCardDataDto (warianty VehicleBasicDocumentDto / VehicleFullDocumentDto). Wszystkie trzy przechodzą tą samą ścieżką source-documents/download-async i tym samym potokiem CMS, co potwierdza wykonaniowo, że zasięg MOB-A-05 obejmuje cały mechanizm dokumentów. Danych osobowych nie odtwarzam.

24.7. Szyfrowanie tożsamości w spoczynku — audyt wykonaniowy

Ekstrakcja kontenerów z pamięci masowej (na koncie badacza, WSA z rootem) pozwoliła zweryfikować ochronę danych w spoczynku. Obraz jest mieszany i pouczający: tam, gdzie sięgnięto po gotowe, zaudytowane biblioteki, jest dobrze; tam, gdzie napisano kryptografię własnym sumptem, pojawia się chałupnictwo — rozwiązania, które biblioteka wykluczyłaby z urzędu.

Co zrobiono dobrze. Rejestry SharedPreferences są w pełni chronione przez EncryptedSharedPreferences z biblioteką Google Tink: nazwy kluczy szyfrowane deterministycznie (AesSivKey), wartości uwierzytelnionym AesGcmKey. To jest wzorcowe: AEAD z gotowego, sprawdzonego źródła.

Kontener tożsamości — pięć sygnałów chałupnictwa. Sam plik kontenera jest zaszyfrowany, ale sposób jego złożenia obnaża rękodzieło:

1. AES-256-CBC bez uwierzytelnienia. Tryb to AES/CBC/PKCS5Padding (ch2/c.java:22) — CBC bez MAC, czyli bez kontroli integralności. W 2026 r. standardem jest AEAD (AES-GCM), a Tink, którego COI używa obok w SharedPreferences, daje je za darmo. Tutaj świadomie sięgnięto po własny CBC.
2. Wektor IV doklejany na końcu pliku. ch2/a.java zwraca concatenate(prefiks, doFinal(dane), IV) — IV trafia na koniec strumienia zamiast, jak w każdej normalnej bibliotece, na początek. Działa, lecz to jednoznaczny ślad formatu składanego ręcznie, wbrew konwencji.
3. 17-bajtowy losowy „junk prefix". Przed właściwym strumieniem ZLIB wstrzykiwane jest siedemnaście losowych bajtów z CSPRNG (ch2/a.java, cipher.update(random(17))), co przesuwa granicę pierwszego bloku AES o jeden bajt. Cel: chałupnicze maskowanie nagłówka ZLIB, żeby utrudnić rozpoznanie formatu pod spodem. To security-by-obscurity w czystej postaci — nie dodaje ani grama realnego bezpieczeństwa (z kluczem odczyt i tak następuje, bez klucza CBC i tak nie zdradza treści), a komplikuje format. Podręcznikowa definicja chałupnictwa: rozwiązywanie nieistniejącego problemu własnym pomysłem zamiast użyć AEAD.
4. Sól KDF bez realnej wartości ochronnej po zrzucie danych. Klucz kontenera wyprowadza PBKDF2 z soli saltApp ⊕ NSalt ⊕ deviceID (j.java, g()); mimo losowej NSalt wszystkie składniki są odczytywalne z danych aplikacji, więc sól nie chroni pliku w modelu utraty urządzenia. Odrębny, mocniejszy przypadek stałej soli dotyczy legitymacji studenckiej (MOB-A-06).
5. Brak wiązania integralności z tożsamością — spójne z MOB-A-05 i 9.8: szyfrowanie chroni poufność, ale nic nie wiąże kontenera z okazicielem na poziomie kryptograficznym.

Wyciek, który obchodzi całą tę kryptografię. Podczas gdy kontenery i rejestry są szyfrowane, dwie bazy Room — powiadomień (LocalNotificationsDatabase, plik local_notifications_db) oraz indeks wyszukiwania (GlobalSearchDatabase) — zainicjowane standardowym Room.databaseBuilder bez fabryki openHelperFactory/SQLCipher, leżą w czystym tekście i trzyma dane pochodne o wysokiej wrażliwości: numer tablicy rejestracyjnej, typ dokumentu oraz daty ważności — badania technicznego, ubezpieczenia OC, a także ważności mDowodu i prawa jazdy. Model danych potwierdza dekompilacja (br1/p0.java: pola registerNo, insuranceDate, technicalExaminationDate; encja x04/LocalVehicleNotificationEntity z polem registerNo, obok LocalDocumentNotifications). Dowolny proces z dostępem do danych aplikacji albo ekstrakcja powypadkowa czyta te fakty z pominięciem KeyStore, SQLCipher i Tink. To jest realna luka poufności: cała inwestycja w kryptografię kontenera zostaje obejściem bocznym kanałem, który te same wrażliwe informacje przechowuje jawnie.

Przykład odczytany wprost z bazy (dane badacza, częściowo zredagowane — to realny wyciek z mojego urządzenia): RegisterNo = WN42XXA, DocType = VEHICLE_CARD, badanie techniczne 2026-07-xx, OC 2027-03-xx; w tabeli dokumentów ważność mDowodu 2029-… i prawa jazdy 2028-…. Wszystko w otwartym SQLite, bez jednego bajtu szyfrowania.

Brak jakiegokolwiek Keystore w ścieżce kontenera — i co z tego wynika. Przeszukanie całego pakietu legacy/storage nie wykazało ani jednego odwołania do Android Keystore, KeyGenParameterSpec ani StrongBox; materiał klucza żyje w zwykłej mapie w pamięci (ContainerManagerNew.java:57, Map<d, byte[]>). Klucz kontenera powstaje w całości programowo: PBKDF2WithHmacSHA256(sekret, sól, 65 536 iteracji, 256 bitów) (bh2/a.java:58; CMSAlgorithm.AES256_CBC, bh2/a.java:55), a sól — inaczej niż w legitymacji studenckiej (MOB-A-06) — nie jest pojedynczą stałą: wyprowadza się ją operacją XOR z trzech składników saltApp ⊕ NSalt ⊕ deviceID (j.java, metoda g()), gdzie stała saltApp pochodzi z DEX (d64/p.java:11), NSalt jest losowana per instalacja i zapisana jawnie w mDoki_0.10.xml (j.java, metoda f()), a deviceID bazuje na Android ID / IMEI (j.java, metoda c()). Sekretem jest hasło odblokowujące — w ścieżce aktywacji do wyprowadzenia klucza trafia b0.e(password).getBytes() (ei2/b.java), a w typowym trybie jest to czterocyfrowy lub sześciocyfrowy PIN. Ochrona Keystore opisana w MOB-BIN-02 dotyczy wyłącznie loginowego bloba biometrii, nie samego pliku kontenera. Konsekwencja jest poważna i podnosi ocenę tej klasy: plik kontenera tożsamości jest atakowalny offline po zrzucie danych aplikacji — pliku kontenera wraz z NSalt z mDoki_0.10.xml i identyfikatorem urządzenia — bez sprzętowego klucza. W trybie PIN przestrzeń sekretu wynosi 10⁴–10⁶ kombinacji; bez sprzętowego ograniczania prób pełny przegląd na konsumenckiej karcie GPU rzędu RTX 4090 zamyka się w sekundach — od ułamka sekundy dla czterech cyfr do kilkunastu–dwudziestu sekund dla sześciu. W trybie hasła koszt zależy od jego siły; losowa NSalt wyklucza jedynie tablice tęczowe współdzielone między ofiarami, natomiast nie chroni pojedynczego celu — wszystkie składniki soli są odczytywalne z danych urządzenia. Dodatkowo 65 536 iteracji PBKDF2 jest niemal dziesięciokrotnie poniżej bieżących zaleceń OWASP (≥ 600 000), a brak układu TEE pozwala na nieograniczony, zrównoleglony atak słownikowy na klastrze GPU.

Zjawisko jest niezależne od urządzenia — ścieżka kontenera jest identyczna w kodzie, więc dotyczy zwykłego telefonu tak samo jak środowiska wirtualnego. Co więcej, na telefonie z PIN-em ochrona jest słabsza (sekundy), a biometria nie zabezpiecza samego pliku: klucz „BiometricKey" w Keystore owija jedynie przechowywaną kopię sekretu dla wygody odblokowania, natomiast atakujący dysponujący kopią danych aplikacji łamie PIN wprost przeciw plikowi, z pominięciem Keystore. Sprzętowy magazyn chroni wejście do aplikacji, nie dane w spoczynku. W żadnym wariancie nie ma sprzętowego wiązania klucza ani ograniczania tempa prób. To jest dysonans w czystej postaci: nowoczesne rejestry chroni Tink z Keystore, a najcenniejszy plik — tożsamość obywatela — kryptografia własnej roboty bez sprzętu.

Dysonans widać w jednym zestawieniu:

Ocena i naprawa. Wzorzec jest podręcznikowy: gdzie użyto biblioteki (Tink), jest dobrze; gdzie pisano samemu (CBC bez MAC, IV na końcu, junk-prefix, sól w całości odtwarzalna z danych urządzenia, jawne bazy pomocnicze), tam błędy. Naprawa jest nudna i znana: AEAD (AES-GCM) z prawdziwym MAC na kontenerze, sole z CSPRNG osadzone w magazynie kluczy, i szyfrowanie wszystkich baz trzymających dane pochodne — openHelperFactory SQLCipher także dla powiadomień i indeksu wyszukiwania, nie tylko dla głównych kontenerów. Kierunek domyka wzorzec z 22.1.

24.8. Granice FLAG_SECURE wobec uprawnień root

Podrozdział 24.2 potwierdził, że FLAG_SECURE blokuje zrzut ekranu i nagrywanie programowe — i tak jest, lecz wyłącznie wobec napastnika nieuprzywilejowanego. Wobec właściciela urządzenia dysponującego rootem flaga jest ochroną iluzoryczną. Nie jest to wada mObywatela, tylko granica samego mechanizmu; odnotowuję ją, ponieważ audyt nie może traktować FLAG_SECURE jako gwarancji przed ekstrakcją lokalną (spójne z sekcją 18 i z wnioskiem 24.7 o danych w spoczynku).

Flaga jest własnością obiektu Window w procesie aplikacji, więc z rootem zdejmuje się ją co najmniej na trzy znane, generyczne sposoby — niezależne od tej aplikacji:

• Instrumentacja w locie (Frida). Hook na tworzeniu widoku czyści flagę, po czym telefonowy zrzut działa normalnie:

  Activity.onResume.implementation = function () {
  this.getWindow().clearFlags(0x2000); // 0x2000 = FLAG_SECURE
  this.onResume();
  };

• Moduł Xposed/LSPosed (klasy „Disable FLAG_SECURE"). Hook setFlags w procesie system_server sprawia, że system ignoruje żądanie aplikacji — okno trafia do SurfaceFlingera jako jawne, a zrzuty działają globalnie, w każdej aplikacji.
• Patch SurfaceFlinger (Magisk). Podmiana/łatka libgui.so lub procesu surfaceflinger tak, by layer->isSecure() zawsze zwracało false, powoduje kopiowanie każdego bufora graficznego niezależnie od ustawień aplikacji.

Wniosek z modelu zagrożeń. FLAG_SECURE zaprojektowano wyłącznie jako ochronę przed nieuprzywilejowanym malware — na przykład by aplikacja ze sklepu, nadużywająca usług ułatwień dostępu lub nagrywania ekranu w tle, nie podejrzała wpisywanego hasła czy dowodu. Nigdy nie było barierą przed właścicielem urządzenia ani przed rootem. Traktowanie go jako gwaranta ochrony danych przed ekstrakcją lokalną jest błędem architektonicznym — i właśnie dlatego ochrona tożsamości w spoczynku (24.7) nie może się na nim opierać.

25. Źródła zewnętrzne

• KVC Research — wzorzec publikacji technicznej
• Oficjalny Digital Asset Links mObywatel
• Google Play — mObywatel
• CERT Polska — CVE-2025-11598
• NVD — CVE-2025-11598
• Oficjalna publikacja kodu — dostęp po potwierdzeniu tożsamości
• BIP Ministerstwa Cyfryzacji — komunikat o udostępnieniu kodu źródłowego
• Kopia lustrzana kodu — fajfer/mObywatel, zmiana d39d2f94 z 4 stycznia 2026 r.
• Kopia lustrzana kodu — neziw/mObywatel-mirror, materiał badany w sekcji 20.3
• Analiza zakresu publikacji kodu mObywatel
• SecuRing — How we helped secure Poland's digital ID system (analiza server-side, ang.)
• CyberDefence24 — opublikowano fragmenty kodu źródłowego mObywatela
• Ministerstwo Cyfryzacji — komunikat o publikacji kodu
• Prawo autorskie — tekst jednolity, art. 74–77
• Ustawa o aplikacji mObywatel — tekst jednolity
• Bouncy Castle Java 1.85 — nota wydania i lista poprawek CVE
• Bouncy Castle — CVE-2026-5588
• Bouncy Castle — CVE-2025-14813
• Bouncy Castle — CVE-2026-0636
• Bouncy Castle — CVE-2026-3505
• Bouncy Castle — CVE-2026-5598
• Bouncy Castle Java — bieżące wydania 1.85.x
• OSV API
• Bouncy Castle API — CMSSignedData
• OWASP Password Storage Cheat Sheet — punkt odniesienia dla PBKDF2
• RFC 9700 / BCP 240 — OAuth 2.0 Security Best Current Practice
• Android Developers — Tapjacking

Add a comment

Name (optional)

Email (optional, never published)

Comment *

Type the characters from the image *

Submit