Phase 2 - UE, Android, and SIM Security Assessment

Purpose

This phase evaluates subscriber-side risk without requiring RF transmission. It is the fastest way to start collecting useful findings while your core lab is being stabilized.

Two tools make "the handset exposes X" a measured, reproducible claim: CellScope reads what the device reports, and lab/ supplies the ground truth for identity-privacy behavior.

Primary assessment questions

Tooling for this phase

Recommended workflow

1. Build a device baseline: OS version, patch level, baseband version, carrier profile, root state.
2. Inventory carrier and telephony apps and document the components worth reviewing.
3. Validate proxying, capture, and logging on your own device before testing any workflow.
4. Review SIM/eSIM identity and service configuration using approved lab SIM material.
5. Snapshot the handset with CellScope (SOURCE=pixel) so device-reported cell/identity state is captured as evidence, not memory.
6. Record findings as control weaknesses, not just interesting behaviors.

Outputs expected from this phase

• Device baseline sheet
• Carrier-app traffic summary
• SIM/eSIM service inventory
• CellScope pixel snapshot of what the handset reports (cells, bands, exposed identifiers)
• Privacy observations tied to specific controls or misconfigurations
• A short list of tests to repeat later when the RF and core phases are active

Assessment themes

1. Device and carrier-app review

Focus on:

• Traffic visibility and TLS behavior
• Exported activities, services, and receivers
• Secrets stored on-device
• Debug or diagnostic functions exposed to normal users

2. Telephony and local interface review

Focus on:

• Which device interfaces are reachable without elevated access
• Which telephony metadata can be read locally
• Whether debug surfaces are consistently disabled, gated, or logged

3. SIM and OTA posture

Focus on:

• What identity and service files are present
• Whether OTA-related services are enabled where they should not be
• Whether the SIM profile matches the intended lab or operator role

4. Evidence and decision points

Capture enough detail to answer:

• Is this a lab-only artifact or a production-relevant weakness?
• Does the issue require rooted/device-admin access, subscriber access, or operator access?
• Can the finding be traced to a compensating control, or is it currently unmonitored?

Verify it with your own tools

The verification question in Phase 2 is: does the subscriber side (SIM profile + handset) actually conceal permanent identity the way policy says it should? You answer it by comparing the handset's real behavior against the lab ground truth from Phase 1.

Ground-truth reference (run once, in lab/):

That table is your yardstick. It tells you exactly which CellScope flag corresponds to which real-world privacy failure, calibrated on a network you own.

Device-side check (your own handset):

cd ~/code/CodeCollector/mobility/cellscope
SOURCE=pixel ./cellscope.sh start          # rooted Pixel 9 CellInfo → dashboard, http://localhost:8000
# nasdiag (pre-cipher NAS identity/auth), offline replay of your own capture:
SOURCES=nasdiag NASDIAG_REPLAY=my_device_capture.pcap ./cellscope.sh start

Pass/fail for the phase:

• SIM/eSIM control check — with a correctly-provisioned lab profile, your device's 5G registration should read like the concealed-SUCI case, not the null-scheme case. A device that reads supi-in-clear where policy expects concealment is a finding.
• Fallback exposure check — if the device or profile silently drops to LTE, the identity goes in the clear (imsi-in-clear), which the Phase-3 RF work will look for over the air. Note here whether the subscriber-side configuration permits that fallback.

Companion procedures

• Support_Hardware_Pixel9
• open5gs_lab/16_android_cell_analysis
• open5gs_lab/18_test_plan_mobility_site_to_core

Exit criteria

Move on when you can clearly explain:

• What the handset exposes locally
• What the carrier-app ecosystem exposes at the application layer
• What SIM/eSIM controls are relevant to the later RF and core phases
• Which CellScope flag your own device produces against the Phase-1 ground-truth table — so Phase 3 starts from a known device baseline, not an assumption