Question

I have written a program to decode a CDMA 3GPP2 point-to-point SMS message. I tested it on a couple CDMA PDU hex strings I found on the internet, and it works perfectly. However, when I try to implement it on all incoming text messages on the Android platform, it always fails.

I took a look at the incoming PDU, and it doesn’t seem to follow the same pattern I have been used to seeing. Can anyone explain what format this PDU is in, or what I am missing to correctly decode this PDU? Is there additional header or fields I am not taking into account?

Example PDU pulled from a incoming text message on my phone:

000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000

All of the CDMA pdus I found and tested my parser on look more like:

00000210020207028CE95DCC65800601FC08150003168D3001061024183060800306101004044847

Carrier: Verizon
Phone: Samsung Galaxy S Fascinate running Android 2.3.3

Answer 1

See the javadoc from $SDK/sources/android-16/com/android/internal/telephony/cdma/SmsMessage:

/**
 * Creates byte array (pseudo pdu) from SMS object.
 * Note: Do not call this method more than once per object!
 */

…so it’s not following any particular CDMA standard. You can decode it however; so in fine ASCII art:-

000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
--------messageType     --digitMode                   --------bearerReply   ------------------------------------------------------bearer data
        --------teleService --ton --------------------src     --replySeqNo  --messageID --msts          --userdata
                --------serviceCategory                         --errorClass  --len   --XX--len           --len
                          --numberMode                            --causeCode   ------      ------------2012/06/24 20:56:11
                              --npi                                 --------bearerDataLength                ----------------------userdata
                                --len                                           

Note that I think you made a cut/paste error in your message – the 00 byte marked ‘XX’ I think shouldn’t be there – luckily it’s easy to spot the date and work backwards. So this is a message from 6789101674 with userdata:

104C2CF9F3F5EBD73E7000, the first five bits of which show that it’s 7-bit encoded (0x02). Having shifted the remainder of the userdata 5 bits to the left, we’re left with:

09859f3e7ebd7ae7ce00
--len(septets) 9 septets == 63 bits, so we expect 8 bytes of body
  ----------------7bit-body

So your 7bit-body decoded is “Bggguuugg”.