---
title: 'mBank 3.122.4 — niezależny audyt bezpieczeństwa (analiza statyczna i dynamiczna)'
url: 'https://kvc.pl/analizy-techniczne-pl/mbank-audyt-bezpieczenstwa'
markdown: 'https://kvc.pl/analizy-techniczne-pl/mbank-audyt-bezpieczenstwa.md'
date: '2026-09-26'
description: 'Niezależna analiza statyczna i dynamiczna produkcyjnego pakietu APK mBank 3.122.4 (pl.mbank) w środowisku WSA z MagiskSU. Weryfikacja TrustKit, 21 domen z przypiętymi certyfikatami, FaceTec, eksportowanych komponentów, BlikC HCE, baz SQLite, telemetrii oraz powiązanej aplikacji maklerskiej eMakler giełda (pl.mbank.bmmobile 6.7.4, .NET MAUI). Wyniki rozdzielają fakty statyczne, potwierdzenia wykonaniowe oraz weryfikację hipotez bezpieczeństwa.'
---

# mBank 3.122.4 — niezależny audyt bezpieczeństwa (analiza statyczna i dynamiczna)

**Autor:** Marek Wesołowski (WESMAR) · [github.com/wesmar](https://github.com/wesmar) · [kvc.pl](https://kvc.pl)

> **W skrócie.** Artykuł przedstawia wyniki niezależnego audytu bezpieczeństwa aplikacji mBank 3.122.4, pakiet `pl.mbank`, versionCode 99201. Zakres prac objął analizę statyczną manifestu, konfiguracji bezpieczeństwa sieci TrustKit obejmującej 21 domen i 78 skrótów SPKI SHA-256, eksportowanych komponentów w liczbie 6 aktywności, 4 usług, 3 odbiorników oraz 1 dostawcy treści, uprawnień i bibliotek natywnych. Analizę dynamiczną zrealizowano w środowisku WSA 2407 z aktywnym MagiskSU oraz proxy rejestrującym BurpSuite. Aplikacja pozostaje zalogowana w trybie obserwacyjnym. Żadna operacja finansowa nie była wykonywana.

 **Status z 22 września 2026 r.** Środowisko WSA: `127.0.0.1:58526`, Android 13, API 33, architektura x86_64, aktywny MagiskSU. Wersja produkcyjna `pl.mbank 3.122.4` pomyślnie aktywowana i zalogowana w widoku `MainActivity`. Dekompilacja JADX zakończona: 44 677 plików Java. Działanie flagi `FLAG_SECURE` potwierdzone wykonaniowo: zrzut klatki zablokowany, rozmiar pliku wyjściowego 0 B. Analiza statyczna modułu tożsamości SAM, mechanizmów anty-root, baz danych SQLite oraz komponentu `EMaklerProvider` została zakończona. Przygotowano zestaw skryptów Frida do kontrolowanych testów dynamicznych. 

Werdykt końcowy: analiza statyczna i dynamiczna

**mBank 3.122.4: ocena końcowa 7,2/10.** Prawidłowo wdrożone mechanizmy bezpieczeństwa obejmują reguły `allowBackup=false`, `usesCleartextTraffic=false`, dyrektywę bazową `cleartextTrafficPermitted=false`, bibliotekę TrustKit z parametrem `enforcePinning=true` dla 21 domen oraz usługę BlikC HCE zabezpieczoną dedykowanym uprawnieniem NFC. Zidentyfikowane uchybienia i obszary ryzyka obejmują uprawnienia `QUERY_ALL_PACKAGES` oraz `READ_PHONE_STATE`, rozbudowane żądania lokalizacyjne, flagę `requestLegacyExternalStorage=true`, zewnętrzny moduł biometrii FaceTec oraz wyeksportowaną aktywność `BiometricSettingsDeeplinkActivity` bez deklaracji uprawnień. Ogólny poziom bezpieczeństwa plasuje się blisko aplikacji eDO App, obniżony głównie przez podatność MBA-A-08 w procedurze szyfrowania preferencji. 

Ocena ważona architektury bezpieczeństwa

| Oś oceny | Waga | Ocena | Uzasadnienie |
|---|---|---|---|
| Dane w spoczynku | 25% | **5,5/10** | Podatność MBA-A-08: uniwersalny klucz w kodzie aplikacji oraz deterministyczny schemat szyfrowania; MBA-A-06: przestarzały KDF bez uwierzytelnienia AEAD. Ocenę łagodzi brak danych kartowych i sald w lokalnych magazynach. |
| Transport i pinning | 20% | **9,0/10** | Rygorystyczna konfiguracja TrustKit z wymuszeniem enforcePinning na 21 domenach, 78 skrótów SPKI SHA-256, całkowite zablokowanie ruchu jawnego. |
| Ochrona przed modyfikacją i root | 15% | **7,5/10** | Stopniowana degradacja: wyłączenie metod biometrycznych w środowisku ze zmodyfikowanym systemem; przekazanie sygnału integralności do logiki biznesowej bez wymuszania natychmiastowego zakończenia procesu. |
| Komponenty i IPC | 15% | **7,0/10** | Odsyłacze nieeksportowane, kluczowe formularze renderowane natywnie. Uchybienie MBA-A-07: brak weryfikacji podpisu wywołującego w metodzie insert() komponentu EMaklerProvider. |
| Biometria i klucze sprzętowe | 15% | **8,5/10** | Izolacja kluczy BLIK oraz biometrii w sprzętowym module TEE przez Android Keystore, wymóg autoryzacji użytkownika z oknem ważności 60 sekund. |
| Prywatność | 10% | **6,0/10** | Pełna enumeracja zainstalowanych pakietów, próby odczytu identyfikatora sprzętowego IMEI, telemetria zewnętrznych modułów FaceTec oraz Synerise. |

**Wynik ważony: 7,2/10.** Architektura sieciowa i integracja z magazynem sprzętowym reprezentują wysoki standard inżynierski. Zidentyfikowane uchybienia dotyczą lokalnej implementacji kryptograficznej, określonej w ustaleniach MBA-A-08 oraz MBA-A-06, a także kalibracji heurystyk oceny ryzyka anti-fraud.

---

## 1. Zakres badania i granice wniosków

Badanie przeprowadzono na kontrolowanej instalacji testowej w środowisku WSA z wykorzystaniem dedykowanego rachunku bankowego. Celem prac jest niezależna ocena architektury bezpieczeństwa klienta mobilnego. W analizie wyodrębniono trzy kategorie ustaleń:

1. **Dowód statyczny:** fakty wynikające bezpośrednio ze zdekodowanego manifestu, zasobów oraz kodu bajtowego DEX.
2. **Dowód wykonaniowy:** fakty zarejestrowane w logach systemowych logcat, sesji ADB oraz analizie ruchu TLS w proxy BurpSuite.
3. **Hipoteza audytowa:** wektor wymagający weryfikacji w kontrolowanych warunkach testowych.

Zasada integralności środowiska: wszelkie czynności prowadzono w reżimie pasywnym bez inicjowania operacji finansowych, takich jak przelewy, modyfikacja limitów transakcyjnych czy zmiana danych profilowych. Zakres badania obejmuje monitorowanie zachowania zalogowanej aplikacji, rejestrację pakietów sieciowych oraz analizę reakcji na spreparowane obiekty Intent.

## 2. Materiał i powtarzalność

| Element | Wartość |
|---|---|
| Pakiet | `pl.mbank` |
| Wersja | `3.122.4` |
| VersionCode | `99201` |
| minSdk / targetSdk | `29` / `35` |
| Stos technologiczny | Kotlin, Java w środowisku uruchomieniowym Android Runtime |
| Plik APK `base.apk` | 123 489 608 B (~118 MiB) |
| SHA-256 `base.apk` | `447B0EDFD998E5F3C54B3D40721C2059CA4C4CD4392D0DED0A427AE54AC85782` |
| Źródło pochodzenia | Sklep Google Play, pobranie poleceniem `adb pull` ze środowiska WSA |
| Data instalacji | 2026-09-22 23:10:39 |

## 3. Środowisko testowe

| Warstwa | Stan środowiska |
|---|---|
| Podsystem WSA | Wersja `2407.40000.4.0`, Android 13, API 33, architektura x86\_64 |
| Połączenie ADB | `127.0.0.1:58526` |
| Uprawnienia root | MagiskSU aktywny |
| Poziom SELinux | `Enforcing` |
| Proxy rejestrujące | BurpSuite z certyfikatem badawczym |
| Framework Frida | Skrypty przygotowane do testów kontrolowanych |
| Status mBank | Aktywna sesja w wersji produkcyjnej |

## 4. Identyfikacja i weryfikacja artefaktu

Dane identyfikacyjne pakietu uzyskane z polecenia `dumpsys package pl.mbank` w podsystemie WSA:

```text
userId    = 10088
codePath  = /data/app/~~2Scj4FO7bWZRi2PMCLv43w==/pl.mbank-ohHMJGPG8zUqbNgM7AkRBw==
versionCode=99201 minSdk=29 targetSdk=35
versionName=3.122.4
pkgFlags  = [ HAS_CODE ALLOW_CLEAR_USER_DATA LARGE_HEAP ]
firstInstallTime=2026-09-22 23:10:39
```

Certyfikat podpisujący podlega weryfikacji po pełnej dekompilacji JADX poprzez zestawienie z odciskiem publikowanym przez domenę `mbank.pl`.

---

## 5. Analiza manifestu aplikacji

### 5.1. Główne flagi konfiguracyjne

| Właściwość | Wartość | Ocena techniczna |
|---|---|---|
| `android:allowBackup` | `false` | Kopia zapasowa wyłączona |
| `android:usesCleartextTraffic` | `false` | Transmisja jawnym tekstem zablokowana |
| `android:debuggable` | domyślnie false z braku deklaracji | Tryb debugowania wyłączony |
| `android:networkSecurityConfig` | `@xml/network_security_config` | Dedykowana konfiguracja bezpieczeństwa sieci |
| `android:requestLegacyExternalStorage` | `true` | Zezwolenie na tradycyjny model dostępu do pamięci masowej |
| `android:largeHeap` | `true` | Alokacja powiększonej sterty pamięci |
| `android:fullBackupContent` | `@xml/synerise_backup_rules` | Selektywne reguły kopii zapasowej Synerise |

**MBA-O-01: Obecność flagi requestLegacyExternalStorage=true.** Flaga wymusza tradycyjny model dostępu do pamięci masowej z pominięciem mechanizmu Scoped Storage. Na urządzeniach z poziomem API 29, odpowiadającym wartości minSdk aplikacji, umożliwia to odczyt i zapis w katalogach ogólnodostępnych. Tworzy to potencjalne ryzyko zapisu danych aplikacji w lokalizacjach dostępnych dla innych procesów. Zakres reguł wykluczeń zdefiniowany w `synerise_backup_rules.xml` podlega szczegółowej weryfikacji.

### 5.2. Analiza eksportowanych komponentów

#### Aktywności eksportowane

| Komponent | Zabezpieczenie | Uwagi architektoniczne |
|---|---|---|
| `pl.mbank.core.activity.StartActivity` | brak deklaracji permission | Punkt wejścia aplikacji przyjmujący zewnętrzne obiekty Intent |
| `pl.mbank.feature.androidpay.view.activity.AndroidPayTokenVerificationActivity` | `readPermission` oraz `writePermission = pl.mbank.permission.ROUTE_INTERNAL` | Dostęp ograniczony uprawnieniem wewnętrznym |
| `pl.mbank.feature.androidpay.view.activity.AndroidPayPushTokenizeActivity` | `pl.mbank.permission.ROUTE_INTERNAL` | Dostęp ograniczony uprawnieniem wewnętrznym |
| `pl.mbank.pinpad.biometry.ui.view.BiometricSettingsDeeplinkActivity` | **brak deklaracji permission** | Aktywność wyeksportowana bez ochrony uprawnieniem |
| `pl.mbank.feature.notification.view.NotificationsActivity` | `pl.mbank.permission.ROUTE_INTERNAL` | Dostęp ograniczony uprawnieniem wewnętrznym |
| `pl.mbank.EMaklerActivity` | `pl.mbank.eMaklerProviderPermission` | Alias aktywności. Dostęp ograniczony uprawnieniem dostawcy maklerskiego |

**MBA-A-01: Wyeksportowanie BiometricSettingsDeeplinkActivity bez deklaracji uprawnień.** Aktywność `pl.mbank.pinpad.biometry.ui.view.BiometricSettingsDeeplinkActivity` oznaczono atrybutem `exported="true"` bez wymogu posiadania uprawnienia `android:permission`. Pozwala to dowolnej aplikacji w systemie na przesłanie jawnego obiektu Intent. Analiza statyczna metody `onCreate()` wykazała, że aktywność realizuje wstrzyknięcie komponentu DI i wykonuje przekierowanie do klasy `LegacyBiometricSettingsActivity`, po czym kończy własne działanie. W implementacji wykluczono odczyt parametrów ze strumienia wejściowego, co potwierdza brak wywołań `getIntent()` oraz `getData()`. Eliminuje to wektor wstrzyknięcia parametrów do sesji. Aplikacja zewnętrzna może wywołać jedynie przejście do wewnętrznego ekranu konfiguracji biometrii, który egzekwuje własną kontrolę sesji. Test dynamiczny w środowisku WSA potwierdził to zachowanie: polecenie `am start` skierowane do omawianej aktywności otworzyło `LegacyBiometricSettingsActivity` w kontekście trwającej sesji bez transferu nieautoryzowanych danych.

#### Usługi eksportowane

| Komponent | Zabezpieczenie | Rola komponentu |
|---|---|---|
| `pl.mbank.core.authenticator.NmbAuthenticationService` | `ROUTE_INTERNAL` | Moduł integracji z Android AccountManager |
| `pl.mbank.feature.blikc.service.BlikCHceService` | `android.permission.BIND_NFC_SERVICE` | Obsługa transakcji zbliżeniowych BLIK Contactless w standardzie HCE |
| `com.google.android.gms.auth.api.signin.RevocationBoundService` | Uprawnienie systemowe GMS | Usługa odwoływania sesji Google Sign-In |
| `androidx.work.impl.background.systemjob.SystemJobService` | `BIND_JOB_SERVICE` | Harmonogram zadań biblioteki WorkManager |

Usługę `BlikCHceService` zabezpieczono uprawnieniem `android.permission.BIND_NFC_SERVICE`, co stanowi poprawną implementację standardu emulacji kart hosta Host Card Emulation w systemie Android.

#### Dostawcy treści

| Komponent | Zabezpieczenie |
|---|---|
| `pl.mbank.EMaklerProvider` | `readPermission` oraz `writePermission = pl.mbank.eMaklerProviderPermission` |

Dostęp do dostawcy treści ograniczono dedykowanym uprawnieniem aplikacyjnym.

---

## 6. Konfiguracja bezpieczeństwa sieci: TrustKit oraz Network Security Config

### 6.1. Konfiguracja bazowa Network Security Config

```xml
<base-config cleartextTrafficPermitted="false">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>
```

**Ocena techniczna:** Konfiguracja poprawna. Globalna transmisja jawnym tekstem została zablokowana. Magazyn kotwic zaufania ograniczono wyłącznie do certyfikatów systemowych. W konsekwencji instalacja certyfikatu inspekcyjnego BurpSuite w magazynie użytkownika nie pozwala na przechwycenie ruchu TLS bez uprzedniego przełamania mechanizmu przypinania certyfikatów.

### 6.2. Wdrożenie biblioteki TrustKit i przypinanie certyfikatów

Aplikacja wykorzystuje bibliotekę **TrustKit-Android** firmy Data Theorem jako dedykowaną warstwę weryfikacji certyfikatów nadbudowaną nad standardowym plikiem konfiguracji sieci. Każda domena posiada:

- regułę `cleartextTrafficPermitted="false"`;
- sekcję `<pin-set>` zawierającą od 4 do 5 skrótów SPKI SHA-256 zapewniających redundancję awaryjną;
- dyrektywę `<trustkit-config enforcePinning="true"/>`.

| Zasięg konfiguracji | Wartość |
|---|---|
| Liczba zdefiniowanych domen | **21** |
| Łączna liczba przypiętych skrótów SPKI SHA-256 | **78** |
| Domeny z zezwoleniem na nieszyfrowany ruch HTTP | 0 |
| Egzekwowanie reguły enforcePinning | **100% domen** |
| Obecność sekcji debug-overrides | **brak** |

**Objęte domeny:** `m.mbank.pl`, `m.mbank.cz`, `m.mbank.sk`, `online.mbank.pl`, `online.mbank.cz`, `online.mbank.sk`, `www.mbank.pl`, `www.mbank.cz`, `www.mbank.sk`, `csp.mbank.pl`, `skp.mbank.pl`, `eo.eombank.pl`, `form.mbank.pl/cz/sk`, `ecommerce.cdn-az.mbank.pl`, `podpis.mbank.pl`, `mojeid.mbank.pl`.

**Weryfikacja statyczna.** Konfiguracja biblioteki TrustKit została wdrożona rygorystycznie. Wyłączono ruch otwarty, pominięto sekcję `debug-overrides`, wykluczono certyfikaty użytkownika oraz wymuszono regułę `enforcePinning="true"` dla wszystkich domen. Implementacja spełnia wymagania bezpiecznego przypinania kluczy publicznych w standardzie HPKP i SPKI. Weryfikacja odporności w warunkach dynamicznych wymaga kontrolowanego testu proxy z certyfikatem badawczym po załadowaniu skryptu neutralizującego TrustKit we frameworku Frida.

### 6.3. Wektory obejścia mechanizmu pinningu

| Hipoteza badawcza | Status weryfikacji |
|---|---|
| Obejście TrustKit przez przechwycenie metody PinningTrustManager.checkServerTrusted() | Hipoteza P0: przygotowano skrypt `03_trustkit_bypass.js` |
| Obejście przez modyfikację fabryki SSLContext w maszynie JVM | Hipoteza P0: skrypt `01_ssl_pinning_bypass.js` |
| Obejście natywne przez hook na symbol SSL\_verify\_peer\_certificate w libssl.so | Hipoteza P0: implementacja w skrypcie 03 |
| Transmisja nieszyfrowana do domen zewnętrznych poza regułami NSC | Weryfikacja w toku analizy dziennika logcat |

---

## 7. Analiza uprawnień aplikacji

### 7.1. Uprawnienia o podwyższonym poziomie ryzyka

| Uprawnienie | Uzasadnienie techniczne i wektory ryzyka |
|---|---|
| `ACCESS_FINE_LOCATION`, `ACCESS_COARSE_LOCATION` | Odczyt precyzyjnych i przybliżonych współrzędnych geograficznych: moduł lokalizacji placówek lub telemetria kontekstowa |
| `READ_PHONE_STATE` | Odczyt parametrów sieci komórkowej oraz próba dostępu do numerów IMEI i IMSI: profilowanie urządzenia |
| `QUERY_ALL_PACKAGES` | Pełna enumeracja zainstalowanych pakietów oprogramowania: detekcja narzędzi modyfikujących system |
| `WRITE_EXTERNAL_STORAGE`, `READ_EXTERNAL_STORAGE` | Dostęp do współdzielonej pamięci urządzenia: zapis pobieranych dokumentów i potwierdzeń |
| `GET_ACCOUNTS`, `MANAGE_ACCOUNTS` | Dostęp do kont systemowych: zaszłość wsteczna zbędna od wersji Android 8.0, poziom API 26 |
| `SMARTCARD`, `org.simalliance.openmobileapi.SMARTCARD` | Bezpośrednia komunikacja z kartą SIM oraz modułem Secure Element: obsługa usługi BlikC HCE |
| `com.google.android.gms.permission.AD_ID` | Odczyt identyfikatora reklamowego na potrzeby analityki zachowań w modułach Synerise i Firebase |
| `ACCESS_ADSERVICES_ATTRIBUTION` | Integracja z interfejsem Attribution API w celach telemetrycznych |

**MBA-O-02: Połączenie uprawnień QUERY\_ALL\_PACKAGES oraz READ\_PHONE\_STATE.** Zestawienie tych przywilejów umożliwia tworzenie szczegółowego profilu środowiska wykonawczego: odczyt parametrów identyfikacyjnych urządzenia oraz pełnej listy zainstalowanego oprogramowania. Zestaw ten typowo wspiera algorytmy oceny ryzyka nadużyć w modułach anti-fraud, lecz w wymiarze ochrony prywatności oznacza głębokie profilowanie stacji klienta. Rzeczywisty zakres danych telemetrycznych wysyłanych do infrastruktury bankowej podlega weryfikacji w analizie pakietów TLS.

---

## 8. Biblioteki i komponenty zewnętrzne

### 8.1. Zestawienie komponentów i bibliotek natywnych

| Komponent | Obsługiwane ABI | Rola architektoniczna | Uwagi techniczne |
|---|---|---|---|
| **`libnativeSeclib.so`** | arm64, armv7, x86, **x86\_64** | Natywny moduł bezpieczeństwa aplikacji | Eksportuje pojedynczy symbol JNI: `Java_pl_mbank_nativelib_SecLib_initialize`. Zwarta powierzchnia ataku. |
| **`libPhoenixAndroid.so`** | arm64, armv7 | Moduł biometrii FaceTec 3D Liveness, biblioteki Botan i OpenCV | Brak kompilacji dla architektury x86/x86\_64; komponent nieaktywny w środowisku WSA. |
| **`libbeda.so`**, **`libc5ba.so`** | arm64, armv7, x86, x86\_64 | Pliki zaślepiające o rozmiarze 1 bajta | Struktury atrapowe; docelowe binarne moduły ładowane dynamicznie. |
| **`libnative-library.so`** | arm64, armv7, x86, x86\_64 | Ogólna biblioteka natywna | Moduł podlegający dalszej analizie statycznej. |
| **Firebase** | nd. | Powiadomienia push Cloud Messaging oraz telemetria zdarzeń | Transmisja danych analitycznych do infrastruktury Google. |
| **Synerise** | nd. | Automatyzacja komunikacji i analityka behawioralna | Dedykowane reguły kopii w pliku `synerise_backup_rules.xml`. |
| **Picasso** | nd. | Asynchroniczne ładowanie obrazów przez PicassoProvider | Standardowa biblioteka pomocnicza; brak bezpośrednich ryzyk bezpieczeństwa. |
| **Room** | nd. | Lokalna warstwa dostępu do bazy SQLite | Koordynacja unieważniania instancji przez MultiInstanceInvalidationService. |

### 8.2. Weryfikacja pakietów blokowanych w security-packages-list.json

Plik `assets/security-packages-list.json` o rozmiarze 65 KB zawiera 643 wpisy pakietów blokowanych przez aplikację. Identyfikatory pakietów zapisano w postaci skrótów SHA-256.

```json
{
  "Timestamp": "66B85AB21E7D848FD89A5D01C17F6AAC",
  "Applications": [
    { "PackageName": "fc04fdeee345485421a5e1df4b7fded2bdc062666f48d1993dbda84f4a8b3963" },
    { "PackageName": "6733e8b20b34cb5fe82c976a5a7c1b5161afc185f2d20dcdea17d06d048a3d8d" },
    ...
  ]
}
```

Wyliczony skrót `SHA-256("com.topjohnwu.magisk")` wynosi `1d61da52...` i nie występuje na liście pośród 643 zdefiniowanych rekordów. Detekcja narzędzia Magisk realizowana jest na poziomie natywnym w bibliotece `libnativeSeclib`. Analizowany zbiór identyfikuje sygnatury znanego oprogramowania złośliwego oraz narzędzi wyłudzających dane.

**MBA-O-05: Statyczna lista blokowanych pakietów w security-packages-list.json.** Zastosowanie funkcji skrótu SHA-256 utrudnia bezpośrednią analizę zawartości czarnej listy. Pole znacznika czasu `66B85AB21E7D848FD89A5D01C17F6AAC` wskazuje na wersjonowanie zbioru. Statyczna dystrybucja listy wewnątrz pliku APK ogranicza elastyczność aktualizacji sygnatur; modyfikacja reguł wymaga wydania nowej wersji aplikacji, wykluczając bieżącą synchronizację z punktem końcowym serwera.

### 8.3. Moduł biometryczny FaceTec w bibliotece libPhoenixAndroid.so

Analiza ciągów tekstowych w bibliotece `libPhoenixAndroid.so` dla architektury arm64 o rozmiarze 3,47 MB wykazała obecność następujących komponentów:

- Symbole interfejsu JNI FaceTec: `Java_com_facetec_passportreaderapp_PassportReaderActivity_registerPassportReader`, `Java_com_facetec_sdk_JNI_rnm/fnm` realizujące weryfikację biometrii twarzy oraz dokumentów tożsamości.
- Biblioteka kryptograficzna Botan: klasa `N5Botan25Integer_Overflow_DetectedE` wbudowana w moduł FaceTec.
- Biblioteka widzenia komputerowego OpenCV: symbole `N2cv12RemapInvokerE`, `SVMDetector`, `opencv-object-detector-hog`.
- Dostępność architektur: bibliotekę skompilowano wyłącznie dla środowisk arm64-v8a oraz armeabi-v7a.

**MBA-A-02: Zewnętrzny łańcuch dostaw FaceTec oraz brak wsparcia dla platformy x86\_64.** Moduł FaceTec pozostaje nieaktywny w środowisku WSA z uwagi na brak binariów x86_64. W kontekście badania wyklucza to jeden z mechanizmów detekcji wirtualizacji. W obszarze ochrony prywatności przetwarzanie strumienia wideo twarzy przez bibliotekę dostawcy zewnętrznego rodzi wymóg formalnej weryfikacji powierzenia przetwarzania danych w umowie DPA.

---

## 8.4. Analiza dekompilatu JADX

### 8.4.1. DeeplinkTranslator: statyczne mapowanie identyfikatora hosta w zasobach lokalnych

Plik `assets/webapps/webapps_host_mapping.json` o rozmiarze 29 bajtów:

```json
{ "ib": "online.mbank.pl" }
```

Konfiguracja definiuje pojedynczą relację: `hostid=ib` mapowane na `online.mbank.pl`. Dane odczytywane są bezpośrednio z zasobów lokalnych pakietu za pośrednictwem metody `WebAppsConfigImpl.a()` wywołującej `context.getAssets().open(str)`. Wyklucza to hipotezę o możliwości podrobienia mapowania w komunikacji sieciowej.

```java
// WebAppsConfigImpl.a(): odczyt pliku z zasobów lokalnych
InputStream open = this.a.getAssets().open(str);
// str = determinant + "/" + configName
// np. "webapps/webapps_host_mapping.json"
```

**Ocena techniczna:** Statyczna definicja hostów w zasobach aplikacji zapobiega ingerencji w routing przez manipulację odpowiedzią serwera, co wyklucza podatność na modyfikację parametrów w locie.

### 8.4.2. Weryfikacja reguł białych list komponentu WebApps

| Plik zasobu | Rozmiar | Zawartość reguły | Ocena techniczna |
|---|---|---|---|
| `webapps_host_mapping.json` | 29 B | `{"ib": "online.mbank.pl"}` | Pojedynczy stały host w zasobach |
| `webapps_resources_white_list.json` | 204 B | `online.mbank.pl`, `(www.)?mbank.pl`, `(.+.)*csp.mbank.pl`, `ecommerce.cdn-az.mbank.pl` | Ograniczenie do domen banku |
| `webapps_websocket_white_list.json` | 46 B | `^wss://online.mbank.pl/.*` | Ograniczenie do dedykowanego endpointu WebSocket |
| `webapps_deeplinks_white_list.json` | 1708 B | 25 reguł regex dla schematu `mbankpl://app/...` | Ściśle zdefiniowane ścieżki odsyłaczy |
| **`webapps_popup_white_list.json`** | **25 B** | \**`\["^https://.*"\]`\*\* | **Dopuszczenie dowolnej domeny HTTPS** |

**MBA-A-05: Brak ograniczenia domenowego w konfiguracji webapps\_popup\_white\_list.json.**Plik konfiguracyjny białej listy okien wyskakujących zawiera wyłącznie wyrażenie: `^https://.*`. W konsekwencji komponent WebView w trybie okna wyskakującego akceptuje dowolny adres URL z protokołem HTTPS. Weryfikację reguły realizuje metoda `ag0.a.a(url)`, która porównuje adres z konfiguracją `POPUPS_WHITELIST` za pomocą metody `matches()`. Warunek `^https://.*` ogranicza walidację wyłącznie do protokołu TLS, pomijając weryfikację samej nazwy domeny. Stanowi to wyłączenie mechanizmu obrony w głąb. Wpływ podatności zależy od możliwości wskazania docelowego adresu URL przez podmiot zewnętrzny. Weryfikacja wykonaniowa w środowisku WSA wykazała, że wywołanie polecenia `am start` z adresem `mbankpl://app/...` skierowane do `MainActivity` kończy się błędem `SecurityException: not exported` pod identyfikatorem UID 10088. Komponent obsługujący odsyłacze nie jest eksportowany, co eliminuje wektor wstrzyknięcia adresu pomiędzy aplikacjami w systemie operacyjnym. Zagrożenie ogranicza się do potencjalnej manipulacji adresem w istniejącym widoku WebView bądź przekierowania z zewnętrznej przeglądarki systemowej. Dalsza analiza wymaga dynamicznego śledzenia skryptem `05_webview_deeplink_tracer.js` w aktywnej sesji.

Reguły dla zasobów i połączeń WebSocket poprawnie ograniczają komunikację do domen własnych banku. Wyrażenia regularne odsyłaczy głębokich posiadają precyzyjną strukturę, aczkolwiek wzorce pokroju `^mbankpl://app/uwapps(/.*)?$` dopuszczają dowolny ciąg znaków po segmencie bazowym.

### 8.4.3. Implementacja usługi BlikCHceService dla płatności zbliżeniowych HCE

```java
// pl.mbank.feature.blikc.service.BlikCHceService extends HostApduService
public h blikCInfoStorage;           // magazyn danych BLIK
public f mainCommandApduHandler;     // handler komend APDU
public e1 paymentEventsHandler;      // handler zdarzeń płatności

@Override public void onCreate() {
    getComponent().a(this);  // DI inject przez Dagger
    super.onCreate();
}
```

Usługa `BlikCHceService` stanowi implementację standardu Android HCE. Dostęp do komponentu zabezpieczono uprawnieniem `android.permission.BIND_NFC_SERVICE`. Przetwarzanie poleceń protokołu APDU oddelegowano do modułu `mcore.kk0.f`. Mechanizm rotacji tokenów transakcyjnych podlega weryfikacji w testach dynamicznych.

### 8.4.4. Architektura komponentu StartActivity

```java
// pl.mbank.core.activity.StartActivity
public me0.a pairingHelper;           // logika parowania urządzeń
public v50.a intentRouter;            // router intencji
public hf0.c remoteConfigSplashGate;  // brama Remote Config na splash
```

Komponent `StartActivity` został wyeksportowany bez deklaracji uprawnień i przyjmuje wywołania z innych procesów. Przejście po ekranie powitalnym kontrolują komponenty `splashGateReady` oraz `remoteConfigSplashGate`. W przypadku braku aktywnej sesji aplikacja wymusza przejście do procedury logowania.

### 8.4.5. Interfejs JNI biblioteki SecLib i ewaluacja kodu integralności

```java
// pl.mbank.nativelib.SecLib
public final class SecLib {
    static { System.loadLibrary("nativeSeclib"); }
    private final native int initialize();
    public final int a() { return initialize(); }
}
```

Struktura JNI obejmuje pojedynczy symbol natywny: `Java_pl_mbank_nativelib_SecLib_initialize`. Implementacja procedury zawarta jest w bibliotece `libnativeSeclib.so`. Weryfikacja wykonawcza w klasie `pl.mbank.mcore.xr2.e`:

```java
int a = this.a.a(); // wywołanie SecLib.initialize()
return new pl.mbank.mcore.fa0.f(a == 8 ? pl.mbank.mcore.fa0.h.SAFE : pl.mbank.mcore.fa0.h.ROOTORJAILBREAK, 8992);
```

Biblioteka natywna musi zwrócić kod `8`, aby stan urządzenia został zakwalifikowany jako bezpieczny ze statusem `SAFE`. Zwrócenie standardowej wartości `0` logika aplikacji kwalifikuje jako naruszenie integralności środowiska ze statusem `ROOTORJAILBREAK`.

Analiza biblioteki x86\_64 w programie IDA 9.4 wykazała zwartą strukturę procedury weryfikacyjnej. Funkcja wykonuje polecenie systemowe `which su`, po czym sprawdza dostępność programu `su` w dziewięciu ścieżkach systemowych: `/bin`, `/sbin`, `/system`, `/system/bin`, `/system/sbin`, `/system/xbin`, `/vendor/bin`, `/su/bin` oraz `/su/xbin`. Wartość 8 stanowi bazowy kod stanu. Wykrycie obecności pliku `su` w zmiennej środowiskowej `PATH` ustawia bit 1, dając kod stanu 9. Odnalezienie pliku w zdefiniowanych ścieżkach ustawia bit 2, co generuje kod 10 lub 11.

Kontrolowane wywołanie funkcji w procesie aplikacji z użyciem frameworka Frida 17.18.0 zwróciło wartość **9**, stanowiącą sumę bitową wartości bazowej 8 oraz flagi 1. Biblioteka zidentyfikowała obecność pliku wykonywalnego `su` w środowisku WSA pod ścieżką `/product/bin/su`. Aplikacja kontynuuje działanie i wyświetla formularz wprowadzania kodu PIN. Wykrycie modyfikacji systemu nie skutkuje przerwaniem wykonywania procesu.

### 8.4.6. Integracja z platformą tokenizacji Mastercard MPSDK CBPP

Wdrożenie platformy Mastercard Cloud-Based Payments Platform obejmuje klasy `ProvisionRequestEncrypted`, `ChangeMobilePinRequestEncrypted` oraz `ReplenishRequestEncrypted`. Transmisja podlega szyfrowaniu na poziomie warstwy aplikacji. Klucze tokenów transakcyjnych pozostają pod wyłączną kontrolą biblioteki Mastercard SDK.

---

## 8.5. Moduł weryfikacji integralności urządzenia: pakiety xr2 oraz vr2

Analiza pakietu `pl.mbank.mcore.xr2` wykazała obecność sześciu detektorów integrowanych przez moduł agregujący `pl.mbank.mcore.xr2.i`:

| Klasa | Kod błędu | Badany wektor | Logika detekcji |
|---|---|---|---|
| `xr2.a` | `8961` | Pakiety uprawnień root oraz narzędzi maskujących | Wywołanie `PackageManager.getPackageInfo()` dla 18 pakietów: `com.topjohnwu.magisk`, `com.koushikdutta.superuser`, `de.robv.android.xposed.installer`, `eu.chainfire.supersu`, `com.saurik.substrate`, `com.devadvance.rootcloak` |
| `xr2.b` | `8962` | Uprawnienia zapisu na partycjach systemowych | Parsowanie wyniku polecenia `mount` pod kątem flagi `rw` na ścieżkach: `/`, `/bin`, `/sbin`, `/su/bin`, `/su/xbin`, `/system`, `/system/bin`, `/system/sbin`, `/system/xbin`, `/vendor/bin` |
| `xr2.d` | `8964` | Flagi kompilacji jądra i obrazu systemu | Weryfikacja `Build.TAGS` pod kątem obecności ciągu `test-keys` |
| `xr2.e` | `8992` | Weryfikacja w warstwie biblioteki natywnej | Sprawdzenie warunku `SecLib.initialize() == 8` |
| `xr2.k` | `8968` | Dostępność plików wykonywalnych su oraz busybox | Wywołanie `which su` oraz `which busybox` przez `ProcessBuilder("/system/bin/sh")` |
| `xr2.l` | `8976` | Właściwości systemowe platformy Android | Odczyt parametrów przez `getprop`: `ro.secure` równe 1, `ro.debuggable` różne od 1, `ro.build.selinux` równe 1, `.adb.root` różne od 1 |

### 8.5.1. Analiza zachowania aplikacji w środowisku WSA z aktywnym MagiskSU

Uruchomienie produkcyjnego klienta mBank na emulatorze WSA z aktywnym modułem MagiskSU nie wynika z braku detekcji uprawnień roota. Test wykonaniowy wykazał, że funkcja natywna zwraca kod 9 w wyniku odnalezienia pliku `su` przez polecenie systemowe. WSA udostępnia program pod ścieżką `/product/bin/su`, widoczną w środowisku procesu.

Metoda `vr2.j.p()` łączy wynik testu lokalnego z oceną integralności pobieraną z usługi sieciowej:

```java
public final boolean p() {
    b a2 = k.a(n());
    Boolean k = k();
    return k != null ? k.booleanValue() : a2 != b.UNSAFE;
}
```

Analiza statyczna pakietu `pl.mbank` wykazała brak instrukcji bezwzględnego zakończenia procesu powiązanych ze statusem roota, takich jak `finish()`, `System.exit()` czy `killProcess`. Detektory pakietu `xr2` przekazują kod stanu, na przykład `ROOTORJAILBREAK` o kodzie `8961`, do obiektu oceny `fa0.f`.

Wykrycie zmodyfikowanego środowiska skutkuje stopniowaną degradacją funkcjonalności klienta:

- Blokada metod biometrycznych: próba włączenia logowania odciskiem palca, skanem twarzy lub tęczówki kończy się odmową i wymuszeniem autoryzacji kodem PIN.
- Komunikat błędu: aplikacja wyświetla ciąg `biometric_security_error_disabled` o treści: „Twój telefon ma nieoryginalny lub modyfikowany system operacyjny. Ze względów bezpieczeństwa nie możesz skorzystać z tych metod”.
- Potwierdzenie wykonaniowe: zachowanie to zarejestrowano na platformie WSA z Magiskiem podczas próby konfiguracji biometrii.
- Weryfikacja serwerowa: egzekwowanie ograniczeń transakcyjnych na poziomie backendu za pośrednictwem API Play Integrity stanowi przedmiot dalszych testów dynamicznych z przechwytywaniem odpowiedzi usługi.

---

## 8.6. Architektura kryptograficzna tożsamości: moduł SAM

Zarządzanie tożsamością klienta, przechowywanie poświadczeń sesyjnych oraz ochrona klucza prywatnego RSA zaimplementowane są w pakiecie `pl.mbank.sam.internal`.

**MBA-A-06: Zastosowanie algorytmu PKCS#12 PBE o niskiej liczbie iteracji oraz szyfrowanie klucza prywatnego RSA w trybie AES-CTR bez ochrony integralności (AEAD).** Łańcuch kryptograficzny tożsamości łączy funkcję wyprowadzania klucza PKCS#12 PBE o parametrze 10 000 iteracji SHA-256 z szyfrowaniem symetrycznym w trybie AES-CTR pozbawionym mechanizmu kontroli integralności danych. Wektor ataku offline po wyodrębnieniu rekordu z systemowej bazy kont pozwala na odzyskanie kodu PIN w czasie liczonym w sekundach oraz modyfikację struktury wyodrębnionego klucza tożsamości.

### 8.6.1. Przepływ danych kryptograficznych w module SAM

Schemat przepływu danych tożsamości obejmuje trzy etapy: derywację klucza symetrycznego z kodu PIN, szyfrowanie surowego klucza prywatnego oraz utrwalenie rekordu w systemie operacyjnym:

flowchart TD subgraph KDF ["1. Wyprowadzanie klucza tożsamości (KDF)"] PIN(["PIN użytkownika
4–8 cyfr"]) --> PBE[["PKCS#12 PBE
SHA-256 · 10 000 iteracji"]] Salt[("Sól KDF: s0.b
z kontenera tożsamości")] --> PBE PBE --> Key(["Klucz AES-256
obiekt SecretKeySpec"]) end subgraph CRYPT ["2. Szyfrowanie klucza RSA (brak ochrony AEAD)"] RSA(["Klucz prywatny RSA
format PKCS#8"]) --> Cipher[["AES/CTR/NoPadding
klasa internal.h0"]] Key --> Cipher IV[("Wektor IV: s0.a
z kontenera tożsamości")] --> Cipher Cipher --> CT(["Szyfrogram klucza RSA
brak tagu MAC / AEAD"]) end subgraph STORAGE ["3. Trwały kontener tożsamości"] IV -.-> Serializer(["Serializacja rekordu w0
IV : Sól : Szyfrogram"]) Salt -.-> Serializer CT --> Serializer Serializer --> AccountDB[("Android AccountManager
typ: pl.mbank · accounts_ce.db")] end 

### 8.6.2. Funkcja wyprowadzania klucza z kodu PIN (KDF)

W klasie `pl.mbank.sam.internal.j0` zidentyfikowano procedurę wyprowadzania klucza z kodu PIN użytkownika:

```java
public final SecretKeySpec a(@NotNull char[] cArr, @NotNull byte[] bArr) {
    return new SecretKeySpec(
        SecretKeyFactory.getInstance("PBEWITHSHA256AND256BITAES-CBC-BC")
            .generateSecret(new PBEKeySpec(cArr, bArr, 10000, 256))
            .getEncoded(), 
        "AES"
    );
}
```

Implementacja wykorzystuje algorytm PKCS#12 PBE z biblioteki BouncyCastle, zarejestrowany pod identyfikatorem `PBEWITHSHA256AND256BITAES-CBC-BC`, z funkcją skrótu SHA-256 oraz stałą liczbą 10 000 iteracji. Z fabryki kluczy pobierany jest surowy ciąg 256 bitów metodą `getEncoded()`, stanowiący klucz szyfrujący dla warstwy prezentacji tożsamości.

Zestawienie parametrów implementacji z obowiązującymi wytycznymi bezpieczeństwa:

| Parametr | Implementacja mBank SAM | Rekomendacje OWASP i NIST SP 800-132 | Status zgodności |
|---|---|---|---|
| Algorytm KDF | PKCS#12 PBE (BouncyCastle) | PBKDF2-HMAC-SHA256 lub Argon2id | Niezgodny; przestarzały schemat PKCS#12 |
| Liczba iteracji | 10 000 | Minimum 600 000 dla PBKDF2-HMAC-SHA256 | Krytycznie niska; 60-krotnie poniżej progu |
| Koszt pamięciowy | Pomijalny (brak pamięciożerności) | Wysoki (Argon2id, scrypt) | Podatny na zrównoleglenie na układach ASIC i GPU |
| Odporność na brute-force | PIN 4 cyfry: poniżej 1 s na GPU; PIN 6 cyfr: poniżej 10 s | Trwała odporność wieloletnia | Wąska przestrzeń przeszukania kodu numerycznego |

### 8.6.3. Szyfrowanie klucza prywatnego RSA w trybie AES-CTR

Procedura szyfrowania klucza prywatnego RSA w klasie `pl.mbank.sam.internal.h0` wykorzystuje tryb strumieniowy `AES/CTR/NoPadding`:

```java
j0Var.b("AES/CTR/NoPadding", s0Var.a, j0Var.a(cArr, s0Var.f42389b), bArr);
```

Parametry operacji:

- `s0Var.a`: wektor inicjalizacyjny IV pobierany z kontenera.
- `j0Var.a(cArr, s0Var.f42389b)`: klucz AES wygenerowany przez funkcję KDF.
- `bArr`: surowe bajty klucza prywatnego RSA w formacie PKCS#8.

Tryb CTR zapewnia poufność danych. Jest jednak pozbawiony mechanizmu kontroli integralności. W architekturze brakuje uwierzytelnienia kryptograficznego w postaci tagu MAC, trybu GCM bądź konstrukcji Poly1305. Cecha plastyczności (malleability) trybu CTR sprawia, że zmiana dowolnego bitu w szyfrogramie skutkuje przewidywalną modyfikacją odpowiadającego mu bitu w odzyskanym tekście jawnym podczas deszyfrowania. W przypadku manipulacji szyfrogramem aplikacja nie wykrywa naruszenia integralności na etapie operacji symetrycznej, zgłaszając dopiero błąd parsowania struktury ASN.1 i DER klucza prywatnego. Standard OWASP MASVS w wymaganiu MASVS-CRYPTO-1 nakazuje stosowanie szyfrowania uwierzytelnionego AEAD.

### 8.6.4. Struktura kontenera tożsamości w0 i wektor ataku offline

Dane tożsamości podlegają serializacji w strukturze `w0` w postaci ciągu wartości rozdzielanych dwukropkiem:
`IV : Sól : Szyfrogram`

Kontener rejestrowany jest w usłudze systemowej **Android AccountManager** pod typem konta `pl.mbank`, obsługiwanym przez komponent `NmbAuthenticationService`. Baza kont składowana jest w systemowym pliku chronionym poświadczeniami:
`/data/system_ce/0/accounts_ce.db`

flowchart LR Acc[("Systemowa baza kont
accounts_ce.db")] --> Dump(["Pozyskanie rekordu
uprawnienia root / ADB"]) Dump --> Split(["Rozbicie formatu w0
IV : Sól : Szyfrogram"]) Split --> Crack[["KDF PKCS#12 offline
10 000 iteracji SHA-256"]] Dict(["Słownik kodów PIN
0000–9999 (10^4)"]) --> Crack Crack --> Done(["Odzyskany kod PIN
i klucz prywatny RSA"]) 

Z uwagi na numeryczny format kodu PIN oraz umieszczenie soli i wektora IV bezpośrednio w kontenerze, atak słownikowy na wyodrębnioną bazę charakteryzuje się znikomym kosztem obliczeniowym. Weryfikacja wykonawcza wymaga uprawnień roota do odczytania magazynu `accounts_ce.db` na urządzeniu z aktywnym kluczem CE po odblokowaniu ekranu. Z tego względu wagę podatności ustalono na poziomie średnim. Wektor MBA-A-08 cechuje się wyższą krytycznością z uwagi na obecność stałego klucza bezpośrednio w pakiecie APK.

---

## 8.7. Sprzętowy magazyn kluczy AndroidKeyStore

Dla operacji krytycznych czasowo i biometrycznie aplikacja korzysta ze sprzętowego magazynu kluczy `AndroidKeyStore`:

| Alias klucza | Algorytm | Parametry ochrony | Przeznaczenie |
|---|---|---|---|
| `"blikc_alias_key"` | `AES-256-CBC` / PKCS7 | Wymóg autoryzacji użytkownika z oknem ważności 60 sekund: `setUserAuthenticationParameters(60, 3)` | Ochrona tokenów transakcyjnych BLIK Zbliżeniowy w standardzie HCE |
| `"FingerprintAuthorization"` | `AES-CBC` / PKCS7 | `setUserAuthenticationRequired(true)` | Integracja z `BiometricPrompt.CryptoObject` na potrzeby autoryzacji biometrycznej |

Klucze sprzętowe podlegają izolacji w module TEE. Ograniczenie czasu ważności autoryzacji do 60 sekund dla operacji BLIK zapobiega wykonaniu nieautoryzowanych transakcji zbliżeniowych po zablokowaniu ekranu urządzenia.

---

## 8.8. Bazy danych SQLite oraz magazyn tożsamości AccountManager

### 8.8.1. Analiza zawartości lokalnej bazy danych SQLite

Weryfikacja binarnej zawartości katalogu `/data/data/pl.mbank/databases/` wykazała standardowy nagłówek `SQLite format 3` w pliku `nmbMobile` bez szyfrowania SQLCipher. Analiza klasy `pl.mbank.core.legacy.services.db.DataBaseHelper` wykazała obecność tabel `dictionaries` oraz `dictionary_values`. Tabele te przechowują słowniki systemowe: kody walut, opisy operacji oraz typy dokumentów. Baza nie zawiera historii rachunku, sald kont ani danych kart płatniczych.

### 8.8.2. Magazyn danych tożsamości w usłudze AccountManager

Główny rekord tożsamości `AccountData` rejestrowany jest w systemie Android za pośrednictwem komponentu `pl.mbank.core.authenticator.NmbAuthenticationService`:

- Nazwa konta: `mBank`
- Typ konta: `pl.mbank`
- Atrybuty w `AccountManager`: `deviceToken`, `encryptedDeviceSecret`, `encryptedRsaSignKey`, `aesDeviceSecretKey`, `encryptedRandom`, `rsaPublicServerCommKey`.

---

## 8.9. Asymetria autoryzacji w komponencie EMaklerProvider: podatność MBA-A-07

Komponent `pl.mbank.feature.emakler.legacy.sso.emakler.EMaklerProvider` pośredniczy w logowaniu jednokrotnym SSO do usługi maklerskiej eMakler.

```xml
<provider 
    android:authorities="pl.mbank.EMaklerProvider" 
    android:exported="true" 
    android:name="pl.mbank.feature.emakler.legacy.sso.emakler.EMaklerProvider" 
    android:readPermission="pl.mbank.eMaklerProviderPermission" 
    android:writePermission="pl.mbank.eMaklerProviderPermissionWrite" />
```

**MBA-A-07: Asymetria weryfikacji tożsamości w EMaklerProvider: pominięcie walidacji podpisu w metodzie insert().**1. **Klasyfikacja poziomu ochrony uprawnień:** Uprawnienia `pl.mbank.eMaklerProviderPermission` oraz `pl.mbank.eMaklerProviderPermissionWrite` zdefiniowano z atrybutem `android:protectionLevel="dangerous"`. Deklaracja ta nie wymusza poziomu ochrony `signature`, co pozwala dowolnej aplikacji na uzyskanie uprawnienia po zatwierdzeniu przez użytkownika. 2. **Weryfikacja wywołującego w metodzie query():** Implementacja metody `query()` pobiera identyfikator UID procesu przez `Binder.getCallingUid()`, odczytuje strukturę `SigningInfo` i weryfikuje skrót SHA-1 certyfikatu wywołującego z białą listą zdefiniowaną w `pl.mbank.mcore.tp1.b`. 3. **Pominięcie kontroli w metodzie insert():** Metoda `insert()` nie realizuje procedury weryfikacji tożsamości wywołującego `p(packageName)`: ```java @Override public Uri insert(Uri uri, ContentValues contentValues) { if (j().match(uri) != 1) return null; k().delete("TokenTable", null, null); k().insert("TokenTable", null, contentValues); i().getContentResolver().notifyChange(h().a(), null); return uri; } ``` Dowolny proces posiadający uprawnienie `eMaklerProviderPermissionWrite` może dokonać zapisu w tabeli `TokenTable`, co umożliwia usunięcie bądź nadpisanie tokenu SSO bez kryptograficznej walidacji tożsamości nadawcy.

---

## 8.10. Zabezpieczenie przed nakładkami interfejsu i usługami dostępności

Plik `assets/accessibility-white-list.json` o rozmiarze 168 KB zawiera bazę skrótów SHA-256 aktywności systemowych oraz zaufanych narzędzi ułatwień dostępu, którym zezwolono na interakcję z interfejsem aplikacji. Rozwiązanie to stanowi zabezpieczenie przed oprogramowaniem trojańskim wykorzystującym interfejs `AccessibilityService` do rejestracji zawartości ekranu oraz symulowania akcji użytkownika.

## 8.11. Ekstrakcja danych aplikacji przez mechanizm kopii zapasowej MIUI

Kopia wykonana w systemie Xiaomi 13T zawiera plik `mBank(pl.mbank).bak` o rozmiarze 124 689 979 bajtów i skrócie SHA-256 `0103aa7d6e1d596cdac156eb54ae9c2cf2a92164bcbf47dffe84b3465e3eb88d`. Nagłówek MIUI poprzedza standardowy strumień `ANDROID BACKUP` w wersji 5 z wartością pola szyfrowania `none`. Dostęp do archiwum nie wymaga podania kodu blokady urządzenia ani kluczy z Android Keystore.

Archiwum zawiera prywatne katalogi aplikacji: `shared_prefs`, bazy SQLite, pliki wewnętrzne oraz profil WebView z magazynem lokalnym, sesyjnym i bazą ciasteczek. Kopia została wygenerowana pomimo obecności flagi `android:allowBackup="false"` w manifeście, co wskazuje na nadrzędność mechanizmu producenta nad standardową flagą platformy Android.

Główny plik konfiguracyjny `shared_prefs/mBank.xml` zawierał 143 rekordy: jeden wpis z kluczem AES oraz 142 zaszyfrowane pary klucz-wartość. Implementacja w klasie `pl.mbank.mcore.i90.e` wykorzystuje algorytm AES-CBC z dopełnieniem PKCS#7. Nazwy pól szyfrowane są ze stałym zerowym wektorem IV, natomiast wartości szyfrowane są z wektorem utworzonym z pierwszych 16 bajtów jawnej nazwy pola. Klucz AES-128 zapisano w tym samym pliku pod stałą nazwą `47C61146870D6E18826E53807E2EB97C`. W przypadku braku tego rekordu metoda `e.x()` sięga po wbudowaną w kod APK stałą `132F1A90***DEE8`, identyczną dla wszystkich instalacji. Schemat szyfrowania jest w pełni deterministyczny: stały klucz, zerowy IV dla nazw oraz deterministyczny IV dla wartości generują identyczny szyfrogram na każdym urządzeniu. Opracowany skrypt deszyfrujący odzyskał komplet 142 wpisów bez dostępu do telefonu, kodu PIN oraz magazynu Android Keystore.

Odzyskane dane konfiguracyjne zawierają między innymi parametry `DeviceId`, `AnalyticsId`, identyfikator sesji parowania, trzy tokeny rejestracji Firebase, klucz i wektor szyfrowania powiadomień, sól oraz wektor innego magazynu, a także flagi stanu zabezpieczeń. W pliku nie stwierdzono obecności kodu PIN, loginu, numeru rachunku ani salda konta. Wstępne dopasowanie ciągu testowego PIN w surowym pliku XML wynikało z przypadkowej zbieżności bajtów wewnątrz szyfrogramu; w zdekodowanych polach wartość ta nie występuje.

Baza `token` zawiera pojedynczy rekord Base64 o długości 44 znaków, reprezentujący 32 bajty danych binarnych. Wartość zamaskowano w raporcie jako `wnQ+***DuU=`; jej skrót SHA-256 wynosi `c4afc73752b039da95abae3406bfc2b91929249b0515bd1a7cdf86b06e62336e`. Rekord ten stanowi element mechanizmu logowania jednokrotnego eMakler i nie jest tożsamy z tokenem sesji głównej bankowości.

Plik bazy `MCBP.db` platformy płatności Mastercard zawiera tabele profili kart, kluczy mobilnych, portfela oraz dzienników transakcyjnych. W analizowanej kopii tabele te pozostawały puste, co potwierdza brak ekspozycji tokenów płatniczych w tym kanale.

**MBA-A-08: Odwracalne szyfrowanie konfiguracji w kopii zapasowej MIUI.** Aplikacja szyfruje lokalne ustawienia, lecz przechowuje klucz symetryczny w tym samym pliku XML bez powiązania ze sprzętowym magazynem Android Keystore. Mechanizm ten wykazuje dwie wady implementacyjne: obecność uniwersalnego, zapasowego klucza AES-128 `132F1A90***DEE8` zaszytego w kodzie APK dla plików pozbawionych wpisu z kluczem oraz w pełni deterministyczny schemat kryptograficzny obejmujący stały klucz, zerowy wektor IV dla nazw oraz wektor IV wyliczany bezpośrednio z nazwy pola dla wartości. Umożliwia to całkowite odszyfrowanie identyfikatorów urządzenia, tokenów rejestracyjnych Firebase oraz klucza szyfrowania powiadomień bezpośrednio z pliku kopii, bez znajomości kodu PIN i bez dostępu do urządzenia. Zgodnie ze standardem OWASP MASVS w kategorii MASVS-CRYPTO zapisanie klucza szyfrującego w tym samym zasobie bądź wbudowanie stałego klucza w kod aplikacji stanowi krytyczną niezgodność architektoniczną.

---

## 8.12. Analiza powiązanej aplikacji maklerskiej eMakler giełda: pl.mbank.bmmobile 6.7.4

Do obsługi rachunku maklerskiego mBank udostępnia aplikację eMakler giełda, pakiet `pl.mbank.bmmobile` w wersji 6.7.4. Aplikację zbudowano w technologii **.NET MAUI**, w przestrzeni nazw `Pomelo.*`, i skompilowano w trybie AOT. Kod zarządzany wyodrębniono ze skompresowanego magazynu `libassembly-store.so` w formacie XABA z kompresją LZ4/XALZ obejmującym 242 biblioteki, po czym poddano go dekompilacji do kodu źródłowego C#.

**Architektura mostka SSO z aplikacją bankową:** Aplikacja maklerska realizuje logowanie jednokrotne przez metodę `ReadTokenFromContentProvider` pobierającą token z dostawcy treści mBanku pod adresem `content://pl.mbank.EMaklerProvider/TokenTable`. Pobrany token przekazywany jest do usługi IdentityServer protokołem OIDC na ścieżce `/identityserver/connect/token` w domenie `https://bmmobile.mbank.pl` w celu wymiany na token sesyjny. Weryfikację poprawności tokenu przeprowadza serwer uwierzytelniający. W odniesieniu do podatności MBA-A-07 oznacza to, że nieuprawniona aplikacja z prawem zapisu może usunąć lub podmienić wpis w tabeli `TokenTable`, co wywołuje ryzyko odmowy usługi lub narzucenia sesji. Bezpośredni dostęp do konta wymaga jednak poprawnej walidacji po stronie serwera.

**Zaimplementowane mechanizmy zabezpieczeń sieciowych:**

- **Przypinanie certyfikatów:** Zastosowano dedykowany moduł walidacji `PomeloHttpClientHandler` implementujący interfejs `ICertPinningValidator`, egzekwowany również dla połączeń WebSocket silnika EngineIo przy obsłudze notowań giełdowych.
- **Bezpieczny magazyn danych:** Wykorzystano interfejs `SecureStorage` powiązany z Android Keystore do przechowywania kontekstu urządzenia.
- **Poprawność kryptograficzna:** Wykluczono stosowanie przestarzałych algorytmów, takich jak MD5, DES czy tryb ECB, oraz wyeliminowano procedury pomijania walidacji łańcucha certyfikatów.

**MBA-B-01: Brak obfuskacji kodu zarządzanego w aplikacji maklerskiej.** Pakiet `pl.mbank.bmmobile` został opublikowany z zachowaniem pełnej czytelności kodu IL. Dekompilacja ujawnia oryginalne nazwy typów i metod, w tym `AuthService`, `RsaKeyStoreCertService` oraz `ActivateTokenLogonAsync`, adresy endpointów API, identyfikator klienta SSO `bmmobile2:sso` oraz kompletną logikę biznesową. W procesie budowania nie zastosowano zaciemniania nazw, szyfrowania ciągów znakowych ani ochrony metadanych. Zaniechanie to radykalnie obniża koszt analizy inżynierii wstecznej.

**MBA-B-02: Obecność stałego parametru client\_secret w publicznym kliencie mobilnym.** Plik konfiguracyjny aplikacji zawiera zaszyte poświadczenia klienta OAuth2/OIDC: `AppClientId = bmmobile2:bm` z parametrem `AppClientSecret = FE813C06-***-DAB7C8B3F3E2` oraz `AppSsoClientId = bmmobile2:sso` z parametrem `AppSsoClientSecret = C594B5A9-***-B8023B03D2B5`. Zakres uprawnień obejmuje flagę `offline_access ... openid` umożliwiającą pobieranie długoterminowych tokenów odświeżających. Zgodnie ze specyfikacją RFC 8252 aplikacja mobilna stanowi klienta publicznego, który nie jest w stanie zagwarantować poufności klucza symetrycznego. Wobec braku obfuskacji binarnej wskazanej w ustaleniu MBA-B-01 wyodrębnienie tych wartości następuje bezpośrednio po rozpakowaniu zasobów. Architektura uwierzytelniania w publicznym kliencie mobilnym powinna opierać się na protokole PKCE określonym w specyfikacji RFC 7636, bez polegania na poufności parametru `client_secret`. Wymóg weryfikacji sekretu przez usługę IdentityServer podlega sprawdzeniu w teście dynamicznym.

**Spójność architektury bezpieczeństwa w portfolio aplikacji:** Zestawienie obu aplikacji wykazuje rozbieżność standardów bezpieczeństwa. Główna aplikacja bankowa stosuje deterministyczne szyfrowanie preferencji uniwersalnym kluczem opisanym w ustaleniu MBA-A-08, natomiast aplikacja maklerska została opublikowana bez obfuskacji kodu zgodnie z ustaleniem MBA-B-01 oraz z jawnym parametrem uwierzytelniającym wskazanym w MBA-B-02. Wskazuje to na brak jednolitego standardu ochrony w procesie wytwórczym obu produktów.

## 8.13. Analiza podatności na modyfikację i repakowanie aplikacji

W architekturze aplikacji mobilnych kod binarny oraz zasoby lokalne podlegają bezpośredniej kontroli użytkownika urządzenia. Lokalne mechanizmy sprawdzające integralność mogą zostać zmodyfikowane w procesie inżynierii wstecznej.

Czynniki techniczne wpływające na podatność pakietu na modyfikację:

1. **Jawność kodu zarządzanego:** Brak obfuskacji modułów .NET MAUI w aplikacji `pl.mbank.bmmobile` pozwala na bezpośrednią dekompilację do kodu C# i analizę logiki uwierzytelniania, co udokumentowano w ustaleniu MBA-B-01.
2. **Klientowa detekcja środowiska:** Procedura wykrywania roota omówiona w rozdziale 8.5.1 nie przerywa działania aplikacji i podlega neutralizacji przez modyfikację instrukcji warunkowych w kodzie bajtowym.
3. **Determinizm lokalnej kryptografii:** Zastosowanie stałego klucza zaszytego w kodzie APK, wskazane w ustaleniu MBA-A-08, eliminuje barierę ochrony lokalnych plików konfiguracyjnych.
4. **Standardowe formaty binarne:** Wykorzystanie standardowych struktur DEX oraz bibliotek .NET bez komercyjnych warstw ochronnych pokroju DexGuard czy Promon umożliwia dekompilację ogólnodostępnymi narzędziami.

**Rola weryfikacji serwerowej jako granicy zaufania:**
Kluczowa granica bezpieczeństwa spoczywa po stronie serwera bankowego. Obejmuje ona wymuszenie atestacji Play Integrity API podczas rejestracji urządzenia i autoryzacji operacji oraz kryptograficzne powiązanie sesji ze sprzętowym modułem bezpieczeństwa. Brak rygorystycznej walidacji po stronie backendu przenosi ryzyko na użytkownika końcowego.

**Zagrożenia wynikające z modyfikacji pakietu:**
Głównym wektorem ryzyka jest tworzenie trojanizowanych klonów aplikacji oraz kampanie phishingowe. Możliwość odtworzenia interfejsu i przepływów logowania sprzyja dystrybucji złośliwych pakietów poza oficjalnym sklepem Google Play w celu wyłudzania poświadczeń użytkowników.

## 8.14. Studium przypadku: kalibracja heurystyk anti-fraud i analiza prawno-techniczna procedur wsparcia

Aplikacja pobiera z systemu szereg parametrów telemetrycznych służących do oceny integralności środowiska wykonawczego, szczegółowo opisanych w rozdziale 8.5: pełną listę zainstalowanych pakietów na podstawie uprawnienia `QUERY_ALL_PACKAGES` w zestawieniu z czarną listą 643 skrótów, odczyt parametrów identyfikacyjnych przez metodę `tb1.q`, stan flag systemowych oraz status połączeń głosowych. Dane te zasilają silnik oceny ryzyka po stronie serwera. Rozbudowane zestawy reguł heurystycznych niosą ze sobą ryzyko błędnej klasyfikacji poprawnych operacji.

W toku eksploatacji środowiska badawczego udokumentowano wystąpienie błędu fałszywie pozytywnego (false positive), który doprowadził do nieuzasadnionego ograniczenia usług płatniczych oraz ujawnił istotne luki w procedurach operacyjnych banku.

### 8.14.1. Architektura stacji badawczej i kontekst wieloletniej eksploatacji WSA

Badania zrealizowano na stacji roboczej Lenovo ThinkPad T14 opartej na procesorze Intel Core Ultra architektury Lunar Lake pod kontrolą systemu operacyjnego Windows 11. Podsystem Windows Subsystem for Android w wersji 2407 (kompilacja 2407.40000.4.0, jądro x86\_64, Android 13) stanowi dla autora stałe środowisko produkcyjne i analityczne wykorzystywane nieprzerwanie od ponad pięciu lat.

Eksploatacja podsystemu WSA w architekturze stacjonarnej Windows wynika z określonych przesłanek inżynierskich:

- **Niezależność operacyjna:** Pełne uniezależnienie procesów uwierzytelniania i autoryzacji bankowej od fizycznego aparatu telefonicznego. Pozostawienie smartfona poza zasięgiem nie blokuje ciągłości realizowanych operacji.
- **Automatyzacja procesów rynkowych:** Przed przeniesieniem portfela inwestycyjnego do brokera XTB stacja WSA służyła do zautomatyzowanego nadzorowania zleceń na Giełdzie Papierów Wartościowych za pośrednictwem modułu eMakler powiązanego z aplikacją główną. Integracja w jednym środowisku systemowym umożliwiała równoległe przetwarzanie arkuszy notowań i deterministyczną realizację zleceń maklerskich.
- **Metodologia badawcza i suwerenność uprawnień:** W środowisku profesjonalnej inżynierii wstecznej, dekompilacji oraz analizy niskopoziomowej jądra systemu praca z maksymalnymi uprawnieniami stanowi warunek konieczny. Badacze zajmujący się architekturą hiperwizorów i rozbiorem kodu maszynowego operują bezpośrednio na koncie roota w Linuksie oraz na wbudowanym koncie Administratora w Windows. Sztuczne mechanizmy separacji uprawnień, takie jak sudo czy architektury UAC i LUA, projektowane są pod kątem przeciętnego konsumenta reprezentującego mainstreamowe wzorce użytkowe. Dla inżyniera analizującego kod bajtowy i struktury pamięci wprowadzenie pośrednich warstw restrykcji stoi w sprzeczności z elementarną metodologią dowodową, gdyż ogranicza transparentność rejestracji zdarzeń systemowych.

### 8.14.2. Przebieg incydentu i asymetria nałożonej blokady

W dniu 22 września 2026 r. algorytmy bezpieczeństwa mBanku zakwalifikowały aktywność sesji w podsystemie WSA na stacji Lenovo ThinkPad T14 jako potencjalny incydent bezpieczeństwa: atak zewnętrzny bądź próbę phishingu. Wektor blokady charakteryzował się specyficzną asymetrią decyzyjną:

1. **Dostęp aplikacyjny:** Sesja mobilna w środowisku WSA zachowała pełną funkcjonalność. Aplikacja pozwalała na logowanie, wgląd w stan rachunku oraz autoryzację dyspozycji przelewów.
2. **Blokada instrumentu płatniczego:** Systemy anti-fraud nałożyły prewencyjną blokadę transakcyjną na powiązaną z kontem fizyczną kartę płatniczą.
3. **Skutek operacyjny:** Dwie kolejne próby wykonania standardowej transakcji bezgotówkowej w lokalu Bosko na warszawskim Ursynowie na kwotę 18 PLN zakończyły się dwukrotną odmową autoryzacji ze strony terminala płatniczego. Wobec braku możliwości realizacji płatności kartą powstała konieczność sporządzenia pisemnego oświadczenia, zdeponowania dokumentów tożsamości u personelu lokalu w charakterze zastawu oraz udania się z małżonką po fizyczną gotówkę w celu uregulowania zobowiązania.

### 8.14.3. Przebieg procedury odblokowania na infolinii bankowej

Kontakt z infolinią banku w celu przywrócenia funkcjonalności karty trwał około pół godziny. Procedura ujawniła strukturalne ograniczenia personelu pierwszej linii wsparcia (L1):

- **Weryfikacja tożsamości i asymetria dokumentów:** Konsultant zażądał numeru PESEL (podanego niezwłocznie z pamięci), imienia ojca, nazwiska panieńskiego matki oraz serii i numeru dowodu tożsamości. Podanie serii i numeru fizycznego dowodu osobistego spotkało się z odmową autoryzacji z uwagi na brak zgodności z bieżącym rekordem w kartotece bankowej. System weryfikacyjny nie zawiera podpowiedzi określającej zarejestrowany typ dokumentu. Posiadacz rachunku musi bezbłędnie pamiętać, czy w relacji z bankiem posłużył się tradycyjnym dokumentem tożsamości, czy cyfrowym mDowodem. W celu dokończenia weryfikacji badacz uruchomił w podsystemie WSA aplikację mObywatel, odczytał serię oraz numer mDowodu i podał je konsultantowi, co skutkowało poprawnym uwierzytelnieniem tożsamości.
- **Brak kompetencji technicznych personelu:** Konsultant wykazał brak wiedzy na temat technologii wirtualizacji Hyper-V oraz środowiska WSA w systemie Windows. Wyrażał zdziwienie faktem uruchomienia aplikacji Android na komputerze PC oraz dopytywał o techniczne nazwy pakietów, w tym komponenty powiązane z modułem eMakler.
- **Narzucenie warunku skanowania antywirusowego:** Konsultant uzależnił odblokowanie karty płatniczej od bezwzględnego przeprowadzenia pełnego skanowania stacji roboczej za pomocą dwóch niezależnych programów antywirusowych. Wyjaśnienia badacza dotyczące architektury systemu Windows, obecności zintegrowanego mechanizmu Microsoft Defender oraz bezcelowości skanowania środowiska inżynierskiego konsumenckimi narzędziami firm trzecich zostały odrzucone z powołaniem na sztywny skrypt procedury.
- **Znoszenie blokad wielopoziomowych:** Konsultant pierwszej linii realizował procedurę ściśle według wyuczonych na szkoleniach skryptów operacyjnych. Wykazał się jednak cierpliwością i stopniowo usuwał blokady zarejestrowane na różnych poziomach systemów bankowych, obejmujące reguły antyfraudowe, filtry antyphishingowe oraz blokady transakcyjne na samej karcie. Całość rozmowy została utrwalona w rejestratorze połączeń banku. W efekcie przeprowadzonej procedury wszystkie ograniczenia zostały zdjęte, co pozwoliło na kontynuację stabilnej pracy aplikacji w podsystemie WSA w szóstym roku jego eksploatacji.

### 8.14.4. Ocena prawna narzucania wymogu instalacji oprogramowania firm trzecich

Uzależnienie odblokowania prawnie zastrzeżonego instrumentu płatniczego od instalacji zewnętrznego oprogramowania antywirusowego stanowi istotne naruszenie przepisów prawa bankowego i konsumenckiego:

1. **Naruszenie art. 43 ust. 3 Ustawy o usługach płatniczych:** Zgodnie z art. 43 ust. 3 ustawy z dnia 19 sierpnia 2011 r. o usługach płatniczych (transponującej unijną dyrektywę PSD2): > *„Dostawca odblokowuje instrument płatniczy lub zastępuje go nowym instrumentem płatniczym, jeżeli przestały istnieć przyczyny uzasadniające utrzymanie blokady”*.
    > W momencie, gdy tożsamość posiadacza rachunku została jednoznacznie zweryfikowana na infolinii, a klient formalnie oświadczył, że transakcje oraz sesja w WSA są w pełni autoryzowane i świadome, obiektywne przyczyny uzasadniające podejrzenie nieuprawnionego użycia ustały. Utrzymywanie blokady karty po tym momencie narusza bezpośredni nakaz ustawowy.
2. **Brak podstawy prawnej do narzucania instalacji programów firm trzecich:** Żaden przepis ustawy o usługach płatniczych, rozporządzenia delegowanego Komisji (UE) 2018/389 (RTS w sprawie silnego uwierzytelniania) ani wytycznych Europejskiego Urzędu Nadzoru Bankowego (EBA) nie uprawnia dostawcy usług płatniczych do uzależniania dostępu do środków pieniężnych od zainstalowania komercyjnego oprogramowania zewnętrznych podmiotów na prywatnym sprzęcie klienta.
3. **Praktyka naruszająca zbiorowe interesy konsumentów:** Wymuszanie spełnienia pozaprawnych i technicznie nieuzasadnionych warunków pod rygorem odcięcia od własnych środków finansowych stanowi nienależyte wykonanie umowy o świadczenie usług płatniczych. Podlega to ocenie Prezesa Urzędu Ochrony Konkurencji i Konsumentów (UOKiK) w świetle art. 24 ustawy o ochronie konkurencji i konsumentów oraz kognicji Komisji Nadzoru Finansowego (KNF).

### 8.14.5. Postępowanie reklamacyjne: zgłoszenie REK122475856

Całkowity czas trwania incydentu zamknął się w przedziale około dwóch godzin. Przedział ten objął dwukrotną odmowę autoryzacji w punkcie handlowym, procedurę zabezpieczenia roszczenia oświadczeniem i depozytem dokumentów tożsamości, pozyskanie fizycznej gotówki w asyście małżonki, około trzydziestominutowe połączenie z infolinią bankową oraz sformułowanie dokumentacji reklamacyjnej.

Wobec bezpodstawnego zablokowania karty, publicznej odmowy autoryzacji oraz dysfunkcyjnej procedury wsparcia, w dniu 25 września 2026 r. skierowano do banku oficjalne zgłoszenie reklamacyjne. Bank zarejestrował sprawę pod sygnaturą **REK122475856** w kategorii *Jakość obsługi Klienta* z ustawowym terminem odpowiedzi.

W treści zgłoszenia wskazano na:

- wystąpienie błędu fałszywie pozytywnego w heurystyce detekcji nadużyć;
- poniesioną szkodę wizerunkową oraz uciążliwość operacyjną wynikającą z dwukrotnego odrzucenia płatności 18 PLN w lokalu Bosko, konieczności pozostawiania dokumentów pod zastaw i awaryjnego pozyskiwania gotówki;
- procedurę infolinii trwającą około pół godziny i operującą na sztywnych skryptach weryfikacyjnych;
- żądanie kalibracji reguł decyzyjnych profilu pod kątem środowiska WSA oraz trwałego przywrócenia pełnej funkcjonalności karty;
- zastrzeżenie skierowania sprawy do UOKiK oraz KNF w przypadku powtórzenia bezprawnych blokad.

## 9. Zestawienie ustaleń

| ID | Ustalenie | Ocena ryzyka | Pewność i status weryfikacji |
|---|---|---|---|
| **MBA-A-01** | `BiometricSettingsDeeplinkActivity` wyeksportowana bez uprawnień | **Niskie** | Potwierdzone; metoda `onCreate()` przekierowuje do wewnętrznego widoku bez przetwarzania parametrów wejściowych |
| **MBA-A-02** | FaceTec SDK w `libPhoenixAndroid.so`: brak binariów dla architektury x86\_64, przetwarzanie biometrii przez podmiot trzeci | **Średnie** | Potwierdzone; komponent nieaktywny w środowisku x86\_64 |
| **MBA-A-03** | Konfiguracja TrustKit: 21 domen, 78 skrótów SPKI SHA-256, `enforcePinning=true` | **Wzorcowe** | Potwierdzone statycznie; pełna redundancja pinów, brak trybu debug |
| **MBA-A-04** | `StartActivity` wyeksportowana bez deklaracji uprawnień | **Niskie** | Potwierdzone; brak aktywnej sesji wymusza procedurę logowania |
| **MBA-A-05** | Biała lista `webapps_popup_white_list.json`: reguła `^https://.*` dopuszcza dowolną domenę HTTPS | **Średnie / P0** | Potwierdzone statycznie; brak ograniczenia domenowego w trybie okna wyskakującego |
| **MBA-A-06** | Moduł SAM: KDF PKCS#12 PBE z 10 000 iteracji SHA-256 oraz szyfr AES-CTR bez uwierzytelnienia AEAD dla klucza prywatnego | **Średnie** | Potwierdzone statycznie w klasach `pl.mbank.sam.internal.j0` oraz `h0` |
| **MBA-A-07** | `EMaklerProvider`: asymetria autoryzacji IPC, pominięcie walidacji podpisu wywołującego w metodzie `insert()` przy uprawnieniu dangerous | **Średnie** | Potwierdzone statycznie w kodzie `EMaklerProvider` |
| **MBA-A-08** | Szyfrowanie `mBank.xml`: klucz AES zapisany w pliku, uniwersalny klucz zapasowy w APK, deterministyczny IV | **Wysokie** | Potwierdzone statycznie i wykonaniowo; pełna deszyfracja 142 wpisów z kopii MIUI |
| **MBA-O-01** | Flaga `requestLegacyExternalStorage=true` w manifeście | **Niskie** | Potwierdzone; zaszłość zgodnościowa dla poziomu API 29 |
| **MBA-O-02** | Uprawnienia `QUERY_ALL_PACKAGES` oraz `READ_PHONE_STATE`: telemetria i profilowanie urządzenia | **Prywatność** | Potwierdzone; pobieranie listy pakietów pod kątem czarnej listy 643 skrótów oraz wywołanie metody `tb1.q` |
| **MBA-O-03** | Konfiguracja `FileProvider` ze ścieżką bazową `path="."` | **Niskie** | Potwierdzone statycznie; uprawnienia ograniczone do komponentów wewnętrznych |
| **MBA-O-04** | Czarne listy pakietów `security-packages-list.json` oraz `accessibility-white-list.json` | **Wzorcowe** | Potwierdzone; ochrona przed narzędziami trojańskimi i nadużyciami ułatwień dostępu |
| **MBA-O-05** | Weryfikacja `SecLib.initialize()`: kod stanu 9 w środowisku WSA przy wykryciu pliku su w zmiennej PATH, brak blokady procesu | **Architektura** | Potwierdzone analizą w IDA oraz punktem zaczepienia Fridy |
| **MBA-O-06** | Baza `nmbMobile` SQLite bez szyfrowania: wyłącznie słowniki systemowe | **Bezpieczne** | Potwierdzone; brak danych finansowych i poświadczeń |
| **MBA-B-01** | Brak obfuskacji kodu w aplikacji maklerskiej `pl.mbank.bmmobile`: pełna jawność typów i metod w kodzie zarządzanym | **Średnie** | Potwierdzone; dekompilacja kodu IL z kontenera AssemblyStore |
| **MBA-B-02** | Obecność parametru `client_secret` w konfiguracji aplikacji maklerskiej dla zakresu `offline_access` | **Średnie** | Potwierdzone; wartości zapisane w konfiguracji `Pomelo.App` |
| **MBA-O-07** | Kalibracja reguł anti-fraud i bezpodstawna blokada karty płatniczej (false positive) | **Operacyjne** | Potwierdzone dwukrotną odmową transakcji 18 PLN w Bosko, dwugodzinnym incydentem operacyjnym, wymogiem skanowania 2 antywirusami i reklamacją REK122475856 |

---

## 10. Weryfikacja dynamiczna w środowisku WSA: Android 13, x86\_64, Magisk

### 10.1. Ochrona bufora ekranu: weryfikacja flagi FLAG\_SECURE

Weryfikacja właściwości aktywnego okna zalogowanej sesji dla komponentu `MainActivity` poleceniem `dumpsys window windows`:

```text
Window #5 Window{47cee61 u0 pl.mbank/...MainActivity}:
  mAttrs={(0,0)(fillxfill) ...
    fl=LAYOUT_IN_SCREEN FORCE_NOT_FULLSCREEN SECURE LAYOUT_INSET_DECOR SPLIT_TOUCH HARDWARE_ACCELERATED DRAWS_SYSTEM_BAR_BACKGROUNDS
```

Flaga `SECURE` pozostaje aktywna zarówno w oknie głównym, jak i w stanie niezalogowanym w widoku `NotAuthenticatedMainActivity`. Próba wykonania zrzutu ekranu narzędziem systemowym:

```powershell
adb shell screencap -p /sdcard/screencap_test.png
```

Zwróciła plik o zerowym rozmiarze. Podsystem SurfaceFlinger zablokował dostęp do bufora klatki.

### 10.2. Rejestracja konta tożsamości w podsystemie Android AccountManager

Polecenie `dumpsys account` potwierdziło utworzenie konta tożsamości przez usługę mBanku w trakcie procedury parowania:

```text
Accounts: 2
  Account {name=mBank, type=pl.mbank}
  ServiceInfo: AuthenticatorDescription {type=pl.mbank}, ComponentInfo{pl.mbank/pl.mbank.core.authenticator.NmbAuthenticationService}, uid 10088
```

### 10.3. Weryfikacja odsyłaczy i widoków WebView za pomocą frameworka Frida

Do obserwacji warstwy WebView i odsyłaczy głębokich wykorzystano proces `frida-server 17.18.0` skompilowany dla architektury android-x86\_64 oraz skrypt `05_webview_deeplink_tracer.js` monitorujący metody `WebView.loadUrl`, `loadData`, `WebViewClient`, `DeeplinkTranslator` oraz `Uri.parse`. Badanie miało charakter wyłącznie obserwacyjny.

Wyniki wykonaniowe weryfikujące powierzchnię ataku:

- **Brak dostarczalności odsyłaczy głębokich między aplikacjami:** Próba uruchomienia adresu `mbankpl://app/...` przez polecenie `am start` została odrzucona przez system z wyjątkiem `SecurityException: not exported` dla identyfikatora UID 10088. Komponent `MainActivity` obsługujący odsyłacze nie posiada atrybutu `exported`, co zapobiega wstrzyknięciu adresu przez aplikację zewnętrzną.
- **Natywne renderowanie krytycznych formularzy:** Podczas pełnego przejścia procedury wniosku kredytowego skrypt śledzący nie zarejestrował wywołań metody `WebView.loadUrl`. Całość interfejsu renderowana jest za pomocą natywnych komponentów platformy Android, z pominięciem kontenera WebView i mostka JavaScript. Zawęża to zakres występowania podatności MBA-A-05 do modułów WebApps o mniejszym krytycznym znaczeniu biznesowym.
- **Stopniowane egzekwowanie ograniczeń środowiska:** Wyniki weryfikacji dynamicznej potwierdziły wnioski z rozdziału 8.5.1. Aplikacja zachowuje stabilność działania i umożliwia autoryzację kodem PIN w zmodyfikowanym środowisku systemowym.

---

## 11. Metodologia i zasady prowadzenia audytu

> Badanie prowadzono wyłącznie w trybie pasywnej obserwacji na aktywnym profilu badawczym. W trakcie testów wykluczono inicjowanie jakichkolwiek operacji finansowych, w szczególności przelewów, zmian limitów transakcyjnych oraz modyfikacji danych profilowych. Wykorzystanie frameworka Frida ograniczało się do monitorowania wywołań API bez modyfikacji logiki biznesowej. Testy obiektów Intent realizowano z użyciem bezpiecznych identyfikatorów testowych niewywołujących skutków po stronie serwerowej infrastruktury bankowej.

---

## 12. Wnioski końcowe i synteza porównawcza: iluzja heurystyk a rzeczywistość inżynierska

### 12.1. Nadreaktywność reguł anti-fraud i zjawisko zmęczenia alertami

Praktyka operacyjna udokumentowana podczas badań ujawnia istotną wadę koncepcyjną systemów oceny ryzyka mBanku. Błędna kwalifikacja bezpiecznej, stacjonarnej sesji w podsystemie WSA jako incydentu krytycznego oraz nałożenie prewencyjnej blokady na fizyczną kartę płatniczą przy transakcji na kwotę 18 PLN stanowi podręcznikowy przykład nadwrażliwości heurystyk detekcyjnych.

Taksowanie standardowych, bezpiecznych operacji mianem incydentów krytycznych generuje zjawisko powszechnie określane w inżynierii bezpieczeństwa jako zmęczenie alertami bądź znieczulica alarmowa. Zjawisko to pociąga za sobą dwustronne konsekwencje operacyjne:

- **Degradacja procesów pierwszej linii wsparcia L1:** Personel infolinii, konfrontowany z ciągłym napływem fałszywych alarmów generowanych przez nadreaktywne reguły scoringowe, traci zdolność odróżniania rzeczywistych ataków od standardowych zachowań użytkowników. Prowadzi to do mechanicznego odczytywania wyuczonych skryptów, chaosu decyzyjnego oraz braku zrozumienia technicznego kontekstu problemu.
- **Zniechęcenie konsumenta i koszty wizerunkowe:** Skazanie klienta na dwugodzinny proces wyjaśniający, konieczność deponowania dokumentów tożsamości pod zastaw w lokalu usługowym oraz awaryjne pozyskiwanie gotówki na drobny rachunek budzi uzasadnioną frustrację. Tworzy to wizerunek instytucji operującej chaotycznie, w której nadmierny rygor proceduralny uderza w niewinnego użytkownika.

### 12.2. Podatność seniorów i osób naiwnych na socjotechnikę w warunkach dysfunkcyjnych procedur

Nieracjonalne zachowania personelu bankowego stwarzają bezpośrednie zagrożenie dla grup klientów o niższych kompetencjach cyfrowych, w szczególności seniorów, emerytów oraz osób podatnych na manipulację.

Gdy konsultant oficjalnej infolinii uzależnia odblokowanie karty od spełnienia absurdalnego technicznie wymogu skanowania stacji roboczej dwoma zewnętrznymi programami antywirusowymi, u klienta ulega zatarciu naturalna granica czujności. Przestępcy stosujący techniki telefonicznego podszywania się pod bank, znane jako vishing oraz caller ID spoofing, posługują się dokładnie tożsamym schematem działania:

1. Wprowadzają stan zagrożenia rzekomym włamaniem na rachunek.
2. Powołują się na rygorystyczne procedury bezpieczeństwa instytucji finansowej.
3. Wymuszają zainstalowanie narzędzi zewnętrznych w postaci aplikacji zdalnego pulpitu AnyDesk, TeamViewer bądź QuickSupport, ewentualnie żądają podania poświadczeń autoryzacyjnych.

Dla osób starszych i zdezorientowanych chaotyczne postępowanie pracowników banku staje się wzorcem postępowania. Użytkownik przyzwyczajony do sytuacji, w której bank stawia nielogiczne wymagania i żąda numerów dokumentów bez wskazania ich formatu, wykonuje bez wahania polecenia fałszywego konsultanta. Nadwrażliwość heurystyk połączona z chaosem proceduralnym na infolinii dostarcza przestępcom gotowego schematu uwiarygadniającego atak socjotechniczny.

### 12.3. Asymetria obrony binarnej: prostota manipulacji pakietem mBanku a długotrwała persystencja w WSA

Analiza binarna pakietów mBanku ujawnia jaskrawą dysproporcję między deklarowanym rygorem reguł scoringowych a poziomem twardych zabezpieczeń w kodzie:

- **Brak komercyjnej obfuskacji:** Aplikacja główna oraz powiązane komponenty są pozbawione zaawansowanych osłon kodu maszynowego i bajtowego, takich jak DexGuard czy Promon SHIELD.
- **Jawność modułu maklerskiego .NET MAUI:** Komponent `pl.mbank.bmmobile` zawiera jawny kod pośredni C# IL w strukturze AssemblyStore. Pozwala to na pełną dekompilację logiki handlowej i procedur uwierzytelniania w ogólnodostępnych narzędziach dekompilacyjnych.
- **Bierność mechanizmów integralności:** Wbudowana funkcja `SecLib.initialize()` po napotkaniu binarnego pliku su zwraca kod stanu 9, powstrzymując się od przerwania działania procesu. W połączeniu z uniwersalnym kluczem zapasowym zaszytym w pliku APK oraz deterministycznym wektorem IV poziom odporności na inżynierię wsteczną pozostaje znikomy.

W rezultacie wyspecjalizowany podmiot może niskim nakładem pracy zmodyfikować pakiet APK, usunąć moduły telemetryczne, wdrożyć aplikację na urządzeniu nieświadomego użytkownika bądź aktywować ją w wirtualnym środowisku podsystemu WSA. W takim środowisku spreparowana sesja może funkcjonować stabilnie przez wiele lat, wykonując dowolne operacje poniżej progu alarmowego heurystyk serwerowych. Występuje tu kardynalny paradoks: rzeczywisty intruz obchodzi powierzchowne zabezpieczenia i zachowuje pełną swobodę działania, podczas gdy praworządny posiadacz rachunku doznaje blokady fizycznej karty płatniczej w punkcie handlowym.

### 12.4. Triada architektoniczna: mBank w zestawieniu z eDO App oraz mObywatelem

Zestawienie mBanku z dwiema wcześniej poddanymi audytowi aplikacjami tożsamościowymi pozwala na wyciągnięcie syntetycznych wniosków inżynierskich:

flowchart TD subgraph EDO["eDO App 1.7.1 PWPW"] direction TB E1(["Karta kryptograficzna e-dowód standard ICAO 9303"]) --> E2[["Protokoły PACE i Chip Authentication"]] E2 --> E3[("Brak magazynu danych w spoczynku / TEE Keystore")] E3 --> E4(["Wysoki rygor sprzętowy / trudna adaptacja pod WSA"]) end subgraph MOB["mObywatel 4.87.2 COI"] direction TB M1(["mDowód w sprzętowym Android Keystore"]) --> M2[["Hybryda: CMS bez verify i stała sól PBKDF2"]] M2 --> M3[("SQLCipher / podatność formatów archiwalnych")] M3 --> M4(["Średni rygor / bezpośrednie wykonanie na WSA"]) end subgraph MBK["mBank 3.122.4 mBank S.A."] direction TB B1(["Jawny kod C# IL .NET MAUI / stały klucz AES"]) --> B2[["Brak przerwania procesu przy roocie w SecLib"]] B2 --> B3[("Naskórkowa telemetria QUERY_ALL_PACKAGES")] B3 --> B4(["Fałszywe alarmy / pełna wygoda analityczna na WSA"]) end 

| Wymiar architektury | eDO App 1.7.1 PWPW | mObywatel 4.87.2 COI | mBank 3.122.4 mBank S.A. |
|---|---|---|---|
| **Kotwica zaufania** | Fizyczny procesor karty e-dowodu w standardzie ICAO 9303 | Sprzętowy Android Keystore z TEE i StrongBox dla mDowodu | Algorytmy serwerowe zasilane telemetrią środowiska |
| **Dane w spoczynku** | Brak lokalnego magazynu tożsamości; odczyt w locie przez NFC | SQLCipher dla mLegitymacji; klucze prywatne w pamięci aplikacji | Plik XML szyfrowany deterministycznie stałym kluczem z APK |
| **Ochrona binarna i obfuskacja** | Spłaszczenie przepływu i szyfrowanie literałów narzędziem Dotfuscator | Standardowa minifikacja R8; usterki w opublikowanym kodzie UI Kotlin | Całkowity brak obfuskacji kodu C# IL w module maklerskim |
| **Detekcja środowiska** | Ścisłe powiązanie z silnikiem Mono; awarie SIMD pod Houdini | Weryfikacja integralności platformy przez silnik Conscrypt i Play Integrity | Kod stanu 9 w SecLib; brak przerwania działania aplikacji |
| **Skuteczność ochrony** | Pełna odporność na klonowanie tożsamości bez fizycznej karty | Odporność mDowodu; dług techniczny w podsystemach legacy | Nadwrażliwość heurystyk; blokowanie praworządnych klientów |
| **Eksploatacja w WSA** | Wymaga zaawansowanego patchowania ICU, trimmera i instrukcji SIMD | Działa bezpośrednio w środowisku maszyny wirtualnej ART | Działa stabilnie od ponad pięciu lat; pełna wygoda inżynierska |

### 12.5. Podsumowanie: wygoda inżynierska a fundamentalna luka architektoniczna

Ocena architektury mBanku prowadzi do jednoznacznej, dwoistej konkluzji:

- **Perspektywa inżyniera i badacza systemowego:** Z punktu widzenia programisty, analityka niskopoziomowego oraz zaawansowanego inwestora giełdowego, środowisko stworzone przez mBank jest wyjątkowo wygodne i pożądane. Brak uciążliwych blokad roota, jawność struktur modułu maklerskiego eMakler oraz stabilne działanie w podsystemie Windows Subsystem for Android na wydajnej stacji roboczej Lenovo ThinkPad T14 z procesorem architektury Lunar Lake umożliwiają pełną automatyzację procesów rynkowych, swobodę badań binarnych oraz suwerenne zarządzanie finansami bez konieczności sięgania po fizyczny telefon.
- **Perspektywa masowego bezpieczeństwa bankowego:** Z punktu widzenia powszechnych standardów ochrony kapitału i tożsamości, przyjęty model stanowi fundamentalny błąd architektoniczny. Bank zrezygnował z twardych, kryptograficznych fundamentów po stronie klienta na rzecz powierzchownego monitorowania środowiska za pomocą telemetrii zainstalowanych pakietów. Rezultatem jest system ułomny w obu kierunkach: generuje agresywne, fałszywe alarmy paraliżujące codzienne życie uczciwych klientów, a zarazem pozostaje podatny na dekompilację, klonowanie i wieloletnie, skryte nadużycia ze strony zorganizowanych grup przestępczych polujących na osoby starsze i bezbronne wobec socjotechniki.

---

*Raport w toku. Data rozpoczęcia: 22 września 2026. Autor: Marek Wesołowski (WESMAR).*

### Add a comment

---

## Navigation

- Parent: [Analizy techniczne (PL)](https://kvc.pl/analizy-techniczne-pl.md)
- Previous: [eDO App 1.7.1 — audyt bezpieczeństwa i reverse engineering na WSA](https://kvc.pl/analizy-techniczne-pl/edo_app-audyt-bezpieczenstwa.md)