Void — Open-source AI Pentesting Agent

Understood. This assessment starts with offline static analysis of the firmware; no physical device is connected. I will confirm the sample structure and authorization boundary, then split the update chain, system services, debug interfaces, and component communication into parallel tasks.

$ ls -la "analysis/firmware" 2>/dev/null
file "analysis/firmware" 2>/dev/null

component-a.bin
component-b.bin
component-c.bin
header.json

analysis/firmware: directory

Seven analysis tasks are created and parallel analysis has started. The review follows these areas:

• Update chain: map software-origin checks, integrity checks, and update entry points.
• System services: read startup configuration, service definitions, and executable-component information.
• Interface boundaries: inspect code and configuration for debug capabilities, component calls, and authorization constraints.

$ S="analysis"
echo "=== component-a build.prop ==="
grep -E "ro.build.tags|ro.build.type|ro.debuggable|ro.build.fingerprint|security_patch|ro.product.device" "$S/containers/component-a/fs_root/build.prop"
echo "=== component-c build.prop ==="
grep -E "ro.build.tags|ro.build.type|ro.debuggable|ro.build.fingerprint|security_patch|ro.product.device" "$S/containers/component-c/fs_root/build.prop"

=== component-a build.prop ===
ro.build.type=userdebug
ro.build.tags=test-keys
ro.product.device=component-a
# ro.build.product is obsolete; use ro.product.device
=== component-c build.prop ===
ro.build.type=userdebug
ro.build.tags=test-keys
ro.product.device=component-c
# ro.build.product is obsolete; use ro.product.device

Initial inventory is complete, with five attack surfaces registered. The review currently prioritizes the firmware update chain and system services, using offline inspection of the filesystem, startup configuration, and executable components.

Two priority review areas

• Firmware update chain: trace each update entry point through the code and map coverage of origin and integrity checks.
• System services: trace declared privileges through startup scripts and service configuration, then inspect maintenance, debugging, and component-call code.

$ UP="analysis/containers/component-a/fs_root/bin/update-service"
r2 -2 -q -c 'af @ update_handler; s digest_check; pd 70' "$UP" 2>/dev/null

    add x0, sp, 8
    …
    bl sym.imp.strncmp
    …
┌─< cbz w0, match_branch
│   …
│   bl debug_log
│   mov w21, -1
┌──< b merge_branch
    …

$ cd "analysis/certificates"
openssl pkcs7 -inform DER -in package/META-INF/CERT.RSA -print_certs 2>/dev/null | openssl x509 -pubkey -noout 2>/dev/null > package-public.pem
openssl x509 -in trust/testkey.x509.pem -pubkey -noout 2>/dev/null > trusted-public.pem
cmp package-public.pem trusted-public.pem && echo "PUBKEY IDENTICAL (CERT.RSA signer == otacert testkey)" || echo "PUBKEY DIFFER"

PUBKEY IDENTICAL (CERT.RSA signer == otacert testkey)

Static review of the update chain found a priority issue: authenticity checks in the code do not cover the full chain. Relevant code and configuration evidence is saved while rollback logic and external-media update entry points are reviewed.

F-01 is registered. The static evidence indicates an incomplete chain of origin and integrity checks. The record includes evidence locations, potential impact, and conditions that require device validation.

Next, compare validation policies across entry points and organize differences between external-media updates and the primary update chain.

Static review of system-service and debug configuration is complete. Some maintenance-service and debug code in the sample includes privileged operations; reachability on a physical device still requires validation against startup conditions and release configuration.

$ R="analysis/containers/component-c/boot/ramdisk"
sed -n '880,915p' "$R/init.rc"

    user root
    group root system

on property:ro.debuggable=1
    start console

# adbd is controlled via property triggers in init.<platform>.usb.rc
service adbd /runtime/sbin/adbd --root_seclabel=u:r:su:s0
    class core
    socket adbd stream 660 system system
    disabled
    seclabel u:r:adbd:s0

# adbd on at boot in emulator
on property:ro.kernel.qemu=1
    start adbd
…

The related Findings are registered. They retain capability boundaries indicated by code and configuration, potential impact, and review recommendations, with static evidence accessible from the board.

Static analysis of component communication identified a potential lead: caller-identity constraints on some internal interfaces need further review. The available code evidence does not establish actual reachability or the complete authorization chain, so F-05 remains a lead pending dynamic validation.

$ F="analysis/containers/component-c/fs_root"
for n in service-a update-service service-supervisor; do
  echo "==== $n ===="
  r2 -q -e bin.demangle=false -c "ii~bind;ii~listen;ii~accept;ii~socket;ii~connect;ii~inet" "$F/bin/$n" 2>/dev/null | head -30
done

==== service-a ====
nth bind   type lib name
61  GLOBAL FUNC     net_bind
42  GLOBAL FUNC     net_set_socket_noblock
==== update-service ====
nth bind   type lib name
==== service-supervisor ====
nth bind   type lib name

The component-call summary retains the inspected code paths and unresolved conditions. Offline analysis alone does not establish this lead as a reproduced access-control vulnerability.

Next, consolidate task records and the evidence index, separating static evidence, potential impact, and conditions that still require device validation in the report.

$ R="analysis/session/security-report.md"
echo "exists: $([ -f "$R" ] && echo yes || echo no)"
echo "size: $(stat -f%z "$R" 2>/dev/null)"
echo "first lines:"
head -6 "$R"

exists: yes
size: 8848
first lines:
# 安全挖掘报告：离线固件样本

## 范围

- **目标**：`analysis/firmware`（component-a / component-b / component-c 与 header.json）。
- **授权**：设备自有/书面授权，全面离线逆向；无实体设备，无网络外联，无真实设备动态验证。授权与源材料已写入 run-manifest。

Archive complete. All 7/7 offline analysis tasks are complete, with 18 Findings recorded: 4 critical, 7 high, and 7 medium. Fourteen records have completed static review, while four remain pending dynamic validation. No physical-device validation was performed.

Finding summary (5 representative records)

The table matches the representative records on the right. Open a Finding to read its impact notes, evidence summary, and remediation guidance.

Human review

• Update-chain records retain static code, configuration, and certificate evidence for review of validation coverage and trust boundaries.
• System-service and debug records retain configuration context; reachability and impact still need review against a physical device and its release environment.
• F-05 is a potential lead with unresolved caller-identity and authorization questions; a conclusion requires dynamic validation.

The final report and evidence index are archived and available in Work artifacts.