Autor: Marek Wesołowski (WESMAR) · github.com/wesmar · 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.

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

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 643 wpisy pakietów blokowanych przez aplikację. Identyfikatory pakietów zapisano w postaci skrótów SHA-256.

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

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.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.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 i biometrycznie 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ę 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.

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. 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ń

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

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:

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

Name (optional)

Email (optional, never published)

Comment *

Type the characters from the image *

Submit