SMS Encoding and Mobile Phone Hex Dumps

1
SMS Encoding and Mobile Phone Hex Dumps
2
TOPICS

• How SMS is Encoded
• A brief overview of mobile phone hex dumps
• CLiVE

3
SMS Encoding

• SMS messages are sent in either text mode or
  Protocol Description Unit (PDU) mode
• Text mode is unavailable on some phones and is
  simply the endoding of the bit stream represented
  by the PDU mode
• The phone will choose the appropriate encoding
• PDU format is specified in documents GSM 03.40
  and GSM 03.38 (www.etsi.org)

4
SMS Encoding
WARNING-HEX AHEAD!!!
5
SMS Encoding

• PDU encoding includes the following information
• The message itself
• SMS service  center
• The time stamp
• It is all in the form of hexadecimal octets or
  decimal semi-octets.

6
SMS Encoding

• Message received on a Nokia 6110 (message
  hellohello)
• 07 917238010010F5 BC87238880900F1000099309251619
  58003C16010
• This octet sequence consists of three parts An
  initial octet indicating the length of the SMSC
  information ("07"), the SMSC information itself
  ("917238010010F5"), and the SMS_DELIVER part
  (specified by ETSI in GSM 03.40).

7
SMS Encoding

• All preceding octets are hexadecimal 8-bit
  octets,  except the Service center number, the
  sender number and the timestamp they are decimal
  semi-octets. The message part in the end of
  thePDU string consists of  hexadecimal 8-bit
  octets, but these octets represent 7-bit data
• The semi-octets are decimal, and e.g. the sender
  number is obtained by performing internal
  swapping within the semi-octets from "72 38 88 09
  00 F1" to "27 83 88 90 00 1F
• The length of the phone number is odd, so a
  proper octet sequence cannot be formed by this
  number. This is the reason why the trailing F has
  been added. The time stamp, when parsed, equals
  "99 03 29 15 16 59 08",  where the 6 first
  characters represent date, the following 6
  represents time, and the last two represents
  time-zone related to GMT.

8
SMS Encoding
How Content is Encoded
9
SMS Encoding

• Assumptions
• PDU format compresses 8 ASCII characters into 7
  bytes.
• We are using a GSM-standard ASCII alphabet, with
  a maximum character value of 127 (decimal) / 7F
  (Hex)

10
SMS Encoding

• First well take an 8 letter/character phrase and
  place it in a table

11
SMS Encoding

• Now we will convert the ASCII to its hex
  representation

12
SMS Encoding

• From here we need to convert our hex values into
  their binary equivalents

13
SMS Encoding

• Now we need to squeeze the message into seven
  spaces. Therefore redundant bits are dropped
• We have assumed a 128 bit character alphabet and
  thereby can drop the left most significant bit
  which is shown in red in the next graphic

14
SMS Encoding

• Left most significant bit
• Left most significant bit removed
• You are left with 8 SEPTETS and can now begin to
  squeeze the characters down into 7 OCTETS.

15
SMS Encoding

• In order to begin populating the 7 octets we need
  to start doing some bit shifting
• We start by shifting the least significant bit of
  the second septet into the most significant bit
  of the first octet

16
SMS Encoding

• The least significant bit of septet two
• to
• The most significant bit of octet one

17
SMS Encoding

• But now we have a problem.the second octet is
  short two bits
• So in order to fully populate the second octet we
  take the two least significant bits of the third
  septet and make them the two most significant
  bits of octet two
• See a pattern?

18
SMS Encoding

• Octet two
• Octet three
• Octet four

19
SMS Encoding

• Octet five
• Octet six
• Octet seven

20
SMS Encoding

• Now from our binary values we calculate new hex
  values

21
SMS Encoding

• So from this hex value
• 426520476E6E6421
• We derive the following PDU encoding
• C232E8E8789343
• The code recycles every 7 octets (8 septets)
• To decode the PDU encoding simply reverse the
  process

22
Hex Dumps of Mobile Phones
23
Hex Dumps

• Using what is commonly known as a flasher the
  physical file system of a mobile unit can be
  dumped
• Potentially dangerous because not designed for
  forensic work-push the wrong button and youve
  just made the mobile phone a brick

24
Hex Dumps

• From a practitioners point of view a Hex Dump
  is snapshot of entire contents of the handsets
  memory.
• We are all striving to grab this data, preserve
  it and analyze in the hope of finding information
  normally hidden from view and or deleted data. It
  may also alleviate the problems caused by
  querying the handsets using AT commands causing
  changes to the handsets memory. If we can image
  the handset as we can Hard Drives or other forms
  of media we can preserve best evidence.
• Most of Mobile Phone Forensic examination
  applications are a progression of backup
  software that concentrates on the users data
  and booting up the device to get it.

25
Hex Dumps

• Common flashing devices
• UFS tornado
• Griffin box
• Vygis box
• Dream box

26
Hex Dumps
27
Hex Dumps

• We are going to concentrate on nokia handsets
  (series 30)
• Physical memory of a nokia handset is called PM
  (Permanent Memory)
• Saved as text files

28
Hex Dumps
29
Hex Dumps

• You need to interpret the hex showing in the text
  file to find information
• Software is being developed to assist in the
  interpretation of the data (UK LEO)
• Called CliVE, it interprets data from the hex
  dumps and allows for export to an excel
  spreadsheet
• Currently CLiVE interprets hex dumps from Nokia
  Handsets (Series 30)

30
Hex Dumps
CLiVE Demo
31
Resources

• www.phone-forensics.com
• http//www.dreamfabric.com/sms/
• http//home.student.utwente.nl/s.p.ekkebus/portfol
  io/resource/sms_pdu.html
• http//www.etsi.org

32
Questions?

• Special Thanks Goes Out To
• Detective Constable 3359 Steve Hirst
• Hi Tech Crime Unit, West Yorkshire Police
• P.O. Box 9, Wakefield WF1 3QP, United Kingdom
• Detective Constable 2919 Steve Miller
• Hi Tech Crime Unit, West Yorkshire Police
• P.O. Box 9, Wakefield WF1 3QP, United Kingdom
• Email wyphtcu_at_googlemail.com
• For their generous support, diligent hex parsing
  and outstanding how-tosCheers Mates!

And all the great minds at Phone-Forensics.com
without whom this presentation would not be
possible!
33
Contact

• Michael Harrington
• m.harrington_at_northpenguin.com
• 517.449.9835