W H I T E PA P E R

ANALYSIS OF CELLULAR BASEDINTERNET OF THINGS(IOT) TECHNOLOGY
Deral Heiland - Principal Security Researcher (IoT), Rapid7
Carlota Bindner - Lead Product Security Researcher, Thermo Fisher Scientific

CONTENTS
Introduction

3

CAT-M and NB-IoT Cellular Technology Overview

3

CAT-M or LTE CAT-M1/CAT-M2

4

Narrow Band IoT (NB-IoT) or CAT-NB1/CAT-NB2

4

Cellular Module Review

5

Circuit Board Layout Analysis

11

AT Commands Overview

23

Inter-chip Communication Data Capture and Analysis

28

General UART Examination

28

USB Examination and Evaluation

30

MAIN UART Leveraged for Command Injections

33

Conclusion

37

References372

INTRODUCTION
In recent years, the increased use of cellular communications in Internet of Things (IoT)
technology has played a crucial role in enabling communication with IoT devices that lack
wired internet access. In addition, cellular communication is now commonly relied upon asa backup solution for wired connections like ethernet or Wi-Fi should they fail. Common
devices that have adopted cellular communication include cameras, GPS trackers, homeand building security systems, and medical devices.
Given the significant potential for this trend to continue, security researchers must focus oncomprehending this technology, its applications, and developing hardware testing methods
to evaluate the end-to-end security of cellular-based devices. Consequently, this paper
aims to address this topic and explore various testing methodologies.

CAT-M AND NB-IOT CELLULARTECHNOLOGY OVERVIEW
Since the first cellular phone service appeared in 1983, cellular technologies have been
rapidly adopted for portable computing, including notebooks, laptops, and smartphones.
Despite cellular technology becoming ubiquitous, it often comes at a premium price, withthe cost being proportional to the bandwidth used. Most IoT devices consume a fractionof the data used for email, browsing, and video streaming, making traditional cellularcommunications cost-prohibitive.
Additionally, reliance on low voltage batteries with limited power output and small form
factors complicated cellular technology use by IoT devices. Yet, a growing number of
IoT devices are leveraging cellular communications as either a primary or secondarycommunication platform. The introduction of CAT-M and NB-IoT has facilitated cellularcommunications for IoT devices.
CAT-M and NB-IoT are communication standards developed by the Third Generation
Partnership Project (3GPP). These standards focus on providing low-power wide area
network (LPWAN) radio communications for supporting IoT technology, which is focusedon machine-to-machine (M2M) communication. 3GPP initially released these standards
with Release 13 in 2015, followed by further improvements and updates in Release 14 in
2017.
CAT-M and NB-IoT are complementary standards that excel in different use cases. Thesestandards now allow IoT devices to communicate directly to the cloud via cellular services
and no longer require local aggregation via bridging technology.

3

CAT-M OR LTE CAT-M1/CAT-M2
Although the 3GPP standards include several variations of CAT-M, for consistency thispaper will focus on the generally referenced standard LTE CAT-M1, which supports a
bandwidth of 1.08 Mhz. The mode of operation supported by CAT-M1 is in-band LTE. Inband signaling is when the data is transferred within the standard LTE band or channel
used for general communication.
CAT-M1 features include upload and download speeds of up to 1 mbps, which is higher
than NB-IoT, and lower latency of 10 to 15 ms. In addition, the CAT-M1 standard supports
half or full-duplex, and has enough bandwidth to support voice communication if needed.
As a result, CAT-M1 is commonly used for IoT machine communication where more
bandwidth is required. Examples of devices that use CAT-M1 include camera systems,
alarm systems, and vehicle data collection devices.

NARROW BAND IOT (NB-IOT) OR CAT-NB1/CAT-NB2
Like CAT-M, the 3GPP standard for NB-IoT has variations. In this case, the overview will
cover the overarching features of NB-IoT. NB-IoT has a maximum bandwidth of 180 kHz
and only supports half-duplex communication. Similar to CAT-M1, NB-IoT uses in-band
LTE, although it has the added feature of using either LTE guard bands or standard mode.
Guard bands are narrow frequency ranges used for separating wider frequency ranges not
typically used for communication, while standard mode leverages unused GSM bands.
Due to limited bandwidth, NB-IoT is best suited for IoT with limited complexity and low
bandwidth requirements. Although it has lower bandwidth capabilities, NB-IoT excels in
reduced power consumption compared to CAT-M1, making it well-suited for use in IoTtechnology dependent on battery power. This standard is often used by gas and water
meters and low-power consumption sensors.
Both CAT-M1 and NB-IoT standards support Extended Discontinuous Reception (eDRX)
and Power Saving Mode (PSM) functionalities. These features allow the device’s cellularcommunication to go into a powered-down sleep mode when data transfers are notrequired, further reducing energy consumption. In the case of NB-IoT, this can extend
battery life for years, potentially up to a decade. Furthermore, since the long-term costassociated with cellular is often based on bandwidth usage, these standards havesignificantly reduced operation costs, making it possible to deploy cellular technologies into
increasingly more IoT products.
Since the initial release, 3GPP has published followup standards, including releases 15, 16,
and 17. These three releases mainly focused on various improvements to current features,
which involved:
Network operation and efficiency

•
•
•
•

Access control
Small-cell support
Power management
Improved support of 5G services and features

4

CELLULAR MODULE REVIEWIn 2022, global shipments of IoT cellular modules grew 14% year-over-year, according toCounterpoint’s Global Cellular IoT Module and Chipset Tracker by Application report. In
the first quarter of 2023, Quectel was the leading manufacturer in the IoT cellular market,
accounting for 37.2% of global cellular IoT module shipments. Other manufacturers that
accounted for just over half of IoT cellular module shipments included Telit Cinterion,
Fibocom, China Mobile, and Sunsea.
During the initial selection of devices, we focused primarily on GPS trackers that used either
NB-IoT or CAT-M for cellular communications and could be readily purchased on the open
market. We later widened our device type search to other areas, including cellular modems
and field cameras. While we performed reconnaissance on devices using FCC IDs whenavailable, we could not identify the cellular modules used by all devices before purchase.
We found 10 of the 14 devices we initially reviewed used Quectel or Telit Cinterion modules
based on FCC documentation.
One of the Quectel modules encountered was the Quectel EG91-NAXD, part of the Quectel
LTE EG91 series that supports LTE CAT-M1, found in two different field camera models
from the same manufacturer. The Quectel LTE EG91 series is pin-to-pin compatible withQuectel’s UG95, UG96, BG95, and BG96 modules. The pin-to-pin compatibility allows
device manufacturers to swap modules, which allows changing modules for cost savings
or if supply chain availability affects a particular cellular module version. As a result, twodevices with the same make and model may have a different cellular module in use if they
were manufactured at different times. Figure 1 shows the Quectel EG91-NAXD from one of
the field cameras.

Figure 1. Quectel EG91-NAXD on Field Camera PCB

5

In addition to the field camera, a Quectel BC26 cellular module was found in a USB
cellular modem, as shown in Figure 2. At the time of writing, a search on the Quectel
website returned no information on the Quectel BC26 or product end-of-life notificationthat would indicate it had been discontinued. We found information for the Quectel BC26
from third-party seller listings and developer forum posts, which indicated it was still forsale and actively used for development. The Quectel BC26 provides CAT NB1 connectivity
with support for various network protocols and multiple serial ports, including one for AT
command and data transmission and two more for debug and serial connection.

Figure 2. Quectel BC26 in Cellular Modem

In other devices, we found an array of Telit Cinterion modules, including some labeled
as Telit and others as Cinterion. The label difference is due to Cinterion’s incorporationof Thales’s cellular IoT products in 2022. Figure 3 shows the Telit ME910CE-NA used
in a compact cellular modem purchased for research. Like the Quectel BG91, the Telit
ME910CE-NA supports CAT-M1 and NB1 communications and industry-standard
interfaces, including USB, UART, SPI, and I2C.

Figure 3. Telit ME910C1-NA in Cellular Modem

6

Another Telit Cinterion cellular module, the Cinterion S30960-S6200-A100-1, was found in
a GPS tracker with a U-Blox SAM-M8Q smart antenna module, as shown in Figure 4.

Figure 4. Cinterion Cellular Module in GPS Tracker

In addition to Quectel and Telit Cinterion modules, other cellular manufacturers wererepresented in GPS trackers purchased for research. After Quectel and Telit Cinterion,
U-Blox cellular modules were third most common in the GPS tracking devices, including
the SARA-R412M, SARA-U201, LISA-C200, and LEON-G100. Figure 5 shows the U-Blox
SARA-R412M found in a pet tracker. The SARA-R412M provides multi-region support
using both CAT M1 and NB1, features an integrated GNSS receiver for positioning,and supports multiple networking protocols focusing on MQTT for low-bandwidthcommunications.

Figure 5. U-Blox SARA-R412M in GPS Tracker

7While we intended to select devices using cellular modules currently on the market, twoof the U-Blox cellular modules in vehicle trackers purchased for our research had been
discontinued, the LEON-G100 and the LISA-C200. Figure 6 shows the LEON-G100
cellular module found in a vehicle tracker purchased in 2021, while U-Blox’s End-of-Lifeannouncement for the module was released on May 19th, 2017. Finding cellular modules
no longer supported by the manufacturer in new devices demonstrates that End-of-Life(EoL) components continue to persist not only in currently deployed products but also incurrent inventory awaiting sale.

Figure 6. U-Blox LEON-G100 Cellular Module

In addition to U-Blox, we found one Nordic cellular module in a pet tracker. Figure 7 shows
the Nordic nRF9160-SICA-R module, which had an ARM Cortex-M33 that supported
LTE CAT M1 and NB1 communications and included SPI, I2C, and UART interfaces. The
Nordic nRF9160-SICA-R was one of the smallest cellular modules with a package size of
10x16x1.04 mm LGA.

Figure 7. Nordic nRF9160-SICA-R Module8In addition to cellular-enabled devices, we also purchased development kits for cellular
modules found in the consumer products purchased or in the same product line. This included
a Telit Bravo Rev D board with a ME910C1-WW module and a U-Blox EVK-R4 evaluation kit
with a SARA-R410Mc cellular module, as shown in Figure 8 and Figure 9, respectively.

Figure 8. Telit Bravo Rev D Board

Figure 9. U-Blox EVK-R4 Evaluation Kit

Additionally, we found some development boards which supported different cellular modules
using various connectors. Figure 10 shows the Cinterion LGA DevKit development board,which included a socket that could accommodate different Cinterion cellular modules.

9Figure 10. Cinterion LGA DevKit with Small Socket

The Quectel UMTS & LTE EVB kit supports four module types, including automotive,
LPWA, LTE Standard, Wi-Fi/Bluetooth, and multiple cellular mobiles for both LPWA andLTE Standard.
Figure 11 shows the Quectel UMTS&LTE-EVB-KIT with an EG91-NA module.

Figure 11. Quectel UMTS&LTE-EVB-KIT with an EG91-NA module

10CIRCUIT BOARD LAYOUT ANALYSIS
When examining cellular modem modules on IoT devices, it is crucial to comprehend thecircuit layout and orientations on the circuit board in relation to other components, such as
the device’s primary CPU. Additionally, you should consider the following factors:•••

How are cellular modules oriented on the circuit board?
How can this orientation information be used during testing to find potential
communication test points?
How do we access these communication test points even if they are not readily
available on the circuit board’s surface?

In this section, we will disassemble a couple of cellular-enabled devices to address thequestions mentioned above and explore various examination and hardware interaction
methodologies.
It is important to note the methodologies discussed here can be used on other circuit
technologies besides cellular.
The first example we looked at was a Telit GE910 cellular module used in a home security
system. Initially, we tried to understand the orientation of the cellular modem and its
potential communication paths on the circuit board to identify connection points for testing,such as:•••Main UART
Debug UART
USB

Like most IoT devices, we examine the circuit board to identify all components, gather
needed manufacturer’s datasheets, and check to see if there are any good markings on thecircuit board to identify points of interest. Once that analysis is complete, if you still need tobetter identify points of interest, the next method we use is a transparency overlay of thecircuit board images.
By using the obverse (frontside) and reverse (backside) of the circuit shown below in Figure
12 and Figure 13, we produce an image as shown in Figure 14, which shows components
on both sides of the board in reference to each other. This helps visualize key components
on each side of the board in reference to each other and potential circuit paths.

11

Figure 12: GSM Telit GE910 Cellular Board Obverse Image

Figure 13: GSM Telit GE910 Cellular Board Reverse Image

Figure 14: GSM Telit GE910 Cellular Board Transparency Overlay

In the final part, we will often overlay the cellular modem device’s Land Grid Array (LGA)
mapping from available datasheets. This allows us to quickly find where the cellularmodem module’s core communication connections are (UART, USB), and identify potential
contact point locations on the circuit board so we can tap into them. An example of thisconcept is shown below in Figure 15:

Figure 15: Telit GE910 LGA Pinout Layout Overlay on Transparency

12

The above method works well for establishing a general starting point for identifying theareas of the circuit board that are most likely to have a potential location for connecting tocommunication points on the circuit board for testing. Although, in some cases, we havefound well-designed circuit boards that do not expose easily accessible communication
points on the board’s surface, but appear to be leveraging sublayers of the board. In thissection, we also want to explore another method for connecting to communication points
not directly exposed on the top layers of the circuit board.
We will refer to this method as submodule unit access (SUA). In this process, we takeadvantage of the fact that the most valid communication connection on cellular modules
LGA pads typically runs around the outer perimeter of the cellular modules. For example,
Figure 16 shows the measurement diagram from the BG95 hardware design manual andgrid array of Quectel BG95 module, which shows that the points of interest are within .2
mm of the module’s edge.

Figure 16: Quectel BG95 Pin-out Diagram and Module Side-by-Side Comparison

With that knowledge, it is possible to make entry from the side along the plane of thecircuit board surface to establish a connection to needed communication points, such as
USB, MAIN UART, and UART DBG. Figure 17 demonstrates a side view of the Quectel
BG95 module attached to a circuit board showing a small gap and individual LGA padconnection points.

Figure 17: Wide-view and Side-view of Quectel BG95 Module13

To attach to these contact points under the cellular modules, we used acupuncture needles(probes) to tap into the device’s UART communication. Using different size acupuncture needles(.15 - .35 mm) we built several test probes. We purchased these probes — acupuncture-styleneedles — from online retailers selling them for cleaning out 3d printer nozzles.
Figure 18 shows an example of an assembled test probe consisting of an acupunctureneedle and jumper wire connected using heat shrink butt connectors. During testing, wefound that the larger needles (.35mm) were easier to work with when connecting to LGA
modules where the pads were closer to the edge of the modules. The reason for this was
the thicker probes were less flexible.

Figure 18: Test Probes Assembled from Acupuncture Needles

Before inserting probes under the cellular module edge, any exposed components on thecircuit board should be covered with insulation tape to prevent shorting the probes. To dothis, we used Kapton tape. It is also possible to wrap the probe needle, except the very end,in Kapton tape to insulate it from shorting. Also, during this process, we noted that entry
under the modules must be made by remaining parallel with the PCB surface as much as
possible to avoid damaging solder masking, which could lead to shorting out the probe. An
example of this is shown in Figure 19.

Figure 19: Probes Inserted Parallel to PCB with Kapton Tape

14

Once probes were inserted, getting them to remain in place was problematic. To do this,we used a flexible adhesive called E6000, which can be easily removed after work iscompleted. This adhesive had issues adhering to the stainless-steel probes and required
us to add more E6000 covering a larger section of the probe body to prevent probes
from being dislodged. Further adhesive testing was conducted using different adhesives,
including a couple of different brand super glues and various forms of UV set solder masks
and resins. Ultimately, we found the E6000 to be the most effective method for holding theacupuncture probes in place.
Once the probes were secured with adhesive, we tested the reliability of the overall processby reinstalling the cellular control board, attaching the probes to a Saleae logic analyzer,
and powering up the devices, as shown in Figure 20.

Figure 20: Saleae Connected to Probes Inserted Under the Cellular Module

We also examined the use of this method on larger cellular modules where the LGA
contact points were further from the edge of the module. In the case of the Quectel EG91,
the LGA connection points were 2.75mm from the edge of the module body with a gap
along the edge that was not wide enough to properly insert any size acupuncture probes
to make contact with LGA connection points. So this method was found to be mosteffective against smaller-sized cellular modules where the LGA lands are nearest to themodule edges.
The final mechanical methods we want to examine in this paper are potentially more
destructive and require actually removing and reinstalling the cellular module. If care andpatience are taken, these methods can be very effective, allowing access to more easily
map out critical circuit paths or modifying existing circuit board traces to allow for accessto critical communication points. In this section, we will examine a Quectel EG91-NAXD
module used in a trail camera, as shown in Figure 21.

15

Figure 21: Quectel EG91-NAXD on Trail Camera’s PCB

To remove a cellular module, the method we prefer involves using an Infra-Red (IR) reflow oven.
However, this process can be accomplished with directed IR or hot air systems combined witha preheater hot plate. Setting up a temperature curve to heat the board and chip at a rate that
does not shock or damage the chip is critical, and the hardest part of this process.
To accomplish this in an IR reflow oven, we must also consider the complete mass of thecircuit board, which must be brought to the melting temperature of the solder (183 Celsius)
before components, such as the cellular module, will be released. To do this, we set our
IR reflow oven temperature curve to rise to match manufacturer recommendations, often
defined within the datasheets, along with an extending time and higher peak temperature
set to approximately 240-250 Celsius on average and vary the length of time the reflow
oven stays at that temperature based on the size and thickness of the overall circuit board
to which the cellular module is mounted.
With that said, it is important to remember that individual components on the circuit, suchas memory and CPU chips, can easily be damaged if they reach a temperature of 215
Celsius or higher. Also, when the module is ready to be removed, caution should be taken,
as all components on the circuit board are loose, and it is very easy to accidentally dislodge
other components, especially when working with very small circuit boards.
Furthermore, when removing larger cellular modules with a suction tool, it is not uncommon
to just pull off the shielding and not remove the module. In those cases, we have beenable to either slide the module off the board without dislodging other components or use acellular phone repair tool with a wide blade, as shown in Figure 22. The wider blade can beinserted under the module body to help lift the module from the surface.

16

Figure 22: Thin Blades for Removing Components

Once the module has been removed from the circuit board, we can examine the LGA
layout, and use a multimeter set on continuity check to help trace out the communicationlines we would be interested in accessing, as shown in Figure 23.

Figure 23: Footprint of Quectel EG91-NAXD on Trail Camera’s PCB

For example, in Figure 24, we can see that the Main UART communication lines, labeledin yellow and blue, were routed in a direction under the module body, which would have
impacted our transparency overlay method used for finding possible communication on thecircuit board, as described at the beginning of this section. Although chip-off examination
adds a level of complexity to the testing process, this example helps emphasize the value
in chip-off examination methods.

17Figure 24: UART Traces Highlighted on PCB

In addition to examining the PCB traces for UART, we were able to map out USB
communication lines. Cellular devices typically do not use both USB and the Main UART
for transmitting data or controlling the cellular module. Most often, the one (USB or Main
UART) not in use will have its LGA lands not connected to any circuit paths on the circuitboard, which can indicate the one currently in use.
Additionally, while examining the board with the cellular modules removed and comparing
other connection points to the pinout diagram within the EG91 Series design manual, we
identified the USB_Boot circuit layout. USB_Boot is used to place the device into a modefor conducting firmware upgrade processes. Examining our device, we also see that thecircuit board contains most of the circuit designed to support that functionality, as shown in
Figure 25.

Figure 25: USB_Boot Pin on PCB18

It can often be difficult to locate USB communication tap points on a circuit board. Thisis because, in many cases, those communication lines are routed via the sublayers on
the circuit board and not easily accessible. However, many times we have found that
the USB circuit path between the cellular module and CPU involved the installation ofresistors inline. When that is the case, the USB circuit paths are routed to the circuit board’s
surface for that purpose. In some cases, to effectively map out those USB paths, it may benecessary to also remove the primary CPU if it is on the same circuit board. For the device
we are examining, that was not the case, and we could easily identify various tap points on
the circuit board, as shown in Figure 26. Also shown in Figure 26, the USB communicationline does have resistors installed inline, as mentioned above.

Figure 26: USB Inline Resistors on PCB

To prepare the USB communication for analysis, we also needed to install 20-40 ohm
resistors between the USB D+ and D- lines and the testing gear. Adding these resistors
helps to prevent impedance mismatching and signal echos that would degrade the USB
communication signals. In our case, we installed surface mount device (SMD) size 0601
33 ohm resistors directly on the circuit board next to the inline resistors already installed,which would allow us to attach test gear later during signal capture and analysis. A
sample of this is shown in Figure 27.

Figure 27: Installation of Additional Resistors

19

To better streamline this for future research, we decided to build a USB test jig, which could
then be attached to the target device and or piggybacked onto the circuit board using
E6000 adhesive. Building out the prefabricated test jigs, we purchased USB micro breakout
boards and cut the circuit traces for D- and D+, then soldered SMD size 0402 33 ohm
resistors in place, as shown in Figure 28.

Figure 28: Installation of Resistors on USB Test Jig

In this final section of the Circuit Board Layout Analysis, we want to cover those rare cases
where we may find a need to alter the circuit board design to better support the testing
work and to gain access to communication features for the cellular device. Although theneed for this is rare, it is important to understand the processes and also have the skills to
do the work. Building and understanding the skills needed ahead of time will help facilitatea more streamlined and timely effort versus wasting time with trial and error efforts whenrequired.
Although not needed in our test example, we decided to walk through the process of board
alteration to add lines from the EG91 LGA pads for Main UART out to an easily accessed
point on the circuit board. Figure 29 shows the LGA pads of interest.

Figure 29: Identified Main UART LGA Pads

20

Some of the supplies we used for the exercise example included circuit board traces, a
pad repair kit, and UV solder mask ink, as shown in Figure 30. We tested several brandsof UV ink and found all required a long UV set time to cure. This set time varied from a few
minutes to 10+ minutes based on how thick the UV solder mask was applied.

Figure 30: Pad Repair Kit and UV Solder Mask Examples

In the first step, we peeled off the copper repair trace from the kit, which had a sticky backthat allowed us to place it on the circuit board to hold it in place. Note: These repair traces are
small and fragile and patience should be taken while handling them. In our case, this typicallytook a couple of tries before we did it correctly without damaging the fragile traces.
Besides using a circuit board repair kit, it was also possible to use thin gauge wire, such as
40 gauge or smaller. Once we had the repair traces properly placed, we tinned the LGA padand the trace connected to the LGA pad so that proper electrical continuity could be validated
between the LGA pad and the repair trace pad. Once that was validated, we applied the UV
solder mask to electrically insulate the added trace, and hold it in place. We then set the UV
solder mask with a UV lamp, as shown in Figure 31 and Figure 32, respectively.

Figure 31: Installed Repaired Traces

21

Figure 32: Hardening UV Mask with UV Lamp

Next, we tinned the repair trace pads, added more UV solder mask around the pad, andcured it to strengthen it further, as shown in Figure 33. This was done to avoid accidentally
damaging the pads later when connecting them for testing purposes.

Figure 33: Tinned Repair Trace Pads and Set UV Mask

The final step was re-attaching the cellular module by reflowing it on with an IR oven. To
re-attach, there are several methods available. Often the solder paste is applied usinga screen that matches the LGA layout for that module. Diagrams of these screens are
typically available from the manufacturer. If solder screens are not readily available, using
solder paste correctly can often be problematic. In those cases, we have successfully used
BGA balls applied to the cellular module with much success.
An example of this process is demonstrated in Figure 34, where BGA balls were used andthen reflowed within an IR oven using the manufacturer’s recommended temperature
curve. The final results after reassembly show the added circuit traces and pads in the rightside image of Figure 34.

Figure 34: Reflowed BGA Balls with an IR-Oven

22

AT COMMANDS OVERVIEW
AT commands, short for “Attention Commands,” are instructions that allow a host controller
to control and debug a modem. AT commands, originally known as the Hayes command
set, were developed in 1981 for the Hayes Smartmodem 300. The original Hayes
command set allowed for dialing, hanging up, and configuration of the modem.
To support new functionality available with 1200 and 2400 baud modems, a Hayes
extended commands set was created with the new commands denoted by including anampersand (&) prefix. By the early 1990s, with the introduction of the 14.4 and 28.8 kbit/s
modems, modern AT commands heavily based on the original Hayes extended set were
widely adopted by most modem manufacturers.
The original Hayes extended command set influenced the modern universal AT commands.
While AT commands are often common across different modems, AT commands forcellular modems have been defined in Technical Specifications (TS). In particular, the
ETSI GSM TS and 3GPP TS 27.007 technical specifications apply to cellular modules that
support NB-IoT and CAT-M1/M2. During our research, we also found cellular module
manufacturers, such as Telit, U-Blox, Quectel, and Nordic, implemented proprietary AT
commands for use in their cellular modules. AT commands in mobile communications canbe used to perform many actions including, but not limited to:

•
•
•
•
•
•
•

Obtaining device or manufacturer information
Accessing SIM and network information
Scanning for and registering with supported networks and radio types
Receiving updates about network conditions
Waking and putting the device to sleep
Receiving and sending SMS and calls
Sending data via TCP/IP

There are four (4) main AT command types, including test, read, write, and execute. The
command type informs the syntax of the command. Each AT command begins with theprefix ‘AT’ or ‘at’ followed by a command. The command portion may contain one ormore fields or suffixes, which indicate the command mode or ‘type’ and a data field forcommands that support or require data. The table below outlines the command syntax
associated with the main AT command types.

23

Type

SyntaxFunction

Test

AT+<COMMAND>=?

Returns parameters and value
ranges set by <COMMAND>.

Read

AT+<COMMAND>?

Returns the current parametervalues.

Write

AT+<COMMAND>=<User Input>

Sets command parameters to userdefined values.

Execute

AT+<COMMAND>

Executes the command. May
function similarly to read returning
non-variable parameters.

Note that AT commands can be sent individually, with each AT command terminated by acarriage return or multiple commands placed on the same line with a single AT prefix at the
beginning of the line followed by individual commands separated by a semicolon.
The 3GPP TS 27.007 details a standard AT command set for controlling Mobile Termination(MT) functions and network services from Terminal Equipment (TE) through Terminal
Adapter (TA). The 3GPP TS 27.007 used commands from ITU T Recommendation V.250
and existing digital cellular standards whenever applicable.
Some examples of common AT commands include:

•
•
•
•
•

AT: This is the most basic AT command, confirming that the modem and hostsystem can communicate, denoted by an ‘OK’ response.
AT&F: This command sets all modem parameters to manufacturer defaults.
AT+CPIN: This command can query whether the module requires a PIN, which isnecessary for registration, and be used to set the PIN. By issuing this AT commandwith a question mark (?) at the end, the cellular module will respond with whether
a PIN is set, whereas issuing this command with an equal sign (=) followed byalphanumeric characters will set a PIN.
AT+CGSN: This command requests the product serial number identification or theInternational Mobile Equipment Identifier (IMEI).
AT+CLAC: This command will return a list of AT commands available to the user.

As mentioned previously, manufacturers can implement their own proprietary commands
for use with their cellular modules. Based on AT command documentation and articles,
manufacturer proprietary commands can be identified based on the syntax adopted by the
manufacturer.

24

Examples of cellular module manufacturer’s proprietary AT command syntax include:

•
•
•
•

Quectel: AT+Q<COMMAND>
U-Blox: AT+U<COMMAND>
Telit: AT@<COMMAND>, AT#<COMMAND>, AT$<COMMAND>, orAT*<COMMAND>
Nordic: AT%<COMMAND>

Since AT commands are used to perform various functions on a cellular modem,
unauthorized use poses an inherent security risk to cellular-enabled devices. We reviewed
previous security research on AT command vulnerabilities and found it focused on the
Android ecosystem and smartphones. In particular, a research project called ATtention
Spanned released a research paper at USENIX in 2018 on vulnerable AT commands.
Additionally, we found a security paper titled “ATFuzzer: Dynamic Analysis Framework
for AT Interface for Android Smartphones,” which had a corresponding GitHub repository
where the researchers published the Python-based ATFuzzer tool.
As part of our research, we wanted to focus on the ability to intercept and identify AT
commands sent to the cellular module and attempt to inject AT commands. Since there areboth standard and custom AT commands, we used documentation released by vendors togenerate a list of possible AT commands. Manufacturers will often include AT commands incellular module documentation or AT command reference guides that have proprietary AT
commands, such as Telit’s AT Commands Reference Guide.
To automate testing AT commands against cellular modules, we created a couple of simple
Python scripts that can be used to send various AT commands when connected to theMain UART of the cellular module. The scripts we generated are focused on the following
functions:•••

Read command options
Retrieve device settings and status
Fuzz command options

Each script allows the user to configure the local UART interface within the script.
Additionally, the ATquery.py script allows users to select from common cellular module
manufacturers, including Quectel, Telit, and U-Blox, to read and test against common
AT commands. The CellModuleATFuzz.py script enables the user to input individual
AT commands for testing and fuzzing the various variables associated with each AT
command. The following section describes the syntax for using these various scripts.
The first script, ATquery.py, allows us to query the cellular module via serial connection tocarry out two possible options:
1. Identify which commands are functional by using the TEST switch, or
2. Query the available commands using the READ switch to retrieve the current setting
for that command, if available.

25

To initially set up the script, you must add the location path for the attached serial device tothis script. Currently, the change needs to be made on line 40, as shown below in Figure 35.

Figure 35: Configuration of Serial Connection on Line 40 of ATquery.py

The syntax for this script is simple and takes two arguments. The first argument is for thebrand of the device being tested. The script currently supports the following manufacturers:

•
•
•
•

CINTERIONQUECTEL
TELIT
UBLOX

Note: The supplied AT commands do not include those that may negatively impact testing,such as those that cause the cellular module to reboot, shutdown, sleep, or delete data,
which impacts desired functionality when testing.
The second switch is either READ or TEST. As mentioned above, the TEST switch returns
the command with the parameters and available input syntax data. The READ switch will
return the current setting under that command, if available. If the command or data areunavailable, the device will return an error message for that AT command.
An example of the script ATquery.py being run against an EG91-NAXD cellular modulewith the TEST switch set, as shown in Figure 36.

Figure 36: ATquery.py with TEST Switch Set for a Quectel Module

Figure 37 shows the script ATquery.py running against the EG91-NAXD cellular modulewith the READ switch set.

Figure 37: ATquery.py with READ Switch Set for a Quectel Module

26

The second script, CellModuleATFuzz.py, allows us to query the cellular module and inject
various values into the options available for an AT command. Upon initial execution of
CellModuleATFuzz.py, the user is prompted for an AT command. The script runs the TEST
version of the AT command and returns the available parameters and values. Figure 38
shows the initial prompt and supplied AT command “CMGL,” used to list either new (0),read (1), stored and not sent (2), stored and sent (3), or all (4) SMS messages depending on
the value selected.

Figure 38: Initial Prompts for CellModuleATFuzz.py

The Python script then requests the number of parameters for the supplied AT command anduser input for the parameters with an index beginning at zero (0), as shown in Figure 39.

Figure 39: User Input Configured for AT Command Parameters in CellModuleATFuzz.py

Once the parameters are defined, a user can either select to fuzz all the parameters or
select individual parameters, as shown in Figure 40.

Figure 40: Selecting AT Command Parameters to Fuzz

27

Figure 41: Output for CellModuleATFuzz.py

The script will then use the supplied file of fuzzing payloads to test the selectedparameters. The output, including the command sent and the response, is printed to theconsole and saved to a text file for easy review. Figure 41 shows the fuzzing initiated on
the AT+CMGL command.

INTER-CHIP COMMUNICATION DATACAPTURE AND ANALYSIS
In the following section, we focus on capturing data and understanding what is taking
place and possibly manipulating that data in some cases to allow for more advanced
security testing to take place. To effectively do these we need to first be able to capture thedata. Using the method described in the previous section, we can tap into Main UART and
USB communication for this purpose. In the following examples, we will be using a cellularbased trail camera, which is using a Quectel EG91-NAXD cellular module to demonstratethese processes.

GENERAL UART EXAMINATION
The first communication data we want to look at on this device is the UART. This cellular
module has two UART connections, one for device debug purposes (Debug UART) and one
for cellular data and/or AT commands (Main UART). When we attach to the Debug UART
we can see the device boot up and a login prompt show up. This boot process shows somedetailed messaging that can help reveal some details about the cellular module and its
current state. An example of this output of the cellular module device booting up is shownin Figure 42.

28

Figure 42: Debug UART Output

Next, we focused on the MAIN UART port, which handles cellular communication andassociated cellular modem commands. Since this Main UART had communication going inboth directions (Inter-chip communication) between the cellular module and the CPU, it isimportant to capture communication in both directions, represented in Figure 43.

Figure 43: Inter-chip Communications Example

To accomplish this, we used two FTDI serial to USB devices, represented in Figure 44,
attached the Rx (receiver) side of the FTDI devices to the device under test, and started
two instances of Coolterm, a serial application to the FTDI devices. When choosing FTDI
devices, it is important to match the device to the proper voltages of the UART you areattaching to. This voltage is most often either 1.8vdc or 3.3vdc. In the case of the EG91
modules, the voltage being used is 1.8vdc, as identified within the available datasheets.

Figure 44: Placement of FTDI Serial Devices

29

Using the methods described in the section “Circuit Board Layout Analysis,” we identified
the location of the Main UART — which is typically used for cellular data and or AT
commands — and attached a Saleae logic analyzer to the circuit to identify communication
and baud rate. With the Saleae logic analyzer, we determined the baud rate to be 115200
and that the CPU was not using the Main UART for cellular communication nor cellularmodem AT commands.
No data or commands were transmitted from the CPU side of the circuit. We only saw thecellular module responding with an ‘RDY’ ready response when it powered up for initial
functionality. Additionally, we noted a ‘Powered Down’ response when the cellular module
was turned off or was placed into sleep mode. This indicated that the trail camera device
was configured for data and AT commands to flow from CPU over USB to the cellular
module device. An example of this Main UART communication from the cellular module on
the Saleae logic analyzer is shown in Figure 45.

Figure 45: Main UART Communication Example from Trail Camera

USB EXAMINATION AND EVALUATION
Next, we focused on examining the USB communications of the sample device (a cellular
trail camera). Typical USB communication within IoT technology is the USB 2.0 standard
or a subset of that standard. The communication speed of USB 2.0, also known as highspeed USB, is 480Mbps. To sniff and decode this traffic requires a device that can handle
communications at that speed. Typical logic analyzers are unable to sniff and decode highspeed USB. Also, many USB sniffers are designed to only be placed in line to be able tocapture and decode USB traffic. In the case of high-speed inter-chip USB communication,
it is not possible to place a typical USB sniffer device inline. However, after some searching,
we found that the Beagle USB 480 product from Total Phase was capable of performinginter-chip communication sniffing.
Using the configuration discussed in the section “Circuit Board Layout Analysis” for tapping
into USB inter-chip communication, we attached our USB sniffer to the device being tested,
as shown in Figure 46.

30

Figure 46: Inline USB Sniffing

According to the manufacturer, to work properly, the Beagle also needs to detect the VBus
voltage, which would normally be detected when inline testing of USB devices. However,since this is inter-chip communication and VBus is not always accessible, we tricked the
Beagle by supplying the 5v VBus to it via an external power supply, as shown in Figure 47.
The vendor also defines settings that can be made to the Beagle on their support site to
bypass the required detection of the 5v VBus.

Figure 47: Attachment of an External 5V Power Supply for VBus

The device under test had not yet been registered nor activated for cellular service, since
we wanted to capture the entire activation, configuration, and data transfer via the USB
sniffer. By doing this, it allows us to gather a full understanding of — from beginning to end— how a hardware device is set up and integrated into a functioning ecosystem.
Once the sniffer application “Data Center”, which was provided by Total Phase, wasconnected and started, we enabled filters to only show data packets. We quickly saw that
the CPU was sending AT command queries to the cellular module to make some general
settings and to check the status.
Since we had not requested activation of the product service as of yet, we see a numberof queries about setting and status showing that the service has not yet been activated.
For example, the CPU continued to make requests for the status of the network using thecommand AT+QNWINFO to the cellular module, and the cellular module continued to reply‘No Service,’ as shown in Figure 48.

31

Figure 48: Example Sniffing of AT Commands

Once the service activation occurs and the cellular module connects to the LTE-M1 cellular
services, the response to the AT+QNWINFO returns details on the current network status,
as shown in Figure 49.

Figure 49: AT Command Output Showing Connection Information

Once the trail camera was configured to capture images and send the data to the available
cloud service via cellular communication, we captured key parts of that communication
as it flowed between the CPU and the EG91-NAXD cellular modules for transmission.
Analyzing this communication helps in properly identifying and understanding thedevice’s end-to-end security and associated security configurations. Figure 50 shows
key authentication data being sent for authorization to Amazon S3 buckets and thetransmission of captured images and video.

32

Figure 50: Authorization and Transmission of Data

Exporting the captured USB communication data also allows for more detailed parsing andexamination of the captured information. For example, the above packets were exported
and then parsed to extract the ASCII data showing OAuth Authentication and S3 bucket
information, as shown in Figure 51.

Figure 51: Traffic Capture of OAuth Authentication Information

MAIN UART LEVERAGED FOR COMMAND INJECTIONSIn the final part of the section, we want to circle back and further address how Main
UART could be used for testing. On this trail camera device, we found that the Main UART,
although electrically connected in-circuit, was not leveraged on this device for command ordata communication services.
During monitoring for communication, we only observed the cellular module responding
with an ‘RDY’ response when it powered up and became functional and a ‘Powered Down’
response when the cellular module was turned off or was placed into sleep mode. Throughthat observation, we determined that the Main UART was functional and could be used tosend and receive command data to the cellular module. To test this option, the Main UARTTX and RX circuit traces between the CPU and cellular modem would need to be severed
to allow external injection of AT commands via serial FTDI, as shown in Figure 52.

33

Figure 52: Placement of FTDI Serial to USB Devices for Main UART Channel

To implement the above configuration, we located the Main UART circuit traces between
the CPU and the cellular module on the trail camera circuit board, cut the circuit traces,
and rerouted each side of the severed connection to a breakout board containing on/off
switches with 2.54mm headers and screw terminals, as shown in Figure 53 and Figure 54.
This allowed us to connect the device under test and needed test equipment (FTDI, Saleae
Logic Analyzer, etc.). This also allowed us to use the on/off switches to open and close
the Main UART communication circuit between the CPU and cellular module as needed.
Details of this alteration are shown in Figure 53.

Figure 53: Cut and Tap in Main UART TX and RX Circuit Traces

Figure 54: Attachment of Tapped Main UART TX and RX Leads to Switches

34

Once the trail camera circuit board was prepped and serial FTDI was connected, we
powered up the device and opened the on/off switches on the breakout board to sever theMain UART inter-chip communications. Once we received the ‘RDY’ reply from the cellular
module, we were able to then send AT commands, and successfully received responses
from the EG91-NAXD cellular module. Figure 55 demonstrates the sending and receiving ofmultiple AT commands.

Figure 55: Successful Execution of AT Commands on Cellular Modules

During this testing, we also injected a full list of AT commands using the ATquery.py scripts
described in the AT Commands section and the QUECTEL AT command list, which wecreated using available Quectel vendor AT manuals we could identify. With this script, we
identified that many AT commands were valid despite not being listed within the EG91 AT
manual nor being returned by the module when the AT+CLAC command was used. The
most interesting of these commands were communications commands for interacting with
FTP, HTTP or setting up and communicating over IP sockets.
Next, to test this undocumented functionality on the EG91-NAXD module and validate
what level of communication could be established outside of the cellular module’s purpose
within the trail camera, we used the trail camera’s installed cellular module (EG91-NAXD)
to establish an FTP connection to the internet and listed the files and folders on that server.
This was done by injecting specific AT commands to establish FTP connection to the server
over the internet and retrieve listing, as shown in Figure 56.

35

Figure 56: FTP Connection to Remote Server

It is also important to note, unlike the device we used in this test example, we haveencountered cellular-enabled IoT devices that were configured to only establish private
Access Point Name (APN) or private cloud (VPC) connections into backend services andwere not accessible directly from the general internet IP address ranges.
This is typically done to add a higher level of security to those services by not having them
directly exposed to the internet. In those cases, communication functions on the cellular
module could potentially be leveraged to conduct further security testing into those private
APN environments using features such as MQTT, FTP, HTTP, and IP socket enablement
functions if available on the cellular module of the device being tested. Figure 57 visually
represents a high-level diagram of such use cases.

Figure 57: Possible Communications Path of Private APN or Private Cloud Environments

36

CONCLUSION
In conclusion, the main purpose of this paper was to discuss various methods andmethodologies for interacting and working with cellular-based IoT technology for the
purpose of understanding and being able to effectively test these technologies. Although
this paper is only the starting point for being able to truly understand and conduct
thorough security testing of cellular IoT technologies, it has helped us build a solid baseline
to continue growing.
As with most projects, just the process of sharing this knowledge and working throughsome of these methods and procedures has helped us further expand our areas ofknowledge. It is important to note that even beyond cellular-related device research, thesections “Circuit Board Layout Analysis” and “Inter-chip Communication Data Capture andAnalysis” can also be easily applied to other embedded device testing and analysis work.

REFERENCES:
https://i.blackhat.com/USA-19/Wednesday/us-19-Shupeng-All-The-4G-Modules-CouldBe-Hacked.pdf
https://pallavaggarwal.in/2023/11/08/quectel-ec25-cellular-modem-teardown/
https://www.5gamericas.org/wp-content/uploads/2021/01/InDesign-3GPPRel-16-17-2021.pdf
https://www.gsma.com/solutions-and-impact/technologies/internet-of-things/wp-content/
uploads/2019/07/201906-GSMA-NB-IoT-Deployment-Guide-v3.pdf
https://www.nxp.com/docs/en/application-note/AN2265.pdf
https://www.rapid7.com/globalassets/_pdfs/whitepaperguide/rapid7-leveraging-inter-chipcommunication-analysis.pdf
https://github.com/FICS/atcmd

37

About Rapid7
Rapid7 is creating a more secure digital future for all by helping organizations
strengthen their security programs in the face of accelerating digital transformation.
Our portfolio of best-in-class solutions empowers security professionals to manage
risk and eliminate threats across the entire threat landscape from apps to the cloud
to traditional infrastructure to the dark web. We foster open source communities
and cutting-edge research–using these insights to optimize our products and arm
the global security community with the latest in attacker methodology. Trusted bymore than 11,000 customers worldwide, our industry-leading solutions and services
help businesses stay ahead of attackers, ahead of the competition, and future-readyfor what’s next.
The information provided in this paper is intended for informational purposes only and Rapid7 makes nowarranties, express or implied, regarding the suitability of the content for any specific purpose. The content
within this paper is based on data and findings available up to the date of its publication.
The information contained herein is provided “as is,” and readers are advised to use their own discretion when
applying the information to their specific situations. Furthermore, any third-party sources, tools, or software
mentioned in this report are included for informational purposes only. Rapid7 does not take responsibility forthe accuracy, functionality, or security of these external resources.
Rapid7 is not liable for any damages, losses, or consequences that may arise from the use of the information
provided within. This includes but is not limited to direct, indirect, incidental, or consequential damages related
to actions taken based on the content of this paper.
Any reproduction, distribution, or unauthorized use of this paper’s contents without explicit permission fromthe authors and publishers is strictly prohibited.

CONTACT US

PRODUCTS
Cloud Security
XDR & SIEM
Threat Intelligence

Application Security

rapid7.com/contact

Orchestration & Automation
Managed Services

Vulnerability Risk Management
To learn more or start a free trial, visit: https://www.rapid7.com/try/insight/© RAPID7 2024 V6.038