Cinterion®
EHS5
3G
UMTS/HSPA Module Research

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 1 of 82

Table of contents
1

Abstract....................................................................................................................... 42

Overview ..................................................................................................................... 53

Modem description...................................................................................................... 6
3.1 Modem software components ..................................................................................6
3.2 Types of MIDlets ......................................................................................................6
3.3 Software update .......................................................................................................7
3.4 Installing MIDlets on the modem ..............................................................................7
3.5 Debugging MIDlets and modem execution ..............................................................94

Information security assumptions regarding the modem ........................................... 12
4.1 MIDlet security .......................................................................................................12
4.2 Modem OS security ...............................................................................................12

5

Obtaining modem firmware ....................................................................................... 14
5.1 Building a logical image of firmware .......................................................................15
5.2 Analyzing the contents of the UFS .........................................................................20

6

Analysis of MIDlets security ...................................................................................... 25
6.1 FTP client security .................................................................................................25
6.2 Getting information about internal FS paths via a static method inside a custom
MIDlet .............................................................................................................................25
6.3 Getting information about internal FS paths from a user MIDlet via a standard
FileConnector call...........................................................................................................26
6.4 Changing the security domain of a custom MIDlet .................................................27

7

Modem OS security .................................................................................................. 29
7.1 Selecting interfaces for research............................................................................29
7.2 Researching modem AT commands ......................................................................29
7.3 Vendor-specific AT commands ..............................................................................31
7.4 Fuzzing AT commands ..........................................................................................41
7.5 SMS message processing .....................................................................................45
7.6 OTAP protocol analysis .........................................................................................52
7.7 ULP protocol analysis ............................................................................................54
7.8 How to read memory very, very slowly ..................................................................58
7.8.1

HeapFree and HeapBase structures ................................................................59

7.8.2

Memory map ....................................................................................................61

7.8.3

Reading memory via a heap overflow ..............................................................62

7.8.4

Getting the overflow context.............................................................................63

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 2 of 82

7.9 Write primitive ........................................................................................................64

8

7.9.1

Free function ....................................................................................................64

7.9.2

Thread structure...............................................................................................66

7.9.3

HeapBase structure .........................................................................................68

7.9.4

Strategy for handling free and occupied chunks ..............................................69

7.9.5

Selecting a new chunk .....................................................................................69

7.9.6

Releasing an occupied chunk ..........................................................................69

7.9.7

Processing fragmented SMSes ........................................................................70

7.9.8

Specifics of processing each WAP message ...................................................72

7.9.9

Putting it all together ........................................................................................73

Post exploitation of network level vulnerabilities ....................................................... 74
8.1 Executing AT commands .......................................................................................74
8.2 Code execution? ....................................................................................................76
8.3 Configuring the MMU .............................................................................................77
8.4 SMS FS and OTAP activation ................................................................................77

9

CVE list ..................................................................................................................... 81

10Conclusion ................................................................................................................ 82

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 3 of 82

1 Abstract
Modems play an important role in enabling connectivity for a wide range of devices. This
includes not only traditional mobile devices and household appliances, but also
telecommunication systems in vehicles, ATMs and Automated Process Control Systems(APCS).
When integrating a modem, many product developers do not think of protecting their device
from a potential modem compromise. As one of the main communication channels for theend device, the modem not only has access to the information flow between the device andthe outside world, but may also have almost unlimited access to the end device’s mostcritical systems and resources. Thus, modem security is of vital importance.
To make the problem worse, when a critical vulnerability is discovered in just one modem
model and version, a significant amount of time may be required to update all the devices
in which it is installed. And some of them may even not have a remote modem updating
feature at all, such as a car's Telematic Control Unit (TCU). In such cases, installing the
update typically requires additional effort and expense for the manufacturer of the end
product to manually address each vulnerable device or vehicle.
For this reason, a particular modem manufactured by Cinterion caught our interest. When
we began our assessment, the only known registered vulnerability was CVE-2020-158581,
which is described in greater detail elsewhere2.
We ultimately discovered several vulnerabilities, two of which are considered critical. One
allows remote execution of arbitrary code at the level of the modem OS via sending speciallycrafted SMS messages to it. The other vulnerability allows local execution of an unsigned
MIDlet with vendor privileges on the modem. When combined, the identified vulnerabilities
allow an attacker to remotely obtain full control over the modem.

12

https://www.cve.org/CVERecord?id=CVE-2020-15858
https://threatpost.com/flaw-affecting-millions-iot-devices/158472/

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 4 of 82

2 Overview
Section 3 provides general information about the modem. In this section, we describe themodem’s user features, ways to interact with it according to the documentation, as well as
its hardware components.
Section 5 outlines the algorithm for recovering the modem firmware from its ROM image.
The recovery process involved reading the modem's NAND memory using a programmer,
followed by reconstructing the logical image of the modem ROM sections from the extracted
physical dump.
Section 6 focuses on evaluating the security of the MIDlets. It examines various attack
vectors and outlines the potential impacts of exploiting the identified vulnerabilities.
Section 7 contains a detailed analysis of the security of the modem OS. It explains how an
attacker can execute malicious code on the modem CPU by sending a few specific SMS
messages.
Section 8 focuses on code execution on the modem. It discusses the specifics of the modem
CPU's internal architecture and outlines the method for executing arbitrary code within thecontext of any modem OS process.
Section 9 contains a list of all the discovered vulnerabilities with their respective CVEs andcriticality scores.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 5 of 82

3 Modem description
The study focused on the EHS5-E series modem, originally manufactured by Thales before
the business unit was acquired by Telit. Several modem models from this vendor sharesimilar software and hardware architectures. Therefore, the findings of this study apply todevices across multiple model series:
•
•
•
•
•

Cinterion BGS5
Cinterion EHS5/6/7
Cinterion PDS5/6/8
Cinterion ELS61/81
Cinterion PLS62

According to the software model, the modem consists of four software components:••••

Firmware (FW)Application (App)Java Remote Control (JRC)
Service LWM2M Agent (SLAE)

3.1 Modem software components
The modem is provided to device developers along with an SDK for creating software
components that execute business logic, known as MIDlets. The firmware (FW) andapplication (App) components form part of the modem's low-level code, containing themodem's operating system and the execution environment for user MIDlets. A MIDlet is aJava application supported by a specialized subsystem, Java ME (Micro Edition), whichfeatures a limited set of Java commands. The JRC and SLAE components are special
MIDlets developed by the manufacturer.
The user is provided with the ability to install MIDlets independently and to configure thesecurity settings for their execution. The following security mechanisms are used forMIDlets:••

Java bytecode checks during installation (always enabled)
MIDlet digital signatures (configured by the endpoint developer)

By default, only the manufacturer certificate is installed on the modem to validate MIDlets
with manufacturer-level execution privileges. Installing and configuring certificates forcustom MIDlets is the responsibility of the end product developer. This is described in moredetail in the user manual3.

3.2 Types of MIDlets
Based on our analysis, all MIDlets on the modem can be divided into two categories byprivilege level:•

3

Manufacturer

EHSx Java User’s Guide, v15

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 6 of 82

•User signed / unsigned

Only the JRC and SLAE MIDlets belong to the manufacturer level. They have the highest
privileges without any code execution restrictions at the Java level.
The second category of privileges is granted to user MIDlets. Their functionality is restricted
in relation to file system (FS) operations, GSM module operations, etc. For example, a user
MIDlet cannot read the entire modem FS, but the JRC module can.
If a user certificate is installed, only a signed user MIDlet with User Signed privileges will be
executed on the modem. In other words, User Signed MIDlets are only used to protect themodem from executing a MIDlet from an illegitimate user, such as an intruder or security
researcher.

3.3 Software update
A modem software update file is supplied by the manufacturer in the form an encryptedbinary image. The image contains an update for the FW and App, an update for the JRC
component, and optionally for the SLAE. Although the JRC is a MIDlet, it also contains
modules that use APIs to interact with OS drivers. This provides interaction with OS
subsystems: the FS, the data transfer subsystem, and communication with external
hardware interfaces (e.g., USB). That’s why the JRC and App components are always
updated together – a driver update in the OS may entail a change in the APIs.
Our research did not involve a detailed analysis of the modem software update mechanism.

3.4 Installing MIDlets on the modem
MIDlets can be installed both locally and remotely. Local installation of MIDlets is done
through the JRC component. Remote installation is possible via a special OTAP
mechanism, or in M2M scenarios, via the SLAE component.
Using the modem in an M2M scenario involves creating a personal user account on the
manufacturer's website. This personal account allows the user to perform standard actions
with MIDlets on all paired devices, such as installing and uninstalling MIDlets. In our study,
we did not analyze the mechanisms of remote M2M installation of MIDlets.
OTAP support is provided by the App and JRC components. The process of installing andupdating user MIDlets via OTAP requires prior activation of OTAP by the user on themodem. The user may specify additional attributes that will be used for OTAP: JAD File
URL, HTTP User, HTTP Password, etc. The process of updating via OTAP is described indetail in the EHSx Java User’s Guide.
Local installation is performed via the MES communication protocol and special AT
commands. The interface itself and AT command processing are implemented in the JRC
component. The MES protocol enables interaction with the modem's user FS (hereinafterreferred to as the "UFS"), including writing to or deleting files from the UFS.
Upon installing the driver provided with the SDK, the content of the modem’s UFS, which ismounted at the path '///a:/', becomes accessible. The driver functions as a user add-on over
the MES protocol. Although MES formally supports working with any path value except for'///a:/', no other internal paths are known, and attempts to read paths starting with a different
root result in an error. This is due to the filtering of query parameters in MES, ensuring that

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 7 of 82

everything not belonging to the 'a://' root returns an error, even though the UFS has several
valid roots.
Local installation of MIDlets is performed in two steps. First, the MIDlet files (.jar and .jad)must be copied to the modem UFS. Next, the MIDlet is installed on the modem using the
AT^SJAM=0 AT command. During the execution of this command, the MIDlet files arecopied to a part of the modem FS that is inaccessible to the user and are then removed fromthe UFS. The path to which MIDlets are copied during installation is unknown. This helps
ensure the confidentiality of both user and manufacturer MIDlets. An installed MIDlet islaunched from its new location in the modem FS. A list of all installed MIDlets can also be
extracted using the AT^SJAM command. Figure 1 shows an example of the output of thiscommand.

Figure 1. Example output of the AT^SJAM command

The
modem
documentation(Figure2)
statesthatthejavax.microedition.io.file.File.FileConnection connector used to work with the FS filters
requests to files with the .jar extension.

Figure 2. Snippet from the Cinterion documentation

This behavior was confirmed by a simple test: trying to access files with the .jar extension(Figure 3) produced an error.

Figure 3. Attempting to access files with the .jar extension

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 8 of 82

3.5 Debugging MIDlets and modem execution
According to the modem’s official documentation 4 , several interfaces are available tointeract with the modem, as shown in Figure 4.

Figure 4. Available modem interfaces

Among these, the ASC0, ASC1 and USB interfaces make it possible to get debug
information. ASC0 or ASC1 are used to transmit information between the modem and the
debugging host through the UART protocol. In case of USB, the UART interface is emulated.
The modem provides multiple mechanisms for getting debug information:

Cinterion®
EHS5-E/EHS5-US
Hardware
Interface
m2m.de/fileadmin/Bilder/GSM_Module/Module/EHS5/ehs5_us_e_hid_04003a.pdf
4

Description:

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 9 of 82

https://www.gs-

•
•

IDE
UART interface (logical or physical)

IDE allows full debugging of an executable MIDlet on the modem using the Java MIDlets
debugging subsystem. This includes their loading onto the modem, step-by-step execution,and unloading. Interaction with the modem in debug mode takes place through a special
PPP connection established via USB. The debugging mechanism is described in detail inthe manufacturer's documentation5.
In addition to debugging MIDlets, the modem allows the collection of logs of its subsystems,
including MIDlet operations. The output format is determined by the AT+TRACE command.
An example of the command to enable output of debugging information on the modem isshown below.
at+trace=,115200,"st=0,pr=1,bt=0,ap=1,db=1,lt=0,li=0"

The command parameters determine which modem subsystems to collect information from.
Information on the subsystems from which debugging information can be collected isavailable in the detailed help (Figure 5) for this AT command.

5

EHSx Java User’s Guide, v15

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 10 of 82

Figure 5. Detailed help output of the AT+TRACE command

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 11 of 82

4 Information security assumptions regarding themodem
The modem’s information security can be divided into two domains:••

Security of user MIDlets and manufacturer MIDlets
Security of the modem OS

4.1 MIDlet security
MIDlets are protected on the modem to preserve two main security properties: confidentiality
and integrity.
MIDlet confidentiality is provided by special restrictions on AT commands that allow the user
to install, delete and execute MIDlets, as well as by prohibiting reading of .jar files from the
UFS. After installation, MIDlets themselves are stored in an unknown location in the modem
FS.
The question of violating the confidentiality of user MIDlets can be examined by testing two
assumptions. The first is that it is impossible to determine the path where MIDlets are stored
within the modem. The second asserts that it is impossible to bypass the restrictions
preventing the reading of files with the .jar extension. If both assumptions are false, thenMIDlet confidentiality could be violated.
The integrity property is ensured on the modem by means of a digital signature. The integrityof the Java byte code is additionally checked by the Java virtual machine for .jar files.
However, this latter mechanism does not provide sufficient tamper protection, so we only
consider the digital signature mechanism as a measure that ensures integrity.
Digital signatures are checked when MIDlets are launched. MIDlets with specificpermissions can only be launched if this check is passed successfully. It is important to notethat if the developer of the end device has not installed a security certificate, integrity is only
ensured for the manufacturer's MIDlets that have been signed with its key and launchedwith the manufacturer's privileges. If a security certificate is installed, such protection is also
extended to user MIDlets.
Thus, claiming that the integrity of user MIDlets cannot be violated entails there is no way
to modify an existing MIDlet on the modem FS and that there is no way to launch a modified
MIDlet if a digital signature is used (since in case that no signature is used, any user can
install, reinstall and launch MIDlets). If both statements are false, the integrity of modem
MIDlets could be violated.

4.2 Modem OS security
From a security perspective, the main component of a modem is its OS. Confidentiality andintegrity are ensured by distributing OS updates only to registered users and only inencrypted form. We have not been able to find any update images available for downloadin public sources.
It is important to note that violating the confidentiality property alone does not grant an
attacker the ability to execute arbitrary code on the modem. Similarly, even with the ability

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 12 of 82

to violate the integrity of the executable code, exploiting this capability to execute arbitrarycode is significantly more difficult without access to the code base itself, either in sourcecode or binary form. However, compromising both confidentiality and integrity would
completely compromise the modem OS and all its MIDlets.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 13 of 82

5 Obtaining modem firmware
While researching the modem, our team aimed to verify its stated security properties. We
focused on analyzing both MIDlet and modem OS security. To achieve this, we developeda research device using a printed circuit board of our own design (Figure 6).

Figure 6. Research device

Next, we analyzed the modem’s hardware components (Figure 7). We identified its ROM,
which is based on NAND memory and used to store the modem's software components.
We extracted an image from this NAND memory using the ChipProg programmer.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 14 of 82

Figure 7. Hardware components of the modem

5.1 Building a logical image of firmware
The modem firmware extracted from the NAND memory dump consists of "raw" data fromthe physical NAND blocks. Data in NAND memory is stored as charges in specialized
hardware cells, each made up of a transistor and capacitor. All physical space available forstorage is segmented into sectors, which are then grouped into pages. Pages in turn areassembled into blocks6.
Due to the nature of the storage device, reading errors may occur at the physical level - azero may be read as a one and vice versa. Error-correcting codes are used to handle such
errors. Usually, these codes are stored together with user data in NAND memory. The codes
themselves are calculated for each sector of stored data and are stored together with othertechnical information in memory areas called the Spare Area (SA). As each sector is read,
it is "corrected" with data from its SA, if necessary.
In addition, NAND memory itself is not durable. The high number of possible writes isachieved by two other data conversion mechanisms: gamma and wear leveling. Gamma is
the bitwise XOR of a special gamma function with the data currently being written. The
gamma is generated using a conventional LFSR7 and is not an element of cryptographic
protection but is used to ensure even wear of all memory storage cells. The wear levelingmechanism is used to ensure the uniform wear not only of the memory cells within sectors,
but also of the physical sectors. To achieve this, the concepts of logical sector, page andblock are introduced. A logical sector, page or block is mapped to actual physical blocks,
pages and sectors. In the case of sector mapping, we speak of mapping a physical sector

6Open NAND Flash Interface Specification URL: https://media-www.micron.com/-/media/client/onfi/specs/onfi_4_2gold.pdf
7
Cryptographic Boolean Functions and Applications URL: https://doi.org/10.1016/C2016-0-00852-5

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 15 of 82

with some number, which we will denote as PSN, into a logical sector with the number LSN.
In the case of blocks, a physical block with the number PB N is completely mapped to alogical block with the number LBN. Similarly, at the page level, a physical page PPN ismapped to a logical LPN.
Typical tasks for restoring user data from "raw" bytes include removal of gamma (if used),
and recovering the physical-to-logical mapping. This is usually done by the NAND controller,
but in this case, we had no access to it. Analysis of the entropy of the stripped image (Figure8) indicated the absence of gamma.

Figure 8. Entropy of the NAND controller image

However, the image itself did not look like meaningful binary data. It lacked artifacts of any
physical storage-level file systems. binwalk also found only high-level file system artifacts.
Accordingly, we concluded we were dealing with a standard mapping from the logical levelof data representation to the physical level.
The mapping algorithm is not universal and depends on the vendor. There are solutions forrecovering user data from "raw" data. Lacking such equipment, we decided to perform thedata recovery on our own.
First, we determined where exactly the SA was stored. In our case, it turned out that every
0x200 bytes of data was accompanied by 16 bytes that clearly had nothing to do with user
data. This can be seen particularly well at the boundary of the two physical sectors (Figure
9).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 16 of 82

Figure 9. The boundary of the two physical sectors in the image

To analyze the contents of these 16 bytes, we wrote a script that built a binary image
containing only this data for each physical sector of the original image. We assumed thatthese 16 bytes represented some structure containing service information. By reviewing thecontents of the resulting file, we were able to partially determine the purpose of the fields ofthis structure. It turned out that in most cases the mapping included only “physical blocks tological blocks” and “physical sectors to logical sectors”. In this case, the SA of a particularphysical sector stores the logical block number LBN and logical sector number LSN to which
this physical sector is mapped. The description is presented in Figure 10.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 17 of 82

Figure 10. Logical block LBN and logical sector LSN

Then, we wrote a script that builds binary images of logical blocks using data from service
records. This did not assemble the full logical image, because some sectors appeared to be
distributed into logical pages (PBNs). Assembling them required a deeper analysis of thephysical block, page and sector allocation table structure. As a result, it turned out that few
logical blocks were originally written on the disk. A separate binary file was generated foreach of them, shown in Figure 11.

Figure 11. Binary files for logical blocks

Not all blocks contained meaningful information, but we were able to identify blocks
corresponding to the two main components of the modem: a combination of the FW and
APP, and the UFS. The FW and APP components were in block number 1. We determined
this by looking at the strings found in the assembled image (Figure 12). Furthermore, we
observed that the resulting assembly was for the XMM6260 series modem.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 18 of 82

Figure 12. Strings found in the image

The correctness of the constructed image was confirmed by identifying various strings
related to the modem OS libraries (Figure 13). These strings are located consecutively
across several sectors, and after our transformations, we got a meaningful set of librarynames.

Figure 13. Modem OS library name strings

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 19 of 82

The UFS image was easily identified by the characteristic file system header shown in Figure
14.

Figure 14. FS header

As a result, when we mounted the resulting image as a FAT FS image, we had access to
all user MIDlets as well as system files and folders (Figure 15).

Figure 15. FAT FS

5.2 Analyzing the contents of the UFS
After reviewing the contents of the UFS, we found that it contained folders and files hiddenfrom the user and inaccessible through the MES mechanism, namely .cinterion.internal and.cinterion.service. Access to them was restricted directly in the JRC MIDlet code, filtered bytheir name prefix. The code snippet from the JRC module that filters access to these folders
is shown in Figure 16.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 20 of 82

Figure 16. Example code from the JRC module

We discovered that the virtual root ///a:/ corresponds to the physical path /sys/. We also
extracted information about the path to which user MIDlets are copied after installation andthe format in which they are stored. The contents of the folder with MIDlets is shown in
Figure 17.

Figure 17. Contents of the folder with MIDlets

It was determined that all MIDlets are stored on the device at the path/sys/.cinterion.internal/java. Each MIDlet is represented on the FS as four files with the .ss,
.ii, .ap, and .jar extensions.
Files with the .jar extension are Java executable files. After analyzing the contents of thefolder with installed MIDlets, we found that each MIDlet is renamed during the installation
process. To allow the user to run MIDlets by their name, the file system maintains a mapping
between the original name of the MIDlet and its alias within a simple database that is stored
in the _suites.dat file. For example, by analyzing the binary contents of this file, it is clearthat the file named 00000003.jar (Figure 18) is actually JRC.jar.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 21 of 82

Figure 18. Contents of the binary file _suites.dat

The .ap file is the .jad file converted to UTF-16. This file contains information about theoriginal name of the MIDlet and the libraries that were used. It may also contain the MIDlet’s
digital signature. The contents of such a file for the JRC MIDlet are shown in Figure 19.

Figure 19. Contents of the .ap file for the JRC MIDlet

The .ii file contains information about the MIDlet installation path, the permissions assigned
during installation, and other service information (Figure 20).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 22 of 82

Figure 20. Contents of a file with the .ii extension

Finally, the .ss file contains a description of the Java-level permissions available to thisMIDlet. An example of the JRC vendor MIDlet permissions description is shown in Figure
21.

Figure 21. Example of JRC vendor MIDlet permissions description

It is important to note that this permission set gives unrestricted access to the Java virtual
machine’s system classes and represents the manufacturer privilege level. Only two MIDlets
have such privileges: JRC and SLAE. Any user MIDlet must list in its manifest the classes
and methods that it needs access to at runtime. Part of the manifest for our test MIDlet isshown in Figure 22.

Figure 22. Example manifest for our test MIDlet

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 23 of 82

The OTAP_AtParams.bin file deserves special attention. Its name suggests that it may berelated to OTAP configuration. During experiments, we found out that this file is created
when the AT^SJOTAP command is executed and contains the settings specified in thiscommand. Part of the file created during our tests is shown in Figure 23.

Figure 23. Example of OTAP_AtParams.bin file contents

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 24 of 82

6 Analysis of MIDlets security
6.1 FTP client security
During our analysis of documented AT commands, we found that there is a set of AT
commands dedicated to FTP interactions.
The FTP service allows downloading and uploading to any internal folder of the modem(Figure 24). JAR files can be accessed without restriction, because the FTP service isimplemented in the code of the JRC MIDlet and operates in the manufacturer security
domain. Thus, any system or user files, including MIDlets, can be read through this method.

Figure 24. FTP operations

The API of the aforementioned FTP client is not protected and is publicly described in themodem's AT command documentation8. This means an attacker with physical access to thedevice can gain read / write access to any files and directories in the modem's file system,
including the hidden ones.

6.2 Getting information about internal FS paths via a static
method inside a custom MIDlet
A user MIDlet can call the static methods Configuration.getSystemPropertiesNames() andConfiguration.getSystemProperty(VAR_NAME). These methods return a list of allenvironment variables and the value of a particular environment variable, respectively.
JVM environment variables, such as the internal path to where MIDlets are stored, can beextracted this way (Figure 25).

8

Cinterion® EHS5-E AT Command Set: https://teleofis.ru/upload/iblock/c85/c851073722a1d525ca5d49cf84e1404a.pdf

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 25 of 82

Figure 25. JVM environment variables

Calling the Configuration.getSystemProperty function with the "system.storage_root"argument from a user MIDlet returns the native path of all installed MIDlets. For our
research, this was /sys/.cinterion.internal/java.

6.3 Getting information about internal FS paths from a user
MIDlet via a standard FileConnector call
Any user MIDlet can bypass the access restriction to the FS above the virtual root of thevirtual FS tree. Access to files on the virtual FS is performed by calling the(FileConnection) Connector.open("file:///root:/PATH")

method, where root is some virtual root of the FS. In our case, using a %2E%2E%2F (URLencoded “../”) sequence at the start of a PATH, forms the path “native_path/../PATH” for the
FS access handler, where native_path is the actual location where the virtual root ismounted.
This occurs due to a flaw in the way the open function processes the path sequence: it firstchecks for any “../” sequences and only then converts the escape sequence to ASCII,
allowing access to any part of the native FS.
We also found out that virtual root b:/ is a folder inside virtual root a:/ (Figure 26 and Figure
27).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 26 of 82

Figure 26. FS tree

Figure 27. FS tree

6.4 Changing the security domain of a custom MIDlet
As mentioned earlier, all installed MIDlets are stored in the modem FS as a set of four files
under the path /sys/.cinterion.internal/java. When a MIDlet is started, its security domain ischecked in the .ii file. Then, depending on the specified domain, access rights are assigned
based on the .ss file. There is no verification of the digital signature when launching a MIDlet
that has the manufacturer-level security domain.
Since any user MIDlet can use the aforementioned FileConnection Java class, the MIDlet’ssecurity permissions and security level can be escalated. An installed user MIDlet canreplace its own .ii and .ss files, so that it starts executing in the manufacturer security domain(Figure 28 and Figure 29).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 27 of 82

Figure 28. Running our MIDlet for the first time

Figure 29. Running our MIDlet for the second time

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 28 of 82

7 Modem OS security
7.1 Selecting interfaces for research
While acquiring the modem firmware, we compromised the confidentiality of its OS data
through invasive and destructive actions.
It was important for us to evaluate whether both the confidentiality and integrity of the OS
image are preserved in the absence of invasive actions. To this end, we considered theavailable software interfaces for interacting with the modem. We identified two of the mostwidespread: the AT command interface and SMS messages.
The AT command interface is a well-known method for controlling the modem. To exchange
AT commands with a modem, one simply needs to connect to one of its wired interfaces,such as USB. The confidentiality and/or integrity of this interface could be compromised if
there are security flaws.
The SMS messaging interface is available on any modem and can be used by knowing thesubscriber number of the target modem within the cellular operator's network. However, it
is not always possible to send binary SMS messages due to operator restrictions. Using a
fake base station allows such limitations to be bypassed.

7.2 Researching modem AT commands
We started our research of the modem’s OS security by analyzing the commands available
at the AT interface level. We decided to rely on fuzzing as our main research approach.
Accordingly, we needed to:••

Build a fuzzing corpus from a set of supported commands and their parameters
Be able to identify run-time errors and their causes

The set of AT commands can be determined from the manufacturer's documentation9. Thismethod yields a corpus composed of only publicly available user AT commands. However,
we are interested in getting an exhaustive list of all AT commands available in our modem
OS image.
By analyzing the modem’s OS image, we determined that the modem is based on RTOS
ThreadX ARM11. While the main drivers and platform are written in C, some portions, suchas the USB stack, are written in C++.
According to the documentation, the commands available to the user start with the "AT"prefix followed by a special character: "+", "^" or "%". The commands themselves have four
execution modes: read, write, execute, and test (help output). Searching the binary image,
we identified a data section (Figure 30) consisting of structures corresponding to thefollowing representation of AT commands.

9

Cinterion® EHS5-E AT Command Set: https://www.euromobile.ru/upload/iblock/ca2/ehs5-e_rn_v04000.pdf

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 29 of 82

Figure 30. Representation of AT commands in binary image

By analyzing the custom AT command descriptor's contents, we identified over 200 uniquecommands. Using the test function, we identified exactly which parameters and how many
parameters each command expects. We found text descriptions of the commands, shownin Figure 31, and used them to determine their purpose.

Figure 31. Text descriptions of AT commands

Among the available AT commands, we managed to find the "AT+XLOG" command, whichallowed reading information about software and hardware errors. With the help of thiscommand, we were able to establish the cause of errors and locate the failure point in themodem code. An example of the output of this command is shown in Figure 32.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 30 of 82

Figure 32. Example output of the AT+XLOG command

7.3 Vendor-specific AT commands
After examining the extracted list of available AT commands, we decided to look moreclosely at the mechanisms used to process them. We discovered that, in addition to thespecial characters "+", "^" or "%", the command interpreter also accepted "@". Upon
receiving that character, the command handler’s lookup mechanism behaved differently.
Further analysis revealed that the modem supports many vendor-specific AT commands
that are registered in the OS at the initialization stage (Figure 33).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 31 of 82

Figure 33. Registration of vendor AT commands

Registration consists of simply copying static data into a separate memory area (Figure 34).
When these commands are processed later, this memory is accessed to find a suitablehandler.

Figure 34. Registration of vendor AT commands

An analysis of the previously copied data showed that it contained a detailed description ofeach command (Figure 35). For example, we were able to find out the name of a command,its purpose, as well as the list of functions it supports and even the version of its
implementation.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 32 of 82

Figure 35. Copied data during command registration

The "SEC Security Interface" command looked particularly promising (Figure 36). It seemed
to be exactly the kind of command that might be used to interact with the modem at the OSlevel.

Figure 36. sec command

The features supported by this command, shown in Figure 37, also reinforced thisassumption.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 33 of 82

Figure 37. Functions supported by the sec command

We also discovered that the format of vendor AT commands differs from the usual one. By
analyzing their handler code, we determined that the general format of a vendor AT
command is:
at@tag:(param1, ..., paramN);

The way these AT commands are called looks similar to calling a function in an interpreted
scripting language. We discovered some useful commands supported by the corresponding
interpreter:••••

at@help - display the command help
at@E? - get information about the execution error of the last command
at@*:? - get a list of all available commands
at@tag:$*? - get a list of all available functions supported by the command

Additionally, we found complete scripts for this interpreter within the OS code (Figure 38).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 34 of 82

Figure 38. Scripts for the interpreter

The final step was to identify the parameters of the functions discovered in the sec
command. This posed no issue, as the complete description of these commands were
contained in the binary image of the OS (Figure 39).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 35 of 82

Figure 39. Full description of the commands available via the help command

For our initial test of the identified vendor command interface (Figure 40), we chose to use
the state_info function, which was not expected to have any impact on the modem's
functionality.

Figure 40. state_info function

Then, we decided to use the hw_details function to get information about the modem
hardware. However, we received an error instead of the expected modem hardware details(Figure 41).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 36 of 82

Figure 41. Error when executing the hw_details function

Further analysis showed that many of the functions available through the “sec” command
verify the current level of user privileges. Figure 42 shows an example of this check for the
hw_details function.

Figure 42. Privilege level checks for hw_details function

The privilege level depends on the modem’s current mode. Switching the modem to anothermode requires a special vendor key (Figure 43) that is tied to the modem’s hardware data:
its model number, IMEI, and so on.

Figure 43. Using a special vendor key

Due to the time-consuming nature of calculating the value of this key, the sec command
proved ineffective for testing the confidentiality or integrity of the OS. Accordingly, we
decided to explore other available vendor commands. Our attention was drawn to the xl1
command (Figure 44).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 37 of 82

Figure 44. xl1 command

This command had functions with promising names (Figure 45).

Figure 45. Functions of the xl1 command

The format of these functions (Figure 46) and their descriptions appeared to be related toreading and writing binary data in memory.

Figure 46. Format of function parameters

Our hypothesis was confirmed by analyzing their implementation (Figure 47). These werecommands for reading/writing RAM. They were not removed from the production firmware.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 38 of 82

Figure 47. Memory read command

Using the at@help command, we requested the modem’s help output to check whether thexl1 command was available. The output is shown in Figure 48.

Figure 48. Help output with the xl1 command

Our target command appeared in the list. However, when we tried to execute the xl1
command, the read and write functions were not executed due to their non-standard
definition in the firmware code. They had a special "@2" prefix in their names. To figure out

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 39 of 82

the meaning of this prefix, we re-examined the AT command processing algorithm. Our goal
was to determine the conditions under which a function called within a command might not
be executed.
We discovered that functions within a vendor-specific AT command can start with the “@”symbol followed by a numerical value from 0 to 2. This value indicates the level of user
privileges required to execute these commands. Our privilege level was hard-coded in themodem’s OS code at the static address 0x600D0AD0. Since it is not assigned based on
software commands or special hardware settings, there is no legitimate way to change it in
the current build.
The modem operates with three privilege levels: 0, 1 and 2. These levels not only restrict
access to functions within vendor-specific commands, but also govern the availability of thecommands themselves.
We found that the privilege levels required for outputting the help information for commands
may differ from what is required for executing those commands. Information about therequired privilege levels is stored in the descriptors of each command. Checks are
performed whenever a vendor-specific AT command processing function is called (Figure
49).

Figure 49. Checking the required privilege levels

Based on the extracted information about the configuration and location of settings foraccessing vendor-specific AT commands and their functions, we managed to reconstruct
the list of all vendor-specific commands implemented in the modem OS (Table 1).
Command
name
ufr
utif
getif
gcal
ucal
speed
prodifprodctrl
xl1
ver
pmu
pow
ts
meas
utasensor
utabm
init
uicc

Description from firmware
UMTS RF
UMTS test interface
GSM EDGE test interface
2G RF driver test and calib. interface
UMTS calibration interface
full speed test interface
Production Interface (prodif)
Production Control Interface (prodctrl)
XL1 trace interface v.1.00.00
Ver test interface v.01.00.0
PMU API AT test interface v.00.00.0
POW API AT test interface v.00.00.0
time services test interface v.01.00.0
meas debug interface v.1.00.00
UTA SENSOR interface v.1.00.00
UTA BM debug interface v.1.00.01
Init test interface v.01.00.0
UICC GTI SUPPORT v.1.00.00

Help available?

Privilege level

no
no
no
no
no
no
no
no
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes

2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 40 of 82

bmmoncdd
utacdset
vsyscalihwcaltbatcaltpcbcaltrfcaltbbiccalsec
usbmwtestfw
ceu
i2c
mipihsi
pcl
xrlc
sic

BMMON interface v.1.00.00
CDD test interface v.2.00.00
DEPRECATED please use at@cdd v.2.00.00
VSYS calibration interface v.1.00.00
IHW calibration interface v.1.00.00
TBAT calibration interface v.1.00.00
TPCB calibration interface v.1.00.00
TRF calibration interface v.1.00.00
TBBIC calibration interface v.1.00.00
sec v.0.00.01
USB Middleware - Test Framework v.0.00.03
CEU Test Interface
I2C interface
GTI for MIPI
pcl interface
GPRS-RLC functions provided to GTI Interface
SIC Interface

yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
no
no
no
no
no
no

1
1
1
1
1
1
1
1
1
1
1
2
1
2
1
2
2

Table 1. List of vendor-specific commands

All the commands shown in the table require either level-2 privileges or level-1 privileges.
Note that the xl1 command is the only command whose functions require level-2 privileges
to run, but its help output can be viewed by a user with level-1 privileges. That's why we cansee this command in help output but are unable to execute the corresponding functions.
Given the presence of the xl1 command, we could completely bypass the key checking
restrictions in the sec command’s functions if we could use its functions for reading andwriting memory functions. We conclude that privilege levels 1 and 2 correspond to "OEM"and "Vendor" privilege levels, respectively.

7.4 Fuzzing AT commands
We used a Raspberry Pi 3 to build our fuzzing stand (Figure 50). We communicated with
the AT interface via USB, and were able to perform a hard reboot of the modem using theappropriate hardware pin.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 41 of 82

Figure 50. AT-command fuzzing standWe built the fuzzing corpus using data obtained from our analysis of the AT commands. To
develop a strategy for corpus generation and mutation, we identified AT command attributes
that, if changed, could lead to execution errors:
1. Number of command parameters
2. Parameter type: string, number, binary value
3. Parameter value range
The mutation was performed by changing these parameters: creating or removing variables,
altering the type of each variable, and modifying its range of values. The initial probability ofthese changes for each AT command was set at 1/2. However, this probability was not fixed;
it varied depending on the results of a single corpus test of a particular AT command. Aftereach corpus test, we evaluated the number of command execution errors on the modem aswell as their execution time. The mutation probability for each attribute was adjusted up or
down accordingly. As a result, each AT command had a unique probability that its attributes
would change.
During the fuzzing process, we had to discern when the modem was in an operational state.
Error detection was based on three conditions that allowed us to reliably identify the current
state:
1. AT interface unavailable
2. No response from the AT interface
3. The last line read is not one of the following: ERROR, CMD ERROR, NO
CARRIER, OK, ABORTED.
If any of these tests failed, it was assumed that an error had occurred in the execution of
the AT command. The cause of the error could be extracted using the AT+XLOG command.
All commands sent between two detected errors were collected in separate logs so that the

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 42 of 82

result could be repeated on the same data set. A hard reboot of the modem ensured thatthe previous error did not affect the test results.
After all the preparations, the fuzzing stand was switched on and left to run for several
months. Many errors were recorded as the result of fuzzing. Most of these errors weresoftware exceptions, which means that they were not exploitable. However, we were able
to detect a stable memory access error when the AT+XMUX command was executed.
Detailed analysis allowed us to discover a heap overflow vulnerability during the handling of
this command.
The command takes 11 parameters as input. Each of these parameters is a single-byte
number. Each received AT command goes through a conversion phase at the beginning of
its handler where the input parameters are converted from a string to the required data type,which is a number in this case. The conversion is performed with help of a library function(Figure 51) that takes a pointer to a buffer containing a string with the AT command and thenumber of parameters as input. The third parameter returns the conversion result as anarray of data representing the result. The software error can be found in this function.

Figure 51. Library function performing data conversion

The function itself is not supposed to convert a string with more than 11 parameters (Figure
52).

Figure 52. Limit on the number of parameters

Each of these parameters must be limited in size by the intermediate buffer length. Thisbuffer is used to perform the string-to-number conversion of each of the parameters

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 43 of 82

individually. Its size is hard coded in the function code. It is also equal to 11 bytes allocatedon the heap (Figure 53).

Figure 53. Limit on the size of parameters

Inside the function there is a check that the number of parameters in the processed string
does not exceed the expected number (Figure 54).

Figure 54. Checking for the expected number of parameters

However, the function does not check if the length of a parameter is greater than the size ofthe buffer allocated to convert it to a number (Figure 55). In this case, each parameter ofthe input string is copied until the "," delimiter is encountered or the end of the input string
is reached.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 44 of 82

Figure 55. Error in the parameter length check

The bytes of the input parameter are added to the same buffer. The first parameter of an AT
command can overflow this buffer if its length exceeds 11 bytes.
Among all AT command handlers, this library function is used only in the AT+XMUX
command handler. This command accepts only numbers as data, which are also checked
during processing. Accordingly, we cannot exploit this error to achieve heap overflow with
arbitrary binary data. We therefore decided to search for another option to implement a fullblown arbitrary code execution exploit.

7.5 SMS message processing
We decided to analyze the security of SMS message processing, starting from the moment
the message is received. To achieve this, we needed to reconstruct the algorithm forprocessing SMS messages, tracing the process from receiving the raw message from the
DSP to its final processing. Several processes10 are involved in SMS message processing,as illustrated in Figure 56.

10

In the ThreadX operating system (now Azure RTOS ThreadX), there is no concept of processes, instead, it operates
on threads. However, since the OEM manufacturer uses the term "process" in the firmware we were studying, we will also
use this term throughout the text of the article to maintain consistent terminology.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 45 of 82

Figure 56. Processes in SMS handling

The first process to handle a received SMS message is the MNM process. It is responsible
for checking whether the received SMS message conforms to the SMS PDU format. If the
body of the received SMS message complies with the standard, it is sent to the next process(Figure 57). It is important to note that this process, shown in Figure 56, not only is
responsible for processing SMS messages, but also participates in the processing pipelineof various messages and events coming from the mobile network.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 46 of 82

Figure 57. Processing the body of a received SMS

In this case, the only interesting function for us is one that can be affected by modifying the
SMS message content, i.e. the function responsible for checking the message structure. It
contains simple checks to ensure that field values of the received SMS comply with expectedvalues. Each of these checks may interrupt the processing of the received SMS. Among all
the fields that can be modified, there is one that deserves attention, namely the OA field(Figure 58).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 47 of 82

Figure 58. OA field

According to the standard, it is assumed that the OA (Originating Address) field stores thenumber of the sender of the message (Figure 59). The length of this number must notexceed 0xC bytes, and there is a corresponding check in the code.

Figure 59. Contents of the OA field according to the standard

However, this check is performed only after the data from the message has been processed.
There is no such check within the handler itself (Figure 60).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 48 of 82

Figure 60. No check of the length of the number of the message sender

Although the parsing of the message header is interrupted, it is possible to copy up to 0x80
bytes into a buffer that should not contain more than 0x2A bytes. This is a software bug inthe lowest-level driver that handles SMS messages. However, in this case, the error does
not result in a vulnerability. The buffer with this copy error is part of the received SMS
message descriptor structure with the size 0xF4, and it is located almost at the beginning at
offset 0x2A. If the structure that stores the processed SMS message header had a different
format, then overflow would be possible.
After all header fields have been checked, the received SMS is passed to the MDH process
for further processing. This handoff is accomplished by sending the 0x2E002A signal (Figure
61).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 49 of 82

Figure 61. Transmitting the message further on via signal 0x2E002A

This signal is handled by the MDH process (Figure 62). The SMS message is processed by
the ATC process via the 0xFE01B7 signal (Figure 63).

Figure 62. Signal processing by the MDH process

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 50 of 82

Figure 63. Passing the message to the ATC process via the 0xFE01B7 signal

This signal is further processed in the callback handler of the UTACAT process, which
UTACAT itself registers when it begins running. This callback puts the SMS message into
the message queue of the UTACAT process (Figure 64).

Figure 64. Signal processing in the callback handler of the "UTACAT" process

Next, UTACAT processes the body of the received SMS message (Figure 65). In this case,right from the start, there is an unconditional check to ensure that the received SMS
messages comply with the OTAP and ULP protocols11. Besides these two protocols, themodem only processes ordinary SMS messages.

11

https://www.openmobilealliance.org/release/supl/V1_0-20070615-A/OMA-TS-ULP-V1_0-20070615-A.pdf

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 51 of 82

Figure 65. SMS message handling by the UTACAT process

7.6 OTAP protocol analysis
In the OTAP protocol, data is transmitted using SMS messages that have special values for
the Class and PID fields (Figure 66).

Figure 66. Data transfer in the OTAP protocol

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 52 of 82

OTAP messages are ASCII text contained within the SMS message body. An example ofsuch a message is shown in Figure 67.

Figure 67. Example of an OTAP message

The initial processing of the received message takes place in the UTACAT process. This
process is responsible for decoding the received SMS message and sending it to theprocess that handles the OTAP protocol.
Only two functions responsible for decoding the OTAP protocol can be affected. The first is
the function that converts the received message to text format (Figure 68).

Figure 68. Function for converting the received message to text format

The second is used to check that the OTAP SMS ID is present in the message header(Figure 69).

Figure 69. Checking whether the OTAP SMS ID is present in the message header

During the research, we did not find any errors in the implementation of these two functions.
Moreover, the transmission protocol itself is trivial, so we proceeded to analyze the functions
that handle the processing of the received message.
The OTAP message handler is located in the native MIDP library implementation of the JVM
process, i.e. the Java interpreter. The JVM process itself greets the researcher with awonderful message (Figure 70).

Figure 70. Surprise log message

And it instantly reveals all the secrets about the location of MIDlets and other system files
and folders (Figure 71).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 53 of 82

Figure 71. Storage data for MIDlets and other system files and folders

The code for handling a received OTAP message has quite a lot of comments. This allowed
us to quickly determine that if OTAP was not previously activated by executing the
AT^SJOTAP command, then the received message would not be processed (Figure 72).
Activation involves creating a special OTAP settings file in the UFS. Since our goal was toanalyze protocol security without putting the system into special operating conditions, we
decided to proceed with analyzing the implementation of the ULP protocol.

Figure 72. OTAP activation check7.7 ULP protocol analysis
In addition to the remote provisioning of MIDlets via SMS messages using the OTAP
protocol, the modem also offers geopositioning capabilities using the SUPL subsystem12.
This subsystem facilitates the exchange of special messages between H-SLP (Home SUPL

12

https://www.openmobilealliance.org/release/SUPL/V2_0-20120417-A/OMA-AD-SUPL-V2_0-20120417-A.pdf

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 54 of 82

Location Platform) and SET (SUPL Enabled Terminal). According to the specification, themodem functions as a SET object. An example of this interaction is shown in Figure 73.

Figure 73. Interaction via the ULP protocol

Messages are exchanged using the ULP binary protocol. In this protocol, data is transmitted
in the GSM network via PUSH messages using WAP stack protocols 13 . A typical ULP
message is illustrated by the SUPL INIT message (Figure 74).

13

UserPlane Location Protocol, Open Mobile Alliance™: https://www.openmobilealliance.org/release/SUPL/V2_0_520191028-A/OMA-TS-ULP-V2_0_5-20191028-A.pdf

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 55 of 82

Figure 74. SUPL INIT message

The ULP protocol includes the ability to fragment the transmitted message to allow thetransmission of large binary messages over a limited SMS message channel at the PUSH
layer of WSP messages. On the SET side, the WSP protocol provides indexing forfragmented SMS message transmission. The first SULP message contains the size of thetransmitted message.
An example of the first SMS message is shown in Figure 75. An example of subsequent
SMS messages is shown in Figure 76.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 56 of 82

Figure 75. Example of the first SMS message

Figure 76. Example of subsequent SMS messages

The ULPSizeFromPacket variable is responsible for the size of the entire ULP packet, andwapTpduLen is responsible for the size of the received WAP message. WAP message
processing consists of copying ULP message fragments into a buffer whose size is equal to
ULPSizeFromPacket.
While analyzing the driver that is responsible for handling the fragmentation of ULP
messages, we discovered a heap overflow vulnerability.
According to the transmission protocol, the ULPSizeFromPacket and wapTpduLen
variables are calculated independently. These variables are interrelated only in the algorithm
for receiving WAP messages: the sum of the sizes of all received WAP messages in a UPL
message must not exceed ULPSizeFromPacket. But the algorithm used to receive WAP
messages does not check this condition. Therefore, a received WAP packet of size

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 57 of 82

wapTpduLen will be copied to a buffer of size ULPSizeFromPacket (Figure 77). This is aclassic heap-based buffer overflow.

Figure 77. Heap overflow

After generating an appropriate SMS message, we managed to cause a heap overflow error
on the modem in one attempt, resulting in a hard reboot. To determine the cause of thereboot, we used the already known AT+XLOG AT command for reading error messages(Figure 78).

Figure 78. Reason for the reboot

The resulting dump made clear that the R0 register contained data that we controlled. Thus,
we confirmed our ability to not only overflow the heap, but also embed our data into
executable code.
However, we had no way to get a dump of memory at the moment of the crash. To
understand whether the discovered vulnerability is serious or just another non-exploitable
BoF, we had to solve the problem of reading the RAM.

7.8 How to read memory very, very slowly
After analysing the code at the address specified as the crash location in the AT command
dump, we clearly understood how our data ended up in the R0 register (Figure 79). The
crash consistently occurred in the malloc() function. The cause of the crash was an attempt
to dereference an unmapped address, resulting in a memory access error and,
consequently, a hardware fault.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 58 of 82

Figure 79. The reason for our data appearing in the R0 registerTo understand why, we had to do a deep dive into the memory manager of the modem OS.

7.8.1 HeapFree and HeapBase structures
All heap memory is segmented into chunks. Each chunk contains a pointer to the next
chunk, some user data (or unoccupied memory), and an indication of whether the chunk iscurrently occupied or free.
A chunk is considered free if its heap_free_magic value is 0xFFFFFFEEEE. If the chunk is
occupied, then instead of heap_free_magic, the field contains a pointer to the global
structure that describes the current state of the whole heap (HeapBase) (Figure 80). The
full list of fields in this structure can be found in the ThreadX operating system headers.
These headers are publicly available14.

Figure 80. Heap structure

The search for a suitable free chunk is performed by traversing all free chunks, starting fromthe first one. The pointer to the first free chunk is stored in the HeapBase structure. The sizeof the current chunk is calculated by the difference of addresses between the next and thecurrent chunk.
In the malloc() function, the search for a suitable free chunk involves a sequential traversalof a unidirectional linked list. If our SMS message exceeds the size of the allocated chunk,it overwrites the data in the next chunk when copied, corrupting it. However, this corruption
did not immediately cause a software error or crash the modem. The OS continued tofunction, allowing the malloc() function to be called again, which involved traversing all
chunks starting from the first free one.
Thus, while executing malloc(), there may be a moment when a free chunk is placed before
the corrupted chunk. When the function attempts to move to the next chunk using the link
14

https://github.com/eclipse-threadx/threadx/blob/0d308c7ae62085e68c7aa0a516f664c39e9a8407/common/inc/tx_api.h#L632C36L632C36

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 59 of 82

from the corrupted chunk (Figure 81), the data in the R0 register is dereferenced to an
address we control.

Figure 81. Executing malloc()

If the data is read from a valid address available in the modem's memory, no error occurs,
and its value is stored in the R0 register.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 60 of 82

Figure 82. Reading data

However, a memory access error occurs if the address in R0 points to an unmapped
memory location. In this case, the R0 register contains the last successfully read data. In
our case, it is the data from the address we placed in the WAP message body.

7.8.2 Memory map
To understand which addresses can be considered valid, we needed to construct a map of
the modem memory. To do this, we used the vendor-specific command to get information
about memory regions: AT@init:get_mem_info(). The following table shows the resulting
memory map.
Start region
0x00080000
0x62B80000
0x60000000
0xFFFF0000
0xFFFF2000
0x00400000
0x18000000
0xE0000000

End region
0x000A0000
0x63E7FFFF
0x62694C48
0xFFFF1010
0xFFFF4000
0x00500000
0x19000000
0xF0000000

Description
PSI RAM
Code Section
Ram Section
Mapped PSI RAM
Mapped PSI RAM
FLASH
HW
HW

Table 2. Memory map

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 61 of 82

Note that the handler of the above command reads memory regions from a table that ishardcoded in the firmware.

7.8.3 Reading memory via a heap overflow
Once we figured out which addresses were mapped, it became clear what kind of memoryread strategy we should use.
If we read data from the code section, the data would represent ARM machine instructions,and therefore, there will be unmapped addresses in memory. Thus, we can read from any
address in the code section, including the BootROM (Figure 83).

Figure 83. Reading a code section

Reading the data section required a slightly different approach (Figure 84). In the data
section, unlike the code section, 4-byte words can potentially represent a mapped addressin the modem's memory. In this case (and if the modem’s CPU configuration allows it),unaligned addresses can be read instead of an address aligned by 4. If any cyclic

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 62 of 82

permutation of 4 bytes of read data is a mapped address, the real value stored at thisaddress will not be read in the described manner. However, we have not found suchaddresses.

Figure 84. Reading the data section

As a result, we were able to read all the memory regions we were interested in. Most
importantly, we discovered the environment context of the WAP SMS buffer overflow. It
should be noted that the reading speed achieved using the described algorithm was only 7b/min, so it took several weeks to read all the memory we wanted to.

7.8.4 Getting the overflow context
The method of reading memory described above assumes that the modem will reboot after
each read of 4 bytes from the data section. However, because the system is loaded
sequentially, the layout of the heap in the region where the overflow occurs never changes.
Moreover, we found that the overflow itself always occurs at the same address!
This was possible because we achieved the overflow using the value of 1 for the
ULPSizeFromPacket variable. This means that the very first free chunk suits us.
Due to the specifics of the OS boot process, the heap always has a small chunk of 8 bytes
that is not suitable for any process (no malloc() calls request such a small amount ofmemory). Simultaneously, there are chunks allocated in memory that will not be freed until
the OS shuts down, so this 8-byte chunk is never defragmented.
Every time we reboot the modem, we cause an overflow at the same memory address.
Because we already know the address of the buffer overflow, we do not need a memory
read primitive based on the discovered vulnerability.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 63 of 82

7.9 Write primitive
Once the overflow context was established, we proceeded to the task of finding the write
primitive. This primitive is often implemented by manipulating pointers to neighbouring
chunks in linked lists with the accompanying injection of addresses into the global heap
descriptor structure.
However, in our case the heap uses a single-linked list, and the only pointer we can control
in the HeapBase structure is the pointer to the first free chunk in the heap.
Therefore, we needed to identify which data structures we could control that would let us
write to memory, and to learn how to assemble these structures in memory.
We started to analyze the available functions affected by chunk overflow on the heap: themalloc() and free() functions. We needed to find a code fragment that would write to an
address whose value could be affected by data from a WAP message.

7.9.1 Free function
The modem OS is a multitasking operating system: the heap memory pool is shared among
many processes. To ensure that access to shared resources is consistent, the HeapBase
structure stores a pointer to the process currently working with the heap. The free() function
checks if the current process needs memory after the memory is freed (Figure 85).

Figure 85. The free() function

This action is crucial for us, because it is the only place in the entire code of the free() andmalloc() functions that writes to a memory address extracted through a double dereference.
This is exactly what we were looking for in order to write to an arbitrary memory address!

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 64 of 82

A situation may arise where a process owns the heap memory pool and has a previously
unprocessed memory allocation request. After returning the just freed memory to the poolof free memory, the free() function attempts to find a suitable free chunk of memory forallocation. Only if a suitable free chunk is found, the free() function update the Thread
structure of the current process with information about the chunk.
This causes a pointer to the found free chunk to be written to the address specified in the
Thread structure at offset 0x80.
Instead of passing the original Thread structure of the current process to the free() function,
we could provide a pointer to a crafted data structure that mimics the Thread structure. This
makes it possible to write to any address in memory. Now we aren’t writing some arbitrary
piece of data, but a pointer to a free memory chunk. This was enough to intercept the flowof execution.
But the pointer to the Thread structure is taken from the HeapBase structure located at a
static address in memory. The pointer to the HeapBase structure is contained in each
occupied chunk at offset +4 and is used to access the HeapBase structure.
Consequently, if we overwrite that pointer with our data, we can completely replace the
HeapBase structure that the free() function will work with, and, therefore, the Thread
structure as well.
Next, we needed to understand the inner workings of these two structures and to find out
which fields must be filled in (Figure 86) for the execution of the free() function to reach thecode we were interested in.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 65 of 82

Figure 86. Our objective

7.9.2 Thread structure
The free() function uses only some of the fields of the Thread structure (Figure 87).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 66 of 82

Figure 87. Fields of the Thread structure in the context of the free() function

The size of the chunk the process tries to allocate is at offset 0x7C. This is the chunk thatthe free() function will try to find in the heap. We can use this field to control which chunk is
assigned. This is important because our WAP SMS data is located on the heap. And if wechoose a suitable memory allocation size in the free function, we will be able to write not
only the address of a suitable free chunk to an arbitrary address, but the address of a chunkthat contains our data!
The address where the pointer to the chunk is to be written to the heap if it is allocatedsuccessfully is located at offset 0x80. Here we can have an arbitrary write address.
Data at offsets 0x74 and 0x78 can be rewritten during the execution of the free() function tovalues obtained by dereferencing current pointers. However, if there is a pointer to ourThread structure at offset 0x74 (verifying that the heap is still occupied by the sameprocess), then nothing will be written to offsets 0x74 and 0x78.
It is also important to note that a zero is written to offsets 0x6C and 0x88 (Figure 88). These
addresses also need to be valid, and writing to them must not cause the OS to fail.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 67 of 82

Figure 88. Offsets 0x6C and 0x88 in the Thread structure

No other offsets in this structure are used during execution of the free() function. Therefore,
we only need to imitate a Thread structure from offset 0x6C to offset 0x88.

7.9.3 HeapBase structure
After solving the question of how to fill in the fields of our simulated Thread structure, we
needed to analyze the HeapBase structure. As shown in the table below, the free() function
only uses a few fields of this structure.
Index in the HeapBase
structure
0x00
0x02
0x05
0x09

0x0A

Description
Magic of this structure: 'BYTE'
Size of available free memory in the heap now
Pointer to the next free chunk
Pointer to the beginning of the Thread structure (we are imitating
only a part of the thread structure, so the pointer should be shifted
accordingly).
Number of requests to perform in the search for free chunks for OS
processes. In our case, the value is 1.

Table 3. Fields of the HeapBase structure used in the free() function

The size of the available memory at offset 0x02 must be larger than the memory that thefree() function will try to allocate for the simulated thread (offset 0x7C of the Thread
structure).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 68 of 82

The pointer at offset 0x05 must not only point to a free chunk, but also be large enough to
be allocated to our simulated thread (offset 0x7C of the Thread structure).
No other offsets of this structure are used during execution of the free() function.
After preparing the structures, we had to develop an algorithm for forming these structuresin the modem memory by sending WAP messages.
The process of receiving and processing WAP messages involves not only WAP protocol
algorithms, but also the algorithm for processing free and occupied chunks as memory formessages is allocated and released. Further analysis of these algorithms helped us form
the necessary Thread and HeapBase structures in the modem memory.

7.9.4 Strategy for handling free and occupied chunks
The free() and malloc() functions are called several times during the processing of incoming
WAP SMS messages. Therefore, even if an overflow is achieved, we need to ensure thatseveral conditions are met:••

No errors occur during the execution of the free() and malloc() functions.
Our Thread and HeapBase structures are created and persist.

The memory manager's handling of free and occupied chunks directly influences whether
these requirements are satisfied. We already knew the following:•••

The search for a free chunk starts from the pointer to the first free chunk in the
HeapBase structure (offset 0x05).
The size of the current chunk is calculated as the difference between the addressof the next chunk and the current chunk.
Only a chunk whose heap_free_magic is equal to 0xFFFFFFEEEE is consideredfree.

7.9.5 Selecting a new chunk
Next, we analyzed what happens when a new chunk is allocated by the malloc() function.
During allocation, the user data is overwritten with zeros. The first chunk of a suitable sizeis always allocated.
If the size of the chunk is too large (exceeds the size of the user data by 20 bytes), it will befragmented: another chunk will be created right after the end of the user data.
If the allocation process identifies a free chunk but it is smaller than the required size, andthe next chunk is also free, then a defragmentation process takes place: the two free chunks
are merged into one.

7.9.6 Releasing an occupied chunk
When releasing a chunk with an address less than the current address of the first free chunkin the HeapBase buffer (offset 0x05), its address is updated as the new address of the first
free chunk in the HeapBase buffer.
Therefore, the first free chunk in the heap is always allocated if the SUPL message size isalways set to 1. If the function for releasing memory is called in time, then sending different
SUPL messages will result in writing to the intermediate buffer located at the same address.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 69 of 82

All that remained for us to do was to call free() and malloc() in the required sequence.

7.9.7 Processing fragmented SMSes
We noticed a condition where the algorithm for receiving WAP SMS messages writes data
to the same memory addresses. If the actual sizes of the sent SMS messages are different,
we can shape our structures so that we don't have to overwrite the previously received data.
However, the size of a single SMS message is not large enough to allow us to create thenecessary structures. Therefore, we had to consider the possibility of using the WAP
message fragmentation algorithm. This way we could deliver all parts of the required data
structures.
Each WAP SMS contains a sequence number in its header. When the first WAP SMS
message is received, a buffer of size ULPSizeFromPacket is allocated on the heap, into
which all WAP message fragments are copied. However, the code does not check whether
the sequence number of the current WAP message has already been used.
This way of processing allows the first message to be followed by the last one. Accordingly,
it is possible to overflow the ULP message buffer with an arbitrarily large amount of data. In
this case, we control the pointer inside the overflowed buffer by changing the offset of thenext SMS message by sending the current SMS of the desired size: during copying, thepointer is moved by this amount. Each subsequent ULP message fragment is copied intomemory immediately after the previous one.
Thus, we can try to form the required data structures by using three kinds of WAP messages:
Message typeFirst WAP SMS message

Any message that isn't thelast one

Last message

Message properties
The size of the entire ULP message is taken from it, and themalloc() function is called to allocate a buffer to store the entire
SUPL message.
The contained data (ULP message fragments) is simply copied
after the data from the previous message (previous ULP message
fragment) into the buffer allocated when the first message wasprocessed.
The contained data is also copied after the data from the previous
message into the buffer allocated when processing the firstmessage. Then the collected ULP packet data is passed to its
handler, and the free() function is called.

If we send a second message with the same index as the first fragmented WAP SMS
message, the code will check if a buffer has already been allocated for the ULP message.
Then, a call to the free() function is made to free it - a new ULP message has been sent, so
there is no point in keeping the old one (Figure 89).
The previously allocated buffer is in the first free chunk, so it will be allocated again in thenext call to malloc() as it has the lowest address among all free chunks. The malloc() function
is called again for the first fragment of the just received ULP message. However, due to theinner workings of the memory allocator described above, the same buffer will be allocated!
This will result in the same buffer being allocated for all the first WAP SMS messages.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 70 of 82

Figure 89. Specifics of sending fragmented WAP messages

The buffer for our first WAP SMS message is always allocated in the same memory location,
so only the first 4 bytes of our ULP message will be zeroed out.
In a WAP SMS, we set the ULP message size to 1. Consequently, DWORD alignment
means that the size of the buffer allocated in the malloc() function will be 4 bytes regardlessof the size of the chunk that it will be placed in. And thanks to fragmentation, we can be surethat an overflow will overwrite the next chunk with our data. This is very important because
in order for the entire chain of free() and malloc() calls to work, it must end with a call tofree() on a chunk whose header data was overwritten by a pointer to our HeapBase
structure. We can satisfy that requirement if we are able to control the header data of freechunks.
Using the previously described methods of writing to the heap, it was possible to not only
store structures or code on the heap via WAP SMS messages, but also add a free chunk tothe chain of all heap chunks. The very first WAP SMS message overwrites the pointer in thenext chunk, which is already in the chain. We were able to overwrite this pointer with thecorrect address of the next chunk. The resulting crafted chunk resides inside our big chunkand will be the first to be found during the search for free chunks due to its location in thememory.
As a result, after creating the necessary data structures, free chunks and code in themodem’s memory, we were able to start sending WAP messages again with the index
corresponding to the first SMS in order to rewrite the data in the previously created freechunk. This ensured that the occupied chunk's HeapBase pointer was replaced with ours.
Now that we have created our own free chunk in the buffer, we need it to get claimed. And
we must ensure this happens before we send a new SMS message that will overwrite thatchunk of data. The algorithm for processing the received WAP message will help us achieve
this (Figure 90).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 71 of 82

Figure 90. Algorithm for processing a received WAP message

7.9.8 Specifics of processing each WAP message
The message is copied to a temporary buffer allocated on the heap when each WAP
message begins to be processed (Figure 91). From there, it is then copied to the buffer forthe entire ULP message created during the processing of the first WAP SMS.

Figure 91. Copying a WAP message to a temporary buffer allocated on the heap

In this case, if the WAP message was not the last one, only the allocated temporary buffer
is released after copying (Figure 92). The buffer containing part of the ULP message
remains occupied.

Figure 92. Releasing the allocated temporary buffer

In the figure above, you can see the free() function that we wanted to use. When receiving
another WAP SMS message, we copy it to the free chunk we created inside the buffer. To
do this, we sent a WAP SMS message with the data size equal to the size of the free chunkcreated inside our buffer. The malloc() function will start searching after this free chunk for

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 72 of 82

a suitable chunk to process the incoming WAP SMS. Thus, malloc() is guaranteed to return
the pointer to our chunk!
All that remained to do was to make the current offset within the ULP message buffer point
exactly to the beginning of the header of the newly allocated chunk.

7.9.9 Putting it all together
Thus, the final algorithm for exploiting the vulnerability consists of the following steps:
1.
2.

3.
4.

5.

6.

Send a WAP SMS message with the index of the first message.
By overflowing the ULP message buffer we overwrite the pointers and data of thenext chunk and create free chunks whose size is 0x10 bytes inside our SUPL
message buffer. It is important that there is an occupied chunk after the freechunk, otherwise defragmentation will happen!
Send the next WAP SMS message fragment. This message contains the
HeapBase and Thread structures.
Send another WAP SMS message with the index of the first message. This timethe message size should be large enough so that the next SMS fragment
overwrites the beginning of our free chunk.
Send another SMS fragment (but not the one with the last index!). The size of themessage must be of 8 bytes. These 8 bytes will overwrite the pointer to the
HeapBase structure in our chunk.
When the WAP message processing function exits, the free() function is called
and uses our HeapBase and Thread structures.

This procedure makes it possible to execute arbitrary code on the modem in just 4 SMS
messages.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 73 of 82

8 Post exploitation of network level vulnerabilities
8.1 Executing AT commands
We were finally able to unlock vendor-specific AT commands after we managed to write anarbitrary modem memory address as the value of our chunk pointer. To do this, we had tochange our privilege level, which is located at the static address 0x600D0AD0. Verificationof the current privilege level is done by overlaying a binary mask that corresponds to thelevel. Therefore, to elevate our privileges in the modem's AT console, we had to write somelarge number at the memory address 0x600D0AD0 (Figure 93).

Figure 93. Privilege escalation

We can run the "at@help" command to ensure that all vendor-specific AT commands areunlocked. We see the full output of the help command only if the commands are unlocked(Figure 94).

Figure 94. Vendor AT commands syntax

We can now get a list of all available vendor-specific AT commands along with theirdescriptions (Figure 95).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 74 of 82

Figure 95. List of all available vendor AT commands

And finally, we read the modem memory without registering in our GSM network and without
using any special ULP SMS (Figure 96).

Figure 96. Reading the modem memory

As a result, we have a full-fledged console for reading and writing data to the modem RAM,
which we used to unlock the vendor-specific AT command sec without knowing the special
manufacturer's key, switch the modem to manufacturer mode, and more.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 75 of 82

8.2 Code execution?
Of course, we haven't yet executed any of our code. We already had the ability to write apointer to our data at an arbitrary address in the modem's memory. This data could be binary
code compiled for ARM. It could be sent to the modem via a WAP SMS. The final step was
to find a suitable location to write the address of our code for intercepting the flow of
execution.
We had the ability to write only a single DWORD, so we searched for a place in the modem
OS code that would immediately transfer control to an address taken from RAM. We foundsuch a place in the code of the OS process manager.
The process manager works with the Thread structure. We found that a function pointercould be stored at offset 0x94 in this structure. Pointers to specific OS kernel callbacks areoften stored in this way.
Accordingly, we only needed to write a pointer to our ARM code in the heap memory atoffset 0x94 of a thread descriptor (Figure 97).
To do this, we rewrote the Thread structure that belonged to the ULP message processor.

Figure 97. Preparing for code execution

As a result, we executed our code on the modem OS in the process manager's context. In
doing so, we also confirmed that the data section is executable.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 76 of 82

8.3 Configuring the MMU
The code fragment where control was intercepted happened to be a part of a critical section.
In this code fragment, all interrupts are disabled, making it unviable for gaining persistencein the OS. Code in this mode must be executed as fast as possible to avoid triggering thewatchdog, and no operations involving external components can be performed in this mode.
Therefore, we decided to use the code executed in the context of the process manager tomodify the code of an OS thread. But the code section was mapped in RX (Read / Execute)mode. Thus, before taking any further action, it was necessary to make sure that the code
section could be written to.
During the research, we determined that the kernel stores a complete MMU translation table
at the logical address 0x00088000. The code section and the data section were mapped inpage mode, where the size of one page is 0x100000 bytes (1 MB). A 1:1 translation wasused for these sections. This can be observed in the memory area where the MMU
translation table is stored (Figure 98).

Figure 98. MMU settings

The section access mode setting was not standard one for the ARM architecture. Therefore,
we decided to simply copy the access setting from the data section, which was mapped in
RWX (read / write / execute) mode, as we have already seen. After that, we were able towrite to the code section.
Additionally, we could now obtain a physical memory map of the modem. At offset
0x00089900 there were free logical addresses guaranteed to be unmapped. However, we
could map them manually! This approach allowed us to supplement the already available
information about the modem memory map with information about the exact size of available
RAM.

8.4 SMS FS and OTAP activation
After unlocking the code section for writing, we needed to select a thread suitable formodification. UTACAT was chosen in order to then develop a half-duplex communication
channel with the modem. This process is responsible for handling SMS messages. Its code
was modified in the SMS processing function (Figure 99).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 77 of 82

Figure 99. Modification of UTACAT

After determining the location that needed to be modified, we compiled a set of functions towork with the modem's UFS. These functions let us activate OTAP and then install ourMIDlet.
Also, since most UFS functions work with local buffers, we needed additional memory
handling functions to manage modem memory. The final list of functions included:•••

Memory allocation function (malloc)
Memory release function (free)
Function for opening/creating a file in the UFS (createFile).

For each of the three functions, we needed to determine whether they could be invoked
during SMS message handling and to identify their input parameters and their format.
Memory can be managed by the malloc() and free() functions. However, high-level functions
for working with the modem’s UFS were only found in the JVM process. Analysis of themodem OS code did not indicate the presence of memory sharing between processes, so
we decided to use the functions of the JVM process within the UTACAT process.
The malloc() and free() functions have no special execution context. malloc() takes only one
parameter as input – the size of the buffer to be allocated. The free() function accepts only
a pointer to the buffer to be freed. They are shown in Figure 100.

Figure 100. Parameters of the free() and malloc() functions

The remaining function for working with the UFS needed to provide the ability to create or
overwrite an OTAP activation file. This function in the JVM process is used to work with the
UFS. It takes only two parameters as input:•

absolute path to the file in the UFS

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 78 of 82

•

operation mode

We found that 'wb' mode corresponds to the value 0x6C (Figure 101).

Figure 101. Function for creating/opening a file in the UFS

Following this research, we developed a small driver written in ARM assembly. The driverallows execution of all described functions via SMS messages (Figure 102).

Figure 102. Driver for invoking functions via SMS messages

We decided to use the special magic value 0x6AA677BB in the header to distinguish our
SMS messages from ULP, OTAP or plain text messages (Figure 103).

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 79 of 82

Figure 103. Using the custom magic value 0x6AA677BB in the message header

By applying the described technique to execute our code, we were able to successfully run
the driver within the context of the UTACAT process. This confirmed that the processes'
RAM was not isolated from each other in any way: all data and code from one process isavailable to any other process. All we had to do was to create the necessary OTAP files on
the FS and install our MIDlet (Figure 104).

Figure 104. Installing our own MIDlet

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 80 of 82

9 CVE list
CVE IDCVE-2023-47610

CVSS Score
8.1 (High)CVE-2023-47611

7.8 (High)CVE-2023-47612

6.8 (Medium)CVE-2023-47613

4.4 (Medium)CVE-2023-47614

3.3 (Low)

CVE-2023-47615

3.3 (Low)

CVE-2023-47616

2.4 (Low)

Description
A CWE-120: Buffer Copy without Checking Size of Input
vulnerability exists in Telit Cinterion BGS5, Telit Cinterion
EHS5/6/8, Telit Cinterion PDS5/6/8, Telit Cinterion ELS61/81, Telit
Cinterion PLS62 that could allow a remote unauthenticatedattacker to execute arbitrary code on the targeted system bysending a specially crafted SMS message.
A CWE-269: Improper Privilege Management vulnerability exists in
Telit Cinterion BGS5, Telit Cinterion EHS5/6/8, Telit Cinterion
PDS5/6/8, Telit Cinterion ELS61/81, Telit Cinterion PLS62 that
could allow a local, low privileged attacker to elevate privileges to"manufacturer" level on the targeted system.
A CWE-552: Files or Directories Accessible to External Parties
vulnerability exists in Telit Cinterion BGS5, Telit Cinterion
EHS5/6/8, Telit Cinterion PDS5/6/8, Telit Cinterion ELS61/81, Telit
Cinterion PLS62 that could allow an attacker with physical accessto the target system to obtain a read/write access to any files anddirectories on the targeted system, including hidden files anddirectories.
A CWE-23: Relative Path Traversal vulnerability exists in Telit
Cinterion BGS5, Telit Cinterion EHS5/6/8, Telit Cinterion
PDS5/6/8, Telit Cinterion ELS61/81, Telit Cinterion PLS62 that
could allow a local, low privileged attacker to escape from virtual
directories and get read/write access to protected files on thetargeted system.
A CWE-200: Exposure of Sensitive Information to an Unauthorized
Actor vulnerability exists in Telit Cinterion BGS5, Telit Cinterion
EHS5/6/8, Telit Cinterion PDS5/6/8, Telit Cinterion ELS61/81, Telit
Cinterion PLS62 that could allow a local, low privileged attacker todisclose hidden virtual paths and file names on the targeted
system.
A CWE-526: Exposure of Sensitive Information ThroughEnvironmental Variables vulnerability exists in Telit Cinterion
BGS5, Telit Cinterion EHS5/6/8, Telit Cinterion PDS5/6/8, Telit
Cinterion ELS61/81, Telit Cinterion PLS62 that could allow a local,
low privileged attacker to get access to a sensitive data on thetargeted system.
A CWE-200: Exposure of Sensitive Information to an Unauthorized
Actor vulnerability exists in Telit Cinterion BGS5, Telit Cinterion
EHS5/6/8, Telit Cinterion PDS5/6/8, Telit Cinterion ELS61/81, Telit
Cinterion PLS62 that could allow an attacker with physical access tothe target system to get access to a sensitive data on the targeted
system.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 81 of 82

10 Conclusion
Though being a special-purpose device, a modern modem implements numerous featuresand potential user scenarios. In fact, it is a complicated system, both from an architecture
and implementation point of view. Due to performance requirements, most of the key
features are implemented in low-level languages such as С and Assembler and therefore
lack built-in safeguards mitigating potential developers’ mistakes.
In the course of the modem security analysis, we found seven locally exploited vulnerabilities
and one remotely exploited vulnerability. The combination of these vulnerabilities could
allow an attacker to completely get control over the modem. In our truck’s security audit
project, having control of the modem we were able to get our foothold in thetelecommunication unit embedding it, and further, to propagate to other truck ECUs ending
with getting control over the main vehicle systems, such as the engine, the gearbox, thesuspension, the breaks, etc., therefore being able to totally compromise the vehicle safety
from remote.
All discovered vulnerabilities have been reported to the vendor. Some of them have notbeen addressed by the vendor so far as the product support discontinued. And even if thevendor fixed all the vulnerabilities, as we stated at the beginning of the report, in some cases,
the modem is integrated in such a way that applying updates would be difficult.
Thus, to counter the threats posed by the found vulnerabilities, Kaspersky recommends:
•
•
•
•
•

Contact the mobile operator to disable the sending of SMS messages to thedevice.
Use private APN with carefully configured security settings to limit the impact ofany potential exploit.
Enforce application signature verification to prohibit the installation of untrusted
MIDlets on the device.
Control physical access to the device at all stages of transportation to protect
against the embedding of backdoors.
When developing a new product consider remote modem compromise as a highpotential risk and restrict accordingly access from the modem (or the unit
embedding it) to other products’ mission-critical components.

As for the vendors of the modems and similar devices, to mitigate potential risks at thedesign stage, Kaspersky recommends:
•
•
•
•
•

Introduce additional memory access restrictions in the ThreadX operating system.
Use static code analysis tools to determine if there are any errors in logic or pointerarithmetic.
Perform fuzz testing (“fuzzing”) for the application to find implementation bugs
using malformed/semi-malformed data injection in an automated fashion.
Perform code walk-through audits to look for confusing logic and other errors.
Select the development tool stack enforcing security domain separation andpromoting a Secure by Design approach such as the one advocated by the
KasperskyOS developers.

Cinterion® EHS5 3G UMTS/HSPA Module Research | page 82 of 82