AndroidForensics documents an ADB collection workflow for an authorized device

The collection model is ADB commands, in a documented order

AndroidForensics is described as an automated Android forensic toolkit for extracting device info, apps, contacts, call logs, SMS and system logs via ADB, and the README expands that into a practical guide for extracting digital artifacts using Android Debug Bridge commands.

The README states its audience and its posture directly: whether you are an investigator, a researcher or a security enthusiast, the repository walks through gathering system and app-level data safely, transparently and reproducibly, using a non-rooted device running Android.

That last clause is the most important technical constraint in the project. The whole workflow assumes a device you can plug in, with USB debugging enabled and authorized. There is no exploitation step, no privilege escalation attempt, and no remote collection path.

The prerequisites section lists three things: ADB installed on your system, USB debugging enabled on the target device, and proper authorization, legal and ethical, to access and analyze the device. The third is stated as a requirement rather than a disclaimer, which is the right way to frame a tool whose value depends on the collection being authorised.

The structure is a numbered sequence, and the order is a collection order rather than a tutorial order. You verify the connection, gather system information, retrieve installed applications, collect logs, extract power data, dump network information, pull directories, gather timeline and activity data, and finally enumerate accounts, contacts, calls and messages. Each step says what the output is for, which is the part that makes it a forensic guide rather than a command list.

The repository is MIT licensed with the primary language listed as Shell, and the top level entries show three scripts, extract.sh, dumpsys.sh and secretCodes.sh, alongside an AirScope.sh, a Docs/ directory and an Assets/ directory.

Setup and the first three collection steps

Installing ADB is the first step and it is a single package:

  sudo apt install adb -y

Then the connection check, which lists attached devices and their state:

adb devices

The example output in the README shows a device line with the status 'device', which is what an authorised device reports.

Step two gathers the general system state with a single getprop, which returns every system property at once:

adb shell getprop

And then the three specific properties that matter for a report, taken individually:

adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.serialno

The README is explicit about the purpose of those three: they give insight into the model, the OS version and the serial number, and it calls them essential for report documentation. That is a small point but a correct one, since a collection without a device identity and a timestamp attached to it is not evidence of anything.

Step three lists installed applications with their installation paths:

adb shell pm list packages -f

And the same command redirected into a file, which is the form the README recommends for analysis:

adb shell pm list packages -f > installed_apps.txt

The -f flag is what makes the output useful forensically, because it pairs each package name with the path it was installed to, which distinguishes a system app from a sideloaded one and can reveal a package that has been moved.

The Notes section at the end of the README makes the same point about output discipline that the rest of the guide follows: always document the Android version and collection timestamp alongside the exported files, and note that data volume can be large, so redirect outputs to files as shown to preserve formatting.

Logs, power state and network configuration

Step four collects the system log, and it is a one-liner that any Android developer will recognise:

adb logcat -d > system_logs.txt

The -d flag dumps the current buffer and exits rather than streaming, which is the correct behaviour for a collection because the script returns. The README describes what the file can hold: crash traces, app activity, network events, and more, valued for timeline reconstruction.

Step five gathers the power metrics:

adb shell dumpsys battery

And the sample output shows AC powered, USB powered, level, and temperature, with the temperature given as a raw integer of 290 in the example, which is the tenths-of-a-degree-Celsius encoding the Android service uses rather than a human-readable figure.

Step six collects network configuration and connection details, and it is three commands:

adb shell dumpsys connectivity
adb shell ifconfig
adb shell netstat

The three together give you the service-level connectivity state, the interface addresses and the current connections. That combination is what you want when reconstructing whether a device had an active network session at the time of collection.

Step seven is the first one that moves data rather than reading state, pulling accessible directories:

adb pull /sdcard/DCIM ./Android_Images
adb pull /sdcard/Download ./Downloads
adb pull /data/system/packages.list ./Package_List

And the README attaches a warning to that step: access to /data directories may require root or forensic-mode images. That is the honest constraint on the whole approach, and it is the reason the third command in that block is likely to fail on an ordinary non-rooted device while the first two succeed, since /sdcard is user-accessible storage and /data/system is not.

Step eight gathers the timeline data, and again it is a set of dumpsys calls plus the settings list:

adb shell dumpsys usagestats
adb shell dumpsys batterystats
adb shell settings list system

The README's framing is that this helps reconstruct user behavior and system-level changes over time. The usagestats and batterystats services hold usage counters and per-app background activity, and the settings list is a snapshot of the system configuration rather than a history, which is a distinction worth keeping in mind when reading it as timeline evidence.

Accounts, contacts, calls and SMS, and the Android 11 wall

Step nine is the one the README spends the most words on, and it is where the interesting limits are.

The mechanism is Android's content providers and system services, queried over adb shell content, and the results are saved locally for later review.

Listing accounts first, filtered to package names that end in com:

adb shell dumpsys account|grep -i com.*$ -o|cut -d' ' -f1|cut -d} -f1|grep -v com$

And listing email addresses registered on the device, by pulling them out of a full dumpsys dump with a regular expression:

adb shell dumpsys | grep -E -o "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b"

The README says this extracts every detected email address from the Account Manager service. The regex approach is worth noting as a technique with a limitation: it finds addresses anywhere in the dump rather than only in account records, so a false positive from an unrelated string is possible.

Then the boot counter, which the README presents as counting the number of device reboots:

adb shell settings list global|grep "boot_count="|cut -d= -f2|head -n 1|xargs echo "Booted:"|sed 's/$/ times/g'

That is a pipeline that reads the boot_count value out of the global settings, takes the first match and reformats it. The boot counter is a genuinely useful forensic data point because it bounds when the device was last started, which matters when you are reasoning about what a piece of cached data could have survived.

Then the user content, and here the constraints bite. Contacts with names and numbers:

adb shell content query --uri content://contacts/phones/ --projection display_name:number | cut -f 3- -d " "

Raw contact provider data:

adb shell content query --uri content://contacts/phones/ 

The call log:

adb shell content query --uri content://call_log/calls 

And the SMS database:

adb shell content query --uri content://sms/ 

The README is blunt about the condition on all of these: on Android 11 and higher, access to contacts, call logs and SMS via adb shell content may be restricted unless the device is rooted or a special forensic build is used. The Notes section repeats it with three ways out: on newer Android releases you may need root, developer-build access, or special forensic images for complete results.

That is the single most important practical fact about this project. The earlier steps work on any device with USB debugging authorised. These last four work on older Android, or on a rooted device, or on a forensic build. Anyone planning a collection should test the content provider queries on the actual target version before relying on the output.

The bundled scripts, and what the README says about them

The Included Scripts section says the repository includes two Bash utilities to automate and standardize the data extraction workflow, and names extract.sh and dumpsys.sh in the surrounding structure, with secretCodes.sh and AirScope.sh also present at the repository root.

The extract.sh description is specific about its behaviour. It is an automated ADB-based forensic data and diagnostics extraction from a connected Android device, designed for system analysis, auditing or incident response, collecting both system snapshots and select user-accessible data in a single organized run.

The step-by-step overview given in the README is worth reading because it documents the collection discipline the scripts implement. Step one checks that adb is installed, starts the ADB server silently, detects a connected device with adb devices, exits if no authorized device is found, and displays the connected device ID.

Step two creates a timestamped output folder, with the example given as ADB_Report_20251025_163200/, and all collected data is stored there, one file per command.

Step three is the core function, run_adb_command, which displays a colorized header. The README calls the script a much more advanced version of an earlier ADB script, which is a hint about how the project evolved: from a documented command sequence to a script that automates it.

The top level entries also include a Docs/ directory and an Assets/ directory, and the repository carries a.github/ directory and the MIT LICENSE file.

One thing worth flagging honestly is that parts of this README read as if they were drafted in conversation with an assistant rather than written as final documentation. There are passages that address the reader directly about polishing a section, and a ready-to-paste Markdown block offered for inclusion, and a question about choosing a name for the script. That is not a criticism of the commands, which are standard and correct, but it does mean the README's prose is uneven as a reference document, so treat the command blocks as the authoritative part and the surrounding commentary as working notes.

Where this approach stops working

The first limit is the one the README states: content provider access for contacts, call logs and SMS on Android 11 and higher. A collection that quietly returns empty results is worse than one that fails, because an empty result set can be mistaken for an absence of data on the device rather than an absence of permission. The README's own guidance, to document the Android version alongside the exports, is what prevents that mistake.

The second limit is that the whole method is interactive and manual in its final form. Every command in the guide is a separate adb invocation, and the extract.sh script automates a defined sequence rather than a general acquisition plan. A case that needs a specific set of artefacts chosen per device, with a chain of custody attached to each one, needs something more deliberate than a fixed sequence of dumpsys calls.

The third limit is scope. The README does not cover app-level database extraction from third-party applications, filesystem forensics of the internal storage beyond the /data note, memory or network capture, or any verification of what the device was doing while it was running rather than what it recorded. It is an ADB collection guide, not a mobile forensics suite.

The fourth is that the collection is not defensive. There is nothing here about hardening a device against this kind of collection, and enabling USB debugging on a device you carry leaves the door open to exactly this. The prerequisite list is the mitigation: USB debugging should only be enabled for the duration of an authorised session.

The alternative to weigh is the tooling built for this job rather than for the platform. Commercial mobile forensics suites and the Android open source project releases exist for the case where you need to acquire an image, hash it, preserve chain of custody and work from a verified copy rather than pulling live data from a running device. The difference in approach is significant. Pulling over ADB is fast and non-destructive and gives you current state, but it does not give you a forensically defensible copy of what was there. An acquisition-and-analysis suite gives you that, with a much larger dependency footprint and more setup. The README's own phrase, a practical guide, describes the right tool for a working investigation on a device you already hold, and the wrong tool for a case that goes to court.

Maintenance, licence and the repository's shape

The maintenance record is current. The last push was on 2026-10-03 and the repository is not archived. The repository has no GitHub releases, so there is no tagged version to pin and the scripts are consumed from the branch.

The licence is MIT, recorded in the repository listing with a LICENSE file at the root. That is a permissive grant with no copyleft obligation on anything you build with it, which is a licensing note rather than legal advice. For a collection toolkit the licence matters less than it might elsewhere, since the substantive content is a sequence of ADB commands documented by Google, but it does mean you can take the scripts, adjust the output paths and fold them into your own case tooling.

The top level entries give a sense of the scope. There are four shell scripts at the root, AirScope.sh, dumpsys.sh, extract.sh and secretCodes.sh, alongside a.github/ directory, an Assets/ directory that holds the Droid-Detective image used in the README header, a Docs/ directory and the LICENSE.

The topics are not given in the repository metadata, so there is no topic list to read the project's positioning from, but the description is precise: automated Android forensic toolkit for extracting device info, apps, contacts, call logs, SMS and system logs via ADB for security audits and investigations.

That phrase, for security audits and investigations, is the scope in two words, and it matches the README's own framing of the audience as investigators, researchers and security enthusiasts working on a non-rooted device. The project is a documented workflow with automation around it, and the value of it is mostly in the sequence and the notes attached to each step rather than in any novel technique.

Editorial conclusion

Adopt AndroidForensics if you are documenting an Android device you are authorized to examine and you want a reproducible, timestamped collection procedure rather than an ad hoc sequence of adb commands. Do not adopt it as a way to read data on a device you do not control, because the README requires proper authorization and because the collection depends on USB debugging being enabled on the device. Verify first whether the content provider queries for contacts, call logs and SMS return anything on the Android version in hand, since the README states these may be restricted on Android 11 and higher, and that the device state is recorded alongside the exports.

Frequently asked questions

Official sources

1. DouglasFreshHabian/AndroidForensics on GitHub
2. Issues
3. License: MIT
4. README