Cellular SMS Telemetry: PDU Decoding, Smishing Detection & Baseband Message Pipelines

Short Message Service (SMS) remains the most ubiquitous cellular communication protocol globally, operating across every generation of mobile technology from legacy 2G networks to modern 5G New Radio. While smartphone users view text messages through rich graphical applications, the underlying transport relies on compact, binary Protocol Data Unit (PDU) frames routed through carrier Short Message Service Centers (SMSC). Modern telematics and mobile safety engines must decode raw PDU structures, navigate operating system intent sandboxes, and detect sophisticated phishing (smishing) threats in real time.

The Architecture of SMS Transmission: PDU Mode vs. Text Mode

Cellular baseband processors interface with SIM smart cards and network towers using standardized AT commands (Hayes command set extended under 3GPP TS 27.005). When receiving or transmitting cellular messages, modems operate in either basic ASCII Text Mode or binary Protocol Data Unit (PDU) mode.

While Text Mode simplifies human debugging over serial interfaces, production cellular telemetry and carrier routing operate exclusively in PDU mode. A PDU is a serialized hexadecimal bitstream encapsulating both message metadata and the message payload within a strict 140-byte radio transport envelope (3GPP TS 23.040):

Carrier Gateways and the SMPP Protocol

Between carrier core networks and external enterprise telemetry applications, messages travel over Short Message Peer-to-Peer (SMPP v3.4 / v5.0). Operating over TCP/IP sockets, an External Short Message Entity (ESME) connects directly to carrier SMSCs:

* Session Binding: The ESME establishes authenticated sessions using bind_transceiver, bind_transmitter, or bind_receiver PDUs.

* Message Delivery: When a subscriber sends an SMS, the SMSC wraps the decoded PDU into a deliver_sm PDU containing the MSISDN (sender phone number), destination shortcode, and payload.

* Delivery Receipts (DLR): The carrier returns asynchronous delivery status reports (receipted_message_id, delivery timestamps, error codes), allowing monitoring platforms to verify message transmission down to the radio interface level.

Android Ingestion Pipelines: SMS_RECEIVED vs. Default SMS Role

On Android devices, operating system security controls govern how background security and telemetry applications access incoming cellular messages. Prior to Android 4.4, any application with the RECEIVE_SMS permission could intercept and abort SMS broadcasts. Modern Android architectures enforce a strict dual-broadcast model:

1. Telephony.Sms.Intents.SMS_DELIVER_ACTION: Dispatched exclusively to the user-selected default SMS application. This broadcast is ordered and cannot be intercepted by background utilities, ensuring that primary messaging functionality remains reliable.

2. Telephony.Sms.Intents.SMS_RECEIVED_ACTION: Dispatched to all registered background applications holding the android.permission.RECEIVE_SMS runtime permission. This broadcast is non-abortable, allowing monitoring, parental safety, and threat detection engines to inspect incoming PDUs asynchronously without altering the default dialer or messaging app.

// Android Kotlin Snippet: Intercepting and decoding incoming SMS PDUs
class SmsTelemetryReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Telephony.Sms.Intents.SMS_RECEIVED_ACTION) {
            val bundle = intent.extras ?: return
            val format = bundle.getString("format")
            val pdus = bundle.get("pdus") as? Array<*> ?: return
            
            for (pduObj in pdus) {
                val pduBytes = pduObj as ByteArray
                val smsMessage = SmsMessage.createFromPdu(pduBytes, format)
                
                val sender = smsMessage.originatingAddress ?: "UNKNOWN"
                val body = smsMessage.messageBody
                val timestamp = smsMessage.timestampMillis
                
                // Dispatch message to real-time smishing evaluation worker
                evaluateSmishingThreat(context, sender, body, timestamp)
            }
        }
    }
}

Real-Time Smishing Detection and Natural Language Heuristics

SMS phishing ("smishing") has evolved into the primary delivery mechanism for banking trojans, credential harvesting campaigns, and parcel delivery scams. Because SMS lacks built-in sender verification (permitting alphanumeric sender ID spoofing across unhardened networks), telemetry engines deploy real-time heuristic filters on the device.

High-precision detection engines evaluate three primary threat vectors:

* Urgency & Threat Lexicon Matching: Algorithms scan tokenized message bodies against curated dictionaries of social engineering triggers ("account locked", "immediate verification required", "unauthorized charge", "warrant issued").

* URL Obfuscation & Homograph Analysis: Attackers frequently deploy Internationalized Domain Names (IDN) with Cyrillic homoglyphs or URL shorteners (e.g., bit.ly, tinyurl) to disguise malicious destinations. The telemetry parser unshortens redirects via asynchronous HTTP HEAD requests and inspects the terminal domain against threat intelligence feeds (PhishTank, Google Safe Browsing).

* Sender Reputation & Shortcode Verification: Commercial banks and government agencies broadcast strictly from verified 5-digit or 6-digit carrier shortcodes. If an alert claiming to be an official tax authority originates from a standard 10-digit virtual VoIP number, the heuristic engine flags the message as an impersonation attempt, alerting users before malicious links are opened.

Multipart Concatenated SMS and User Data Header (UDH) Assembly

When an SMS message exceeds the single-segment capacity (160 characters in GSM 7-bit or 70 characters in UCS-2), cellular carriers divide the text across multiple discrete PDU transmissions using Concatenated SMS. To signal multi-segment delivery to the receiving terminal, the First Octet in the PDU sets the User Data Header Indicator (UDHI) flag bit to 1.

When UDHI is asserted, the first bytes of the User Data payload are reserved for a standardized binary control header known as the User Data Header (UDH). In a standard 8-bit concatenated sequence (3GPP TS 23.040 Section 9.2.3.24.1), the UDH consumes 6 bytes (or 7 septets) structured as follows:

* IEI (Information Element Identifier): Set to 0x00 (8-bit reference number) or 0x08 (16-bit reference number) indicating concatenated message signaling.

* IEDL (Information Element Data Length): Defines header parameter length (typically 0x03 for 8-bit or 0x04 for 16-bit identifiers).

* Reference Number: A shared pseudo-random transaction ID grouping all constituent fragments of the parent message.

* Total Segments & Sequence Number: Respectively indicate the total number of parts (up to 255) and the 1-based index of the specific fragment.

Because the 6-byte UDH reduces available payload capacity from 140 bytes down to 134 bytes, each concatenated segment accommodates only 153 GSM 7-bit characters ($134 \times 8 / 7 = 153.1$) or 67 UCS-2 characters. Telematics and endpoint security engines must maintain a stateful reassembly cache equipped with Time-to-Live (TTL) expiration algorithms. This ensures that fragments arriving out of order across 5G-to-LTE carrier handover events are seamlessly reconstructed prior to threat analysis.