Most people who have never used a mobile application security testing tool imagine something complicated. A command-line interface. Weeks of configuration. A team of security experts interpreting raw output. The reality is significantly simpler and significantly faster.
This post walks you through exactly what happens when you scan a mobile application with HEXMobileSuite, from the moment you upload the file to the moment you download your compliance-ready report. Whether you are a developer running your first security scan, a CISO evaluating tools, or a compliance officer who needs to understand what the output looks like, this walkthrough covers the full process.
Step 1: Upload Your Application
You start by uploading your mobile application file. For Android, this is an APK (Android Package Kit) file. For iOS, this is an IPA (iPhone Application Archive) file. The upload happens through a standard web browser no software installation, no plugins, no desktop client.
If you do not have the APK or IPA file readily available, there are several ways to obtain it. For Android, the APK can be extracted directly from a device using ADB, downloaded from the Google Play Store using a third-party extraction tool, or retrieved from your development team’s build pipeline. For iOS, the IPA is typically available from your CI/CD pipeline artifacts or your development team’s archive.
The upload takes seconds for most applications. Once the file is received, the platform begins its analysis automatically no additional configuration or input required.
Step 2: Decompilation and Artefact Extraction
This is where the platform does the heavy technical work, and it happens entirely behind the scenes.
For an Android APK, the platform performs a multi-stage decompilation process. It uses APKTool to decode the application’s resources layouts, strings, configuration files, and the AndroidManifest.xml that declares every component, permission, intent filter, and exported service. It uses JADX to recover readable Java and Kotlin source code from the compiled DEX bytecode. It performs binary analysis on the DEX files directly. It inspects the application’s signing certificate, network security configuration, and embedded resources.
The result is a complete inventory of the application’s internal structure every class, every method, every permission, every configuration setting, every embedded URL, every hardcoded string. The application has been taken apart the way a mechanic disassembles an engine, and every component is now available for inspection.
For an iOS IPA, the platform analyses the app bundle structure, inspects the Info.plist configuration (which declares the application’s capabilities, permissions, and transport security settings), examines the Mach-O binary for architecture, encryption, and symbol information, extracts entitlements, and performs string analysis on the binary.
This entire decompilation and extraction phase completes in minutes for most applications. The output is a structured set of artefacts that the detection engine will process in the next step.
Step 3: Detection Engine 124 Rules Against Your Application
The decompiled artefacts are now processed through the MPTL (Mobile Platform Threat Library) v2 engine. This is the core of the scanning process.
The engine runs 124 detection rules against the artefacts. Each rule is defined in YAML and targets a specific class of vulnerability. The rules are organised into two packs Standard and Extended and cover both Android-specific and iOS-specific checks, as well as general checks that apply to both platforms.
The rules span the full OWASP MASVS v2.1 control framework. Here is what each MASVS category covers and the types of issues the rules detect:
MASVS-STORAGE Secure data storage. The rules check for sensitive data stored in cleartext, insecure SharedPreferences or Keychain usage, data written to external storage, backup flags that expose application data, and logging of sensitive information.
MASVS-CRYPTO Cryptographic requirements. The rules check for weak algorithms (DES, RC4, MD5), hardcoded encryption keys, insufficient key lengths, insecure random number generation, and improper use of cryptographic APIs.
MASVS-AUTH Authentication and session management. The rules check for improper credential storage, missing session timeout, biometric authentication bypass vectors, and insecure token handling.
MASVS-NETWORK Network communication security. The rules check for cleartext HTTP traffic, missing certificate pinning, insecure SSL/TLS configurations, custom trust managers that accept all certificates, and network security configuration weaknesses.
MASVS-PLATFORM Platform interaction. The rules check for exported components that lack proper protection, insecure deep link handling, WebView vulnerabilities, content provider exposure, and improper use of platform APIs.
MASVS-CODE Code quality and build settings. The rules check for debugging enabled in production builds, stack trace leakage, deprecated API usage, and code obfuscation status.
MASVS-RESILIENCE Reverse engineering resistance. The rules check for root and jailbreak detection, tamper detection, debugger detection, and emulator detection controls that are particularly important for banking and payment applications.
MASVS-PRIVACY Privacy controls. The rules check for unnecessary data collection, missing privacy declarations, and data handling that may conflict with DPDP Act or GDPR requirements.
Each rule that fires produces a structured finding that includes the specific code location or configuration where the issue was detected, an evidence snippet extracted directly from the application, the severity rating (Critical, High, Medium, Low, or Informational), the MASVS category mapping, the CWE identifier, and a plain-English explanation of the risk and its recommended remediation.
Step 4: Findings Dashboard
When the scan completes, you see a dashboard that presents the findings in a structured, navigable format.
At the top level, you see a severity summary how many Critical, High, Medium, Low, and Informational findings were detected. This gives you an immediate sense of your application’s security posture. A scan that returns zero Critical findings and a handful of Medium findings tells a different story than one that returns five Critical findings on the first scan.
Below the summary, each finding is listed individually with its title, severity, MASVS category, and a brief description. You can click into any finding to see the full detail the evidence from your application, the explanation of the risk, and the remediation guidance.
The findings are not generic warnings copied from a vulnerability database. They are specific to your application. If the engine detects a hardcoded API key, the finding shows you the exact string, the file where it was found, and the class or method that contains it. If it detects cleartext HTTP traffic, the finding shows you the specific URL or domain involved.
This specificity is what makes automated scanning actionable. Your development team does not need to guess what the finding means or where to look the platform tells them exactly what to fix and where to find it.
Step 5: DREAD Risk Scoring (Optional but Recommended)
For organisations that need a structured risk assessment workflow particularly those preparing for NESA, SAMA, or other compliance audits the platform offers DREAD risk scoring.
DREAD stands for Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. Each finding can be scored across these five dimensions on a scale, producing a composite risk score that prioritises the most dangerous findings.
The scoring workflow also includes a validation cycle: each finding can be marked as Confirmed (the finding is valid and represents a real risk), Inconclusive (further investigation is needed), or Not Confirmed (the finding is a false positive or is mitigated by other controls). This creates a documented audit trail that shows regulators and auditors not just what was found, but how it was assessed.
The DREAD workflow is optional you can use the platform for straightforward scanning without it. But for compliance-driven use cases, it transforms the scan output from a list of findings into a structured risk assessment.
Step 6: Download the Compliance Report
The final step is generating and downloading the PDF report. This is the deliverable that your compliance team, your auditor, or your client will use.
The report includes an executive summary with an overall risk posture assessment, a severity breakdown chart, a detailed listing of every finding with its MASVS mapping, CWE reference, evidence, and remediation guidance, and a compliance summary that maps findings to the relevant regulatory framework.
The report is formatted for direct submission to NESA, SAMA, or any internal governance body. It is professionally structured, branded, and designed to be read by both technical and non-technical audiences.
From upload to downloadable compliance report the entire process completes in minutes, not weeks. No penetration testing firm engagement. No six-figure enterprise tool. No specialist security expertise required to interpret the results.
What Comes After the First Scan
The first scan gives you visibility. What you do with that visibility determines whether you are building a security programme or simply producing a one-time report.
The most valuable next step is to address the Critical and High findings, re-scan to verify remediation, and then configure continuous scanning either through the Play Store Auto-Scanner (for automatic detection of new releases) or CI/CD integration (for pre-release testing on every build).
The organisations that get the most value from HEXMobileSuite are the ones that scan on every release. The first scan shows you where you are. Continuous scanning ensures you stay there or get better.
Run your first scan now free, no credit card, results in minutes: hexmobsuite.hiesencyber.com
Hiesen Cyber Security | Hoisting Digital Fortresses Through the Storm hiesencyber.com