Introduction

“533 million Facebook users’ phone numbers leaked” was one of the highlighted titles that flooded many social networks’ pages. The leak that was initially for sale in 2020 has more recently been released for free on a hacker forum containing mobile numbers, and a bunch of other related information. This news gave birth to websites like https://haveibeenzucked.com, where you could check if the Facebook data leak contained your data. (https://haveibeenpwned.com allows you to check it now as well).

What can they do with my phone number? – Do I need to change my phone number? – The leak is not so serious, they do not have my Facebook password – Were the thoughts expressed by many carefree victims.

Unfortunately, despite the huge impact concerning user privacy, an additional caveat of this event is that this information could be used for multiple malicious purposes such as scam calls, stalking, insurance market studies, and political actions against the population. I wondered about these issues and what was possible in the context of just having a target’s phone number. So, in this post, I’ll dive into some SIM card-related research where I’ll cover some of the physical, software, and other attack avenues available.

Attacks Using Just A Phone Number

Considering the Facebook data breach, we all know that this information would help build a solid and useful springboard for performing multiple attacks, including but not limited to:

Social Engineering attacks – A well-known technique used for retrieving information through human interactions, where the attacker guides the victim to reveal sensitive information after a study of a person’s individual behaviour, in this case on the web. Often, the victim ends up giving away sensitive information after being tricked by psychological manipulation tactics. This could be achieved by one (or multiple) phone calls and/or SMSs. These attacks are often performed by spoofing a number so the victim will recognise the call or the SMS sender as legitimate.

SMS Re-Routing attacks – A while ago, a hacker named Lucky225 highlighted a carrier issue that allowed someone to receive/access an SMS that was intended for another person. Not to be confused with SIM swapping or SMS Hijacking, this discovery rather emerged thanks to a bug in the Sakari platform. Sakari is a trading company offering SMS re-routing, SMS marketing, and mass messaging services for businesses. Apparently, the lack of a two-factor authentication mechanism affecting the Sakari platform allowed Lucky225 to read all the SMSs of a target phone number. Indeed, attackers could read all the victims’ SMSs by simply adding their phone numbers to the platform, and with just a few dollars, they could pretend to be the owner. To be honest, I did not know about these kinds of attacks until I landed on this article: https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakari-netnumber. Driven by curiosity, I tried to create an account on https://sakari.io but, at the time of this blog post, it was no longer possible. Despite the fact that there could be other similar companies out there, many carriers such as AT&T, Verizon, and T-Mobile already mitigated this loophole. Sakari also finally implemented a multi-factor authentication/verification solution.

SIM Swap – This is a technique where bad actors act as the owner of a certain phone number and, with the help of fake documents, manipulate carrier operators who end up transferring ownership onto a new SIM card, hence a new phone number. This operation could allow for an account takeover or, in the worst case, illicit money transactions.

SIM Hijacking (SIM Jacker) – This is a vulnerability announced in 2019 that still affects many SIM cards. The attack involves one or more SMS’s sent to the victim that, by carrying malicious instructions specially crafted for attacking a SIM card applications named S@T Browser (or others), could trigger SIM card events. As a result, logic manipulation on the handset (e.g, the mobile phone) would be achievable. I spent a bit of time researching this matter to fully understand it and, below is a summary of what I understood, what I managed to accomplish, and what I did not do during this journey.

I need to stress the fact that a license is required to perform tests on a real phone system network. Any kind of unsolicited phone system network test is against the law. Tests not permitted without a valid license could range from those where altering the radio frequency channels is involved to sniffing phone system data and more.
It is highly recommended that you understand what you are doing prior to any kind of test. Needless to say, this blog also does not condone illegal testing.

Subscriber Identification Module (SIM)

A SIM card (Subscriber Identification Module ), also known as UICC (Universal Integrated Circuit Card), is a little computer that, despite its dimension, permits very fast and efficient wireless communication between subscribers around the world. The below graph should be enough to give you an idea of how many SIM cards are used nowadays based on smartphone sales worldwide.

A SIM card is effectively a little computer where various bits of data are stored and can be managed. The data stored in a SIM card ranges from the Authentication key (Ki), a 128-bit value used for authentication to a mobile network, to a unique number (64-bit) known as International Mobile Subscriber Identity (IMSI) that permits the identification of subscribers located in an enclosed Cellular Network. A Cellular Network is composed of one (or more) Cell Tower and/or a Base Transceiver Station (BTS) and allows for voice and data transmissions. Sometimes, cellphone radio signal coverage could reach as far as 8 km, depending on the area.

SIM cards may also contain phone contacts and other user-specific data. Emergency numbers such as 112, 113, and/or 991 are also saved on the SIM card.

A SIM card is therefore a computer available in the pocket of billions of people living in different countries, where, depending on the jurisdiction, communication regulators such as Ofcom, Federal Communications Commission, or AGCOM act as the master with their own encoding and different set of frequencies.

While for some reason phones are getting bigger and bigger, SIM cards have shrunk and evolved over time. For example, this is the size evolution over the years:

• Universal or Full-size SIM 1991/1992 (53.98 x 85.6mm)
• Standard or Mini SIM 1996 (15 x 25mm)
• Micro SIM 2003 (12 x 15mm)
• Nano SIM 2012 (8.8 x 12.3mm)
• Embedded-SIM or eSIM 2016

The contact types of SIM cards may change depending on the manufacturers’ preferences. However, the SIM PIN assignment is always the same for obvious reasons.

While we’re talking about the form factor, in the name of “science”, I have been dissolving SIM cards in acetone too. I don’t have any interesting results from this yet, but the process is quite fun.

Finally, each PIN on the SIM card has a specific function, some of which are for transmitting power and others for data transfer. Some more detail can be seen here: https://pinoutguide.com/Memory/SmartCardIso_pinout.shtml.

Being more interested in the content of a SIM card rather than its physical aspects, I analysed the content of a random one by using the PC/SC terminal Gemalto PC Twin Reader together with a forensic tool named SIMspy II. By checking the output returned by this tool, it was clear that information was stored in a directory structure.

Data on the SUT (SIM Under Test) was organised into a tree hierarchy composed of three types of files:

• Master File (MF)
• Elementary Files (EF)
• Dedicated Files (DF)

A similar directory structure can be found in smart or credit/debit cards and, for this reason, each card is configured by manufacturers with an output message named ATR (Answer To Reset). This message contains information about the card itself, its communication parameters, and protocols. The ATR is used during the card-activation process to identify the supported transport protocol and the communication parameters at the start of each card session – when a SIM card is being accessed, for example.

ATR checks can also be done with an online parser. This can be handy to better understand what information an ATR contains and which kind of card is linked to it. Check the following URL for a breakdown of an ATR: https://smartcard-atr.apdu.fr/parse?ATR=3B9F96801FC68031E073F62113675602220080010127

For the example ATR of 3B9F96801FC68031E073F62113675602220080010127, the following list is a breakdown of some of the important bytes.

1. Byte 1: TS = 0x3B – Forward connection
2. Byte 2: T0 = 0x9F – Format character
3. Byte 3: TA(1) = 0x96 – Interface character
4. Byte 4: TD(1) = 0x80 – Interface character (Information about the supported protocol)
5. Byte 5: TD(2) = 0x1F – Interface character (Information about the supported protocol)
6. Byte 6: TA(3) = 0xC6 – Historical characters (Type of SIM card (C2 normal SIM + OTA, C3: STK SIM …))
7. Byte 7: 0x27 – Card capabilities
8. Byte 8: TCK = 0x27 – Checksum

More details about ATR is available on this page: https://www.programmersought.com/article/85154738501/

The hypothetical top-level directory of the system I was analysing (SUT) was designated by a slash (/) and that is known as the Master File (MF). It contained subordinate directories, otherwise named Dedicated Files (DF), and Elementary Files (EF), where a great number of Mobile Network Operator (MNO) and subscriber sensitive information could be found.
Elementary Files can be Transparent, Linear, or Cyclic. They are pretty simple to understand:

• Transparent: A string of bytes
• Linear-fixed length: A sequence of records
• Linear-variable length: A sequence of records but can have also a variable number of bytes
• Cyclic: A “ring” of records that could be overwritten

After the reception of the ATR, the MF (3F00) is automatically selected and becomes the current directory.

I performed various fuzzing attacks against the SUT by using an open-source security tool called SIMTester, hoping to identify more files, extract more information and ultimately understand their purpose.

Data stored within the SUT was extracted from the identified files by using Application Protocol Data Unit (APDU) commands, aka C-APDU (Command Request APDU). APDU is a command-response protocol used for invoking functions on smart cards or similar devices.

The APDU command structure is composed of two parts:

• Command – 4-byte header (Class, Instruction, Parameter 1, Parameter 2) + data body
• Response – 2-byte (SW1, SW2)
  The response may also contain a string of bytes in the data field of the response. E.g, when extracting data form the smart card or similar devices.

The following is a list of possible APDU commands usable.

• SELECT
• STATUS
• READ BINARY
• UPDATE BINARY
• READ RECORD
• UPDATE RECORD
• SEEK
• INCREASE
• VERIFY ADM 
• VERIFY CHV
• CHANGE CHV
• DISABLE CHV
• ENABLE CHV
• UNBLOCK CHV
• INVALIDATE
• REHABILITATE
• RUN GSM ALGORITHM
• SLEEP
• GET RESPONSE

These commands were sent with the PyAPDUTool, a tool used to communicate with the SIM card via the reader, and allowed me to extract and update the data stored within the SUT.
As an example, the following video shows how to access the Master File 3F00, then the Dedicated File “GSM” (7F20) and finally, the Elementary File “SPN” (6F46), from which the string “giffgaff” in hex format (67 69 66 66 67 61 66 66) could be extracted. At that moment the SUT was labeled “Giffgaff” (Giffgaff is a mobile network headquartered in the UK). The last two bytes (90 00) at the end of the output is the response data (SW1, SW2) indicating the APDU command was successfully executed and without errors.

The next video, instead, shows how to update a phonebook entry on the SUT using all of the tools I have mentioned up to now. Note that, physical access to the SIM card is required.

PyAPDUTool provides a useful utility that I used to parse part of the response data, that is a trailer of 2 bytes defined as SW1 (Status byte 1 – Command processing status) and SW2 (Status byte 2 – Command Processing Qualifier). The PyAPDUTool’ SW Lookup utility returns a reference message when using valid SW trailers and helped me to better understand what I was doing. For a non-valid SW trailer, the reference message returned was “Unknown Error”. Some examples of how the SW responses were interpreted by the PyAPDUTool’ SW Lookup utility can be found below.

Consult the following URL for more details about APDU commands: https://cardwerk.com/smart-card-standard-iso7816-4-section-6-basic-interindustry-commands

AT Commands

Some of the SIM card data can also be manipulated using AT commands, also called Attention Commands (A command language originally used for modems, see the Hayes command set). For this step, it is necessary to have a modem. The following is a picture showing what I usually use:

Nevertheless, any ME that supports AT commands will work as well. Still, physical access to the SIM card is required. Some guidance on how to ensure the device is compatible and supports AT command is below.

/*
1. Connect your phone to a computer host via USB.
2. Open a terminal
*/
lsusb -v|less

At this stage, to establish communication with the modem I used Minicom:

Run
1. Open terminal
minicom -D /dev/ttyACM0

Minicom commands can be called by pressing CTRL+A <key>.

Press
/* Open Minicom Helper */
CTRL+A Z

/* Turn ON/OFF Echo (repeat this step twice if you see double input) */
E

Below there are some examples of AT commands to extract information from the SIM card:

// Temporary Mobile Subscriber Identity (TMSI)
// Only first 8 characters (4 bytes)
AT+CRSM=176,28448,0,0,11

// Ciphering key Kc
// Remove last two characters (1 byte)
AT+CRSM=176,28448,0,0,9

// ARFCN
// The second value
AT+KCELL=0

Consult the following page for more details about AT commands: https://www.electronicsforu.com/resources/gsm-at-commands

SIM Application Toolkit (STK)

Some SIM cards have extra features that allow remote access to Network Operators for maintenance purposes or for services designed to improve and facilitate the subscribers’ experience (e.g., credit, weather, banking, and more). SIM applets are usually leveraged in fulfilling these tasks. A SIM applet is an application installed on the memory of the SIM card and uses a set of commands and procedures in the STK, which provides mechanisms that allow interaction between the applications installed in the SIM card and any compatible ME in use; Hence, it also provides the ability for outward communications.

Sometimes the STK application can be accessed from the main or the settings menu of the ME. There are a few cases where the use of Unstructured Supplementary Service Data (USSD) codes is necessary to access an STK application (it is usually a combination of digits like numbers preceded and/or followed by the hash # and the star *).

SIM cards provided by the STKs could be also identified by checking the directory named DF_GSM (3F00/7F20), which contains the “GSM SIM service table” which has a list of all of the network-related information. From here it is also possible to gain knowledge about the services in use by the SUT. An example is below:

Some of the services/applications from the example screenshot are:

• SMS-Cell Broadcast Data Download is used for the delivery of a message to all mobile equipment (ME) within a specific area.
• SMS-Point-to-Point Data Download is used to initialize a SIM card.
• Proactive SIM defines the communication protocols between the SIM and the ME. It offers various commands which the SIM could issue directly on the mobile handset, namely: DISPLAY TEXT, PLAY TONE, RUN AT COMMAND, SETUP A CALL, SEND SHORT MESSAGE, SEND DTMF, and, much more.

TAR (Toolkit Application Reference)

For accurate identification of the services/applications in the toolkit mechanism (e.g., SMS-Cell Broadcast Data Download, SMS-Point-to-Point Data Download, Proactive SIM, and more) and to correctly determine the destination for their generated packages, these are associated with a unique range of numbers or values called a Toolkit Application Reference (TAR). This means that TARs are used to uniquely identify services and/or applications. The value of a TAR could range from 000001 to FFFFFF. More details about the TARs’ values and their associated category may be found in the below list:

• Tar: 000000, Category: Card Manager
• Tar: 000001 to AFFFFF, Category: Allocated by the 1st level application issuer
• Tar: B00000 to B0FFFF, Category: Remote File Management (RFM)
• Tar: B10000 to B1FFFF, Category: Payment application
• Tar: B20000 to BFFEFF, Category: RFU
• Tar: BFFF00 to BFFFFF, Category: Proprietary Toolkit Application
• Tar: C00000 to FFFFFF, Category: Allocated by the 1st level application issuer

TARs trigger features and services/applications’ functionalities used by Network Operators to remotely communicate with SIM cards, install additional applications on them, and manage their contents. Data stored within these TARs can not be accessed unless ADM keys are known and provided. The ability to brute force ADM keys is very limited as well, in fact, a maximum of 5-8 attempts are usually allowed. Failing to provide valid ADM keys could cause irreversible malfunction. Moreover, the services/applications must be activated and allocated in order to be used.

Due to poor security implementation, there are cases where some TARs (and their related services/applications) could be remotely accessed without the need of providing ADM keys. This could be accomplished by using a specially crafted SMS. These messages can be quite large, so due to the character limit (140 bytes including the header) of an SMS, it is necessary to concatenate them.

By looking here and there with the hope of getting my hands on, at least, one of those vulnerable ones, I ended up having an insane collection of multiple carriers’ commercial SIM cards. Fortunately, I already had some SIM cards at home from previous research. Despite the fact that some of them were expired and no longer usable on the cellular network, they were still good enough to take a closer look at.
I bought many SIM cards on the Internet (waited months for some). A few were sent by friends living in other countries (on contract and with top-up included <3 ) and more are still on their way (pandemic situation + border issues, etc.). A few SIM cards I bought were very old and sold for “collectors” only; thus, not usable on the network but good for research. For most of them, some credit was required on each SIM card, otherwise, the activation process and further tests were not possible.

I tested more than 60 SIM cards during the course of this research. A breakdown of networks and where they are from follows:

• Giffgaff (United Kingdom) * 16
• Lebara (United Kingdom) * 8
• O2 (United Kingdom) * 6
• T-Mobile (United Kingdom) * 5
• Lyca Mobile (United Kingdom) * 4
• Smarty (United Kingdom) * 3
• VOXY (United Kingdom) * 2
• EE (United Kingdom) * 2
• Vodafone (United Kingdom) * 2
• 3 (United Kingdom) * 2
• Tesco Mobile (United Kingdom) * 2
• Wind Tre (Italy) * 2
• Talk Home (United Kingdom) * 1
• ASDA Mobile (United Kingdom) * 1
• Vodafone (Italy) * 1
• Vodacom (Tanzania) * 1
• Salt Mobile (Switzerland) * 1
• Natel (Switzerland) * 1
• Kölbi (Costa Rica) * 1

It appeared as though many of the SIM cards I had were vulnerable to SIM Hijacking attacks due to unprotected applications. To identify vulnerable applications, I queried all of the TARs used by the applications installed in the SUTs to identify those that returned a response without any security mechanism involved (e.g, KIC and KIK). Various vulnerable TARs were identified by using SIMTester. These TARs were associated with the values dedicated to Remote File Management (RFM) and could potentially be accessed via OTA SMSs but also used for transmitting push commands. Needless to say, each SIM card was produced and released on the market on different dates. Sadly, many vulnerable SIM cards are still available to be purchased. Below is a series of screenshots showing the process of identifying those unprotected TARs, and what SIMtester’s output looks like when testing vulnerable SIM cards.

Testing Setup

I used a limited demo version of NowSMS in the hopes of learning about Over The Air (OTA) and how to remotely trigger services/applications on vulnerable SIM cards with SMSs. NowSMS is an SMS&MMS Gateway solution (449,00USD for the full version, lol).

The NowSMS server software was installed on my laptop (the Gateway) and for the client, I used a Samsung S6 (GSM Modem).

SMSs were sent to a Nokia 3330 (a variant of the famous Nokia 3310) connected to a different laptop by using an F-BUS data cable (Model DAU-05B) and a USB to RS232 converter in conjunction with the dct3-gsmtap utility, running the well-known Wireshark utility to sniff traffic.

This made it possible to capture GSM data (back and forth) after enabling a secret menu named the NetMonitor on the Nokia 3330. This process could be done with a tool called gnokii.

The NetMonitor menu, which is available on various Nokia phones, is composed of a set of displays where a large amount of information about the SIM card, the phone, and the network is accessible. Below is the list of the available displays; more details about the Nokia NetMonitor menu could be found here: http://www.nobbi.com/download/nmmanual.pdf

• Display 1: Serving cell info
• Display 2: More info about serving cell
• Display 3: Serving cell, 1st, and 2nd neighbor
• Display 4 & 5: 3rd to 8th neighbor cell
• Display 6: Network selection display
• Display 7: System information bits for the serving cell
• Display 10: Paging Repetition Period, TMSI, Location Update Timer, AFC and AGC
• Display 12: Ciphering, hopping, DTX Status, and IMSI
• Display 13: Uplink DTX switching display
• Display 14: Toggle Screening Indicator
• Display 17: Switch ‘BTS Test’ Status
• Display 18: Lights status control
• Display 19: Toggle Cell Barred Status
• Display 20: Charging state
• Display 21: Constant voltage charging display
• Display 22: Battery full detection
• Display 23: Battery and phone state monitor
• Display 24: BSI values
• Display 30: Audio API register display
• Display 34: FBUS display
• Display 35: Reasons for SW resets
• Display 36: Counters for resets
• Display 39: Information about reasons for call clearing
• Display 40: Reset handover counters
• Display 41 (Single-band): Handover display
• Display 41 (Dual-band): Handover display, INTER CELL
• Display 42 (Dual-band): Handover display, INTRA CELL
• Display 43 L2 display
• Display 44: Toggle revision level
• Display 45: Toggle transmitter functionality
• Display 51: SIM information
• Display 54: Block display 1
• Display 55: Block display 2
• Display 56: Block display 3
• Display 57: Memory status before reset
• Display 60: Reset counters to zero
• Display 61: Search and reselection counter display
• Display 61 (Dual-band): Search and reselection counter display
• Display 62: Neighbour measurement counter display
• Display 63: Call attempts counters
• Display 64: Location Update attempts counters
• Display 65: SMS attempts counters
• Display 66: SMS timeout counters
• Display 70: Temporary counters of DSP
• Display 71 & 72: Control DSP audio enhancements 1 & 2
• Display 73: Generic display for DSP Audio Enhancements
• Display 74: DSP audio enhancements 1 (DRC)
• Display 75: Audio path status
• Display 76: Ear (= SownLink) audio display
• Display 77: Microphone (= UpLink) audio display
• Display 78: DSP audio enhancements (AEC)
• Display 79: Audio equalizer display
• Display 80: Reset and restart timers
• Display 81: Enable or disable timers
• Display 82: Test timer display
• Display 83: Control of task information displays
• Display 84, 85 & 86: Information about tasks
• Display 87: Information about OS_SYSTEM_STACK
• Display 88: Information on the current MCU and DSP software versions
• Display 88 (Nokia 9210): Version information for organizer part
• Display 89: Information of the current HW and TXT versions
• Display 89 (Nokia 9210): Version information for the phone part
• Display 96 (Nokia 3210): receiver temperature
• Display 99 (Nokia 7110): FBUS mode and Accessory mode
• Display 100 (Nokia 7110, 62XX): Internal memory usage, overview
• Display 102 (Nokia 9210): last data call type
• Display 103 (Nokia 9210): last MT call type
• Display 107 (Nokia 62XX): Voice dialing feature
• Display 110 to 115 (Nokia 7110, Nokia 62XX): Internal memory usage, detail
• Display 130 (Nokia 7110): Slide open counter
• Display 132 (Nokia 3310): Call information
• Display 133 (Nokia 3310): Charger information
• Display 240 (No output): Clear counters and start timers
• Display 241 (No output): Disable the NetMonitor menu
• Display 242 (No output): Disable R&D field test displays

Display 17 is a subsequent hidden option of the NetMonitor menu and it could be enabled by creating a SIM phonebook entry named “BTS TEST” at position 33 of the contact list using the Cell Tower ID number as the contact phone number. This could also be done by using gnokii using the below as a phonebook entry:

// Entry Name; Cell ID, Location; Position; Shortcut
BTS TEST;113;SM;33;5

Display 17 makes it possible to “bind” the ME to a single Cell Tower and, while using this feature, no information is shared with neighboring cells while data can still be sent and received without any problem. Since IMSI catchers profit by creating fake Cell Towers and victims connect to them because of the stronger signal power, surely Display 17 required more investigation.

SHORT MESSAGE SERVICE (SMS)

An SMS could be sent via a ME, a computer, or a server and gets transmitted to a Short Message Service Center (SMSC), which finally routes it to its destination. While the whole process of sending/receiving an SMS could give the impression of something simple, there are a few roles and routes involved that differentiate the SMS type, in fact, Short Message Service is composed of two services:

• Short Message Mobile Terminated (SM MT), this service regards the SMS received on the subscriber ME. In this case, the SMS type is defined as SMS-DELIVER.
• Short Message Mobile Originated (SM MO), this service is about the SMS being sent from the ME subscriber. The SMS type that this action will produce is defined as SMS-SUBMIT.

There could be cases where a subsequent SMS, defined as SMS-STATUS-REPORT, is sent by the SMSC to the ME sender to confirm that the Destination Address (DA) successfully received the SMS.

More details here https://en.wikipedia.org/wiki/GSM_03.40

All outbound SMSs sent using NowSMS were listed in the administrator’s web interface and encoded in a Protocol Data Unit (PDU) format following the GSM 7-bit standard. This meant that all of the PDU SMSs could be analyzed, reversed, customized, and reused.

PDU messages could be sent through a USB modem (or a compatible phone) using Minicom. Below is an example of how to send an SMS-SUBMIT PDU that contains the text “Hello SensePost” using Minicom.

AT+CMGS=27 // Lenght of Octets (70 chars / 2 - 8 SMSC)
>079144872000626001000C9144573227562000000FC8329BFD064DCBEE7919FA9ED301 // Here it is necessary to press Ctrl+Z instead of pressing ENTER

The following is a table describing each part (the octets) of the above payload. SMS PDU decoders can also be easily found online – E.g. https://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-submit-pdu-decoder/. A handy tool to construct the correct payload was also the python module SMS PDU (pip install smspdu).

• Octet: 07, Reference: Length of Address
• Octet: 91, TP Field: Type of Address, Reference: 91 International (81 National)
• Octet: International 448720006260 National 7008022660F (F == padding), TP Field: SMSC, Reference: International (+447802002606)
• Octet: 01, TP Field: TP-MTI, Reference: Message Type Indicator – SMS-SUBMIT (21 SMS-SUBMIT + Request Report Status)
• Octet: 00, TP Field: TP-MR, Reference: Message Reference
• Octet: 0C, Reference: Length of Address in semi-octets
• Octet: 91, TP Field: Type of Address, Reference: 91 International
• Octet: 441122334455, TP Field: TP-DA, Reference: Destination Address (+441122334455)
• Octet: 00, TP Field: TP-PID, Reference: Protocol Identifier
• Octet: 00, TP Field: TP-DCS, Reference: Data Coding Scheme
• Octet: 0F, TP Field: TP-UDL, Reference: User Data Length
• Octet: C8329BFD064DCBEE7919FA9ED301, TP Field: TP-UD, Reference: User Data (Hello SensePost)

The SMSC could also be omitted (00). In this case, it is the default one that will be used. It is saved on the SIM card (EFsmsp – SM service parameters).

Normally, the SMS is automatically saved onto the SIM card once received from the ME. The possibility to delete or keep the SMS is available to the subscriber at a later stage. However, SMS Classes could be used to determine the location where the SMS should be saved.

• Class 0: Using this class the SMS will appear on the receiver’s mobile screen and no user interaction is required. This SMS will be automatically deleted after a very short time (By default is 5 minutes but it could also be set to 0 seconds, resulting in an invisible SMS) unless the user decides to save it. To use this class, the Data Coding Scheme (TP-DCS) field must be set to 10.
• Class 1: This class indicates that the SMS will be stored in the device memory or the SIM card. The TP-DCS field must be set to 11.
• Class 2: This class is used when the SMS message contains SIM card data. For this class, the Data Coding Scheme (TP-DCS) must be set to 12.
• Class 3: This class indicates that the SMS will be forwarded to an external device once received. In this case, the TP-DCS field must be set to 13.

Below is a simple Class 0 PDU SMS (No additional tests were conducted in regards to other SMS Class types) followed by an example of how to abuse this feature.

AT+CMGS=28
0001000C914411223344550010114676788E064D9B53500B34A7D7E96D

While the following would only work on old phones (mostly Nokia), below is an example of WAP OTA service settings that could be sent using an SMS as well.

<!-- TP-USER-DATA -->
<?xml version="1.0"?>
<!DOCTYPE CHARACTERISTIC-LIST SYSTEM "file://c:/settingspush/settings.dtd" >
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GSM/CSD"/>
<PARM NAME="PROXY" VALUE="52.85.104.62"/>
<PARM NAME="CSD_DIALSTRING" VALUE="+44123456"/>
<PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>
<PARM NAME="PPP_AUTHNAME" VALUE="stutm"/>
<PARM NAME="PPP_AUTHSERCRET" VALUE="password123"/>
<PARM NAME="CSD_CALLTYPE" VALUE="ANALOGUE"/>
<PARM NAME="CSD_CALLSPEED" VALUE="AUTO"/>
</CHARACTERISTIC>
<CHARACTERISTIC TYPE="URL" VALUE="https://sensepost.com"/>
<CHARACTERISTIC TYPE="NAME">
<PARM NAME="NAME" VALUE="SensePost:)"/>
</CHARACTERISTIC>
<CHARACTERISTIC TYPE="BOOKMARK">
<PARM NAME="NAME" VALUE="Wap"/>
<PARM NAME="URL" VALUE="https://sensepost.com"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>

// First PDU SMS
AT+CMGS=155
>0051000C9144571651228900F5A78C0B0504C34FC002000304020101062C1F2A6170706C69636174696F6E2F782D7761702D70726F762E62726F777365722D73657474696E67730081EA01016A0045C60601871245018713110335322E38352E3130342E36320001872111032B343431323334353600018722700187231103737475746D00018724110370617373776F726431323300018728720187

// Second PDU SMS
AT+CMGS=123
>0051000C9144571651228900F5A75D0B0504C34FC0020003040202296A01018607110368747470733A2F2F73656E7365706F73742E636F6D0001C608018715110353656E7365506F73743A29000101C67F0187151103737475746D3A2900018717110368747470733A2F2F73656E7365706F73742E636F6D00010101

Conclusion

In this post, we looked at a lot of SIM card-related things which included some physical aspects, software internals (incl. how to interact with and test applications on a SIM card), and finally some SMS-related information to send your own crafted SMSs.

I’ll tell you more about that adventure while I am working on the second part of this blog post.

PS: If you want to contribute you can send 0ne or more SIM cards from your country. Any kind of help is more than welcome. :)

Thanks for reading.

Proudly made by one of those lazy Italians.
HAPPY HACKING! <1337