Some of the most useful evidence on an Android phone is a file the phone will write for you on request. It is called a bug report. It was built for engineers, but it carries exactly the things a compromise check wants to know: what is installed, what each app may reach, how the device is set up and what its logs recorded. It is not everything. This article says what SectraTEK reads in an Android bug report, what it cannot, and how the examination ends in a report a client can act on.
What an Android bug report is, and how it is obtained
An Android bug report is a diagnostic bundle that the phone generates about itself on request. It contains system logs, the state of installed packages and their permissions, the device’s build and identity, and the settings the system reports. It is produced from the device, not from a lab bench, and it is far smaller than a full extraction.
There are two usual routes. An examiner connects the phone with USB debugging turned on and collects the report directly. Or the owner collects it remotely: SectraTEK Quick Capture lists the five steps to turn on USB debugging and then detects the phone, guiding the owner through collecting the files from their own Android phone. Either way, the result is a file the examination can reference where it is stored.
SectraTEK recognizes the report from its content, so a renamed file still works. It is opened read-only and is not copied into the product. A SHA-256 hash of the evidence is recorded in the case before analysis starts, and a final check near the end confirms the evidence still matches.
What the evidence shows, and what it cannot
A bug report is a snapshot of the phone as the system describes it. That is its strength and its limit.
It shows which apps are installed, with their permission state, and it shows how the device identifies itself: the Android release, the build and the Security Patch Level. It shows the settings the system reports, such as developer and debugging options. It carries the logs the phone retained, and SectraTEK reports the dates those logs cover.
It does not show the phone’s data stores. There is no message content in it, no browsing history and no documents; SectraTEK’s document and attachment examination applies to backups and file systems, not to this evidence. Settings that are held only in those stores cannot be read from it, and SectraTEK says so: controls the evidence cannot establish are left out of the score, and settings held only in the device’s databases appear as not reconstructed, not as failures. If a log section is missing from a bug report, that source simply shows zero records. Nothing is fabricated.
Then there is the limit that applies to every device examination. Zero-day and memory-corruption attacks can leave few lasting traces, and a result with no findings is not proof that a device was never attacked. Android logging varies by phone and release, and it has been a constraint for investigators before. In 2021, Amnesty Security Lab’s forensic examination of 67 phones included 15 Android devices; OCCRP reported that Android phones do not log the kinds of information that work relied on, and that three of the Android phones still showed signs of targeting[S2]. Evidence is evidence even when it is thin. The skill is in stating what it can support and what it cannot.
Describe this figure
Schematic. On the left, what an Android bug report holds: normalized logs, crash and not-responding records, installed apps and permissions, device identity with Android release and security patch level, and system-reported settings. Message content and the phone's data stores are marked as not present. On the right, the five engines that read it.
What we look for
The Lab reads a bug report for five kinds of signal.
Apps and the access they hold. SectraTEK brings each installed app together with the sensitive capabilities it can reach, including camera and microphone, and shows how the app was installed where the device recorded it. Every permission record is tied to its app and shown with its recorded state, so you can tell what an app was able to reach and decide whether it used it. Each app gets a Low, Medium or High review priority that tells you where to look first. A bug report on its own carries less installation detail than a full extraction, so SectraTEK is conservative about which software it treats as part of the phone’s own image, and a fuller acquisition of the same device resolves the question.
Device security configuration. SectraTEK reconstructs the recoverable configuration: screen lock, updates, developer and debugging options and privacy settings. Only settings the evidence establishes are assessed. The configuration score and evidence coverage are read together, so you see how the device is set up and how much of it the evidence covers. A setting to review is a hardening recommendation, not an accusation.
Crash and system logs. The logs the phone retained are normalized so they can be read, with the period they cover stated. Crashes and not-responding records are part of the picture.
Known-bad indicators. What the report contains, such as apps, certificates, files, domains and addresses, is compared with SectraTEK Intelligence, and every exact match is reported with its family and context. A result with no match is reported with the coverage behind it, so you can state exactly what was compared.
Vulnerability exposure. The Android release and Security Patch Level recovered from the report are compared with vendor security releases and known-exploitation context. Technical exposure and known exploitation are shown separately, so you can state exposure precisely. Where the evidence holds little version detail, the result says so. CISA’s Known Exploited Vulnerabilities catalog lists 17 entries under the vendor Android as of October 21, 2026[S1], covering platform and Pixel components; entries for Chromium, Samsung and chipset vendors are counted separately.
Five of the eight engines read an Android bug report. Insight adds ranked leads for activity that does not fit the apps and identities the device records. The others need evidence a bug report does not contain.
Our approach
How SectraTEK approaches this
The Lab treats a bug report the way it treats every evidence type: as a statement the phone made about itself, to be checked, not believed.
The device’s identity comes from the evidence, and conflicting values are kept rather than silently overwritten. The examination makes no outside contact, which keeps results reproducible. Each check reports whether it had the evidence to run, and when a comparison cannot complete, SectraTEK tells you rather than showing a partial result. Anything that cannot be decided is reported as such, never as clean.
That candor is what makes a thin evidence type usable. A report that says this setting could not be established from a bug report is a report a reviewer can trust, and it tells the client exactly what a fuller acquisition would add. SectraTEK reports what it compared and what matched; the examiner draws the conclusion.
Describe this figure
Flow in four steps: the bug report is referenced in place and hashed; five engines read it and settings it cannot establish are shown as not reconstructed; results are rated Critical, High, Moderate, Low or No match; the AI-Dossier carries the findings, leads, intelligence matches, limits and the integrity record.
From findings to a report you can act on
The AI-Dossier carries the whole examination to the AI tool you choose: the findings with the examiner’s dispositions, Insight leads, threat intelligence matches, exposure and security configuration results, permission correlation, the processing record and the evidence integrity history. Evidence references stay with the AI-Dossier: every file in it is listed with its hash, and its instructions ask the report to tie each material statement to the records behind it. The AI-Dossier opens with a readable cover that names the evidence examined, what it can and cannot establish and the key figures of the case.
Ratings are words, so the page reads the same without color: Critical, the strongest evidence, where you start; High, strong evidence worth immediate review; Moderate, a signal worth a second look; Low, context or ordinary activity, noted for completeness; and No match, a neutral result shown with its coverage.
The AI-Dossier asks for an executive report that a senior executive, general counsel or board member can read in minutes, with the technical depth placed behind it in appendices. For a bug report, the next steps are practical. If the Security Patch Level falls inside a published vulnerability scope, install the update. If an app holds access out of proportion to its purpose, review it. If a developer or debugging option is on without a reason, switch it off. And where a lead stays open, the report recommends the evidence that would settle it: an advanced Android acquisition, or a full file system.
Who it is for, and how it fits
A bug report examination is for labs and consultancies that need a fast first look for a customer, and for corporate security teams checking Android phones that cannot be extracted: devices in the field, devices owned by people who will not hand over the phone, and devices where the question is is anything obviously wrong rather than what happened last March.
It sits at the light end of the Android evidence types, next to the advanced acquisition and the full file system, which carry progressively more. SectraTEK sits between the security apps you install on your own device and a comprehensive digital forensic examination, a more thorough check for compromise than an on-device scan without the cost of a full examination. The same engines run on the same intelligence in SectraTEK Full and SectraTEK Lite: Lite keeps the results. Full keeps the case.
No findings means no known indicators were found in the evidence provided. For a bug report, the AI-Dossier says precisely what that evidence was.
Sources
Facts about third parties are attributed to the publisher named in the sentence. Each marker such as [S1] opens its row here.
| Marker | Publisher and title | Published | Accessed | Address |
|---|---|---|---|---|
| [S1] | CISA Known Exploited Vulnerabilities Catalog | www.cisa.gov | ||
| [S2] | OCCRP (reporting on the Amnesty Security Lab review) The Pegasus Project: Israeli-made spyware used to monitor journalists and activists worldwide | Address not listed |
The sources were last read on . If a fact here changes, the correction carries its date.