apkleaks - Moses Yebei

The Problem

APK files bundle compiled bytecode, resources, and metadata that often contain hardcoded endpoints, API keys, and other secrets. Manually decompiling and grepping for these patterns is slow and error-prone. APKLeaks automates the discovery of URIs, endpoints, and secrets inside an APK by decompiling it and scanning the result against a set of regex patterns.

What This Does

APKLeaks is a Python CLI tool that takes an APK file, decompiles it using jadx, and scans the decompiled source for sensitive patterns. The default patterns live in config/regexes.json; users can supply their own via a --pattern argument. Results can be written to a text or JSON file.

The codebase is small: 6 Python files, with the core logic in apkleaks/apkleaks.py and helper functions in apkleaks/utils.py. It ships with a Dockerfile, a Makefile, and GitHub Actions workflows for CI and publishing.

How It Is Wired

Execution starts at main in apkleaks/cli.py:32. That function reaches 11 other functions, making it the single entry point through which all control flows. The call graph shows the main path: main calls APKLeaks, integrity, and decompile; integrity calls dependencies and apk_info; and decompile calls extract and cleanup.

The two most-connected modules are apkleaks/apkleaks.py (8 functions, 1 class) and apkleaks/utils.py (3 functions, 1 class). Both have an instability score of 0.67, meaning they are relatively volatile. The function writeln in utils.py is called from 6 different places — the widest blast radius in the repo. Changing its signature or behavior will ripple through most of the tool's output handling.

A full run does the following: main → APKLeaks → integrity (checks jadx availability) → decompile → extract → scanning → writeln (writes results to disk). The tool touches the filesystem for the APK, the decompiled output, and the results file; it invokes an external process (jadx) for decompilation. No network calls or database writes are present.

File-by-file map:

apkleaks/cli.py — argument parsing, header, main
apkleaks/apkleaks.py — core orchestration: apk_info, dependencies, integrity, decompile, extract, scanning, cleanup
apkleaks/utils.py — write, writeln, finder (regex matching), utility class
apkleaks/colors.py — ANSI color output
config/regexes.json — default secret patterns

How To Use It

Setup — Install from PyPI or clone and install requirements:

pip3 install apkleaks
# or from source
git clone https://github.com/moses-y/apkleaks
cd apkleaks/
pip3 install -r requirements.txt

Running it — The CLI entry point is apkleaks, or python3 apkleaks.py from source:

apkleaks -f /path/to/file.apk -o results.txt
apkleaks -f /path/to/file.apk -p custom-rules.json --json

Configuration — No environment variables are required. Custom patterns go in a JSON file passed via -p. The jadx disassembler must be installed or available for download.

Real-World Use

A security engineer auditing a mobile app before release would run:

apkleaks -f app-release.apk -o audit-results.txt --json

The output file lists all matched endpoints and secrets, which can then be triaged — hardcoded API keys get revoked, exposed internal endpoints get reviewed. The custom pattern file lets the team add org-specific patterns (e.g., internal hostnames) without modifying the tool.

Code Health & Issues

Static analysis found 6 issues: 1 high, 5 medium.

High - Deep nesting — apkleaks/utils.py and apkleaks/apkleaks.py have max indentation depth of 8, making control flow hard to follow. Fix with guard clauses and early returns.
Medium - File opened without context manager — apkleaks/cli.py uses open(...) without with, risking a leaked handle on error.
Medium - Broad exception handling — except clauses in apkleaks/apkleaks.py, apkleaks/cli.py, and apkleaks/utils.py swallow errors indiscriminately.

SDLC observations: no test files exist, and dependencies are declared without a lockfile (pyproject.toml), so builds are not reproducible. CI exists via GitHub Actions, and no committed secrets were detected.

The Bottom Line

A functional, focused tool that does one job well. The lack of tests and lockfile makes it risky to modify, but the small codebase is easy to read and the core logic is straightforward. Suitable for security engineers who need a quick APK secret scanner and are willing to accept the maintenance risk.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

22 files

Python6
YAML4
Markdown2
JSON2
TOML1

Docker

Module dependencies

The 6 most depended-upon modules of 6, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_apkleaks_colors["colors"] n1_apkleaks_apkleaks["apkleaks"] n2_apkleaks_cli["cli"] n3_apkleaks_utils["utils"] n4_apkleaks["apkleaks"] n5_apkleaks___init__["__init__"] n1_apkleaks_apkleaks --> n0_apkleaks_colors n1_apkleaks_apkleaks --> n3_apkleaks_utils n2_apkleaks_cli --> n1_apkleaks_apkleaks n2_apkleaks_cli --> n0_apkleaks_colors n3_apkleaks_utils --> n0_apkleaks_colors n4_apkleaks --> n2_apkleaks_cli

Findings

MediumNo test files detected - untested code paths repository-wide
LowDependencies declared without a lockfile - non-reproducible builds pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium6

low1

Pin third-party GitHub Actions to a commit SHAhigh5 occurrences

.github/workflows

docker/metadata-action@v5, docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Declare least-privilege permissions for GITHUB_TOKENmedium2 occurrences

.github/workflows/codeql.yaml

2 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

python:3-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Give the outbound request a timeoutmedium

apkleaks/apkleaks.py

1 outbound call(s) with no timeout

requests has no default timeout, so a peer that accepts the connection and then says nothing holds the worker forever, and with a small worker pool a single slow dependency takes the whole service down without anything appearing to fail.

Fix: Pass timeout= on every call, or use a session with one configured.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/codeql.yaml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.