Malware triage, parser robustness and Android boundaries — DedSec Project

13. Malware triage without execution

Focus: Malware triage without execution.

When an unknown file appears, do not double-click it to “see what happens.” Start with provenance: expected source, hash, file type, signatures, timestamps and whether it was requested. Static strings and metadata can suggest a hypothesis but are not a verdict.

Isolate untrusted samples from normal work. Prefer a dedicated authorized analysis environment with no production credentials and clear network limits; if you do not have one, stop at read-only metadata checks. A benign test file is enough to practice this workflow.

Safe lab: create a harmless text file, hash it, rename its extension, and compare extension versus detected content type. Change one byte and observe the checksum change. This teaches integrity and type confusion without handling real malware.

Report: observed facts, confidence, what was not executed, potential exposure, next specialist step. Do not treat antivirus labels alone as definitive proof or upload private files to public scanners without authorization.

Further reading: Hacking Guide Project — module 79.

14. Parser robustness and small fuzz tests

Focus: Parser robustness and small fuzz tests.

Parsers fail on edge cases: empty data, invalid byte sequences, deep nesting, oversized lengths, missing delimiters and duplicate keys. Specify what inputs are valid, then test invalid forms without allowing uncontrolled resource use.

Toy example: a configuration parser expects KEY=VALUE once per line. Test blank lines, whitespace, duplicate KEY, missing '=', an embedded '=' in VALUE, and non-ASCII text. Decide whether duplicates are rejected or last-wins, and document the choice.

Properties to check: valid input round-trips; invalid input returns a defined error; memory/time remain bounded; malformed input does not write outside the intended output; results are deterministic.

Practice: create a dozen small, harmless input mutations and run them against a parser you wrote. Log which mutation changed behavior. Use synthetic strings only, not arbitrary hostile files on a privileged production process.

Fuzzing generates candidates; a useful regression test preserves every crash or surprising behavior once minimized and fixed.

Further reading: Hacking Guide Project — module 68.

15. Android app boundaries and package updates

Focus: Android app boundaries and package updates.

An Android APK is installed under a package identity and signing key. A usable update typically must preserve compatible package identity and signing lineage; replacing an APK with an unrelated signature is not a normal upgrade path. Treat signing keys as high-impact secrets.

Runtime permissions should follow the feature that needs them. A camera, microphone or storage permission should have a clear user-facing purpose, and lack of permission must produce a graceful message rather than a crash.

Cross-platform design: a Python tool ported to Android may need a native file picker, foreground/background lifecycle handling, scoped storage and different notifications. Showing the same menu does not guarantee equivalent behavior.

Practice: choose an imaginary note-taking app. Define permissions (ideally none beyond required), offline storage, import/export, backup, package name, signing identity and minimal smoke tests across an old and new Android version.

Avoid testing private user data or implying emulator builds prove all physical-device behavior.

Further reading: Hacking Guide Project — module 56.

16. Ethical testing and reporting

Focus: Ethical testing and reporting.

Security research begins with scope, authorization and non-disruption, not with tools. A target's public visibility is not permission to test it. Confirm written scope, allowed techniques, rate limits, reporting channel and data-handling rules.

A useful vulnerability report separates observed facts from hypotheses: affected version, prerequisites, impact within scope, smallest safe reproduction, evidence without personal data, expected versus actual behavior, and a proposed fix. Give maintainers time and a safe way to reproduce.

Toy example: you find in your own local notes app that a second test account can read the first account's note. Use synthetic records, state how IDs were created, and provide a failing test. Do not dump real user records.

Practice: write one-page report for that fictional authorization bug, including an explicit negative regression test after repair.

Do not perform real-world intrusive scanning, social engineering or exposure of third-party data for this exercise.

Further reading: Hacking Guide Project — module 43.