Loading...
Loading...
OWASP MASVS/MASTG-aligned security assessment for Malaysian fintech, e-wallet, and banking apps. Root/jailbreak bypass, insecure storage, backend API testing — mapped to BNM RMiT compliance requirements.
Malaysia's e-wallet and digital banking ecosystem has grown substantially: multiple BNM-licensed e-money operators, a proliferating digital bank sector, and consumer apps handling financial transactions that were previously conducted at physical branches. The mobile application is now the primary interface between a financial institution and its retail customers — and it is the most accessible attack surface for an adversary who wants to steal session tokens, bypass transaction authentication, or extract private key material from compromised devices.
The attack profile for Malaysian fintech apps is distinct from general mobile application security. Attackers targeting e-wallet apps are motivated by financial gain, are willing to invest in jailbroken or rooted devices to break application controls, and specifically look for backend API endpoints that implement authorisation logic inconsistently between the mobile client and a web interface. A common finding: a transaction limit enforced in the mobile app UI is not validated server-side, allowing an attacker who proxies the API directly to exceed limits entirely.
nCrypt's mobile app penetration testing follows the OWASP Mobile Application Security Testing Guide (MASTG) and maps findings to OWASP MASVS levels, providing structured evidence for BNM RMiT examination and internal audit.
Every nCrypt mobile assessment is scoped to one or more MASVS levels. The level determines the depth and focus of the assessment and the controls tested.
The baseline for all mobile applications. Covers fundamental controls: no sensitive data in unprotected storage, no hardcoded credentials in the app binary, proper use of platform cryptography APIs, secure network communication (TLS), and basic authentication hygiene. L1 applies to all apps regardless of sensitivity. Failing L1 is not a judgment call — it is a clear security failure.
Applies to:
Builds on L1 with controls for high-value applications: secure inter-process communication (IPC), runtime protection against hooking and dynamic instrumentation, certificate pinning for API traffic, and secure local data storage using platform keychains and secure enclaves. L2 is the appropriate level for fintech apps, healthcare apps, and any application where a compromise would cause financial loss or PDPA-regulated data exposure.
Applies to:
The highest tier: testing specifically for resistance against skilled attackers using reverse engineering, tampering, and emulator bypass. MASVS-R includes obfuscation effectiveness, anti-debugging controls, emulator and root/jailbreak detection reliability, and tamper-evidence mechanisms. Relevant for DRM-protected applications and apps where business logic (pricing, entitlements, fraud scoring) must not be visible or modifiable by the end user.
Applies to:
iOS and Android share the MASVS control objectives but differ significantly in implementation, tooling, and exploitability. Understanding the differences matters for scoping and remediation.
| Area | iOS | Android |
|---|---|---|
| Data storage | Keychain Services API for sensitive data. Incorrect Keychain accessibility settings (kSecAttrAccessibleAlways) expose data to other apps or backup extractions. NSUserDefaults and plist files are tested for sensitive data written outside the Keychain. | Shared Preferences, internal/external storage, Room/SQLite databases. External storage is world-readable by default. Backup configuration (allowBackup=true) exposes data to ADB backup on non-production devices. |
| Root/jailbreak bypass | Jailbreak detection via Cydia presence, dylib injection hooks (Frida), filesystem path checks, and fork() syscall availability. Bypass via Frida script injection or Liberty Lite/Shadow on jailbroken device. We test detection reliability and evasion difficulty. | Root detection via su binary, Magisk module presence, build prop flags (ro.build.tags=test-keys), and SafetyNet/Play Integrity API responses. Bypass via Magisk DenyList or LSPosed module. We test whether your app correctly fails closed when bypass is detected. |
| Binary protection | PIE, ARC, and stack canary flags verified via otool. Swift/ObjC metadata is inherently more decompilable than native Android — class names and selectors are recoverable from the binary. IPA payload is extracted and inspected. | APK decompilation via jadx/apktool. Native .so libraries tested for PIE and canary flags. R8/ProGuard obfuscation assessed for effectiveness — many apps use obfuscation that jadx deobfuscates automatically. |
| Certificate pinning | NSURLSession pinning via TrustKit or custom delegate. Bypass via Frida + SSL Kill Switch 2 on jailbroken device. We test whether the app functions at all without pinning and whether the bypass is straightforward. | OkHttp or Volley network library pinning. TrustManager bypass via Frida or custom network_security_config.xml injection on rooted device. We verify that pinning covers all backend hostnames, not just the primary API domain. |
BNM RMiT's requirements for secure application development and testing expect FIs to ensure that mobile banking applications are assessed for security vulnerabilities before deployment and after material changes.
The BNM e-Money and payment service guidelines require licensees to demonstrate security controls over mobile interfaces as part of ongoing licensing compliance.
OWASP MASVS-L2 is referenced in BNM technology risk guidance as an appropriate standard for high-risk financial mobile applications.
Apps subject to the BNM Cyber Risk Management (CRM) framework requirements should map mobile application findings to the relevant CRM control objectives.
e-Wallet apps licensed under BNM must comply with the Electronic Money Policy Document — security testing is part of demonstrating operational risk controls.
Common questions about mobile application penetration testing for Malaysian fintech, banking, and e-wallet operators.
OWASP MASVS — the Mobile Application Security Verification Standard — is the global reference framework for mobile application security requirements. It defines three levels of controls, from baseline (L1) through defence-in-depth (L2) to resilience against reverse engineering (MASVS-R). For Malaysian fintech and e-wallet apps, MASVS-L2 is the appropriate baseline: it covers the controls BNM technology risk examiners look for, including secure key storage, certificate pinning, and root/jailbreak detection. An assessment mapped to MASVS provides structured evidence for RMiT compliance and audit responses.
A code review (static analysis) analyses the source code or binary for vulnerabilities without running the application. A penetration test is dynamic: we run the app on a real or emulated device, interact with it as a user and as an attacker, intercept its network traffic, hook its runtime with Frida or objection, and test whether protections such as certificate pinning, jailbreak detection, and secure storage actually function under attack conditions. Code review and pentest are complementary — code review catches more logic errors, pentest confirms whether runtime protections are bypassable in practice.
Yes — a black-box mobile pentest uses only the compiled binary (IPA for iOS, APK for Android) and a test account. We decompile the binary, analyse the filesystem, intercept network traffic, and probe the backend API without source code. Black-box testing reflects what a real attacker has access to. Source-assisted testing (grey-box) is also available and allows us to identify vulnerabilities in business logic that are not visible through binary analysis alone — particularly useful for payment flows and fraud controls.
BNM does not prescribe a specific testing frequency by name for mobile apps, but the Electronic Money Policy Document and RMiT's requirements for secure application development and testing require licensees to demonstrate security assessment of mobile interfaces. In practice, BNM technology risk examiners request evidence of mobile application security testing — typically an OWASP MASVS-mapped pentest report — during examinations. Applications should be tested before major release and after material changes. Many Malaysian e-wallet operators conduct annual MASVS-L2 assessments as standard practice for licensing compliance.
Testing on a jailbroken (iOS) or rooted (Android) device unlocks the most powerful attack techniques: Frida runtime hooking, SSL Kill Switch for pinning bypass, filesystem access to app-private directories, and dynamic patching of application logic. This represents the capabilities of a skilled attacker who has physical access to a device. Testing on a standard (non-jailbroken) device reflects the threat from a malicious app on the same device or a compromised app binary. nCrypt tests on both: rooted/jailbroken devices for depth, standard devices for real-world reachability.
A standard MASVS-L1/L2 assessment of a single mobile app (iOS or Android) with a moderately complex backend API takes five to eight business days of testing plus two days for reporting. Cross-platform assessment covering both iOS and Android simultaneously typically takes eight to twelve days. Factors that extend scope: complex payment flows, multiple user roles requiring separate test accounts, deep API surface, or MASVS-R resilience requirements. Report delivery is within ten business days of testing completion.
Share your scope. We'll respond within 24 hours.
Share your scope. We'll respond within 24 hours.
MASVS-aligned assessment across iOS and Android with backend API testing included. Evidence-grade reporting for BNM RMiT examinations and internal audit.
Complementary services Malaysian buyers commonly pair with mobile app pentest.
OWASP-aligned web app penetration testing with manual exploitation.
Learn moreREST, GraphQL and gRPC API security testing against OWASP API Top 10.
Learn moreSAST plus CREST-aligned manual code audit across Java, .NET, Python, JS/TS.
Learn more