Cellular OPSEC cheatsheet

The BSSID (Basic Service Set Identifier) is the MAC address broadcast by a Wi-Fi access point. If your device acts as a hotspot (like the Mudi router), its BSSID is constantly transmitted in every beacon frame (~10 per second).

BSSID vs SSID: SSID is the network name (user-chosen, can be duplicated). BSSID is the MAC address (hardware-unique by default). Even hidden SSIDs still broadcast the BSSID.

# Requirement: GL-E750 Mudi router, firmware 4.3.8

# 1. Download latest IPK from GitHub releases
wget https://github.com/srlabs/blue-merle/releases/latest

# 2. Copy to router via SCP
scp blue-merle*.ipk [email protected]:/tmp/

# 3. SSH into router
ssh [email protected]

# 4. Install package
opkg update
opkg install /tmp/blue-merle*.ipk

# BSSID randomization and MAC log wiping
# are automatic after install and on every boot

Physical toggle switch workflow (no SSH needed):

1. Flip the Mudi's hardware switch
   -> Display: "Disabling the ME from transmitting
                and receiving RF signals..."

2. Replace the SIM card

3. Flip the switch again
   -> Blue Merle sets a random IMEI
   -> Device powers off

4. Change your physical location

5. Boot the device
   -> New IMEI + new SIM + new location = unlinkable

# Manual procedure (debug/development only)

# 1. Disable radio
gl_modem AT AT+CFUN=4

# 2. Replace SIM card physically

# 3. Init new SIM + disable radio again
gl_modem AT AT+CFUN=0 && gl_modem AT AT+CFUN=4

# 4. Generate random IMEI
python3 /lib/blue-merle/imei_generate.py -r

# Or deterministic IMEI (seeded from IMSI)
python3 /lib/blue-merle/imei_generate.py -d

# 5. Verify
gl_modem AT AT+GSN

# 6. Power off
echo '{ "poweroff": "1" }' > /dev/ttyS0

# 7. Change location, then boot

All automatic on every boot via blue-merle init scripts:

# BSSID randomization
# hostapd reads MAC from /etc/config/wireless (mac80211)
# Blue Merle overrides via OpenWrt uci:
uci set wireless.@wifi-iface[0].macaddr='XX:XX:XX:XX:XX:XX'
uci set wireless.@wifi-iface[1].macaddr='XX:XX:XX:XX:XX:XX'
uci commit wireless
wifi reload
# Result: new AP identity on every boot

# WAN MAC randomization
# When Mudi connects to upstream Wi-Fi, its own MAC is visible
# Blue Merle randomizes this too to prevent tracking

# MAC address log wiping
# Stock firmware stores ALL connected client MACs in /etc/oui-tertf
# This is forensic gold if device is seized
shred -vfz /etc/oui-tertf          # secure overwrite
mount -t tmpfs tmpfs /etc/oui-tertf  # tmpfs overlay prevents new writes
# Result: no persistent record of any connected device

From the SRLabs whitepaper (Section 5):

• Blue merle permanently removes the router's old identity. Privacy depends on SIM anonymity and VPN/Tor usage.
• Changing IMEI to one already active on the same network can cause issues or detection.
• Deterministic mode risk: IMEI derived from IMSI creates a detectable mathematical relationship. An observer comparing IMEI/IMSI pairs could identify blue-merle usage.
• RF transmission delay: Always disable RF (AT+CFUN=4) before IMEI change to prevent identity contamination.
• Blue merle is a research project - effectiveness may change with firmware updates.

# Most Linux systems with USB modems
# Find the modem device
ls /dev/ttyUSB* /dev/ttyACM*

# Send AT command via screen
screen /dev/ttyUSB2 115200

# Or via echo
echo -e "AT+GSN\r" > /dev/ttyUSB2
cat /dev/ttyUSB2

# Or via mmcli (ModemManager)
mmcli -m 0 --command="AT+GSN"

# Check IMEI
mmcli -m 0 --command="AT+GSN"

# Check signal
mmcli -m 0 --command="AT+CSQ"

# Check operator
mmcli -m 0 --command="AT+COPS?"

A silent SMS (Type 0 SMS, also called a stealth ping) is a specially crafted SMS that does not display any notification on the target phone. It forces the phone to respond to the network, revealing its current cell tower location.

How it works:
1. Attacker sends Type 0 SMS to target MSISDN
2. Network delivers SMS to phone
3. Phone acknowledges receipt (network-level)
4. No notification shown to user
5. Attacker queries network for delivery report
   -> Report includes serving cell ID = location

Detection:
- SnoopSnitch (Android, Qualcomm): logs silent SMS
- Some custom Android ROMs expose Type 0 in logs
- Baseband-level detection only (not visible to OS)

Usage: law enforcement uses thousands per investigation
Germany: 600,000+ silent SMS in 2018 (Bundestag data)

Downgrade attacks force a phone from a secure protocol (4G/5G) to an insecure one (2G/GSM). In 2G, encryption is weak (A5/1) or absent (A5/0), and there is no mutual authentication.

Mitigation on Android (GrapheneOS / stock):

• Settings > Network > Preferred network type > LTE only
• On GrapheneOS: Settings > Security > Force LTE-only mode
• On Pixel: *#*#4636#*#* > Phone information > Set preferred network type

• Use 4G/5G only (disable 2G/3G fallback if possible)
• VoLTE for calls (encrypted over LTE, not GSM A5/1)
• Blue Merle + Mudi router for data (isolate cellular from device)
• Faraday bags when not in use (block all RF)
• Airplane mode does NOT guarantee radio off (baseband may still respond)
• For high-risk: separate burner device per operation, power off between uses
• Never use SMS for 2FA on sensitive accounts (use TOTP or hardware keys)
• End-to-end encrypted messaging (Signal, Session, Briar) instead of SMS/RCS

• Never carry burner + personal phone simultaneously (co-location analysis links them)
• Power off when not actively in use
• Never connect to home/work Wi-Fi
• Never log into personal accounts
• Never call personal contacts
• Battery pull > software power off (baseband trust issue)
• Dispose of device + SIM separately after use
• Wipe before disposal if possible

Note: laws change frequently. Always verify current local regulations.

Block ALL RF emissions (cellular, Wi-Fi, Bluetooth, NFC, GPS) to prevent tracking when the device should be silent.

Always test before trusting: Put your phone in the bag, call it from another phone. If it rings, the bag doesn't work.

Airplane mode is NOT equivalent:

• Baseband firmware can be buggy or malicious
• Some devices still transmit in airplane mode
• Physical RF isolation is the only guarantee

Coming soon: Cyber Aurelien Guidi plans to open an OPSEC gear shop with tested Faraday bags, burner accessories, and privacy hardware. Stay tuned.

Principle: each identity/operation gets its own
device, SIM, location pattern, and behavior profile.

Example compartmentalization:

Identity A (personal):
  - Personal phone, personal SIM
  - Home/work locations
  - Personal accounts

Identity B (operational):
  - Burner phone, cash-bought prepaid SIM
  - Never near home/work
  - Dedicated accounts (created over Tor)
  - Used only for specific operation

Identity C (communication):
  - Separate burner for encrypted comms
  - Signal/Session with dedicated number
  - Never used for any other purpose

Rules:
- Identities NEVER share devices or SIMs
- Identities NEVER co-locate (same cell tower)
- Identities NEVER contact each other
- Identities have different usage time patterns

SIM swap is a social engineering attack where the attacker convinces the mobile carrier to transfer the target's phone number to a SIM the attacker controls.

Attack flow:
1. Attacker gathers target's personal info
   (name, DOB, last 4 SSN, address)
2. Calls carrier support, impersonates target
3. Requests number port to new SIM
4. Carrier deactivates target's SIM
5. Attacker receives all SMS (including 2FA codes)
6. Attacker accesses email, banking, crypto

Defenses:
- Set carrier PIN/passcode (T-Mobile, AT&T, etc.)
- Port freeze / number lock with carrier
- Never use SMS-based 2FA for critical accounts
- Use TOTP (Aegis, KeePassXC) or hardware keys (YubiKey)
- Monitor for sudden loss of cellular service

For anonymity: physical prepaid SIM purchased with cash remains superior. eSIM creates a digital paper trail through the provisioning process (email, payment, IP address).

The SIM Toolkit is a set of commands built into the SIM card by the carrier. The SIM can run applets (JavaCard) that execute independently of the phone OS.

STK capabilities (carrier-controlled):
- Display messages on screen
- Send SMS silently
- Make calls
- Request location data
- Open browser to URL
- Access device info

OPSEC concern:
- STK applets run BELOW the OS (on SIM processor)
- Cannot be inspected or controlled by Android/iOS
- Carrier can push OTA updates to SIM applets
- Simjacker attack (2019): exploit STK S@T Browser
  to silently execute commands on target phone

Mitigation:
- Use a clean prepaid SIM from a trusted source
- PySIM can read and audit SIM applets
- Some custom ROMs allow disabling STK

1. Airplane mode
   + Disables cellular/Wi-Fi/Bluetooth at OS level
   - Baseband firmware may still respond to network
   - NOT a guarantee of radio silence

2. Faraday bag
   + Physically blocks all RF (cellular, Wi-Fi, BT, GPS, NFC)
   + Testable: call the phone, it should go to voicemail
   - Must be properly sealed (no gaps)

3. Power off
   + Most radios off
   - Some devices have "find my phone" that works powered off
   - Baseband can theoretically wake on certain signals

4. Battery removal
   + Guarantees no transmission
   - Most modern phones have non-removable batteries

5. Leave device at home
   + No location data generated at destination
   - Creates "gap" in your location timeline (suspicious)

6. Burner device
   + Fresh identity per operation
   - Must never co-locate with personal device

Everything that transits the cellular network unencrypted is visible to the carrier. Even encrypted traffic reveals metadata.

Android Debug Bridge (ADB) is a powerful debug interface. If enabled, it grants shell-level access to the device via USB or Wi-Fi.

Risks of ADB enabled:
- USB connected computer gets shell access
- Can install APKs, extract data, read logs
- ADB over Wi-Fi: any device on same network can connect
- Juice jacking: malicious chargers can exploit ADB
- Law enforcement: plug in device, extract everything

Hardening:
- Disable USB debugging when not needed
- Disable "ADB over network" always
- Use charge-only USB cables (no data pins)
- On GrapheneOS: USB-C port can be set to
  charge-only mode (Settings > Security)
- Review authorized ADB keys regularly
- Revoke all USB debugging authorizations
  (Settings > Developer options > Revoke)

Locked bootloader:
- Verifies boot image signature on every boot
- Prevents loading modified OS images
- Required for verified boot chain
- GrapheneOS: re-lock after installation

Unlocked bootloader:
- Anyone with physical access can flash new OS
- Can boot custom recovery (TWRP)
- Can extract data via custom recovery
- Tamper detection broken

OPSEC implications:
- Always re-lock bootloader after OS install
- Unlocked bootloader + physical access = full compromise
- GrapheneOS supports locked BL (unlike most custom ROMs)
- LineageOS requires unlocked BL = weaker physical security
- Check state: fastboot oem device-info

RCS (Rich Communication Services) is the successor to SMS. Google Messages supports RCS with end-to-end encryption (E2EE) for 1:1 conversations, but with major caveats.

RCS security caveats:
- E2EE only between Google Messages users
  (not Samsung Messages, not carrier RCS)
- Group chats: E2EE added in 2024, verify support
- Fallback to SMS/MMS if E2EE unavailable
- Metadata (who, when, frequency) visible to carrier
- RCS profile data shared with carrier
- No forward secrecy in some implementations
- Apple iMessage-to-RCS: NOT end-to-end encrypted
- Cross-platform (Android-to-iPhone via RCS): no E2EE

For OPSEC: do not rely on RCS.
Use Signal, Session, or Briar instead.

• Pixel phones: IOMMU isolates baseband from application processor memory (no DMA)
• GrapheneOS: exploit mitigations applied where possible
• Disable 2G: reduces legacy attack surface significantly
• Keep device updated: baseband firmware in monthly security patches
• Use Mudi router: isolate baseband from personal device entirely
• Avoid MediaTek chipsets in high-risk scenarios (historically weaker security)
• Samsung Exynos: multiple critical CVEs, prefer Qualcomm or Google Tensor

What a network observer (carrier, state actor, MITM) can determine from your cellular data traffic, even when encrypted.

Traffic analysis techniques:
1. Website fingerprinting
   - HTTPS hides content but not packet sizes/timing
   - ML classifiers can identify visited sites
   - Especially effective on mobile (predictable patterns)

2. App identification
   - Each app has distinct traffic patterns
   - Push notification timing reveals app usage
   - API endpoint IPs identify the service

3. Encrypted DNS leaks
   - Default: DNS queries sent in plaintext to carrier
   - Even with DoH/DoT: resolver IP visible
   - DNS over Tor: best option for DNS privacy

4. VPN detection
   - Carrier sees VPN tunnel establishment
   - Traffic volume/timing still visible
   - WireGuard has distinctive handshake pattern
   - OpenVPN can be fingerprinted (DPI)

Mitigations:
- Use VPN (hides destination IPs from carrier)
- Use Tor (hides traffic patterns via onion routing)
- Use DNS over HTTPS/TLS (hides DNS queries)
- Mudi router with VPN: all device traffic tunneled

If a device has MDM:
- Never use it for sensitive operations
- MDM can see all network traffic (if VPN forced)
- MDM CA cert enables TLS interception
- App inventory reveals operational tools
- Location tracked continuously

Approaches:
- Use a completely separate, non-enrolled device
- Personal device with no MDM profile
- Check: Settings > General > VPN & Device Mgmt (iOS)
- Check: Settings > Security > Device admin apps (Android)
- GrapheneOS: cannot be enrolled in most MDM
  (no Google device policy support unless sandboxed Play)

Do NOT attempt to remove MDM from a corporate device.
The removal itself is logged and creates an incident.
Use a clean, separate device.

Tools law enforcement and forensic analysts use to extract data from seized phones.

Forensic extraction levels:
1. Logical: app data, contacts, messages, call logs
   - Easiest, works on most locked devices

2. Filesystem: full file tree including deleted files
   - Requires exploit or unlocked bootloader

3. Physical: bit-for-bit chip dump
   - Raw NAND image, recovers deleted data
   - Requires chip-off or JTAG/ISP

Defenses:
- Strong alphanumeric passcode (not 4/6-digit PIN)
- GrapheneOS auto-reboot timer (clears keys from RAM)
- BFU state (Before First Unlock) limits extraction
- USB restricted mode (GrapheneOS, iOS)
- Full-disk encryption (default on modern Android/iOS)

awesome-telco - Comprehensive curated list of telco open-source tools, SDR resources, and 5G/4G/2G projects.

• Blue Merle - SRLabs
• GSM Map
• SnoopSnitch
• EFF - Problem with Mobile Phones
• awesome-telco
• Crocodile Hunter - EFF
• Rayhunter - EFF

• Anonymization (Identity separation and Tor routing)
• OPSEC Checklist (Engagement security checklists)
• GrapheneOS (Hardened Android OS)
• Tails (Amnesic live operating system)
• Crypto OPSEC (Anonymous cryptocurrency usage)
• Anti-Forensics (Artifact removal and log cleanup)
• Encoding & Crypto Toolkit (Encoding, ciphers, obfuscation, JWT)