Phase2_UE_Android_SIM
Phase 2 - UE, Android, and SIM Security Assessment
Warning
Keep this phase focused on devices, SIMs, and applications that you own or are explicitly authorized to assess.
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.
Primary assessment questions
| Area | Question | Typical evidence |
|---|---|---|
| Carrier app exposure | Do carrier apps over-collect, trust weak TLS paths, or expose sensitive functions? | Traffic captures, manifest review, exported component review |
| Device telephony exposure | Are diagnostic, telephony, or local management surfaces overly permissive? | Device inventory, service list, allowed/blocked interfaces |
| SIM and eSIM controls | Are subscriber identifiers, SIM services, and OTA features appropriately constrained? | SIM file inventory, enabled services, provisioning notes |
| Privacy posture | Does the device expose more identity or cell data than expected? | Screenshots, dumpsys output, cell inventory, settings state |
Recommended workflow
- Build a device baseline: OS version, patch level, baseband version, carrier profile, root state.
- Inventory carrier and telephony apps and document the components worth reviewing.
- Validate proxying, capture, and logging on your own device before testing any workflow.
- Review SIM/eSIM identity and service configuration using approved lab SIM material.
- 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
- 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?
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