OnePlus 8T Wireless Security and AI Field Guide

简体中文 detailed edition · English concise edition

Move from running tools to understanding systems, protocols, evidence, and models—using one real phone as the laboratory.

This is a human-edited concise edition. It follows the same learning model and safety boundaries as the more detailed Chinese guide, but it does not claim paragraph-by-paragraph parity. Check the translation status when citing it.

What mastery means here

After completing the labs, you should be able to:

• draw a request from an Android app through VPN routing, Wi-Fi, DNS, TCP, TLS, and a remote API;
• distinguish Android root, SELinux, app UIDs, Linux capabilities, and the simulated root view inside PRoot;
• investigate failures using RSSI, routes, resolver behavior, packet captures, and Android logs;
• state what this phone can do, why it can do it, and where radio, driver, kernel, or service policy imposes a hard limit;
• inspect an app you own or are authorized to test, using both static structure and narrowly scoped runtime observation;
• use an LLM to form falsifiable hypotheses without confusing fluent output with evidence;
• preserve commands, timestamps, versions, hashes, counterexamples, and rollback notes.

The learning loop is deliberately small:

flowchart LR
    O["Observe"] --> H["Form mutually exclusive hypotheses"]
    H --> E["Change one variable"]
    E --> V["Collect evidence"]
    V --> R["Review facts, inferences, unknowns"]
    R --> O

Authorization and safety

Use the material only with:

1. your own OnePlus 8T, router, computer, and accounts;
2. an isolated lab SSID or VLAN;
3. an app you built, a training app, or a CTF;
4. a target covered by explicit written authorization that defines scope and time.

Do not practice against strangers, public Wi-Fi users, production accounts, payment apps, or infrastructure outside that scope. Root, USB gadget changes, app instrumentation, certificate changes, and flashing can destroy data or weaken the device. Read first, back up, identify rollback, change one thing, and verify the result.

Part I — Know the platform

1. Verified baseline

The following describes the actual platform on 2026-08-07, not a promise about every OnePlus 8T:

The hardened resting state has no Magisk modules, no system-wide user-CA promotion, no Conscrypt APEX overlay, and no DNS mount. Frida is stopped when unused. Model credentials live in a private mode-0600 file. Local Happy services listen on loopback, not the LAN.

2. Five kinds of “power”

flowchart TB
    HW["Hardware: Wi-Fi / USB / NFC / BLE"] --> K["Android Linux kernel: drivers / SELinux / capabilities"]
    K --> A["LineageOS: framework / app sandbox / VpnService"]
    K --> M["Magisk: Android root and boot stages"]
    A --> T["Termux: app UID"]
    T --> P["PRoot: syscall and path translation"]
    P --> KL["Kali user space: glibc / Python / tools"]
    A --> VPN["VPN/TUN: routes and DNS"]
    M --> F["Frida server: root, on demand"]

• Android root: Magisk su can obtain UID 0 and the capabilities granted to its domain.
• PRoot’s root prompt: a user-space illusion built on syscall interception; the host process remains a Termux app process.
• SELinux: a second access-control dimension; UID 0 does not mean every policy check disappears.
• Linux capabilities: operations such as raw packet sockets require specific kernel-granted capabilities.
• VPN authority: Android VpnService can redirect app traffic but is not kernel root.

This explains a common puzzle: Kali may contain tcpdump, yet opening a packet socket still fails because the Termux-hosted process lacks CAP_NET_RAW.

3. Five-minute health record

From the computer:

adb devices
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch
adb shell su -c id
adb shell settings get secure always_on_vpn_app
adb shell settings get secure always_on_vpn_lockdown
adb shell ip -brief addr show wlan0
adb shell ip -brief addr show tun0

From Termux/Kali, record tool versions and test a real DNS and HTTPS request. Do not “verify” a secret by printing it. Verify only that its file exists, has narrow permissions, and the intended API call works.

Part II — Linux, Android, and network fundamentals

4. Keep the three shells separate

pm belongs to Android, pkg to Termux, and apt to Kali. A command copied into the wrong layer can fail for the right reason.

Create an evidence directory for each lab:

LAB="$HOME/labs/$(date +%Y%m%d-%H%M)-topic"
mkdir -p "$LAB"/{notes,logs,pcap,artifacts}
date -Ins | tee "$LAB/notes/start-time.txt"
uname -a | tee "$LAB/logs/uname.txt"

Hash the final artifacts so another review analyzes the same bytes.

5. Trace one request by layer

sequenceDiagram
    participant App as Android app
    participant VPN as VPN / tun0
    participant DNS as Resolver
    participant TCP as TCP/IP
    participant TLS as TLS
    participant API as Remote API
    App->>VPN: Request a hostname
    VPN->>DNS: A / AAAA query
    DNS-->>VPN: Address result
    VPN->>TCP: Connect
    TCP->>TLS: Handshake
    TLS->>API: Encrypted HTTP
    API-->>App: Encrypted response

Lab A — Link, route, DNS, application

adb shell cmd wifi status
adb shell ip -brief addr show wlan0
adb shell ip route
adb shell ip -brief addr show tun0

Then, inside Kali:

cat /etc/resolv.conf
getent ahostsv4 example.com
dig example.com A
curl -I --max-time 10 https://example.com/

Interpretation:

• association failure belongs to the link layer;
• no default route is not a DNS failure;
• a resolver failure does not prove TLS is broken;
• successful name resolution plus a connection timeout points toward routing, policy, or transport;
• a TCP connection followed by a certificate error moves the investigation to TLS.

A VPN status screen is not evidence that all four layers work. Use routes, a real lookup, and an application request.

Lab B — Understand a loopback socket

In one Kali terminal:

python3 -m http.server 8765 --bind 127.0.0.1

In another:

curl -v http://127.0.0.1:8765/
ss -ltnp | grep 8765

Identify the listening address, port, and process. Changing the bind address to 0.0.0.0 expands exposure; local services should remain on loopback unless the lab explicitly requires LAN access.

6. Packet capture without pretending PRoot is privileged

Use one of these evidence sources:

1. Wireshark on an authorized test AP or external computer;
2. an Android VPN-capture app for traffic generated by the phone;
3. an existing PCAP copied into Kali and inspected with tshark -r.

Prefer connect scans such as nmap -sT -Pn in PRoot when the owned target and scope permit it. Do not assume raw SYN scans work without raw-socket capability.

Part III — Wireless networking from radio to protocol

7. Build the layer model first

flowchart TB
    RF["Radio: channel / noise / RSSI / SNR"] --> MAC["802.11: management / control / data frames"]
    MAC --> AUTH["Authentication and association"]
    AUTH --> SEC["WPA2/WPA3 key establishment"]
    SEC --> IP["DHCP / ARP / IPv4 / IPv6"]
    IP --> APP["DNS / TLS / application"]

Lab C — Make a signal map

On your own AP, choose five repeatable locations. At each location, take three readings of RSSI and link speed while keeping orientation and AP placement documented. Report median and variation rather than one exciting number.

Ask:

• did RSSI change while throughput stayed stable?
• did channel width or band change?
• is the observed variation larger than the location effect?
• what evidence would reject “distance caused it”?

8. Read 802.11 state instead of treating Wi-Fi as Ethernet

Use a capture produced by your own AP or an external adapter that supports monitor mode. Identify Beacon, Probe, Authentication, Association, EAPOL, and Deauthentication frames. Build a timeline; do not transmit disruptive frames.

The phone’s built-in adapter does not gain monitor mode or injection merely because Android is rooted. Chipset, firmware, driver, kernel configuration, interface mode, and user-space tooling all have to support the operation.

9. Understand the WPA2 four-way handshake

The handshake demonstrates possession of key material; it does not transmit the Wi-Fi password in cleartext. In an isolated lab using your own known passphrase, inspect EAPOL message order and confirm why offline verification can test a candidate without revealing an arbitrary strong passphrase.

The useful defensive conclusion is to choose a long, unique passphrase, prefer WPA3 when the complete client ecosystem supports it, disable obsolete compatibility modes, and investigate unexpected management-frame patterns.

10. BLE, NFC, and SDR are different systems

• BLE scanning observes advertisements, not every private application payload;
• NFC reading depends on tag technology, protocol, distance, and authorization;
• SDR requires suitable radio hardware and often an external adapter; software installation does not add a receiver front end.

Keep claims narrow: “the phone can enumerate advertisements” is not “the phone can sniff all nearby Bluetooth traffic.”

Part IV — Android app security and runtime observation

11. Start from the security model

flowchart TB
    APK["APK: code / resources / manifest / signature"] --> UID["App UID"]
    UID --> SB["Linux DAC + SELinux sandbox"]
    SB --> IPC["Binder / intents / providers"]
    SB --> NET["Network Security Config / TLS"]
    SB --> KEY["Keystore / file encryption"]

An APK signature protects update and publisher continuity; it does not certify that the code is safe. Root crosses many app-sandbox boundaries, but SELinux, hardware-backed keys, and server-side validation may remain relevant.

12. Case study — a Google Play message was not a Wi-Fi failure

The Play-distributed Happy app displayed a Play Store licensing error on this Google-free LineageOS device, while other phones on the same Wi-Fi worked. The decisive evidence came from the foreground activity and logcat:

adb shell dumpsys activity activities | grep -m1 mResumedActivity
adb logcat -d | grep -iE 'pairip|license|play store|happy'

The foreground moved into a PairIP license activity and the device lacked Play Store support. Changing DNS would not address that dependency.

A preview flavor built from a pinned, reviewed upstream commit removed the distribution wrapper, but account creation then failed with a second, unrelated error:

CLEARTEXT communication to 127.0.0.1 not permitted by network security policy

The narrow fix was a preview-only Network Security Config:

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="false">127.0.0.1</domain>
        <domain includeSubdomains="false">localhost</domain>
    </domain-config>
</network-security-config>

This permits loopback cleartext for the local preview service while continuing to reject arbitrary external HTTP. Success required real /v1/auth, session, machine, and feed requests returning 200—not merely an app home screen.

The public repository does not distribute the locally signed APK. Reproduction starts from a pinned upstream commit, records the build environment and patch, signs locally, and records the resulting SHA-256 outside the repository.

13. Static observation

For an owned or explicitly authorized package:

PKG=com.example.training
adb shell pm path "$PKG"
adb shell dumpsys package "$PKG" | less
adb shell cmd package resolve-activity --brief "$PKG"

Review exported components, permissions and protection levels, deep links, backup and cleartext policy, debug status, target SDK, and split APK layout. The advanced output is a data-flow map: input → trust boundary → sensitive operation → output.

14. Narrow runtime observation with Frida

Start a version-matched server only for the lab and bind it to loopback:

su -c '/data/adb/frida/frida-server -l 127.0.0.1:27042 -D'
su -c 'ss -ltnp | grep 27042'

Connect from Kali, perform read-only enumeration, and stop the daemon when finished:

frida-ps -H 127.0.0.1:27042
objection -N -h 127.0.0.1 -P 27042 -n com.example.training start
su -c 'pkill -x frida-server'

Do not expose the server on 0.0.0.0 or leave it world-readable in a shared temporary directory. A good first hook records an original return value without changing it. This distinguishes an observation failure from a behavioral modification.

15. Scope TLS trust to the app and build

For source you own, use a debug-only Network Security Config and a dedicated debug CA. Android ignores debug-overrides in a non-debuggable release build. For an authorized app you cannot rebuild, a temporary, targeted runtime observation may be appropriate; stop it immediately afterward.

Do not promote all user CAs to system trust and do not overlay the Conscrypt APEX as a default method. Those approaches expand the MITM surface beyond the one app under test.

Part V — Magisk, the boot chain, and recovery engineering

16. Place Magisk on the timeline

flowchart LR
    BL["Bootloader"] --> BI["boot image / ramdisk"]
    BI --> MI["Magisk init"]
    MI --> PFD["post-fs-data: early and blocking"]
    PFD --> Z["Zygote / Android framework"]
    Z --> LS["late_start service"]
    LS --> BC["boot complete / counter reset"]

A value observed after boot-complete cannot prove it had the same value during post-fs-data.

17. Case study — safe mode and the misleading zero

The source-level decision can be simplified as:

boot counter threshold OR safe-mode property OR key combination

Patching the key-combination check before proving that branch was taken changed the wrong thing. The later observation bootloop=0 was not contradictory: the boot-complete stage can clear a counter that was nonzero earlier.

The useful experiment is a timestamped, read-only early-boot trace:

adb reboot
adb wait-for-device

for i in $(seq 1 45); do
  printf '%s boot_completed=' "$(date -Ins)"
  adb shell getprop sys.boot_completed | tr -d '\r'
  adb shell "su -c 'magisk --sqlite \"SELECT * FROM settings;\"'" 2>/dev/null || true
  sleep 1
done | tee magisk-early-boot.log

Also record safe-mode properties and module disable files. Compare timestamps and transitions; do not reconstruct a state machine from one final snapshot.

magisk --remove-modules is a destructive rescue path that removes all modules and reboots. It is not an ordinary diagnostic command.

18. A backup is proven by restoration

For every private backup, record what it restores, version, size, hash, encryption method, and a test that demonstrates the archive can be decrypted and parsed. Keep device-unique partitions, signing keys, and private service data outside the public repository. Never restore over a phone until target paths, ownership, and rollback have been checked.

Part VI — USB and physical interfaces

19. Understand HID as descriptors plus reports

In a controlled keyboard demonstration, Android configfs describes a USB HID function and the gadget sends keyboard reports. The host trusts the device because it identifies as a keyboard; no “exploit” is required.

That makes the lesson defensive: lock unattended hosts, restrict unknown USB peripherals, and distinguish USB charging from data mode.

20. Safe lab

Use only an owned test computer, focus a plain text editor, send a harmless fixed sentence, and include an emergency stop and restoration of the original USB gadget configuration. Never use credential prompts, shell launchers, downloads, persistence, or another person’s unlocked session.

Part VII — AI models as evidence assistants

21. A model predicts tokens, not truth

flowchart LR
    TEXT["Text / logs / code"] --> TOK["Tokenizer"]
    TOK --> EMB["Embeddings"]
    EMB --> ATT["Self-attention"]
    ATT --> LAYERS["Repeated transformations"]
    LAYERS --> NEXT["Next-token distribution"]

This architecture is useful for proposing hypotheses, explaining logs, drafting parsers, and organizing tests. It can also produce a polished false answer, inherit prompt injection from untrusted text, and ignore authorization unless you impose it.

22. OpenCode is a tool-call layer

On this device, the glibc arm64 OpenCode build runs inside Kali. A Termux wrapper enters PRoot, supplies configuration from private storage, and reaches the model API through the phone’s routing layer. This avoids depending on a Magisk DNS module.

The health test is not “the binary prints a version.” It includes resolver success, TLS/API success, correct secret-file permissions, and a minimal real model response.

23. Happy is a local UI, not proof of an end-to-end session

The local preview service binds to 127.0.0.1:3005 and starts only on demand. A connected label is useful, but the stronger evidence is server-side status for authentication and session APIs. APKs, signing files, and private service configuration remain private.

24. Give the model an evidence contract

Authorization: owned OnePlus 8T and isolated lab SSID
Goal: explain DNS failure without changing the device
Environment: LineageOS 21 / Android 14 / VPN routing / Kali PRoot
Observation: redacted original route, resolver, and request output
Constraint: read-only diagnostics only
Output: at most three mutually exclusive hypotheses; label facts,
inferences, and unknowns; give one falsification test for each

Every proposed action passes three gates:

flowchart LR
    M["Model suggestion"] --> A{"Inside authorized scope?"}
    A -- No --> STOP["Stop"]
    A -- Yes --> R{"Reversible and single-variable?"}
    R -- No --> SMALL["Reduce the experiment"]
    R -- Yes --> E["Execute and collect evidence"]
    E --> C{"Evidence supports it?"}
    C -- No --> H["Revise hypotheses"]
    C -- Yes --> D["Document with counterexample"]

Never delegate authorization, secret handling, irreversible flashing, autonomous exploitation, or unreviewed root commands to a model.

Part VIII — Projects and a 12-week path

25. Nine progressive projects

26. Schedule

• Weeks 1–2: shells, permissions, PRoot limits, and a health report;
• Weeks 3–4: TCP/IP, routes, DNS, TLS, RSSI, and an owned capture;
• Weeks 5–6: 802.11 frame types, EAPOL state, and defensive anomaly timelines;
• Weeks 7–8: manifest trust boundaries, read-only instrumentation, and app-scoped TLS debugging;
• Weeks 9–10: boot stages, safe-mode evidence, backup and restoration drills;
• Weeks 11–12: evidence contracts, model counterexamples, and one publishable postmortem.

Mastery is not the number of installed tools. It is the ability to explain why -sT may work where -sS does not, why certificate installation does not imply app trust, why a version match does not guarantee Frida attachment, why a final counter value cannot reconstruct early boot, and how to reject a confident model answer cheaply.

Part IX — Daily checklist and failure tree

27. Start narrowly, stop what you started

Start only the component required by today’s lab. Stop local AI services and Frida afterward. Record listeners before and after:

ss -ltnp
su -c 'pidof frida-server || true'

28. First evidence, not first workaround

29. Designs deliberately removed

• globally promoting all user-installed CAs;
• overlaying the Conscrypt APEX with tmpfs;
• using a Magisk DNS mount for OpenCode;
• leaving Frida world-readable or persistent;
• storing model keys or tunnel URIs in documentation or shell history;
• installing unverified wheels, APKs, or binaries;
• patching Magisk merely because a hypothesis sounds plausible.

Completion record

Finish each project with the experiment template and a postmortem when a hypothesis fails. When you can consistently produce a report that separates evidence from inference and survives a counterexample, you are doing security engineering rather than merely running scripts.

Primary references

• Magisk documentation
• PRoot-Distro
• Frida on Android
• Android Network Security Configuration
• OWASP Mobile Application Security
• Wireshark display filters
• Happy source