GrapheneOS cheatsheet

GrapheneOS dramatically reduces the attack surface of a mobile device. Stock Android and iOS constantly phone home with telemetry, location data, and usage analytics. GrapheneOS eliminates this by default.

GrapheneOS requires the Titan M2 security chip for hardware-backed verified boot and attestation. Only devices still receiving firmware updates from Google are officially supported. Best devices for new installs are Pixel 8 through Pixel 10 series.

Check grapheneos.org/faq for the most current device support list, as older devices get dropped when Google ends firmware updates.

For advanced users or when WebUSB is unavailable. Requires Android platform tools.

# Install dependencies
sudo apt install android-sdk-platform-tools signify-openbsd

# Download factory image from:
# https://grapheneos.org/releases
# Match your device codename (e.g., shiba for Pixel 8)

# Verify the image signature
signify -Vp grapheneos.pub -m <device>-factory.zip

# Boot into bootloader
adb reboot bootloader
# OR: hold Power + Volume Down from powered off state

# Unlock the bootloader (erases all data)
fastboot flashing unlock
# Confirm on device with volume keys + power

# Extract and flash
unzip <device>-factory.zip
cd <device>-factory/
./flash-all.sh

# Wait for flash to complete and device to boot
# Then reboot back to bootloader
adb reboot bootloader

# RELOCK bootloader (critical for verified boot)
fastboot flashing lock
# Confirm on device

# Device will reboot and wipe again (expected)

GrapheneOS receives over-the-air updates automatically. No manual intervention needed after initial install.

Settings > System > System update

- Updates are automatic by default
- Check manually: tap "Check for update"
- Updates are incremental (small downloads)
- Verified boot checks integrity on every boot
- If update fails, device rolls back automatically

Updates include both OS patches and firmware/microcode updates from Google, typically within days of upstream release.

Hardware-level controls to reduce physical tracking and data extraction vectors.

# Auto-reboot timer
Settings > Security & privacy > Auto reboot
> Set between 10 minutes and 72 hours (default: 18h)
# Timer resets on each successful unlock

Why auto-reboot is critical for forensic resistance:

Auto-reboot forces the device from AFU back to BFU after the timer expires. This means:

• Perquisition / saisie : if police seize your phone while it's locked but AFU, they can potentially extract data. If it auto-rebooted to BFU, they get encrypted blocks only.
• Overnight seizure : set timer to 4-8h. If seized while you sleep, device reboots to BFU before forensic analysis begins.
• Border crossing : set timer to 10 minutes. Phone reboots to BFU during the interaction. Combined with duress PIN for immediate wipe if forced to unlock.
• Theft / loss : device auto-reboots, thief faces BFU encryption wall.

Recommended settings by threat level:

USB-C security (five modes):

Settings > Security > USB accessories

Other hardware controls:

# Camera/microphone indicators
# Green dot in status bar when active (cannot be disabled by apps)

# NFC: Settings > Connected devices > NFC > OFF
# Enable only when actively using for payment/tags

# Bluetooth: Settings > Connected devices > Bluetooth > OFF
# Each enable uses a new randomized MAC address

# Screen lock: Settings > Security > Screen lock > Timeout > 30 seconds
# Power button instantly locks: Settings > Security > ON

GrapheneOS applies hardening beyond stock Android at the system level. These are active by default - no configuration needed.

hardened_malloc is GrapheneOS's custom memory allocator with out-of-line metadata protection. It replaces Android's default scudo allocator with separate memory regions for metadata, large allocations, and slab classes, providing significantly stronger exploit mitigations.

How it mitigates common heap exploits:

• Use-after-free (UAF) - quarantine zones delay memory reuse so that accessing freed memory hits zeroed/canary-protected regions. MTE on Pixel 8+ adds hardware-level probabilistic UAF detection
• Heap buffer overflow - guard pages between allocations cause a segfault on linear overflows. Slab canaries detect non-linear overflows at free time
• Double-free - detected by internal bookkeeping and canary validation at free time
• Heap spray - randomized allocation layout makes heap spray unreliable
• Information leaks - zero-on-free prevents reading stale data from reallocated memory

Stock Android uses a Zygote process model: a single Zygote process is initialized at boot, and all app processes are forked from it. This means every app inherits the same initial memory layout, including:

• Identical ASLR base addresses
• Shared initial memory contents
• Same randomized secrets (stack canaries, pointer authentication keys)

GrapheneOS replaces this with exec-based spawning: a secure application spawning system preventing address space layout sharing. Each new app process is created via exec from a clean state. JIT compilation is fully disabled and replaced with ahead-of-time compilation. This means:

• Fresh ASLR layout per process - no shared base addresses between apps
• Unique stack canaries per process - knowing one app's canary reveals nothing about another's
• No shared memory contents - eliminates cross-app information leakage from the Zygote model
• No JIT compilation - JIT fully disabled, replaced with ahead-of-time compilation, eliminating JIT spray attacks
• Higher cold-start time - tradeoff is slightly slower app launch (typically under 100ms difference)
• Higher initial memory use - each process has its own clean initialization instead of sharing Zygote pages

Both Titan M2 and Apple's Secure Enclave serve the same fundamental role: an isolated hardware security processor that protects encryption keys and enforces authentication rate limits independently of the main CPU.

GrapheneOS requires hardware features that only Pixel devices (and select partner devices) provide:

• Titan M2 secure element - enables hardware-backed verified boot with attestation. Most Android OEMs use software-only or weaker secure elements
• Unlockable and relockable bootloader - most OEMs either prevent bootloader unlocking entirely or do not support relocking after flashing a custom OS. Pixels support unlock, flash, and relock
• Full firmware update access - Google publishes complete firmware images and factory images. Other OEMs do not publish the firmware needed for a custom OS to maintain full security
• Hardware attestation after relock - after relocking the bootloader with GrapheneOS, the Titan M2 performs verified boot and the device passes hardware attestation checks
• Long support lifecycle - Pixel 8+ receive 7 years of firmware and security updates from Google

Without these properties, a custom OS cannot provide verified boot, hardware-backed encryption, or resistance to firmware-level attacks. This is why GrapheneOS cannot simply be ported to Samsung, OnePlus, or other Android devices without critical security regressions.

Secure key erasure (sometimes called "weeting") is the process of irreversibly destroying encryption keys so that encrypted data becomes permanently unrecoverable.

On GrapheneOS with Titan M2:

• Failed attempt threshold - after too many incorrect PIN/password attempts, the Titan M2 can trigger secure key erasure, destroying the key encryption key inside the secure element
• Duress wipe - entering the duress PIN/password triggers immediate secure key erasure plus full factory reset, including eSIM wipe
• Profile deletion - deleting a user profile cryptographically destroys that profile's encryption keys
• Factory reset - destroys all key material in the Titan M2, rendering all on-device data unrecoverable
• Auto-reboot - does not erase keys permanently, but purges decryption keys from RAM, returning the device to BFU (Before First Unlock) state where all data is encrypted at rest

The combination of hardware-backed key storage (keys never exist in software) and secure erasure (keys destroyed inside the chip) means that forensic extraction of a properly wiped device is not feasible.

Disabling 2G eliminates the easiest and most common IMSI catcher vector, but does not stop all cell-site simulator attacks. Advanced 4G catchers exist but are significantly more expensive and less common. See the Cellular OPSEC sheet for full IMSI catcher analysis and countermeasures.

When the duress PIN or password is entered:

The duress PIN activates when entered as a PIN (lock screen PIN, fingerprint fallback PIN). The duress password activates when entered as a password. The duress PIN also triggers a wipe when entered as the two-factor fingerprint unlock PIN.

# Border crossing scenario:
# 1. Set auto-reboot to 1h before arrival
#    (device is in BFU state, all data encrypted)
# 2. If compelled to unlock, enter duress PIN
#    instead of real PIN - device wipes
# 3. Device appears to "reset" or "malfunction"

# Coercion / arrest scenario:
# 1. Duress PIN is a different but plausible PIN
#    (e.g., real PIN is 847291, duress is 192748)
# 2. Under pressure, enter the duress PIN
# 3. Device performs full wipe

# Combined with auto-reboot:
# Auto-reboot after X hours of inactivity forces
# the device back to BFU state (password required,
# biometrics disabled). This means:
# - A seized device left powered on will auto-lock
# - After reboot, only PIN/password works (no fingerprint)
# - This is when duress PIN can be entered

# Combined with user profiles:
# Keep a "clean" Owner profile with minimal data.
# If compelled to unlock, you could unlock Owner
# and show a boring, clean profile. Duress PIN is
# the last resort if they demand the real password.

Each profile is isolated at the filesystem level with independent encryption:

Combined with duress password: you can keep a clean Owner profile with normal-looking apps. If coerced, unlock the Owner profile and show a boring device. Other profiles remain encrypted and invisible. The duress PIN/password is the last resort for full wipe.

# Create profiles
Settings > System > Multiple users > Add user

# Recommended setup:
# 1. "Daily" profile
#    - Sandboxed Google Play for banking/maps
#    - Aurora Store for other apps
#    - VPN: Mullvad or ProtonVPN always-on
#    - Set unique PIN/password

# 2. "Secure" profile
#    - Signal (with disappearing messages)
#    - ProtonMail
#    - Tor Browser
#    - Aegis for 2FA
#    - VPN: Mullvad always-on
#    - No Google Play at all
#    - Set strong password (not PIN)

# 3. "Burner" profile
#    - Minimal apps for the task
#    - VPN: Mullvad always-on
#    - Wipe after engagement:
#      Settings > System > Multiple users
#      > Select Burner > Delete user

# Switch profiles from lock screen
# Or: Settings > System > Multiple users > tap profile

# End session protocol:
# 1. Switch to Owner profile
# 2. All other profiles lock and encrypt
# 3. For maximum security: trigger auto-reboot
#    (returns device to BFU state)

Each profile can run its own VPN and DNS configuration independently. This means different profiles can exit through different VPN servers or providers.

# Profile "Daily"
VPN: ProtonVPN (standard servers)
DNS: Quad9

# Profile "Secure"
VPN: Mullvad (paid with crypto)
DNS: Mullvad DNS

# Profile "Burner"
VPN: Mullvad (different account)
DNS: Mullvad DNS
# Or: Tor via Orbot as VPN

# Each profile maintains its own:
# - VPN connection and credentials
# - DNS configuration
# - Wi-Fi saved networks
# - Network permissions per app

Configuration for using a GrapheneOS Pixel as a dedicated operational device for engagements.

# Device setup checklist:
# 1. Fresh GrapheneOS install, bootloader relocked
# 2. No personal accounts on any profile
# 3. Owner profile: system admin only, no apps
# 4. Create "Ops" profile per engagement
# 5. Auto-reboot set to 24h

# Network configuration:
# - Mullvad VPN always-on + kill switch
# - Paid with cash (mail envelope) or Monero, no email registration
# - 2G disabled, preferred network: LTE only
# - Private DNS: dns.mullvad.net
# - Wi-Fi: connect to GL.iNet Mudi (Blue/Red Merle) for internet
# - Prefer USB tethering over Wi-Fi (no Wi-Fi probe leaks, no BSSID exposure)
# - If Wi-Fi to Mudi: airplane mode first, then enable Wi-Fi only (cellular radio stays off)
# - Never connect to public/known Wi-Fi directly from the phone
# - Forget all networks after use

# Communication:
# - Molly-FOSS (preferred) or Signal with disappearing messages (24h)
# - Separate number (burner SIM or JMP.chat via Tor)
# - No personal contacts in this profile
# - Olvid for maximum security (no phone number needed)

# After engagement:
# 1. Export any needed data via encrypted channel
# 2. Delete the "Ops" profile
#    Settings > System > Multiple users > Delete
# 3. Profile data cryptographically destroyed
# 4. Force reboot to clear RAM
#    (hold power 10+ seconds)

# USB security:
# - USB accessories: charging only
# - USB debugging: disabled
# - ADB: disabled after initial setup

Measures to protect the device itself from physical compromise, seizure, or forensic extraction.

# Duress/emergency:
# - Duress PIN/password: enter at lock screen
#   to trigger irreversible factory reset
#   Settings > Security & privacy > Device unlock
#   > Duress password (see Duress Password section)
# - Ripple (Guardian Project): panic button app
#   that triggers wipe/lock/disguise on configured apps
#   Install from F-Droid: info.guardianproject.ripple
#   Two-step trigger + 5-second cancel window
# - Power off: hold power button > Power off
#   (returns to BFU state, full encryption)
# - Emergency: press power 5x rapidly
#   (triggers emergency SOS, can be configured)

# Lock screen + biometrics:
# Adapt to your threat model:
#
# vs Citizens/competitors: fingerprint OK for convenience
#   Auto-reboot + lockdown mode is sufficient protection
#
# vs Law enforcement: NO fingerprint
#   Biometrics can be compelled in most jurisdictions
#   (police can force your finger on sensor)
#   Passwords generally protected (5th Amendment US,
#   varies in EU - France: can be compelled under Art. 434-15-2)
#   Use strong alphanumeric password ONLY
#
# vs Nation-state: NO fingerprint, short auto-reboot (10-30min)
#   Assume they will attempt to keep phone in AFU state
#
# In ALL cases:
# - Lockdown mode: hold power > Lockdown
#   (instantly disables biometrics until password entered)
#   Use this BEFORE handing device to anyone
# - After auto-reboot or first boot: biometrics disabled
#   Password required first (BFU state = safe)
# - So biometrics ARE acceptable for daily convenience IF:
#   1. Auto-reboot is set short enough for your threat
#   2. You use Lockdown before any risky situation
#   3. You understand biometrics are convenience, not security

# Anti-forensic considerations:
# - Auto-reboot: adapt to threat model
#   vs Citizens:       18h (default, fine)
#   vs Competitors:    8-12h
#   vs Law enforcement: 4-6h (sleep at 1am, raid at 6am = phone in BFU)
#   vs Nation-state:   1-2h or less
#   Rule: set it to less than your average sleep time
# - USB charging-only blocks forensic tools
#   (Cellebrite, GrayKey need USB data lines)
# - Locked bootloader prevents firmware mods
# - Verified boot detects OS tampering
# - Profile encryption uses strong KDF
#   (Argon2-based key derivation)
# - Duress PIN as last resort if compelled to unlock

Immediately after installing GrapheneOS, run through these settings.

Useful commands for initial setup and verification. Disable ADB/USB debugging after setup is complete.

# Check device status
adb devices

# Verify bootloader lock state
adb reboot bootloader
# Screen shows "locked" or "unlocked"

# Install APK from computer
adb install app.apk

# List installed packages
adb shell pm list packages

# Check running services
adb shell dumpsys activity services

# Check network connections
adb shell netstat -tlnp

# Disable USB debugging when done
# Settings > System > Developer options
# > USB debugging: OFF
# Then disable Developer options entirely:
# Settings > System > Developer options: OFF

# Force reboot (emergency)
adb reboot

# Enable PIN scrambling
Settings > Security & privacy > Device unlock
> Scramble PIN input layout: ON
# PIN pad numbers are randomized on every display
# Defeats camera-based and shoulder-surfing PIN theft

# Set strong password (up to 128 characters)
Settings > Security & privacy > Device unlock
> Screen lock > Password
# Use a long passphrase for high-security profiles

# Two-factor fingerprint unlock
Settings > Security & privacy > Device unlock
> Two-factor fingerprint unlock: ON
# After fingerprint scan, PIN is also required
# Combines something-you-have with something-you-know

# Fingerprint attempts
# Limited to 5 failed fingerprint attempts
# vs stock Android's 20 attempts
# After 5 failures, PIN/password is required

# JIT toggle (per-site)
# JIT is disabled globally by default
# To enable for a specific site that requires it:
Vanadium > Site settings > JavaScript JIT
> Add site exception

# Third-party cookies
# Disabled by default, no action needed
# Can add exceptions per-site if required

# DRM (Widevine)
# Disabled by default
# Enable only if needed for specific streaming services

# For maximum security:
# - Keep JIT disabled (default)
# - Keep third-party cookies blocked (default)
# - Keep DRM disabled (default)
# - Use Tor Browser for anonymous browsing instead

# Install Auditor on BOTH devices:
# - The device to verify (auditee)
# - A trusted device (verifier)

# First-time pairing:
# 1. Open Auditor on the verifier
# 2. Tap "Verify" - generates QR code
# 3. Open Auditor on the auditee
# 4. Tap "Auditee" - scans QR code
# 5. Auditee generates attestation, shows QR
# 6. Verifier scans the attestation QR
# 7. Pairing established with hardware-backed identity

# Subsequent verifications:
# Repeat scan process - verifier confirms
# the same hardware-backed key is present
# Any firmware/OS tampering will fail verification

# Remote attestation service:
# https://attestation.app
# Schedule automatic attestation checks
# Receive alerts if verification fails

• GrapheneOS
• GrapheneOS Features
• GrapheneOS GitHub
• Attestation App
• GrapheneOS Forum
• Molly (Signal fork)
• Olvid
• Ripple (Guardian Project)
• F-Droid
• Plexus

• Cellular OPSEC (IMSI catchers, baseband attacks, Blue/Red Merle, SIM security)
• Anonymization (Tor, VPN, identity separation, Olvid, censorship circumvention)
• Mullvad VPN (No-log VPN, anonymous signup, cash/crypto payment)
• OPSEC Toolkit (OPSEC Scorecard, Cover Identity Builder)
• OPSEC Checklist (Operational security verification steps)
• Anti-Forensics (Secure deletion, log clearing, forensic resistance)
• Tails (Amnesic live OS for temporary anonymous sessions)
• Whonix (Tor-enforced anonymity OS with gateway isolation)
• Qubes OS (Security through compartmentalization with Xen)