Building an Android security toolkit around evidence, not alerts

Why build another toolkit?

Security analysis tools can help people collect facts quickly. But a scanner that produces a long list of warnings is not the same thing as a defensible assessment. I started the Private research record as an experimental command-line project that keeps a simple principle at its centre: observations need context.

The CLI, ahmad-sec, accepts a locally available APK for authorized reconnaissance. It is built for repeatable exercises, developing security rules, and documenting what the tool can and cannot establish.

A useful investigation workflow

A sound approach begins with scope. Confirm permission, record the specific application version, and decide which security assumption you want to test. Then collect evidence that another researcher could reproduce.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
ahmad-sec apk scan /path/to/authorized.apk

That command is an example of a supported workflow, not a claim that any particular target contains an exploitable issue. Every test must remain within the authorization granted by the owner or program.

Three states that should never be confused

My research notes distinguish these levels of confidence:

• Observation: a configuration or behaviour the tool can identify, such as a manifest attribute.
• Candidate risk: a pattern that might introduce an exploitable condition, depending on permissions, reachability and application logic.
• Confirmed vulnerability: a reproducible failure with demonstrated, relevant security impact in an authorized environment.

Not every warning is a vulnerability. The work is in connecting an observation to an actual trust-boundary failure.

Limitations are part of the product

The public repository documents important limitations. Selected secret scanning paths do not cover all code and resource formats, and exported-component checks require careful validation of component attributes, platform rules and permission enforcement. A cleartext-related flag is not proof that sensitive information travelled over an unencrypted connection.

Before a release is treated as suitable for broader use, its publication checklist calls for clean test results, safer masking of potential secrets, controlled fixture tests and a review of repository history. Those remain engineering tasks rather than completed promises.

Where this project goes next

The highest-value improvements are regression-tested manifest parsing, consistent redaction in tool output and small, intentionally vulnerable laboratory applications that explain each rule. A research tool should become more accurate through evidence—not merely louder through additional alerts.