Deconstructing Carrier Bundles: Reverse-Engineering Baseband Profiles, IMS Entitlements, and 5G Overrides in iOS and Android

The Opaque Layer Beneath the OS: How Modern Smartphones Configure Their Radios

When a smartphone boots or latches onto a cellular tower, the operating system does not simply initiate generic radio communications. Beneath standard socket APIs and networking daemons sits an intricate, highly controlled configuration layer that dictates modem baseband state machines, Radio Resource Control (RRC) timers, Access Point Names (APNs), and IP Multimedia Subsystem (IMS) parameters.

Historically, carrier settings were treated as vendor-locked binary black boxes. However, recent open-source tooling—such as the reverse-engineering pipelines seen in projects like Carrier-Explode—has exposed the inner mechanics of how Apple, Google, and Samsung dynamically configure their baseband radios and telephony subsystems.

For systems engineers, mobile kernel researchers, and low-level protocol developers, understanding how carrier configurations operate provides deep visibility into cellular radio management, proprietary entitlement servers, and the software-defined constraints governing 5G Standalone (SA) deployments.

Deconstructing iOS IPCC Bundles: From Signed Plists to Baseband NVRAM

On Apple devices, mobile network profiles are packaged into Carrier Bundle files bearing the .ipcc extension. An .ipcc file is structurally a standard ZIP archive containing a payload directory structured around a specific carrier’s Mobile Country Code (MCC) and Mobile Network Code (MNC) tuple.

The Anatomy of an IPCC Archive

When extracted, an .ipcc reveals several key components:

carrier.plist: The central property list containing service strings, network capabilities, APN dictionaries, and IMS operational flags.
signatures/: Cryptographic signatures generated via Apple’s carrier configuration private key.
Baseband firmware overlays: Binary patches targeting Qualcomm or Apple-designed baseband processors, loaded directly into modem non-volatile memory (NVRAM).

<!-- Snippet from a decompiled carrier.plist -->
<dict>
    <key>AllowEDGEEditing</key>
    <false/>
    <key>APNs</key>
    <array>
        <dict>
            <key>apn</key>
            <string>ims</string>
            <key>type-mask</key>
            <integer>64</integer> <!-- Telephony/IMS bearer -->
        </dict>
        <dict>
            <key>apn</key>
            <string>internet</string>
            <key>type-mask</key>
            <integer>49</integer> <!-- Default data + tethering -->
            <key>IPType</key>
            <string>IPv4v6</string>
        </dict>
    </array>
    <key>CarrierName</key>
    <string>TelcoCore</string>
    <key>ShowCallForwarded</key>
    <false/>
    <key>Supports5GStandalone</key>
    <true/>
</dict>

The iOS CommCenter daemon evaluates these values upon reading the SIM card’s Integrated Circuit Card Identifier (ICCID) and IMSI. If the .ipcc signature validates against Apple’s trust anchors embedded in the Secure Enclave or root filesystem (/System/Library/Carrier Bundles/), CommCenter serializes these parameters into internal IPC calls dispatched via the Baseband IPC interface (historically AppleBaseband IPC over PCIe or shared memory buffers).

If the signature fails verification, the OS drops back to Default.bundle, stripping features like Voice over LTE (VoLTE), native tethering, and Wi-Fi Calling (VoWiFi).

Android’s CarrierConfig Architecture: XML Overrides, Protobufs, and Carrier Privileges

Android approaches telephony configuration through an abstraction model centered on the CarrierConfigManager system service and the TelephonyProvider content provider.

CarrierConfigManager and the UICC Privilege Rule Engine

Rather than relying strictly on centralized OEM cryptographic signatures, the Android Open Source Project (AOSP) utilizes a layered override pipeline:

AOSP Defaults: Hardcoded values defined inside packages/apps/CarrierConfig/assets/carrier_config_carrierid_*.xml.
Device Overrides: OEM-specific variants placed inside vendor partitions (e.g., /vendor/etc/carrier/).
UICC Carrier Privilege Overrides: Cryptographically authorized runtime updates provisioned directly by the SIM card.

Android uses the GSMA TS.43 standard alongside GlobalPlatform Secure Element access rules (ARA-M applets on the SIM). If an installed APK matches the SHA-1 or SHA-256 certificate fingerprint programmed into the SIM card’s EF_DIR and EF_ARF files, that app acquires CARRIER_PRIVILEGE_STATUS_HAS_ACCESS.

// Runtime extraction of CarrierConfig parameters
CarrierConfigManager configManager = (CarrierConfigManager) 
    context.getSystemService(Context.CARRIER_CONFIG_SERVICE);

if (configManager != null) {
    PersistableBundle config = configManager.getConfigForSubId(subscriptionId);
    boolean isVonrEnabled = config.getBoolean(CarrierConfigManager.KEY_VONR_ENABLED_BOOL);
    int volteTimer = config.getInt(CarrierConfigManager.KEY_VOLTE_RETRY_INTERVAL_MILLIS_INT);
    String imsApn = config.getString(CarrierConfigManager.KEY_IMS_APN_STRING);
}

Google Pixel Protobuf Decoding

On modern Google Pixel devices, carrier configurations have migrated away from pure XML files toward serialized Protocol Buffers stored in the telephony persistent database (telephony.db). The carrier_id lookup engine parses carrier_list.pb, matching MCC/MNC pairs, GID1/GID2 (Group Identifier) values, and SPN (Service Provider Name) strings to apply precise baseband profiles.

Reverse-engineering these protobufs exposes low-level parameters normally hidden from mobile engineers: Discontinuous Reception (DRX) timers, Network Slice Selection Policy (NSSP) mappings, and Physical Uplink Control Channel (PUCCH) power control tables.

The IMS Provisioning Pipeline: VoLTE, VoWiFi, and ePDG Tunnels

The most delicate section of any carrier profile governs the IP Multimedia Subsystem (IMS). Voice services on 4G and 5G networks are purely packet-switched SIP/RTP streams. To prevent unauthorized routing and billing leaks, carriers mandate strict authentication barriers.

IMS Bearer Establishment

When CommCenter (iOS) or rild / Telephony HAL (Android) detects VoLTE enablement via carrier configuration:

Dedicated APN Activation: A secondary network interface (rmnet_data1 on Qualcomm architectures) is initialized pointing specifically to the ims APN.
IPsec Security Association: For Voice over Wi-Fi (VoWiFi), the device reads the evolved Packet Data Gateway (ePDG) Fully Qualified Domain Name (FQDN) from the carrier profile.
IKEv2/EAP-AKA Authentication: The device builds an IPsec tunnel terminating at the carrier’s Security Gateway (SecGW). Cryptographic challenges are verified directly by the SIM using EAP-AKA (Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement).

[ Smartphone Client ]                     [ ePDG / SecGW ]           [ IMS Core (CSCF) ]
        |                                        |                           |
        |--- IKE_SA_INIT Request --------------->|                           |
        |<-- IKE_SA_INIT Response ---------------|                           |
        |                                        |                           |
        |--- IKE_AUTH (EAP-AKA Identity) ------->|                           |
        |<-- IKE_AUTH (EAP-AKA Challenge) -------|                           |
        |    [SIM Calculates RAND/AUTN/RES]      |                           |
        |--- IKE_AUTH (EAP-AKA Response) ------->|                           |
        |<-- IKE_AUTH Success (IPsec Established)|                           |
        |                                        |                           |
        |======== Encrypted SIP REGISTER Over IPsec Tunnel =================>|
        |<======= 200 OK (SIP Registration Acknowledged) ===================|

If the carrier configuration file fails to provision correct MTU sizes (typically 1280 to 1440 bytes to account for double-encapsulation overhead) or drops the SIP Session Timers, the device falls victim to silent call drops, one-way audio, or registration rejection.

Reverse-Engineering the GSMA TS.43 Entitlement Flow

Modern cellular capabilities are not merely static; features like Apple Watch eSIM companion pairing, carrier-level Wi-Fi calling switches, and 5G network slicing are dynamic. Carriers control these using the GSMA TS.43 Service Entitlement Configuration protocol.

Carrier configurations specify the URL of an Entitlement Server. The OS interacts with this endpoint using HTTPS REST queries formatted with EAP-AKA authentication tokens:

POST /entitlement/v1/services HTTP/1.1
Host: entitlement.carrier-core.net
User-Agent: iOS/17.4 CommCenter/Entitlements
Content-Type: application/json

{
  "app_id": "com.apple.commcenter",
  "service_names": ["VoWiFi", "CompanionMultiSIM", "5GStandalone"],
  "device_info": {
    "terminal_vendor": "Apple",
    "terminal_model": "iPhone15,2",
    "terminal_sw_version": "21E219"
  }
}

The server returns a signed JSON or XML payload containing entitlement tokens and status flags:

{
  "status": 1000,
  "services": {
    "VoWiFi": {
      "status": 1,
      "ePDGFQDN": "epdg.epc.mnc001.mcc001.pub.3gppnetwork.org"
    },
    "5GStandalone": {
      "status": 0,
      "rejection_reason": "PROVISIONING_REQUIRED"
    }
  }
}

If the carrier configuration server returns status: 0 for 5GStandalone, the device operating system actively suppresses the baseband from attempting RRC Connection Requests to 5G NR (New Radio) gNodeB base stations operating without an LTE anchor, irrespective of raw signal availability.

5G Standalone, Network Slicing, and Modern Edge-Routing Overrides

As cellular architectures migrate to pure 5G Standalone (3GPP Rel-16 and Rel-17), carrier configurations have expanded to include User Equipment Route Selection Policies (URSP).

Network slicing enables a single mobile terminal to split traffic into independent logical networks:

Slice 0 (Default eMBB): General internet browsing.
Slice 1 (Low-Latency URLLC): Enterprise internal routing, remote compute, or low-latency cloud engines.
Slice 2 (Dedicated IMS): Telephony voice signaling.

The carrier profile decodes these policies by assigning explicit Single Network Slice Selection Assistance Information (S-NSSAI) criteria to specific application identifiers:

Carrier configurations supply the baseband modem’s URSP engine with rules detailing how Android UID groups or iOS NetworkExtension frameworks bind outgoing sockets to hardware cellular bearers. If these tables are corrupted, the socket router fails to instantiate the secondary PDU (Protocol Data Unit) session, dropping enterprise packets entirely.

Practical Implications for Mobile Systems Engineers

Decoding carrier configurations strips away the mystique surrounding modern baseband behavior. For mobile developers and security researchers, inspecting these profiles provides concrete architectural answers:

Diagnostic Accuracy: Rather than assuming sporadic cellular dropouts are hardware defects, engineers can trace RRC connection failure to misconfigured T300 / T310 baseband timers inside the carrier definition.
Bypassing Arbitrary Hotspot Locks: On open platforms, identifying the type-mask configurations in telephony.db explains how mobile OSes segregate tethering traffic via separate radio network interfaces with distinct DSCP markings.
Validation of Private 5G Deployments: When setting up CBRS or Private 5G Core networks (such as Open5GS or free5GC), consumer devices often refuse to register on non-standard PLMNs. Deconstructing existing carrier bundles allows engineers to construct valid SIM profiles and local carrier configuration overrides that pass OS validation.

As baseband ecosystems transition toward software-defined cellular stacks, the boundary between network operators and operating system platforms continues to blur. Carrier bundles are the definitive configuration layer executing that dynamic relationship.