This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

decoding GSM_SMS to get plain text SMS Text

0

Hi,

I just try to capture GSMTAP packets from my OpenBTS. unfortunately I could not get SMS content as plain text. only looks symbol etc (seems still encoded). anybody know how to figure out this problem?

some sources said with standart wireshark they could get content sms in plain text. I had tried to copy its hex stream and decode with 7bit encoder which was provided online, but the result was same, I got nothing.

hex stream: 0000001b0405a10017f100 TP-User-Data: SMS TExt : @@@x@ @pa.Di

Many Thanks, Bass

asked 06 Mar '15, 01:48

bass's gravatar image

bass
0225
accept rate: 0%

Could you share your pcap file? At first glance the decoding seems to make sense as the 0000000b character is @. Are you sure this hex stream corresponds to the TP-User-Data?

(06 Mar '15, 06:11) Pascal Quantin

alt text

I dont know how to upload my pcap file here, sorry. But, this is the print screen..

(07 Mar '15, 00:05) bass

You cannot attach captures to ask, but should either upload it on a file sharing site like dropbox & co, or upload it to http://www.cloudshark.org and share the link here. Given the dissection you get, this does not seem to be a valid GSM SMS TPDU (invlaid TP-Service-Center-Time-Stamp, invalid TP-User-Dala-Length, ...). This could be a bug in the old Wiresahrk version you use, or a wrong logging done by your OpenBTS software.

(07 Mar '15, 00:48) Pascal Quantin

sorry for inconvinience, hre the link:

https://drive.google.com/open?id=0B2PfFt7P5kAgcjJaQUNBeVFuMGM&authuser=0

many thnks,

(07 Mar '15, 02:33) bass

One Answer:

1

The TPDU generated by your SMS gateway seems invalid: the CP-User Data is 35 bytes long, the RP-User Data is 27 bytes long (so everything seems coherent so far) but the TP-User-Data-Length indicates a SMS of 161 characters. This is wrong for 2 reasons: a SMS cannot be more than 160 characters otherwise it needs to be segmented, and there is only 11 bytes left in the message (so 12 characters in 7-bits encoding). Moreover the SMSC timestamp field is completely buggy: the value for the month field is 94!

I do not see any Wireshark bug here, but a buggy TPDU payload.

answered 07 Mar '15, 06:15

Pascal%20Quantin's gravatar image

Pascal Quantin
5.5k1060
accept rate: 30%

hmm. so it means that error comes from openbts sms? what possibility of caused? anyway thnks for your information.. I'll try to send sms and capture again.

(07 Mar '15, 06:53) bass

I do not know anything about openbts, but I can tell you that the SMS DELIVER TPDU is definitely malformed.

(07 Mar '15, 07:06) Pascal Quantin

Hi Pascal,

I have re-install my openBTS, with the latest version 5.0. sending SMS again then captute its packet. no "symbol" shown more. But in TP-User-DaTA just showed "Short Messages body". please take look..

here is my pcap file..

https://drive.google.com/file/d/0B2PfFt7P5kAgWjg0bW5VX19jWXc/view?usp=sharing

Manythanks, bass

(24 Mar '15, 22:40) bass

It shows only "short message body" because the character set used is 8 bits, which can be used both for a text (even if usually SMS are more using 7 bits GSM or UCS 2 encoding). A newer release of Wireshark would display the corresponding hex stream: 91:26:18:48:54:00:f9:27:11:aa:07:81:00:19:11:f1:00:00:ff:1e:d4:f2:1c:a4:ae:9f:c3 Which does not correspond to an ASCII text. Wireshark would display the text for 7bits GSM or UCS2 encoding.

(25 Mar '15, 00:15) Pascal Quantin

The second SMS (frame 5082) uses 7 bits GSM encoding, the the length of the SMS is 0: TP-User-Data-Length: (0) no User-Data

(25 Mar '15, 00:17) Pascal Quantin