lab 3 · live artifact acquisition
Acquire the full live artifact set from a rooted / developer-mode device and fuse logs, dumpsys, and app data into one timeline.
objective
Acquisition is where triage becomes forensics. You will collect logs, dumpsys state, packages, network state, and app-private data read-only, then reconstruct when the compromise happened, not just that it did.
materials
- Labs 1–2 completed
- A device in developer mode; ideally one you have rooted, or the planted debuggable test app
acquire_artifacts.sh
procedure
- Confirm access mode. Developer mode is required; root or a debuggable target unlocks app-private data.
$ adb shell su -c id // uid=0 → root available $ adb shell run-as <pkg> id // works on your debuggable test app
- Run the live collector against your own device:
$ chmod +x acquire_artifacts.sh $ ./acquire_artifacts.sh
- Inspect the
logs/tree — correlatelogcat_eventswith app installs and permission grants. - Open the
dumpsys/bundle. Readaccessibility,device_policy, andappopsfor the suspect app. - Pull the suspect's private data via run-as (no root needed on a debuggable app) and inspect its databases / shared_prefs offline:
$ adb exec-out run-as <pkg> tar -c ./ > appdata.tar $ tar -tf appdata.tar | head
- Build a single timeline that fuses install time, first accessibility-enable event, and network activity.
- If authorized and relevant, acquire PII providers with the explicit flag — and document that authorization:
$ ./acquire_artifacts.sh --include-pii
deliverable
Deliverable: the acquisition manifest (SHA256SUMS), plus a fused timeline (install → accessibility-enable → first network egress) with each event cited to its source artifact. Note which access mode each artifact required.
access & privacy
run-as works only on apps that ship debuggable — which is exactly your own lab app, and never a store app you did not build. PII providers stay off unless you pass --include-pii with authorization. Read the acquisition guide before you run it.