Guide · · 14 min read

ADB Forensics Guide: Android Debug Bridge Extraction

ADB forensics Android extraction logical acquisition guide

ADB (Android Debug Bridge) forensic extraction is a logical acquisition method that uses Google's official command-line tool to extract digital evidence from Android devices. ADB communicates over USB or TCP/IP to pull files, query content providers and retrieve device metadata. Combined with per-artifact SHA-256 hashing, ADB extraction produces forensically sound evidence suitable for court proceedings.

What Is ADB and How It Works for Forensics

Android Debug Bridge (ADB) is a command-line utility included in the Android SDK Platform Tools. Google developed ADB as a developer debugging tool, but its ability to communicate directly with an Android device's operating system makes it the foundation of most logical forensic extraction methods.

ADB operates on a client-server architecture. The ADB client runs on the forensic workstation. The ADB daemon (adbd) runs on the Android device. The ADB server manages communication between them. When a device is connected via USB with debugging enabled, the workstation can issue commands that the daemon executes on the device.

For forensic purposes, ADB provides three critical capabilities. First, file transfer via adb pull copies files from the device to the workstation without modifying the source. Second, shell access via adb shell allows querying content providers, system properties and package information. Third, application management via adb install and adb uninstall enables deployment of forensic helper APKs that extend the data accessible through ADB.

The forensic value of ADB lies in its documented and reproducible behavior. Every ADB command is part of Google's published API. The commands do not exploit vulnerabilities or bypass security controls. They access data through the same interfaces that installed applications use, which makes the extraction method legally defensible and technically repeatable.

ADB vs Agent-Based vs Physical Acquisition

Forensic examiners have three primary extraction approaches for Android devices. Each method has distinct capabilities, requirements and limitations that determine when it is appropriate.

Criteria Raw ADB Agent-Based (Helper APK) Physical Extraction
Root required No No Yes (or exploit)
Device unlock required Yes Yes Varies by method
USB debugging required Yes Yes No (hardware methods)
SMS and call logs No (without root) Yes (via content providers) Yes
Contacts No (without root) Yes (via content providers) Yes
Photos and media Yes (shared storage) Yes (all accessible media) Yes (including deleted)
App data Limited (backup scope) Limited (permissions scope) Full (all databases)
Deleted data recovery No No Yes (unallocated space)
Device modification None Temporary APK install May modify boot partition
Legal complexity Low (consent-based) Low (consent-based) High (warrant typically needed)
Per-artifact hashing Manual scripting Automated by tool Image-level hash only
Typical cost Free (manual labor) Free to $399 $5,000 to $25,000+/year

Raw ADB is suitable for quick triage or when only shared storage files are needed. Agent-based extraction using a helper APK is the standard for consent-based examinations requiring SMS, contacts and call logs. Physical extraction is reserved for cases requiring deleted data recovery or non-cooperative device owners under warrant authority. For a broader comparison of Android forensic approaches, see our Android forensics guide.

What Data ADB Can Access

Understanding what ADB can and cannot reach without root access is essential for setting examination expectations and documenting scope limitations in forensic reports.

Accessible via raw ADB (no root, no helper APK)
Shared storage files including photos, videos, downloads and documents in /sdcard/. Device properties via getprop including manufacturer, model, Android version, serial number and build fingerprint. Installed package list via pm list packages. Application APK files. ADB backup data for apps that allow backup (many modern apps disable this). Screenshot capture via screencap.
Accessible via helper APK (no root)
SMS and MMS messages via the Telephony content provider. Contact records via the ContactsContract content provider. Call log entries via the CallLog content provider. Calendar events. Media metadata. Wi-Fi connection history on supported Android versions. Browser bookmarks on supported versions.
Requires root or physical extraction
Application private databases (WhatsApp msgstore.db, Signal database). System logs and tombstones. Deleted files and unallocated space. Full /data/data/ directory. Keystore entries. Device encryption keys.

The distinction between raw ADB access and helper APK access is why tools like Sherlock Android Acquirer install a lightweight APK on the device. The APK requests standard Android permissions through the consent dialog, enabling access to content providers that raw ADB commands cannot reach.

Key ADB Commands for Forensic Extraction

The following commands form the core of ADB-based forensic acquisition. Each command should be documented in the examination notes with its exact syntax, timestamp and output.

adb pull

The adb pull command copies files from the device to the workstation. It preserves file timestamps and operates on individual files or entire directory trees.

adb pull /sdcard/DCIM/ ./evidence/media/

This copies the entire camera directory including all photos and videos. The command reports bytes transferred and transfer rate. After pulling files, compute SHA-256 hashes immediately to establish baseline integrity values.

adb shell content query

The content query command reads from Android content providers. This is how forensic tools access structured data like SMS messages and call logs when a helper APK grants the necessary permissions.

adb shell content query --uri content://sms/ --projection address:body:date

This queries the SMS content provider for message addresses, body text and timestamps. The output is structured text that can be parsed programmatically. Without a helper APK holding SMS permissions, this command returns a permission denial.

pm list packages

The package manager command lists all installed applications on the device. This inventory is critical for identifying applications of forensic interest and documenting the device configuration.

adb shell pm list packages -f

The -f flag includes the APK file path for each package. This allows you to identify system versus user-installed applications and locate APK files for preservation if needed. Document the full package list as part of the device profile.

getprop

The getprop command reads Android system properties. It provides device identification data that is essential for chain of custody documentation.

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

These four commands return the device model, serial number, Android version and build fingerprint. Run adb shell getprop without arguments to dump all system properties. Store the complete property dump as a reference artifact.

Additional useful commands

adb shell dumpsys battery returns battery status and level at the time of examination. adb shell settings list secure returns security-relevant settings including whether USB debugging was previously authorized. adb shell wm size and adb shell wm density document screen configuration. Each of these commands contributes to a complete device profile in the forensic report.

Legal Considerations for ADB-Based Acquisition

ADB extraction operates at the intersection of digital forensics and privacy law. The legal framework governing your extraction depends on your jurisdiction, the nature of the case and the authority under which you are conducting the examination.

Consent-based acquisition

For corporate investigations, civil litigation, HR matters and family law, consent-based ADB extraction is the standard approach. The device owner provides informed written consent specifying what data categories will be extracted. The consent form should document the scope of extraction, storage and retention policies, who will access the data and the owner's right to withdraw consent at any time before extraction begins.

In Canada, consent-based acquisition aligns with PIPEDA requirements for collection of personal information. The consent must be meaningful, which means the device owner must understand what data is being collected and for what purpose. A vague or overly broad consent form may not withstand legal challenge.

Warrant-based acquisition

Law enforcement conducting ADB extraction under warrant authority must ensure the warrant specifically authorizes the data categories being extracted. A warrant authorizing seizure of a device does not automatically authorize extraction of all data on it. The examiner should document the warrant reference number and limit extraction to data within the warrant's scope.

Employer-owned devices

Devices owned by an employer may be subject to different rules. An acceptable use policy that reserves the employer's right to inspect device contents may provide legal basis for extraction without individual consent. However, personal data on employer-owned devices may still be protected under privacy legislation. Consult legal counsel before extracting data from employer-owned devices used for personal purposes.

Cross-border considerations

If the device contains data from cloud services hosted in other jurisdictions, additional legal considerations apply. The extraction of locally cached data is generally governed by the jurisdiction where the examination occurs. However, accessing cloud-synced data may implicate the laws of the jurisdiction where the cloud service operates.

Chain of Custody with ADB Extraction

Chain of custody documentation for ADB forensic extraction must establish data integrity from the moment of extraction through presentation in court. The critical element is per-artifact SHA-256 hashing at the point of extraction.

Chain of Custody Element ADB Extraction Requirement
Device identification Record via getprop: model, serial, Android version, build fingerprint, IMEI
Examiner credentials Name, certifications (CISSP, ISSAP, ISSMP), organization, date of examination
ADB connection verification Screenshot of adb devices output showing device serial and connection status
Consent documentation Signed consent form reference, permissions granted by device owner, timestamp
Extraction log Complete log of all ADB commands executed with timestamps and return codes
Artifact hashing SHA-256 hash computed for each extracted file and database record at point of extraction
Evidence storage Encrypted media identification, storage location, access control documentation

The SHA-256 hash is the cornerstone of forensic integrity in ADB extraction. Unlike physical imaging where the entire disk image receives a single hash, ADB logical extraction hashes each artifact individually. This means that if a single file's integrity is challenged, the remaining artifacts retain independent verification. Per-artifact hashing is arguably stronger evidence of integrity than a single image hash because it allows granular verification.

Document the hashing methodology in the forensic report. Specify whether hashes were computed on the device before transfer, on the workstation immediately after transfer or both. Dual hashing (device-side and workstation-side) provides the strongest integrity evidence but requires root access or a helper APK capable of computing hashes on-device.

How Sherlock Android Acquirer Automates ADB Forensics

Sherlock Android Acquirer automates the ADB forensic extraction process described in this guide. Instead of manually running ADB commands, scripting content provider queries and computing hashes individually, the tool handles the entire workflow from device connection through report generation.

The tool installs a lightweight helper APK on the device with the owner's consent. The APK requests standard Android permissions for contacts, SMS, call logs and media access through the normal Android consent dialog. Once permissions are granted, the tool extracts artifacts through content provider APIs via ADB. Each artifact receives a SHA-256 hash at the point of extraction.

Key automation features include:

  • Automatic device detection and identification via getprop
  • Bootloader status check to document device security state
  • Permission-based access to SMS, contacts, call logs and media via helper APK
  • Per-artifact SHA-256 hashing during extraction
  • Forensic PDF report generation with chain of custody header
  • Artifact inventory with hash manifest
  • Automatic APK cleanup after extraction

The free edition handles device detection, bootloader checks and data inventory. The Forensic Edition ($399) adds full extraction, court-ready PDF reports and hash verification. This is a one-time purchase with no annual subscription.

When to Use ADB vs Cellebrite and Physical Methods

Choosing between ADB-based extraction and enterprise tools like Cellebrite or physical extraction methods depends on the case requirements, legal authority and budget.

Use ADB-based extraction when
The examination is consent-based with a cooperative device owner. You need SMS, contacts, call logs, media and installed application data. Deleted data recovery is not required. The case is corporate, civil or family law. Budget constraints prevent enterprise tool licensing. You need a legally simple extraction method that accesses data through documented Android APIs.
Use Cellebrite or enterprise tools when
You need cloud acquisition capabilities. The case requires iOS and Android support in a single platform. Your organization processes high volumes of devices. You need vendor support and training. The cost ($15,000 to $25,000+ annually) is justified by caseload. For a detailed cost comparison, see our Cellebrite alternative analysis.
Use physical extraction when
Recovery of deleted files is essential to the case. The device owner is non-cooperative and you have warrant authority. You need access to application private databases (WhatsApp, Signal). File system level analysis is required. The case justifies the technical complexity and legal requirements of exploit-based or hardware-based extraction.

For many practitioners, ADB-based extraction with a helper APK covers 70 to 80 percent of their caseload. Corporate investigations, employee misconduct cases, civil discovery and family law matters rarely require deleted data recovery. The remaining cases that need physical extraction can be referred to a lab with the appropriate tools and authority.

ADB Forensic Extraction: Step-by-Step Procedure

The following procedure documents a complete ADB forensic acquisition suitable for chain of custody requirements.

Step 1: Enable Developer Options

The device owner navigates to Settings, About Phone and taps the Build Number entry seven times. A toast message confirms that Developer Options are now enabled. The examiner documents the timestamp and that the device owner performed this action voluntarily.

Step 2: Enable USB Debugging

The device owner navigates to Settings, Developer Options and toggles USB Debugging to the on position. The device displays a warning that USB debugging allows the connected computer to access device data. The device owner acknowledges this warning. The examiner documents the timestamp.

Step 3: Connect the Device

Connect the Android device to the forensic workstation via USB cable. Use a known-good cable that supports data transfer (not a charge-only cable). Verify that the workstation recognizes the USB connection. If using Sherlock Android Acquirer, the tool will detect the device automatically.

Step 4: Authorize ADB Connection

The device displays an RSA key fingerprint authorization prompt asking whether to allow USB debugging from the connected computer. The device owner taps "Allow" to authorize the connection. On the workstation, run adb devices and verify the device serial number appears with "device" status rather than "unauthorized".

Step 5: Run Acquisition

Execute the extraction. If using Sherlock Android Acquirer, click "Start Acquisition" and the tool handles helper APK installation, permission requests, artifact extraction and hashing automatically. If using manual ADB commands, execute each extraction command individually and log the output. Pull shared storage via adb pull /sdcard/. Query content providers via adb shell content query. Dump device properties via adb shell getprop.

Step 6: Verify Hashes

After extraction completes, verify the SHA-256 hash manifest. Each extracted artifact should have a corresponding hash value. If using Sherlock Android Acquirer, the hash manifest is generated automatically. If using manual commands, compute hashes using sha256sum on the workstation and record the values. Compare artifact counts against expected totals for the device usage profile.

Step 7: Generate Report

Compile the forensic report. The report should include the chain of custody header with examiner identification and credentials, device identification from getprop output, consent form reference, extraction methodology, complete artifact inventory with SHA-256 hashes and any anomalies observed during extraction. Store the report and extracted data on encrypted media with documented access controls.

External Resources

Related Guides