Mobile application security audit

Android APK and AAB analysis

An Android package can contain a manifest, DEX bytecode, resources and native shared libraries. These components require different tools and do not all decompile into the same language. Readable Java-like output from a DEX decompiler is a reconstruction, not necessarily the original Java or Kotlin project.

An AAB is a publishing format, so provide the relevant device configuration or installed split packages when the behaviour depends on a particular installation. Obfuscation, dynamic code loading and native logic can limit static interpretation. Define which version of the application is being assessed and retain a hash of the supplied artifact in the engagement record.

iOS IPA and native code review

An iOS application contains compiled native code and platform-specific resources. Depending on the build, metadata can support interpretation of Objective-C classes or Swift types. Optimized machine code should not be described as an intact, recoverable Xcode project.

Artifact availability, device access, operating system version, application signing and encryption affect which tests can run. Confirm these conditions before agreeing to runtime testing. Access to an IPA file alone does not establish that every relevant code path can be inspected or that a working test installation is available.

Choose the mobile security questions

Useful assessment questions include how the app stores sensitive values, which data crosses a platform boundary, what information is exposed through logs and how a selected authentication or integrity check behaves. The OWASP Mobile Application Security Testing Guide provides public methods for organizing such reviews. Referencing it does not mean that a project is certified by OWASP.

Client-side analysis has limits. A mobile package review does not automatically include penetration testing a production backend, reviewing server source or assessing every account role. List the in-scope endpoints, test accounts and permitted interactions if those are needed for the agreed objective.

• Packaged configuration, resources and code structure.
• Relevant native libraries and language boundaries.
• Selected local storage, logging and communication behaviour.
• Reproducibility conditions and remediation for confirmed findings.

Evidence, report and optional artifacts

Agree the outputs before testing: an assessment report, extracted resources, reconstructed headers, decompiled modules or a specific analysis of native routines. State which are feasible for the supplied build. A patched test package or instrumentation script, when appropriate to the engagement, is a separate artifact with its own compatibility and verification conditions.

The report should identify the app version, test environment, observation steps and limitations. Separate confirmed behaviour from hypotheses that could not be tested. This makes the handover useful to an engineering team that needs to reproduce a finding or check a future fix.

Request a mobile assessment

Send TNKRE the platform, artifact type, version and a concise description of the objective. Explain whether a test device, simulator build or sanitized test account is available. Arrange a transfer method before sharing sensitive packages, and agree confidentiality and data-handling expectations for the engagement.

Only include software and environments you are authorized to assess. Use test data and keep personal customer records and production credentials out of the initial inquiry. Pricing and delivery timing are confirmed after review. If your question is specifically about a Go, Rust or Nuitka library embedded in the app, the native binary audit page explains that part of the process.