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

Aktualizacja, 14 października 2026 r.: mBank odpowiedział na reklamację po 19 dniach kalendarzowych, w ustawowym limicie 15 dni roboczych. Potwierdził blokadę bezpieczeństwa i brak bieżących ograniczeń, lecz nie wyjaśnił wymogu dwóch skanów antywirusowych ani nie rozstrzygnął jasno wszystkich zastrzeżeń. Analiza odpowiedzi, podstaw prawnych i dalszych kroków.

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.

Wynik ważony: 8,1/10 — ocena bardzo dobra z minusem. Architektura sieciowa, integracja ze sprzętowym modułem TEE oraz dedykowany silnik RASP uPaid MDC reprezentują wysoki standard inżynierski. Zidentyfikowane uchybienia dotyczą długu technologicznego w postaci archiwalnego magazynu mBank.xml opisanego w ustaleniach MBA-A-08 i MBA-A-06, otwartego kodu modułu maklerskiego eMakler oraz nadwrażliwości heurystyk antyfraudowych.

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ść

3. Środowisko testowe

4. Identyfikacja i weryfikacja artefaktu

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

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

5.2. Analiza eksportowanych komponentów

Aktywności eksportowane

Usługi eksportowane

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

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

<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"/>.

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.

6.3. Wektory obejścia mechanizmu pinningu

7. Analiza uprawnień aplikacji

7.1. Uprawnienia o podwyższonym poziomie ryzyka

8. Biblioteki i komponenty zewnętrzne

8.1. Zestawienie komponentów i bibliotek natywnych

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

Plik assets/security-packages-list.json o rozmiarze 65 KB zawiera bazę 643 wpisów służących do identyfikacji niebezpiecznego oprogramowania. Identyfikatory zapisano w postaci skrótów SHA-256:

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

Analiza dekompilatu klasy pl.mbank.feature.securitycheck.dangerousapps.blacklist.SecurityRepository ujawniła algorytm wyliczania i weryfikacji skrótów:

// SecurityRepository.e(): wyliczenie skrótu SHA-256 z nazwy pakietu
for (ApplicationInfo applicationInfo : installedApplications) {
    String hashCode = Hashing.sha256()
        .hashString(applicationInfo.packageName, StandardCharsets.UTF_8)
        .toString();
    if (hashSet.contains(hashCode)) {
        a.a(null, c.a(arrayList), "[ThreatFound] Unsafe app: " + applicationInfo.packageName);
        arrayList.add(new a(hashCode, null, 2, null));
    }
}

Skrót stanowi standardowy ciąg szesnastkowy SHA-256 wyliczony bezpośrednio z tekstowej nazwy pakietu applicationInfo.packageName w kodowaniu UTF-8. Skrót pomija strukturę binarną pliku APK, certyfikaty oraz kod DEX.

Analiza dopasowań ujawniła obecność popularnych narzędzi zdalnego zarządzania pulpitowego, powszechnie wykorzystywanych przez grupy przestępcze w atakach vishingowych:

Pakiet com.topjohnwu.magisk (skrót 1d61da52...) pozostaje poza omawianym zbiorem. Detekcja narzędzi uprawnień roota odbywa się niezależnie za pośrednictwem modułów xr2 oraz biblioteki natywnej libnativeSeclib.

Dynamiczna synchronizacja i telemetria zwrotna:
Lista wykazuje pełną synchronizację dwukierunkową ze środowiskiem serwerowym:

1. Pobieranie aktualizacji: Metoda SecurityRepository.g() wykonuje zapytanie sieciowe this.a.C4(timestamp), przesyłając znacznik czasu bieżącego zbioru. Serwer zwraca skompresowany strumień danych, który po dekodowaniu Base64 i dekompresji GZIP zapisywany jest w magazynie preferencji pod kluczem security_threats_list.
2. Telemetria zagrożeń: W przypadku wykrycia zainstalowanego pakietu z czarnej listy metoda SecurityRepository.l() przesyła wykaz zidentyfikowanych zagrożeń bezpośrednio do serwera bankowego wywołaniem this.a.J3(arrayList).
3. Detekcja podszywania pod markę banku: Metoda SecurityRepository.e() weryfikuje etykietę każdej zainstalowanej aplikacji (getApplicationLabel). Funkcja i0.a0(label, "mbank", true) sprawdza obecność frazy mbank. W przypadku braku obecności pakietu na liście zaufanych następuje rejestracja zdarzenia [ThreatFound] Suspicious app: <etykieta>, <pakiet>, co stanowi zabezpieczenie przed fałszywymi klonami aplikacji.

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.

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:

{ "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.

// 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

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

// 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

// 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

// 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:

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.4.7. Architektura silnika RASP platformy uPaid MDC oraz dynamiczny loader bibliotek natywnych

Wcześniejsze analizy bezpieczeństwa koncentrowały się na pomocniczym module libnativeSeclib.so oraz statycznej klasie SecLib.initialize(). Szczegółowa dekompilacja pakietów pl.mbank.mcore.vf3, pl.mbank.mcore.xe3, c.o oraz o.h wykazała obecność wielopoziomowego silnika ochrony środowiska wykonawczego RASP zintegrowanego w ramach platformy uPaid Mobile Development Center.

Dynamiczny obfuskowany loader biblioteki natywnej

Inicjalizacja podsystemu natywnego w klasie pl.mbank.mcore.xe3.b opiera się na dynamicznym wyliczaniu nazwy modułu w trakcie działania procesu:

1. Klasa wewnętrzna pl.mbank.mcore.xe3.b$a generuje tablicę 84 bajtów za pomocą łańcucha 32-bitowych przesunięć bitowych bez znaku.
2. Metoda c.o.eu.e1 dekoduje sekwencje szesnastkowe do postaci znaków unikodowych.
3. Metoda c.o.eu.y wykonuje operację bitową XOR z wykorzystaniem klucza dynamicznego 1a9UjiRSHasdfFJDfsdAIhreSJ1.
4. Ostatecznym wynikiem procedury jest identyfikator native-library, przekazywany do System.loadLibrary(). W ten sposób następuje załadowanie biblioteki libnative-library.so o rozmiarze 1,79 MB dla architektury ARM64 oraz 2,02 MB dla x86_64.

Most JNI i rejestracja metod w klasie o.h

Biblioteka libnative-library.so rezygnuje ze statycznych symboli formatu Java_. Wszystkie punkty wejścia podlegają dynamicznej rejestracji przez funkcję JNI_OnLoad za pośrednictwem RegisterNatives środowiska JNI. Docelowym punktem montowania metod natywnych jest klasa o.h, deklarująca 32 niskopoziomowe metody natywne, w tym:

• o(Context): inicjalizacja kontekstu sprzętowego oraz struktur kryptograficznych,
• d(): generowanie sygnatury atestacyjnej środowiska,
• h(String): kryptograficzna weryfikacja integralności tokenów,
• yy(String) oraz u(String): statyczne metody zwrotne wywoływane przez kod maszynowy C++ po wykryciu anomalii.

Pętla sprzężenia zwrotnego i selektywne zerowanie tożsamości

Podsystem uPaid MDC odpowiada za bezpieczeństwo operacji portfelowych i tokenizacji kart zbliżeniowych BLIK Contactless, podlegając asynchronicznej inicjalizacji w klasie pl.mbank.mcore.ck0.g. W przypadku zidentyfikowania manipulacji w pamięci chronionego modułu, obecności debuggerów ptrace lub haków dynamicznych, kod maszynowy w libnative-library.so wykonuje wywołanie powrotne do maszyny wirtualnej:

1. Funkcja C++ przekazuje identyfikator zagrożenia do metody o.h.yy() lub o.h.u().
2. Zdarzenie trafia do dyspozytora c.o.ex i zostaje przekierowane do interfejsu nasłuchującego pl.mbank.mcore.xe3.c.
3. Interfejs deleguje obsługę do procedury pl.mbank.mcore.vf3.ub.
4. Procedura wykonuje asynchroniczną transmisję wektora naruszenia do infrastruktury telemetrycznej banku za pośrednictwem metody dm.d().
5. Następuje unieważnienie sesji portfela poprzez wywołanie w4.reset(). Skutkuje to wyczyszczeniem kluczy sesyjnych oraz zerowaniem tokenów autoryzacyjnych modułu płatniczego.

Architektura ta wyjaśnia obserwację wykonawczą udokumentowaną w rozdziale 10.3: pasywne podłączenie frameworka Frida do głównego komponentu MainActivity pozwala na dalsze stabilne działanie procesu, ponieważ mechanizm ochronny RASP izoluje specyficzny podsystem płatniczy i koncentruje się na unieważnieniu struktur kryptograficznych portfela oraz asynchronicznym raportowaniu zdarzeń.

Weryfikacja obfuskacji R8 oraz integralności klas w pamięci

Platforma uPaid MDC zawiera mechanizmy autoweryfikacji procesu budowania:

• Weryfikacja obfuskacji klas domenowych: Klasa pl.mbank.mcore.vf3.th za pośrednictwem SecurityModuleApi.a.I().a() sprawdza stan zaciemnienia kluczowych struktur aplikacji. Podsystem bada obecność oryginalnych nazw klas domenowych, takich jak CardHolder, MobileDcApiConfiguration oraz ApiErrorDetails. Brak zaciemnienia nazw przez R8 jest traktowany jako modyfikacja binarna i powoduje zatrzymanie aplikacji.
• Weryfikacja sum kontrolnych klas w pamięci: Komponent classChecksumChecker oblicza sumy kontrolne bajtokodu załadowanych klas DEX. Zabezpiecza to proces przed wstrzykiwaniem obcych klas w czasie działania aplikacji.
• Detekcja flagi debugowania: Podczas procedury startowej badana jest flaga ApplicationInfo.FLAG_DEBUGGABLE. Wykrycie aktywnego debugowania powoduje wyrzucenie wyjątku DebugVersionException.

Zaciemnione biblioteki libbeda.so oraz libc5ba.so

W strukturze pakietu APK znajdują się dodatkowo biblioteki libbeda.so o rozmiarze 1,06 MB oraz libc5ba.so o rozmiarze 1,20 MB. Analiza sekcji dynamicznej tych plików wykazała zaawansowane spłaszczenie przepływu sterowania oraz zredukowanie czytelnych ciągów tekstowych do około 100 pozycji. Biblioteki importują bezpośrednie wywołania systemowe jądra Linux: mprotect, syscall, __system_property_get, _exit, fork, kill, dlopen oraz dlsym. Zestaw ten służy do niskopoziomowej ochrony stron pamięci przed modyfikacją oraz bezpośredniego kończenia procesu bez powiadamiania środowiska uruchomieniowego Androida.

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:

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:

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.5.2. Telemetria stanu połączeń i próba sprzętowej identyfikacji urządzenia

Równolegle z detekcją roota aplikacja korzysta z uprawnienia READ_PHONE_STATE w dwóch odrębnych wektorach funkcjonalnych:

1. Detekcja rozmowy telefonicznej (IncomingCallReceiver): Odbiornik pl.mbank.feature.callDetector.IncomingCallReceiver nasłuchuje zdarzeń systemowych TelephonyManager.ACTION_PHONE_STATE_CHANGED. Odczytuje parametr TelephonyManager.EXTRA_STATE, identyfikując stany RINGING, OFFHOOK oraz IDLE. Moduł ten służy celom ochrony antyfraudowej, ostrzegając użytkownika przed autoryzacją operacji finansowych podczas trwającej rozmowy telefonicznej (ochrona przed atakiem typu vishing).
2. Próba odczytu sprzętowego numeru IMEI (tb1.q): W klasie pl.mbank.mcore.tb1.q (linia 320) kod wykonuje bezpośrednie odwołanie this.f34055b.getImei(i) dla każdego dostępnego slotu karty SIM. Od poziomu systemu Android 10 (poziom API 29) wywołanie to kończy się zgłoszeniem wyjątku SecurityException, gdyż odczyt sprzętowych identyfikatorów urządzenia został zastrzeżony dla uprawnień systemowych READ_PRIVILEGED_PHONE_STATE. Obecność tej metody w kodzie produkcyjnym dokumentuje dążenie architektury do pozyskiwania stałych identyfikatorów sprzętowych na potrzeby profilowania stacji klienta.

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.

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:

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:

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:

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:

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

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, biometrycznie oraz ochrony nowoczesnych preferencji aplikacja korzysta ze sprzętowego magazynu kluczy AndroidKeyStore:

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.

<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" />

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ę 1648 skrótów SHA-256 autoryzowanych komponentów ułatwień dostępu.

Weryfikację uprawnień i usług realizuje klasa pl.mbank.mcore.qr2.n zintegrowana z komponentem AccessibilityBackgroundService oraz nasłuchem stanu AccessibilityManager.AccessibilityStateChangeListener. Skrót wyliczany jest ze standardowego ciągu UTF-8 w formacie <nazwa_pakietu>/<klasa_usługi>:

// pl.mbank.mcore.qr2.n.m(): SHA-256 z identyfikatora komponentu
public final String m(String str) {
    return Hashing.sha256().hashString(str, StandardCharsets.UTF_8).toString();
}

Analiza zasobu potwierdziła dopasowania dla kluczowych usług asystujących głównych producentów systemowych:

Logika w metodzie n.k() weryfikuje każdą aktywną usługę systemową. Jeśli aktywny komponent ułatwień dostępu nie figuruje w bazie białej listy, aplikacja rejestruje wpis [Accessibility] Unknown service: <komponent> i uruchamia okno dialogowe AccessibilityDialogFragment z ostrzeżeniem dla użytkownika.

Mechanizm ten stanowi barierę chroniącą przed trojanami bankowymi (np. Sharkbot, Teabot, Xenomorph) nadużywającymi interfejsu AccessibilityService do nakładania fałszywych formularzy logowania (overlay) oraz automatycznego zatwierdzania przelewów (ATS). Jednocześnie generuje on fałszywe alarmy w przypadku legalnego oprogramowania automatyzującego, menedżerów haseł z funkcją autouzupełniania bądź niestandardowych narzędzi ułatwień dostępu w zmodyfikowanych dystrybucjach systemu Android.

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.

8.11.1. Koegzystencja architektur pamięci trwałej: mBank.xml a sprzętowy CryptoPreferences

Szczegółowa inwentaryzacja katalogu shared_prefs w wyekstrahowanej kopii zapasowej ujawniła równoległą obecność dwóch odmiennych generacji magazynów konfiguracyjnych:

1. Warstwa starsza (shared_prefs/mBank.xml):
   Implementacja w klasie pl.mbank.mcore.i90.e bazująca na symetrycznym szyfrowaniu AES-CBC z kluczem zapisanym w pliku lub uniwersalnym kluczem zapasowym w kodzie APK (132F1A90***DEE8). Schemat ten odpowiada za podatność MBA-A-08 i pozwala na odtworzenie 142 parametrów technicznych w trybie offline. Stanowi dług technologiczny aplikacji.

2. Warstwa nowoczesna (shared_prefs/<uuid>.xml):
   Implementacja interfejsu pl.mbank.mcore.xd3.a w klasie pl.mbank.mcore.kw.h7 powiązana z podsystemem uPaid MDC. Pliki noszą nazwy losowo generowanych identyfikatorów UUID. Warstwa ta implementuje schemat szyfrowania kopertowego (envelope encryption) powiązany ze sprzętowym magazynem AndroidKeyStore:

   • Klasa pl.mbank.mcore.kw.q8 generuje losowy, symetryczny klucz szyfrowania danych DEK (Data Encryption Key).
   • Klasa pl.mbank.mcore.rd3.a realizuje operacje owijania i odwijania (wrap oraz unwrap) klucza DEK z użyciem klucza nadrzędnego KEK (Key Encryption Key) zakotwiczonego w AndroidKeyStore. Wzorzec ten opiera się na sekwencji metod sprawdzających obecność klucza, generowania specyfikacji oraz enkapsulacji (hasKey, generate, wrap, unwrap).
   • Silnik kryptograficzny cb0.h konfiguruje specyfikację KeyGenParameterSpec dla dostawcy AndroidKeyStore, obsługując transformacje AES-GCM oraz RSA-PKCS1 z finalizacją szyfrowania przez wywołanie Cipher.doFinal(). Klucz nadrzędny powiązany jest ze stałym aliasem LOGIN_KEY zadeklarowanym w klasie cb0.g.
   • Zastosowanie sprzętowej enklawy TEE uniemożliwia odzyskanie klucza DEK oraz deszyfrację parametrów konfiguracyjnych poza fizycznym procesorem urządzenia.

Koegzystencja obu struktur potwierdza wdrożenie pełnej ochrony sprzętowej w procesorze urządzenia dla nowo projektowanych modułów oraz tokenów transakcyjnych. Archiwalny plik mBank.xml pozostaje komponentem przejściowym bez wsparcia AndroidKeyStore.

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.

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. Architektura hybrydowa i selektywne osłony: Zastosowanie zaawansowanego silnika RASP platformy uPaid MDC ogranicza się do modułu płatności i tokenizacji kart. Główna przestrzeń klas DEX oraz biblioteki .NET MAUI w aplikacji maklerskiej pozostają w standardowych formatach podlegających bezpośredniej dekompilacji.

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 blokadę karty i odmowy płatności, oceniane przez autora jako prawdopodobny błąd fałszywie pozytywny (false positive). Przyczyna decyzji serwerowej pozostaje niepotwierdzona. Odpowiedź banku i granice wniosków opisano w aktualizacji z 14 października w rozdziale 8.14.6.

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. wystąpiła blokada bezpieczeństwa opisana poniżej. Autor wiązał ją z aktywnością sesji WSA, lecz nie ma dostępu do reguł i logów decyzyjnych banku. Związek przyczynowy z WSA nie został potwierdzony w odpowiedzi reklamacyjnej. Zaobserwowano następującą asymetrię ograniczeń:

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. Granice prawne blokady i wymogu skanowania

Bank może stosować blokady bezpieczeństwa. Nie oznacza to jednak, że każda blokada i każdy warunek jej zdjęcia są automatycznie uzasadnione. Art. 41 ust. 2–4 ustawy o usługach płatniczych określa przesłanki blokowania instrumentu, obowiązek powiadomienia z wyjątkami oraz odblokowanie po ustaniu podstaw blokady. Art. 42 ust. 3 wymaga obiektywnych, niedyskryminujących i proporcjonalnych postanowień umowy dotyczących użytkowania instrumentu.

Korekta podstawy prawnej: we wcześniejszej wersji artykułu błędnie wskazano art. 43 ust. 3. Właściwy przepis o odblokowaniu to art. 41 ust. 4. Samo potwierdzenie tożsamości klienta nie dowodzi jeszcze, że ustąpiło ryzyko przejęcia urządzenia lub poświadczeń. Analogicznie sama obecność WSA, roota czy narzędzi badawczych nie dowodzi infekcji.

W opisanej rozmowie konsultant miał uzależniać odblokowanie karty od dwóch skanów antywirusowych. Bank powinien wyjaśnić, czy była to rekomendacja, czy wiążący warunek, na jakim postanowieniu umowy oparty i jaki związek miał z ryzykiem dotyczącym fizycznej karty. Dwa skany nie są dowodem integralności systemu. Ich sens zależy od konkretnego zagrożenia, zakresu badania i kryteriów zakończenia procedury.

Na podstawie samej relacji z rozmowy nie przesądzam naruszenia prawa. Nie znam pełnej dokumentacji decyzji, obowiązującej umowy ani analizy banku. Oceny wymaga zasadność blokady i proporcjonalność warunku jej zdjęcia. Rozróżniam przy tym blokadę karty od całkowitego odcięcia dostępu do środków: według opisanego przebiegu dostęp aplikacyjny pozostał czynny.

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 kwestionowanej blokady karty, publicznej odmowy autoryzacji oraz opisanych problemów 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 kwestionowanych blokad. Właściwość instytucji i możliwość interwencji Rzecznika Finansowego doprecyzowano w aktualizacji z 14 października.

8.14.6. Aktualizacja z 14 października 2026 r.: odpowiedź banku

mBank odpowiedział na reklamację REK122475856 14 października 2026 r. Wiadomość zatytułowana „Rozwiązanie reklamacji REK122475856” została doręczona o 10:16:51 czasu polskiego (CEST). Datę i godzinę potwierdza nagłówek odbiorczego serwera pocztowego w zachowanym pliku MSG. Nie publikuję pliku wiadomości, prywatnych adresów ani danych pracownika. Poniżej omawiam stanowisko banku i jego braki.

Chronologia i termin

Dni robocze policzono od następnego dnia po 25 września, pomijając soboty i niedziele; w tym przedziale nie przypadały polskie święta ustawowe. Jeżeli bank otrzymał reklamację 25 września, piętnasty dzień roboczy przypadał 16 października 2026 r. Czasu nie liczę z dokładnością do godzin od złożenia reklamacji, ponieważ nie mam tu potwierdzonej godziny jej wpływu.

Odpowiedź nie była spóźniona względem limitu 15 dni roboczych dla reklamacji dotyczących usług płatniczych. Wynika on z art. 15a ust. 2 ustawy o usługach płatniczych; Rzecznik Finansowy wyjaśnia również zasady terminów reklamacyjnych. Wewnętrzna kategoria „Jakość obsługi Klienta” nie zastępuje oceny rzeczywistego przedmiotu reklamacji. Dziewiętnaście dni oczekiwania na tak ogólną odpowiedź oceniam krytycznie, ale nie przedstawiam tego jako dowodu przekroczenia ustawowego terminu.

Co bank potwierdził, a czego nie wyjaśnił

Bank podziękował za zgłoszenie i wyraził nadzieję, że pomoże ono w tworzeniu algorytmów szacowania ryzyka. Odmówił przekazania szczegółów systemu antyfraudowego, powołując się na tajemnicę przedsiębiorstwa. Przywołał art. 50 ust. 2 Prawa bankowego, wyraził ubolewanie z powodu niedogodności związanych z blokadą i poinformował, że obecnie rachunek nie podlega ograniczeniom wpływającym na jego działanie.

To potwierdza blokadę bezpieczeństwa i deklarowany brak aktualnych ograniczeń. Nie potwierdza natomiast błędu algorytmu, związku przyczynowego z WSA, przeprowadzenia analizy przyczyny źródłowej ani zmiany reguł. Sformułowanie o przyszłym wykorzystaniu zgłoszenia nie jest potwierdzeniem wykonanej poprawki.

W odpowiedzi zabrakło odniesienia do konkretnych pytań:

• Dlaczego ograniczono fizyczną kartę przy zachowaniu dostępu aplikacyjnego? Różne kanały mogą mieć różne mechanizmy ochrony, ale bank nie wyjaśnił tej decyzji w opisanym przypadku.
• Czy sprawdzono przebieg rozmowy z infolinią i wymóg dwóch skanów antywirusowych? Czy był to warunek odblokowania, czy zalecenie?
• Jaka podstawa umowna uzasadniała ten warunek i co miało potwierdzać usunięcie zagrożenia?
• Czy bank uznał reklamację w całości, częściowo, czy ją odrzucił? Które zastrzeżenia rozpatrzył i z jakim wynikiem?

Nie oczekuję publikacji kodu, progów scoringowych ani sygnatur detekcyjnych. Oczekuję rozliczenia konkretnej decyzji i procedury. Tajemnica przedsiębiorstwa może uzasadniać ochronę mechaniki systemu. Sama w sobie nie wyjaśnia, dlaczego odpowiedź pomija wymóg narzucony przez konsultanta i nie wskazuje wyniku rozpatrzenia poszczególnych zastrzeżeń.

Czy podstawa prawna banku wystarcza?

Bank prawidłowo powołuje obowiązek szczególnej staranności w ochronie środków. Art. 50 ust. 2 Prawa bankowego rzeczywiście go ustanawia. Ustęp 1 tego samego artykułu przewiduje swobodę dysponowania środkami, z możliwością ograniczeń umownych. Obowiązek ochrony nie stanowi więc samodzielnego dowodu prawidłowości każdej decyzji operacyjnej.

Art. 9 ustawy reklamacyjnej wymaga m.in. wyczerpującego stanowiska wobec zastrzeżeń i wskazania odpowiednich fragmentów umowy; uzasadnienie faktyczne i prawne jest wymagane, chyba że reklamację rozpatrzono zgodnie z wolą klienta. Odpowiedź zawiera ogólny przepis prawa, ale nie wskazuje konkretnego postanowienia umowy ani jasno nie rozstrzyga zastrzeżeń dotyczących obsługi.

Jeżeli roszczenia nie zostały uwzględnione, art. 10 wymaga także pouczenia o dostępnych drogach dalszego dochodzenia praw. W otrzymanej wiadomości takiego pouczenia nie ma. Potwierdzenie braku bieżących ograniczeń nie jest jednoznaczne z uwzględnieniem całej reklamacji. To konkretna kwestia do wyjaśnienia przez bank i oceny przez Rzecznika Finansowego, a nie podstawa do ogłoszenia z góry prawomocnego naruszenia.

Właściwa droga dalszego działania

Zasadne jest żądanie uzupełnienia stanowiska banku o rozstrzygnięcie zastrzeżeń, podstawę umowną i ocenę procedury infolinii oraz zabezpieczenie nagrania rozmowy i dokumentacji blokady. Żądanie należy skierować przez oficjalny kanał reklamacyjny mBanku; wiadomość z odpowiedzią informuje, że odpisanie na nią nie przekazuje sprawy konsultantom.

W sporze indywidualnym właściwym kolejnym adresatem jest Rzecznik Finansowy. Wniosek powinien zawierać reklamację, odpowiedź, potwierdzenie wpływu oraz chronologię zdarzeń. Interwencja jest bezpłatna, lecz nie stanowi wiążącego rozstrzygnięcia sporu.

KNF przyjmuje informacje o nieprawidłowościach na potrzeby nadzoru; nie rozstrzyga indywidualnego roszczenia klienta. UOKiK ocenia praktyki naruszające zbiorowe interesy konsumentów. Zawiadomienie do tego urzędu ma sens jako sygnał o możliwej powtarzalnej procedurze, ale jeden incydent nie dowodzi sam w sobie naruszenia interesów zbiorowych.

Wniosek inżynierski: sprawa nie kończy się na zdjęciu blokady. Brakuje informacji, czy decyzja była zasadna, czy procedura odblokowania miała podstawę i czy zgłoszenie doprowadziło do jakiejkolwiek korekty. To pozostają pytania otwarte. Ogólna deklaracja bezpieczeństwa nie zastępuje odpowiedzi na reklamację dotyczącą konkretnego działania systemu.

9. Zestawienie ustaleń

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:

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:

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:

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

Opisany incydent wskazuje na potrzebę zbadania kalibracji reguł i procedury odblokowania. Blokada fizycznej karty oraz dwie odmowy płatności 18 PLN są faktami opisanymi w studium przypadku. False positive pozostaje oceną autora, ponieważ bank nie ujawnił podstaw konkretnej decyzji. Nie utożsamiam samego działania aplikacji w WSA z dowodem bezpieczeństwa całej sesji.

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 oficjalna infolinia uzależnia odblokowanie karty od instalacji lub uruchomienia dodatkowych narzędzi bez jasnego wyjaśnienia, może utrudniać klientowi odróżnienie prawidłowej procedury od socjotechniki. Zalecenie skanowania nie jest tym samym co żądanie zdalnego dostępu czy przekazania poświadczeń. Ryzyko dotyczy przyzwyczajenia do wykonywania niejasnych poleceń pod presją zagrożenia. Przestępcy stosujący vishing oraz caller ID spoofing wykorzystują następujący schemat:

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.

Jasna procedura powinna wskazywać, jak klient może zweryfikować kanał kontaktu, czego bank nigdy nie żąda i jaki jest cel zalecanego działania. Brak tych granic może zwiększać podatność na manipulację. To ocena ryzyka projektowego, nie dowód, że opisany incydent doprowadził do oszustwa.

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 architekturą zabezpieczeń w kodzie:

• Selektywna izolacja silnika RASP: Zaawansowane mechanizmy obfuskacji dynamicznej oraz autoweryfikacji RASP platformy uPaid MDC zostały ograniczone do podsystemu tokenizacji płatniczej. Główny kontener aplikacji oraz przepływy bankowości ogólnej podlegają standardowej translacji R8, umożliwiając analizę przepływów biznesowych.
• 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.
• Pasywność ogólnych 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, ogólny poziom odporności kontenera na modyfikację pozostaje niski.

Dostępność kodu ułatwia analizę i przygotowanie hipotez dotyczących modyfikacji klienta. Nie dowodzi jednak, że zmodyfikowany APK zachowa autoryzację po stronie serwera, ominie wszystkie mechanizmy integralności albo umożliwi wieloletnie wykonywanie nieuprawnionych operacji. W tym audycie nie wykazano takiej persystencji ani przejęcia rachunku. Otwarte pozostaje pytanie o spójność ochrony kanałów: dlaczego w opisanym incydencie zablokowano fizyczną kartę, podczas gdy dostęp aplikacyjny pozostał czynny. Odpowiedź banku z 14 października tej kwestii nie wyjaśnia.

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:

12.5. Podsumowanie: wygoda inżynierska a specyfika architektury wielowarstwowej

Ocena architektury mBanku prowadzi do jednoznacznej 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 w głównym oknie aplikacji, 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ą automatyzację procesów rynkowych, swobodę badań binarnych oraz suwerenne zarządzanie finansami bez sięgania po fizyczny telefon.
• Perspektywa masowego bezpieczeństwa bankowego: Z punktu widzenia powszechnych standardów ochrony kapitału i tożsamości, ocena końcowa 8,1/10 (bardzo dobra z minusem, w skali ocen: bardzo dobry z minusem) odzwierciedla dojrzałość modułów krytycznych oraz obecność długu technologicznego. Zabezpieczenie kanału TLS z użyciem TrustKit i 78 pinów oraz ochrona tokenizacji płatności przez silnik RASP uPaid MDC i sprzętowy TEE Keystore reprezentują wysoki poziom inżynierski. Koegzystencja z archiwalnym magazynem mBank.xml, brak obfuskacji brokera eMakler oraz agresywne heurystyki monitorowania pakietów generujące fałszywe alarmy dla legalnych sesji wyznaczają obszary wymagające dalszych prac modernizacyjnych.

Raport w toku. Data rozpoczęcia: 22 września 2026. Aktualizacja postępowania reklamacyjnego i oceny prawnej: 14 października 2026. Autor: Marek Wesołowski (WESMAR).

Add a comment

Name (optional)

Email (optional, never published)

Comment *

Type the characters from the image *

Submit