Master Blackbox UE-to-Node Test Plan

BLUF

This plan is built on the view that mobility security has to be assessed as an operational system, not just as a handset problem. If the research starts and stops at the UE, it misses where trust actually shifts: the SIM identity boundary, the physical RF environment, the difference between small-cell and macro-tower behavior, the transport path, and the core or datacenter-hosted functions that ultimately deliver service.

From an OT perspective, the mobility network should be examined the same way other critical infrastructure is examined: as a chain of field assets, control functions, dependencies, and failure points. That is why this approach stays blackbox and evidence-driven from UE outward, so physical-layer behavior, mobility events, core behavior, and operational visibility can all be investigated as parts of one end-to-end security system.

Purpose

This plan defines a blackbox mobility assessment path from the user equipment (UE) outward to each relevant node or trust zone:

1. UE / SIM / carrier-app layer
2. Physical layer, RF conditions, and serving / neighbor cell behavior
3. RAN, site, and mobility behavior across small-cell and macro coverage
4. Transport / backhaul / interconnect dependencies
5. Core control plane and hosted core / datacenter dependencies
6. Core user plane / data path
7. Detection and operational visibility

The goal is to produce a repeatable, evidence-driven test plan that matches the current lab reality:

• Current equipment: laptop, Pixel 9a
• Incoming equipment: LibreSDR
• Approach: blackbox-first
• Guardrail: passive-only on live networks; any active RF work stays inside a shielded, authorized lab with your own SIMs and devices

Blackbox operating model

This plan treats the target as a system observed from the outside. Tests focus on:

• externally observable behavior
• protocol outcomes and state changes
• privacy exposure
• fallback and resilience behavior
• logging and evidence generation

This plan does not assume source access, administrative access, or undocumented internal implementation details unless a case is explicitly marked as lab-only.

Current equipment assessment

Test waves

Trust-zone coverage

Architecture reference

These smaller views split the same intent into easier chunks: field-side exposure, transport and core dependency, and the OT-style assessment lens across the whole mobility system.

1. Subscriber edge to field infrastructure

flowchart LR
    UE["UE / app layer"]
    SIM["SIM / eSIM"]
    SC["Small cell"]
    MC["Large cell / macro tower"]
    RF["RF conditions\ncoverage · interference · neighbors"]
    RAN["DU / CU / baseband"]
    MOB["Mobility events\nhandover · reselection"]

    UE --- SIM
    UE -->|"air interface"| SC
    UE -->|"air interface"| MC
    SC --- RF
    MC --- RF
    SC --> RAN
    MC --> RAN
    RAN <--> MOB

2. Transport, core, and datacenter path

flowchart LR
    RAN["RAN / site operations"]
    FH["Fronthaul / midhaul / backhaul"]
    IP["Aggregation / routing / interconnect"]
    AMF["AMF / MME\nmobility + control"]
    AUTH["UDM / AUSF / HSS\nidentity + auth"]
    SMF["SMF / session control"]
    UPF["UPF / user plane"]
    OBS["Logs / telemetry / detection"]
    DN["Internet / IMS / enterprise services"]

    RAN --> FH --> IP --> AMF
    AMF <--> AUTH
    AMF <--> SMF
    SMF <--> UPF
    UPF --> DN
    OBS --- AMF
    OBS --- SMF
    OBS --- UPF

3. OT-style research lens

flowchart LR
    EDGE["Subscriber edge"]
    PHY["Physical / RF layer"]
    SITE["Tower / site operations"]
    TRANS["Transport / backhaul"]
    CORE["Core / datacenter"]
    DET["Detection / monitoring"]

    EDGE --> PHY --> SITE --> TRANS --> CORE
    EDGE -. user-visible symptoms .-> DET
    PHY -. field evidence .-> DET
    SITE -. operations evidence .-> DET
    CORE -. logs / telemetry .-> DET

Blackbox angle: the UE is still the starting point, but the assessment intent is broader: each arrow is a trust boundary, each field node or hosted function is a potential test target, and the security question is how behavior changes from the physical layer through the tower/site layer into the core and datacenter. The mobility-specific interfaces become most relevant when wave 3 and MBX-14/15 are reached.

4. Fiber-backed terrestrial carrier path

This view treats fiber as the primary terrestrial backbone behind towers, aggregation sites, and datacenters. From an assessment standpoint, the key question is how mobility behavior depends on the transport path behind the radio layer.

flowchart LR
    UE["UE"]
    TOWER["Small cell / macro tower"]
    SITE["Site router / baseband"]
    FIBER["Fiber backbone\nmetro · regional · long-haul"]
    POP["Aggregation POP / CO"]
    DC["Core / datacenter"]
    SVC["Internet / IMS / enterprise services"]

    UE --> TOWER --> SITE --> FIBER --> POP --> DC --> SVC

5. Satellite-assisted coverage and backhaul path

This view treats satellite as a gap-filler or resilience layer where fiber or dense terrestrial buildout is impractical. The research angle is how service quality, dependency, and failure behavior change when part of the path leaves the terrestrial network.

flowchart LR
    UE["UE"]
    CELL["Remote cell / deployable site"]
    GROUND["Ground gateway / teleport"]
    SAT["Satellite link"]
    CORE["Carrier core / datacenter"]
    SVC["Internet / mission services"]

    UE --> CELL
    CELL -->|"satellite backhaul"| SAT
    SAT --> GROUND --> CORE --> SVC

6. Hybrid carrier buildout lens

This hybrid view matches the practical carrier model: fiber carries most scale and low-latency transport, while satellite extends reach, continuity, or emergency coverage. A carrier such as AT&T can be studied through this lens by looking at fiber expansion, wireless site density, public-safety coverage, and how alternate backhaul paths affect operations.

flowchart LR
    subgraph ACCESS["Access layer"]
        UE["UE population"]
        SC["Small cells"]
        MC["Macro towers"]
    end

    subgraph TERRESTRIAL["Primary terrestrial path"]
        FIBER["Fiber transport"]
        POP["Aggregation / regional POP"]
    end

    subgraph EXTENSION["Coverage extension"]
        DEP["Deployable / remote site"]
        SAT["Satellite path"]
    end

    subgraph CORE["Hosted services"]
        DC["Core / datacenter"]
        OBS["Detection / operations"]
    end

    UE --> SC
    UE --> MC
    SC --> FIBER
    MC --> FIBER
    FIBER --> POP --> DC
    DEP --> SAT --> DC
    OBS --- DC

Evidence standard

Every executed test case should leave behind at least one of these:

• screenshot
• packet capture
• adb or terminal output
• phone-side observation record
• config excerpt from the lab
• pass/fail entry
• short note on expected versus observed behavior

Use this evidence record for each test:

Master test case matrix

Detailed test cases

MBX-01 - UE local baseline

Objective: establish the reference state of the Pixel 9a before protocol or mobility testing.

Blackbox angle: treat the handset as the only visible subscriber-side endpoint and capture what a normal user or authorized assessor can observe without altering network behavior.

Preconditions:

• Pixel 9a is stable and updated
• USB debugging is enabled if adb collection is used

Steps:

1. Record Android version, security patch level, baseband version, SIM/eSIM profile, carrier settings version, and connection mode behavior.
2. Record installed carrier apps, telephony-related apps, and visible network settings.
3. Capture screenshots and adb output for baseline fields.

Evidence:

• screenshots of network and SIM settings
• adb output for version and baseband details
• app inventory note

Pass criteria: a complete baseline exists and can be referenced in every later test.

MBX-02 - UE to carrier apps

Objective: identify externally visible carrier-app risk at the application layer.

Blackbox angle: test the app as a user-facing client without assuming source access.

Preconditions:

• your own device and accounts only
• a safe interception method for allowed test apps
• see MBX-02 & MBX-08 App Interception Toolkit for Frida + Burp setup

Steps:

1. Inventory carrier apps and exported components:

   adb shell dumpsys package com.att.personalcloud | grep -i "component\|permission"
   

2. Launch interception with Frida/Burp:

   ~/intercept.sh com.att.personalcloud
   

3. Observe network calls during login, activation, billing, support, and device-management workflows.
4. Note in Burp proxy console:
   • Certificate pinning status (unpinned vs. pinned)
   • Token handling and credential exposure
   • Telemetry volume and destinations
   • Weak security headers (missing HSTS, etc.)
   • User-facing security errors or validation failures

Evidence:

• Burp export (HTTP history XML or CSV)
• Frida interception log (injection status, unpinning results)
• Screenshots of app workflows and UI
• Device logcat capture during workflows
• Exported-component inventory (manifest analysis)
• Telemetry endpoint mapping

Pass criteria:

• Carrier app behavior is fully inventoried and traffic is captured
• No unexpected identifiers, weak trust paths, or overly broad app privileges are observed
• Pinning status is confirmed (system cert injection successful via Frida + adb reverse tunnel)
• Evidence is traceable to specific workflows

Reference: MBX-02 & MBX-08 App Interception Toolkit

MBX-03 - UE to SIM/eSIM posture

Objective: document what subscriber identity and service behavior are visible from the UE side.

Blackbox angle: inspect only subscriber-visible and device-visible identity surfaces.

Steps:

1. Record visible ICCID, operator name, PLMN, TAC-related observations, and SIM service behavior exposed to the device.
2. Note eSIM profile handling, profile switching behavior, and any OTA-related user-visible prompts or controls.
3. Record which identifiers are easy to retrieve locally and under what permission level.

Evidence: screenshots, device notes, adb output if used.

Pass criteria: identity and service exposure is understood and documented for later privacy cases.

MBX-04 - UE to serving-cell inventory

Objective: build a passive inventory of serving-cell behavior in the real environment.

Blackbox angle: passive-only observation using handset measurement tools.

Steps:

1. Use NetMonster, CellMapper, or Network Cell Info across several normal locations.
2. Record PLMN, PCI, TAC, EARFCN / NR-ARFCN, bands, RSRP, and whether the UE is LTE, NSA, or SA.
3. Repeat at multiple times of day when possible.

Evidence: screenshots and a simple location-based cell log.

Pass criteria: serving-cell behavior is repeatable enough to distinguish normal operation from later anomalies.

MBX-05 - UE to neighbor-cell and mobility mapping

Objective: map neighbor cells and natural mobility transitions.

Blackbox angle: rely only on externally visible handover and reselection behavior.

Steps:

1. Observe neighbor-cell listings while stationary and while moving.
2. Record PCI changes, TAC changes, signal degradation, and any mode changes between LTE and NR.
3. Build a short map of common routes and expected transitions.

Evidence: screenshots, route notes, time-stamped cell changes.

Pass criteria: expected mobility transitions are understood and can be replayed in future tests.

MBX-06 - UE to privacy and identity-exposure baseline

Objective: baseline identity-related exposure behavior by type and frequency, not just one message class.

Blackbox angle: observe privacy behavior through the handset and lab traces without assuming internal network implementation.

Steps:

1. Record whether the UE is on LTE, NSA, or SA during observations.
2. In the lab, compare clean registration traces across 4G and 5G where available.
3. Note when permanent versus temporary identity handling appears to change, especially during fallback or high-mobility conditions.

Evidence: handset notes, lab trace references, expected-versus-observed table.

Pass criteria: privacy behavior is characterized by scenario and not reduced to a single heuristic.

MBX-07 - UE to fallback path

Objective: observe how the UE behaves when preferred modes are unavailable or degraded.

Blackbox angle: passive observation of natural fallback only in live environments.

Steps:

1. Move through environments where signal quality naturally changes.
2. Record transitions between 5G and LTE, timing, user impact, and whether service continuity is preserved.
3. Note whether fallback correlates with changes in visible identity or cell-state behavior.

Evidence: timestamps, screenshots, application continuity notes.

Pass criteria: fallback behavior is bounded, understandable, and repeatable.

MBX-08 - UE to app data path

Objective: validate application-layer data-path trust from the handset outward.

Blackbox angle: test your own applications and traffic flows as a client.

Preconditions:

• see MBX-02 & MBX-08 App Interception Toolkit for Frida + Burp setup
• Burp Suite configured and listening on 127.0.0.1:8080
• ADB reverse tunnel established: adb reverse tcp:8080 tcp:8080

Steps:

1. Use intercept.sh to test approved apps with Frida/Burp:

   ~/intercept.sh com.gmail.android
   ~/intercept.sh com.uber
   

2. For each app, collect evidence:

   • Capture traffic in Burp HTTP history
   • Document certificate validation behavior (pinned vs. non-pinned)
   • Identify sensitive data in headers/payloads (IMEIs, tokens, location)
   • Note any weak TLS versions or unencrypted HTTP usage
   • Record device identifiers leaked in traffic

3. Separate apps by pinning status:

   • Non-pinned: traffic flows through Frida + Burp without intervention
   • Pinned: requires Frida unpinning scripts (verify in Frida console output)
   • Strongly pinned: may refuse connection even with Frida (e.g., Google apps)

4. Test telemetry and background network behavior:

   • Monitor traffic during app idle time
   • Capture DNS queries for telemetry destinations
   • Note whether telemetry can be intercepted/blocked

Evidence:

• Burp HTTP history export (XML/CSV) for each app
• Frida interception logs showing unpinning success/failure
• Screenshots of traffic analysis in Burp
• Summary table of certificate validation per app
• Sensitive data exposure map (what identifiers leak, where)
• Device logcat capturing any trust errors or validation failures

Pass criteria:

• Weak TLS validation, excessive identifier leakage, or unsafe trust behavior is either identified or ruled out for all tested apps
• Pinning status is determined for each endpoint
• Sensitive data exposure is quantified and documented
• Telemetry behavior is observable and analyzable
• All evidence is correlated to specific workflows

Reference: MBX-02 & MBX-08 App Interception Toolkit

Lab stack architecture (W2 reference)

All W2 tests (MBX-09 through MBX-11) run against this software-only lab stack. No RF hardware required.

graph TD
    subgraph LAB_UE["Lab UE"]
        UERANSIM["UERANSIM UE sim\nor Pixel 9a via LibreSDR (W3)"]
    end

    subgraph LAB_RAN["Lab RAN"]
        GNB["UERANSIM gNB\nor srsRAN + LibreSDR (W3)"]
    end

    subgraph LAB_CORE["Open5GS 5GC"]
        AMF2["AMF"]
        SMF2["SMF"]
        UPF2["UPF"]
        AUSF["AUSF"]
        UDM["UDM / UDR"]
        AMF2 <-->|N11| SMF2
        AMF2 <-->|N12| AUSF
        AUSF <-->|N13| UDM
        SMF2 <-->|N4| UPF2
    end

    CAPTURE["Wireshark / tshark\nevidence capture"]
    DN2["Local DN\nlab data network"]

    UERANSIM -->|"Uu sim or RF (W3)"| GNB
    GNB -->|N2| AMF2
    GNB -->|N3| UPF2
    UPF2 -->|N6| DN2
    GNB -.->|pcap| CAPTURE
    AMF2 -.->|logs| CAPTURE

W3 upgrade path: replace UERANSIM gNB with srsRAN + LibreSDR once RF isolation is in place. The rest of the stack stays the same.

MBX-09 - UE to 5G core baseline

Objective: build a known-good 5G SA lab baseline before RF-dependent testing.

Blackbox angle: treat the Open5GS/UERANSIM environment as the observable network under test and validate registration outcomes.

Preconditions:

• Open5GS lab is functional
• UERANSIM can be launched

Steps:

1. Start the 5G core and confirm network functions are healthy.
2. Execute a clean registration and PDU session setup.
3. Capture signaling and user-plane evidence.

Evidence: pcap, function logs, registration screenshots or command output.

Pass criteria: clean 5G registration exists as the reference baseline.

MBX-10 - UE to 4G core baseline

Objective: build a known-good 4G attach baseline for comparison.

Blackbox angle: validate externally visible attach and bearer outcomes without assuming internal implementation details.

Steps:

1. Start the EPC stack and a compatible 4G simulation path.
2. Execute a clean attach.
3. Record attach, authentication, and default-bearer evidence.

Evidence: pcap, attach logs, IP assignment notes.

Pass criteria: a clean 4G baseline exists for comparison against 5G and fallback behavior.

MBX-11 - UE to cross-mode comparison

Objective: compare observable outcomes across LTE, 5G SA, and mixed-mode operation.

Steps:

1. Compare registration timing, session setup timing, user-visible service continuity, and identity/privacy behavior across modes.
2. Build a short comparison matrix for attach success, data service, fallback, and logging visibility.

Evidence: comparison table and supporting captures.

Pass criteria: differences between modes are documented clearly enough to guide later RF testing.

MBX-12 - UE to controlled lab cell

Objective: validate attach to a controlled isolated cell once the LibreSDR arrives.

Blackbox angle: observe the UE from outside the network while controlling only the lab environment.

Preconditions:

• LibreSDR operational
• RF isolation in place
• lab SIMs only

Steps:

1. Stand up the isolated lab cell and confirm RF containment.
2. Attach the Pixel 9a using the approved lab profile.
3. Record attach outcome, mode, timing, and user-visible behavior.

Evidence: pcap, phone screenshots, SDR/lab notes.

Pass criteria: attach is repeatable and confined to the lab environment.

MBX-13 - UE to controlled fallback

Objective: validate fallback behavior inside the shielded lab.

Blackbox angle: compare what the UE exposes when preferred access changes under controlled conditions.

Steps:

1. Establish the preferred mode in the lab.
2. Alter lab availability to trigger bounded fallback.
3. Record service continuity, timing, and any privacy-relevant changes.

Evidence: before/after screenshots, pcap, timing notes.

Pass criteria: fallback is predictable and consistent with expected policy.

MBX-14 - UE to mobility behavior

Objective: validate handover, reselection, or tracking-area behavior in a controlled environment.

Blackbox angle: focus on externally visible UE behavior and signaling outcomes.

Steps:

1. Create a controlled mobility scenario between cells or tracking areas.
2. Record handover success, interruption time, and whether the UE retains service.
3. Compare observed behavior to the baseline route mapping from W1.

Evidence: pcap, phone-side timestamps, route or scenario notes.

Pass criteria: mobility behavior is measurable, bounded, and attributable to the lab condition under test.

MBX-15 - UE to identity, authentication, and ciphering behavior

Objective: validate whether expected protections appear during controlled registration and service setup.

Blackbox angle: evaluate observable security outcomes rather than internal code paths.

Steps:

1. Record the registration and authentication sequence in the lab.
2. Compare identity handling and security-mode outcomes across LTE and 5G where supported.
3. Note any unexpected downgrade, null, or weakly protected behavior.

Evidence: signaling traces and an expected-versus-observed matrix.

Pass criteria: expected protections are consistently observed and deviations are clearly visible.

MBX-16 - UE to user-plane and data-network path

Objective: validate end-to-end service from registration through usable data.

Blackbox angle: confirm what a user experiences and what packet evidence proves from the outside.

Steps:

1. Establish a session after successful registration.
2. Test DNS, general data flow, and application traffic.
3. Record latency, stability, and whether the session survives expected state changes.

Evidence: packet capture, ping or application notes, DNS observations.

Pass criteria: the user-plane path is stable and traceable end to end.

MBX-17 - UE to detection and telemetry chain

Objective: prove that a user-visible issue can be traced across the lab evidence chain.

Blackbox angle: start from the UE symptom and work outward to the observable network evidence.

Steps:

1. Trigger or observe a benign, controlled event such as registration failure, fallback, or service interruption in the lab.
2. Correlate the handset symptom with captures and logs.
3. Confirm whether the same event is visible at more than one layer.

Evidence: phone-side screenshot, pcap, correlated log fragment.

Pass criteria: the event can be reconstructed from UE symptom to network evidence without blind spots.

MBX-18 - UE to robustness and failure handling

Objective: validate that abnormal or failed procedures are handled safely in the lab.

Blackbox angle: assess externally visible failure behavior and whether the system degrades cleanly.

Steps:

1. Execute approved negative-path or failed-procedure scenarios in the lab baseline.
2. Record whether the UE receives clear rejection or safe failure behavior.
3. Confirm that failure does not become silent corruption or unexplained instability.

Evidence: rejection traces, error logs, handset behavior notes.

Pass criteria: abnormal conditions are rejected safely, logged, and do not create unexplained service state.

Execution order

1. Run MBX-01 through MBX-08 immediately with the Pixel 9a and laptop.
2. Run MBX-09 through MBX-11 next to create a known-good 4G/5G core baseline.
3. Wait for LibreSDR + Faraday setup before running MBX-12 through MBX-15.
4. Finish with MBX-16 through MBX-18 once the lab is stable enough for cross-layer evidence.

Priority order if time is limited

1. MBX-01 UE baseline
2. MBX-04 serving-cell inventory
3. MBX-06 privacy baseline
4. MBX-07 fallback behavior
5. MBX-09 5G core baseline
6. MBX-10 4G core baseline
7. MBX-12 controlled attach
8. MBX-17 detection chain

Immediate readiness summary

Ready now

• MBX-01 through MBX-10

Ready after LibreSDR arrives and RF isolation is set up

• MBX-11 through MBX-18

Recommended additions

• Faraday enclosure or shield box
• lab SIM/eSIM profiles
• USB 3.0 hub and known-good SDR cables
• Linux host for SDR and core tooling
• optional Qualcomm test phone for deeper modem diagnostics

Outcome

This master plan gives you a single blackbox test path from UE to each major node or trust zone, aligned to your actual hardware and staged so you can begin now with the laptop and Pixel 9a, then extend safely into controlled RF lab validation once the LibreSDR arrives.