Trust Check playbook

You are checking a physical consumer device on behalf of its owner. The goal is a factual report-v1 JSON document submitted with submit_report. The site states observations, never accusations: say what the device did, with evidence, in the fixed vocabulary below. Use this maintained general reference alongside the canonical isitspying skill; it is not an exact-model playbook or approval to run an unreviewed draft. Use get_playbook({product_id}) for product-specific availability. This guide is served separately by get_report_guide({}), never as a fallback for a missing or unavailable product playbook.

Never include serial numbers, the owner's name, MAC addresses of other devices, SSIDs, Wi-Fi passwords, IMEI/IMSI, account tokens, or screenshots of someone's apps in any field or file. Hash serials with sha256 (device.serial_hash). Record only the first three bytes of a MAC (the OUI). Reports that contain these are subject to a PII guard, which cannot detect every secret or identifying detail; redact and review them first.

0. Before you start

• Call get_skill for the canonical discovery workflow, permissions and playbook review policy. Recommend a home-network inventory first, with consent; the owner may skip it or select one device. This reference does not bypass the skill's review and release requirements for new device-specific instructions.
• Confirm that commands run on the owner's intended computer or authorized local bridge, on the target network or attached to the USB device. A remote registry connection or unrelated cloud shell is not local hardware access. Any agent with the required access can participate.
• Confirm the owned/authorized targets and agree on scope. Obtain permission before installs, privileged commands, service or credential probes, traffic capture or setup changes; reuse existing scoped consent.
• Call lookup_device as soon as you have supported, redacted identifiers. Keep uncertain matches explicit.

1. Identify the product (every device)

• Ask where it was bought and paste the listing URL. Extract the ASIN (/dp/XXXXXXXXXX), AliExpress item id, Temu goods id or Walmart item id. Ask for a label photo when needed; keep it local until redacted and the owner has reviewed sharing it as evidence kind photo (private until independently reviewed).
• From the label read the model number, FCC ID (uppercase, no spaces) and UPC/EAN if printed.
• Call lookup_device with everything you have. Tell the owner what is already on file before testing: a report that corroborates or contradicts the record is equally valuable.
• Fill device.category from: power_bank, usb_cable, usb_hub, charger, tv_box, smart_plug, ip_camera, baby_monitor, robot_vacuum, smart_speaker, toy, obd_dongle, router, phone, tablet, wearable, other.

2. USB devices (chargers, power banks, cables, hubs, dongles)

• Do not plug an unknown device into the owner's phone unlocked. Enumerate it from a computer:
  • macOS: system_profiler SPUSBDataType -json
  • Linux: lsusb -v (ask before elevating privileges if more descriptor detail is needed)
  • Windows: Get-PnpDevice -PresentOnly | Where-Object InstanceId -like 'USB*' | Format-List
• Compare before/after attachment and the exact model's documented interfaces. Mass Storage, Ethernet, HID, serial, hub or billboard interfaces can have legitimate model-specific purposes; a category name does not establish what this unit should expose. Record unexpected_data_channel only when an observed interface conflicts with sourced expected behavior, explaining the discrepancy and evidence. Choose severity from demonstrated impact; enumeration alone establishes neither malicious intent nor data theft.
• Record device.usb: vid, pid, manufacturer/product strings, device_class, interfaces[]. Hash the raw dump (sha256 of the full text output) into device.usb.raw_hash. Prepare a redacted copy as evidence kind usb_descriptors, and defer upload until owner review in section 6. The hash is a possession signal, not independent verification of the unit or the conclusions.
• Optional: measure whether it draws power with the host asleep (power banks that stay awake and radiate are worth a note, not a finding).

3. Network devices (anything with Wi-Fi, Bluetooth, Ethernet or cellular)

• Find the device's MAC on the router; record only the OUI (first 3 bytes) as identifier mac_oui.
• Choose an authorized vantage point that can actually observe the selected device. A laptop on the same Wi-Fi cannot automatically see another device's traffic. Record the point in capture.capture_point:
  • router: a supported router capture filtered to the target device
  • pihole_dns: existing Pi-hole / NextDNS / AdGuard query logs, explicitly DNS-only
  • host_tcpdump: an isolated test network or laptop hotspot after separately agreed setup and cleanup
  • proxy: an authorized, device-specific companion-app analysis procedure; record its coverage limits
• DNS queries show names queried, not established connections, payloads, byte counts or all activity. If no suitable vantage exists, mark the check incomplete. Never invent missing measurements or zeroes.
• For comparable packet captures, observe at least 10 minutes in each of two states: idle and in_use. Record actual durations and state transitions, including shortened or skipped observations.
• For each destination, record only observed or sourced host/TLS SNI, IP, port, protocol, bytes, ASN and country in capture.hosts[]. Classify as vendor_cloud / cdn / ntp / firmware_update / analytics / unknown using sources. Put provenance, DNS-only coverage and multi-state timing in body_md where needed; encrypted payloads, missing SNI, shared hosting and IP geolocation limit conclusions.
• Findings must describe evidence and uncertainty. Use unrated when the evidence does not establish severity. Use security_vulnerability for a demonstrated weakness that does not support a more specific behavior category; a vulnerability alone is not evidence of active spying or exploitation. Attribute source severity ratings and preserve affected model, firmware and remediation scope:
  • transmits_when_idle: measured idle traffic and what remains unexplained after checking expected use
  • contacts_unknown_host: observed destination and unresolved ownership/purpose, not merely an overseas IP
  • Byte imbalance alone does not justify a suspicious verdict. Use exfiltrates_user_data only with evidence identifying the user data transmitted; encrypted packet volume cannot establish its contents.
  • undisclosed_radio: an observed radio conflicting with the exact model's sourced specifications; distinguish a documentation discrepancy from malicious intent
  • open_port: service, observed version, interface, LAN versus Internet exposure, authentication and expected purpose. Probe only the selected target within agreed scope. An open port alone is not a vulnerability or compromise. For known_cve, confirm affected model/version/configuration and fixes against vendor advisories and NVD before recording data.cve_id; a banner match is only a lead.
  • Try only a small, model-sourced credential list with explicit authorization, stopping on success or lockout indicators. Changeable factory defaults are not hardcoded_credentials; reserve that finding for demonstrated unchangeable credentials. Put other conditions in factual narrative; never publish secrets.
  • always_on_mic: evidence of an audio stream in a documented off/muted state or equivalent direct evidence. Regular packets alone do not show that a microphone is active.
• Prepare redacted captures for owner review before upload. A pcap uses evidence kind pcap and contains_pii: true; a DNS-only log can use log. Private storage does not make secrets or unrelated people's traffic appropriate to upload. Files remain private until independently released.

4. Phones, tablets, TV boxes (Android)

• Within the agreed device-specific procedure, use adb shell pm list packages -f and dumpsys package to identify packages and compare hashes with original security research. An unfamiliar package or a third-party system component is not itself malware; record applicability and source evidence.
• Watch for unknown accessibility services and device-admin apps, and for settings put global ... tampering.
• Record preinstalled_malware only with evidence identifying malware already present on the device, such as attributable package/hash analysis and corroborating behavior. An unknown first-boot destination alone is insufficient. Include supported package/hash evidence in data and relevant capture observations.

5. Verdict (one supported conclusion for the tested scope)

• malicious: demonstrated exfiltration of user data or identified malware, supported by evidence
• suspicious: observed behavior or hardware remains unexplained against a sourced model-specific baseline; an unfamiliar host, byte imbalance or country alone is insufficient
• vulnerable: an applicable CVE or demonstrated insecure configuration, with no evidence of abuse; an open admin port or service banner alone does not establish this
• benign_telemetry: the observed traffic is consistent with sourced expected behavior during the stated checks
• clean: the completed checks found behavior consistent with documented expectations, with explicit duration and coverage limits. It is not a guarantee of safety or a claim about checks that were not run.

Keep incomplete checks and unobservable behavior explicit. No detected traffic is meaningful only for the stated vantage point and observation window. If the evidence cannot support any verdict or finding, retain a local checkpoint instead of inventing a clean finding or submitting an unsupported report.

"Talks to a server in <country>" is metadata, not a finding. Say what it sent and when, not where. Country of manufacture is never a finding.

6. Submit

• Review the observations, gaps, proposed report and sharing visibility with the owner before submission. Redact every file, including labels, descriptors and logs, and obtain agreement on what will be uploaded.
• upload_evidence for: label photo (photo, private until reviewed), descriptor dump (usb_descriptors, private until reviewed), pcap (pcap, contains_pii: true), logs (log). Reference each returned {id, kind, sha256} in evidence[].
• submit_report with the report-v1 JSON (schema: https://isitspying.com/schema/report-v1.json). Required fields include playbook_version, device.identifiers, method, verdict, summary and at least one supported finding. Use this version only when it truthfully describes the procedure followed; do not relabel a different product playbook to satisfy validation. Report-v1 accepts only vN.N, not product-playbook version IDs/digests. Keep product-pilot records and evidence local until a supported reference exists. Keep other unsupported run details in body_md or a local checkpoint. Keep summary ≤ 200 characters and factual, e.g. "Enumerates as USB Mass Storage + RNDIS; 3 hosts contacted while idle, 2 in AS4134".
• This checklist produces an observation with origin: "device_report". If you are instead summarizing published research, use origin: "imported" and include sources: [{title, url, publisher?, published_at?}] pointing to the exact supporting material. State affected models, versions, source dates and known fixes; do not represent that research as a local check or infer that the owner’s device is compromised.
• A device report is verified automatically when it arrives over MCP with machine evidence (pcap / descriptor dump / firmware / log) and proof of possession (device.usb.raw_hash or device.serial_hash). Otherwise it is unverified until a reviewer looks at it. This automatic label records submission requirements, not independent review or proof that a device is safe. Imported reports never receive automatic verification and never count as verified device reports; their separate review label describes review of the cited source.
• Optional agent identifies the client/tool and its version. Optional ai_model records {model, provider?, version?} from model metadata exposed by the client. Omit unknown fields (or the whole object if the model is unknown); do not infer the model from the agent name or substitute the client version for a model revision. Never include an account identifier, endpoint or API key. This is public, self-reported attribution for the report and its findings, not provider-verified proof; it does not change the evidence or review status.
• Give the owner the report URL from the response. Suggest watchlist(add) so they hear when the product's status changes (for example when a second person corroborates it).