KR102546946B1 - Method and System for Automatically Analyzing Bugs in Cellular Baseband Software using Comparative Analysis based on Cellular Specifications - Google Patents

Abstract

A method and system for automatically comparing and analyzing mobile communication baseband software based on mobile communication standard documents are presented. A method of automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to an embodiment of the present invention utilizes the characteristics of the baseband as a modem for network communication and uses the baseband The step of comparing and analyzing the software with the cellular standard, and the step of comparing and analyzing the message structure of the cellular standard, utilizes the standardized message structure of the cellular standard, and automatically converts the message structure implemented in the baseband software. can be inspected

Description

Method and System for Automatically Analyzing Bugs in Cellular Baseband Software using Comparative Analysis based on Cellular Specifications}

Embodiments of the present invention relate to a method and system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document, and more particularly, to a mobile communication standard for performing comparative analysis between baseband firmware and cellular specifications. It relates to a method and system for automatically comparing and analyzing mobile communication baseband software based on documents.

A baseband processor (BP) of a cellular device such as a smartphone plays an important role in a cellular network. Although users primarily interact with the interface of the user application running on the application processor, all application data is transmitted by the BP to use its air interface. The BP runs software, which is usually a real-time operating system for managing radio communications. Thus, it involves low-level digital signal processing and complex cellular protocol stacks. In order to provide users with seamless network services, the baseband software continuously communicates with the core network at layer 3 (L3) using numerous cellular control messages.

Baseband software is an enticing target because, if exploited, it can be used to monitor and modify transmitted data. Therefore, in the prior art, several approaches have been proposed to analyze the security of L3 protocols in particular. Implementations have traditionally used fuzzers to dynamically analyze specific protocols, such as SMS or cell broadcast messages, or manually inspected small pieces of baseband software ad-hoc to find security bugs.

This approach suffers primarily from three technical problems. Namely, the ambiguity of the baseband firmware, the limited applicability of manual analysis, and the difficulty of automation. First, the structure of the baseband firmware is unclear as vendors are reluctant to disclose details. Second, manual analysis is unavoidable to uncover these ambiguities, which requires a significant iterative effort to examine numerous features (i.e., 90K or more) across different baseband models or versions. Third, automation is necessary but not important either. The size of the baseband software is very large (i.e. tens of megabytes) and cellular protocols contain numerous complex states that cannot be statically analyzed or dynamically triggered by a fuzzer. Also, identifying a bug requires an explicit oracle, such as a program crash or noticeable unusual behavior, so it is limited to a few bug types. Therefore, existing approaches can analyze only two device models or versions within a single vendor.

N. Golde and D. Komaromy, "Breaking Band: reverse engineering and exploiting the shannon baseband," REcon, 2016.

Embodiments of the present invention describe a method and system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document, and more specifically, baseband firmware and cellular It provides technology to automatically perform comparative analysis of standards.

Embodiments of the present invention systematically examine the message structure implemented in the baseband software by utilizing the standardized message structure of the standard, compare and analyze the extracted message structure with the standard syntactically and semantically, and then report the discrepancy, It is to provide a method and system for automatically comparing and analyzing mobile communication baseband software based on mobile communication standard documents.

A method of automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to an embodiment of the present invention utilizes the characteristics of the baseband as a modem for network communication and uses the baseband The step of comparing and analyzing the software with the cellular standard, and the step of comparing and analyzing the message structure of the cellular standard, utilizes the standardized message structure of the cellular standard, and automatically converts the message structure implemented in the baseband software. can be inspected

The method may further include identifying discrepancies that do not conform to the cellular standard in a message structure of the baseband software through the comparative analysis.

The step of comparing and analyzing the baseband software with the cellular standard may include: analyzing the baseband software to identify a message decoder and extracting a message structure embedded in the baseband software; and comparing and analyzing the extracted message structure embedded in the baseband software with the cellular standard message structure.

In the comparing and analyzing the message structure of the cellular standard, whether or not the built-in protocol structure is syntactically identical to the cellular standard may be compared and analyzed.

In the step of comparing and analyzing the message structure of the cellular standard, whether or not the function of the message decoder complies with the cellular standard in which a basic logic semantically utilizes symbol execution may be compared and analyzed.

The method may further include analyzing the inconsistency to determine whether a functional or security bug may be created.

In the step of identifying mismatches, remaining information elements (IEs) not mapped to the message structure of the cellular standard in the message structure of the baseband software may be reported as missing mismatches or unknown mismatches.

The step of identifying inconsistencies may automatically identify inconsistencies in a plurality of layer 3 (L3) messages of the baseband software and mark possible buggy points for analysis.

A system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to another embodiment of the present invention compares baseband software with cellular standards by utilizing the characteristics of baseband as a modem for network communication. and a comparison and analysis unit that performs analysis, and the comparison and analysis unit can automatically check a message structure implemented in the baseband software by utilizing a standardized message structure of the cellular standard.

The method may further include a discrepancy identification unit that identifies discrepancies that do not comply with the cellular standard in the message structure of the baseband software through the comparative analysis.

The comparison and analysis unit analyzes the baseband software to identify a message decoder, extracts a message structure embedded in the baseband software, and converts the extracted message structure embedded in the baseband software to a message structure of the cellular standard. can be compared and analyzed.

The comparison and analysis unit may compare and analyze whether the built-in protocol structure is syntactically identical to the cellular standard.

The comparison and analysis unit may compare and analyze whether the function of the message decoder complies with the cellular standard in which a basic logic semantically utilizes symbol execution.

It may further include a bug generation confirmation unit that analyzes the inconsistency and determines whether a functional or security bug can be generated.

The mismatch identification unit may report remaining information elements (IEs) not mapped to the message structure of the cellular standard in the message structure of the baseband software as a missing mismatch or an unknown mismatch.

The inconsistency identification unit may automatically identify inconsistencies in a plurality of layer 3 (L3) messages of the baseband software, and mark possible bug points for analysis.

A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to another embodiment of the present invention has a message structure in baseband firmware having specifications and binary-specific metadata. Extracting; and syntactically comparing the message structure of the standard with the binary embedded message structure of the baseband firmware and semantically analyzing implementation logic using symbolic execution.

The method may further include identifying discrepancies between the message structure of the standard and the message structure of the baseband firmware through the comparison and analysis.

According to the embodiments of the present invention, a message structure implemented in baseband software is systematically inspected using a standardized message structure of the standard, the extracted message structure is syntactically and semantically compared with the standard, and discrepancies are reported after analysis. It is possible to provide a method and system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document.

1 is a diagram schematically illustrating a cellular network structure according to an embodiment of the present invention.
2 is a diagram illustrating the structure of an ATTACH REJECT message in an EMM procedure according to an embodiment of the present invention.
3 is a diagram illustrating manual firmware analysis and automated BASESPEC according to an embodiment of the present invention.
4 is a flowchart illustrating a method of automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention.
5 is a block diagram illustrating a system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention.
6 is a diagram showing a message structure according to an embodiment of the present invention.
7 is a diagram illustrating an example of syntax comparison according to an embodiment of the present invention.
8 is a diagram illustrating semantic analysis according to an embodiment of the present invention.
Figure 9 shows the relationship between the decoder mismatch and the effect of the processor function according to one embodiment of the present invention.

Hereinafter, embodiments will be described with reference to the accompanying drawings. However, the described embodiments may be modified in many different forms, and the scope of the present invention is not limited by the embodiments described below. In addition, several embodiments are provided to more completely explain the present invention to those skilled in the art. The shapes and sizes of elements in the drawings may be exaggerated for clarity.

Cellular baseband plays an important role in mobile communications. However, assessing security is quite difficult for a number of reasons. Manual analysis is unavoidable because baseband firmware is obscure and complex, but such analysis is an iterative effort to deal with different models or versions. Automating the analysis is also not critical, as the firmware is quite large and contains numerous functions related to complex cellular protocols. Thus, traditional approaches to baseband analysis are limited to two models or versions within a single vendor.

An embodiment of the present invention proposes a new approach called BASESPEC that performs comparative analysis of baseband software and cellular specifications. BASESPEC systematically checks the message structure implemented in baseband software by utilizing the standardized message structure of the specification. Determining how the message structure is embedded in the target firmware requires a manual, one-time analysis effort. BASESPEC then compares the extracted message structure syntactically and semantically with the specifications and finally reports any discrepancies. These inconsistencies indicate developer error, either violating the baseband's compliance or implying potential vulnerabilities.

According to the examples, evaluating BASESPEC with 18 baseband firmware images of 9 models from one of the top 3 vendors found hundreds of discrepancies. By analyzing these discrepancies, we found nine failure cases, including five functional errors and four memory-related vulnerabilities. In particular, two of these are significant remote code execution 0-days. In addition, according to embodiments, as a result of applying BASESPEC to three models from different vendors, BASESPEC found several inconsistencies, two of which caused buffer overflow bugs.

Embodiments of the present invention below propose a new system called BASESPEC that performs comparison analysis of baseband implementation and cellular standards by utilizing the characteristics of baseband as a modem for network communication.

BASESPEC's main intuition is that the baseband software's message decoder embeds a protocol specification into a machine-friendly structure for parsing incoming messages. This makes it easy to extract the built-in protocol structure and compare it to a reference to the specification. This allows BASESPEC to automate the entire comparison process and explicitly find inconsistencies in non-compliant protocol implementations. These inconsistencies can directly point to developer mistakes or hint at potential vulnerabilities when embedding protocol structures.

For comparative analysis, BASESPEC first analyzes the baseband firmware to identify the message decoder and extracts the protocol structure embedded in the firmware. Then, the two aspects of the extracted structure and specification are compared. 1) whether the embedded structure is syntactically identical to the specification and 2) whether the decoder function semantically conforms to the specification. Therefore, a comparative analysis between the actual implementation and the specification can clearly identify discrepancies. Then manually analyze these discrepancies to see if they can create functional or security bugs. BASESPEC requires an initial analysis of the target firmware to find the decoder capabilities and determine how the message structures are embedded in the firmware. While this may require a lot of manual work, this analysis is a one-time operation only. The knowledge gained from this analysis can be reused for other baseband models or versions. This is because the main decoding logic rarely changes across different baseband models or versions within a vendor. Meanwhile, an automated comparison procedure can be reused by other vendors after analyzing the firmware.

Using a prototype from BASESPEC, we analyzed standard L3 message implementations in 18 baseband firmware images from nine device models from one of the top three vendors. BASESPE has identified hundreds of inconsistencies that indicate both functional errors and potential weak points in the baseband implementation. According to the embodiments, their functional and security impact was investigated and found 9 error cases affecting 33 messages. Five of these cases are functional errors and four are memory related vulnerabilities. In particular, two vulnerabilities are critical Remote Code Execution (RCE) 0-days. To evaluate the applicability of BASESPEC, we applied BASESPEC to three models from the top three vendors. Through this analysis, BASESPEC identified several inconsistencies, two of which led to the discovery of buffer overflows.

In summary, the contributions of the present invention are as follows.

Embodiments of the present invention propose a new approach called BASESPEC to find bugs in cellular baseband software. Here, BASESPEC performs a comparative analysis of baseband software and embedded specifications of documented specifications.

Further, the examples demonstrate the practicality of BASESPEC. By running BASESPEC's automated prototype on 18 baseband firmware images from nine models from one of the top three vendors, it identified hundreds of non-conforming discrepancies.

In addition, according to the embodiments, mismatches were further analyzed to find 9 error cases, 5 of which were functional errors and 4 were vulnerabilities involving 2 RCE 0-days.

In addition, according to embodiments, applying BASESPEC to three firmware images from different vendors identified several inconsistencies, two of which caused buffer overflow bugs.

1 is a diagram schematically illustrating a cellular network structure according to an embodiment of the present invention.

Referring to FIG. 1 , a cellular network has three main components: a cellular device (Cellular Device, 120), a base station (Base Station, 110), and a core network (Core Network, 130). These components use different terms depending on the cell generation. For simplicity, we use generic terminology here. For example, NodeB, eNodeB, and gNodeB represent base stations 110 of 3G, 4G, and 5G, respectively.

Cellular device 120 refers to any device located at the edge of a cellular network and allowing a user to access cellular services. The most common device is a smartphone. Cellular device 120 typically has two separate processors for performance. An application processor (AP) in which a mobile operating system and user applications are executed, and a cellular baseband processor (BP) in which wireless/digital signal processing is performed.

Base station 110 provides a wireless connection to cellular device 120 . Messages are transmitted from the core network 130 to the cellular device 120 and vice versa over the air interface. Therefore, it is responsible for managing radio resources to provide users with better quality of service. The core network 130 provides key procedures such as mobility management and session management, including important user identification and security services such as encryption and integrity checking.

In addition, the cellular protocol stack 121 has several layers as an OSI model. The air interface of a cellular network is at layers 1 and 2 of the OSI model. Various key procedural messages are carried at Layer 3. To properly handle these layers, the baseband of cellular device 120 also implements cellular protocol stack 121 . In addition, newer 4G/5G cellular devices also support older 2G/3G cellular technologies to provide backward compatibility for cell coverage and roaming.

The cellular specifications and standard layer 3 messages are described below.

Cellular specifications are defined by an international working group called the 3rd Generation Partnership Project (3GPP), which unites seven telecommunication standards development organizations such as ETSI. There are over 100 specifications, most of which are hundreds of pages. Many mistakes have been observed in the prior art because of their sheer volume and complexity.

Among the various protocols and messages in the specification, standard layer 3 (L3) messages are used in complex core procedures such as mobility management, session management or even cryptographic operations to protect user privacy. Therefore, several vulnerabilities were discovered in the processing routine. Standard L3 messages are not only limited to a specific cellular generation, such as GSM or LTE, but also cover different protocols across generations. [Table 1] lists the L3 protocol, protocol discriminator (PD), and specification number. Each specification defines the detailed message format and direction of the corresponding protocol. The L3 message may be sent to the cellular device (ie downlink) or to the core network (ie uplink). In addition, L3 messages may have different formats depending on the direction in which they are transmitted. Hereinafter, each L3 protocol is represented using the abbreviations listed in [Table 1].

[Table 1]

Each standard L3 message has a specific format defined in the corresponding specification [Table 1]. A standard L3 message starts with a 2-byte header containing the PD and Message ID. The tuple of PD and message ID allows the receiver baseband to determine the format of the message designated for decoding the message. Each successive field of a message is called a standard information element (IE).

Standard IE has three parts: an IE identifier (IEI), a length indicator (LI), and a value (type (T), length (L), and value (V), respectively). This can be. The IE may be either imperative or non-imperative depending on the occurrence of the IEI. Command IEs do not have an IEI, whereas non-command IEs must have an IEI. In a message, command IEs must appear in a fixed order before non-command IEs, so they can be distinguished without IEIs. LI indicates the number of bytes of the value part, whereas the IE length of the specification indicates the number of bytes of all parts. There are seven IE formats: T, V, TV, LV, TLV, LV-E, and TLV-E. where T, L, and V represent the occurrence of IEI, LI, and values, respectively. The -E suffix expands a 1-byte LI to a 2-byte LI, and is between 0 and 65535 in length.

2 is a diagram illustrating the structure of an ATTACH REJECT message in an EMM procedure according to an embodiment of the present invention.

Referring to FIG. 2, an example message called ATTACH REJECT in an EMM procedure with raw packet data is shown. Each row of the message structure represents an IE. The header consists of a 4-bit PD (0x7), a 4-bit Security Header Type (0x0), and an 8-bit Message ID (0x44). In addition, the command IE includes non-header part IE, EMM cause. The packet then continues with the ESM message container and the value T3346, of which the IEIs are 0x78 and 0x5f, respectively. Since the format of the ESM message container IE is TLV-E, LI can represent a length from 0 to 65535. The length of T3346 value IE is fixed to 3 even if LI is applied.

The baseband processor is described below.

In a cellular device, the BP is a dedicated processor that manages all radio functions for cellular communication including digital signal processing. To meet the real-time requirements for wireless communication, it runs a real-time operating system as its firmware. Thus, its firmware works as a single executable file and is loaded into memory at runtime. Therefore, baseband firmware is referred to herein as the baseband binary.

Baseband software is usually proprietary and manufacturers do not publicly share details such as source code. For example, Qualcomm's Snapdragon, MediaTe's Helio and Samsung's Exynos are the big three system-on-a-chip products that include BP. However, none of these manufacturers are sharing detailed information. Therefore, researchers often perform reverse engineering to analyze and identify security issues in baseband software. Also, each baseband may have a different structure depending on design choices. Therefore, baseband analysis requires appropriate tools to support the target baseband structure.

In baseband, L3 messages are first classified by PD and message ID. The baseband then parses and decodes the message to obtain the IE's information using a predefined message structure. After decoding the message, appropriate actions are performed for each decoded IE, and finally, the message is processed as defined in the specification. Hereafter, functions related to the decoding procedure are referred to as L3 message decoders, and functions for message processing are referred to as IE and message handler.

There are mainly three technical challenges that hamper conventional approaches to finding bugs in baseband firmware.

First, the ambiguity of the baseband firmware. Cellular baseband firmware is largely unknown as vendors do not disclose details to protect their proprietary implementations. This ambiguity severely hinders firmware analysis, which requires significant manual effort. To reduce manual effort, memory dumps have already taken care of the initialization phase and often contain runtime information. However, getting these features requires a real device and special features (eg a hidden dump menu only available on older Android devices) or vulnerabilities to trigger them. You could consider using a hardware debug interface like JTAG, but it's not available on newer devices. Also, memory dumps cannot be analyzed by state-of-the-art binary analysis tools such as IDA Pro. For example, function identification, which is fundamental to static analysis, often fails due to ambiguities in the firmware.

Second, the applicability of manual analysis is limited. To uncover ambiguities in the baseband firmware, the researchers focused on manual analysis. However, since it is almost impossible to manually investigate numerous functions of hundreds of L3 messages, this method has fundamental limitations in scalability and applicability. Therefore, even similar types of vulnerabilities often remain undiscovered. Also, as mobile devices evolve rapidly in software and hardware, firmware binaries have significant differences from each other. Therefore, checking the firmware of different device models or versions, even within a single vendor, remains a challenge and requires additional serious manual work.

Third, the difficulty of automatic analysis. To achieve scalability and applicability, automating baseband analysis is imperative. Automated analysis can be broadly divided into static analysis and dynamic analysis, but both methods have some challenges. For static analysis, the baseband firmware is very large (i.e. tens of MB) and contains numerous trivial features to analyze, such as cryptographic operations. Moreover, making analysis rules is difficult because the cellular specifications are very complex with over 100 documents. Thus, existing studies rely heavily on dynamic analysis (eg, fuzzing) using real or emulated hardware. Unfortunately, many vulnerabilities in baseband are difficult to trigger dynamically because of their complex state. Additionally, this approach relies on explicit oracles, such as program crashes, to identify bugs, limiting bugs to a few bug types.

In order to solve this problem, embodiments of the present invention propose a new approach called BASESPEC that performs comparative analysis of baseband firmware and cellular specifications. BASESPEC exploits the natural properties of message decoders in network communication. The main intuition of the present invention is that 1) message decoders of network communication should have specifications built into their implementations to be able to identify and parse message fields. 2) Since such built-in message structures exist in machine-friendly form, embodiments can certainly extract them. 3) Comparative analysis on the extracted structures can identify misplaced structures with respect to specifications. 4) The message structure can similarly be extracted from various device models/transformations, since the main logic of the decoding routine hardly changes. Hereafter, the built-in specifications and message structure of the baseband firmware are called binary embedded specifications/messages.

3 is a diagram illustrating manual firmware analysis and automated BASESPEC according to an embodiment of the present invention.

Referring to FIG. 3 , the approach of the embodiments is largely divided into two parts: manual firmware analysis 310 and fully automated BASESPEC 320 .

Passive firmware analysis 310 primarily searches for the location of message decoders and how specifications are built into the baseband firmware called binary-specific metadata. Since the main logic of the decoding procedure rarely changes across different device models or versions within the same vendor, this procedure is manual but a one-time task.

The fully automated BASESPEC 320 then utilizes these results for syntactic/semantic comparisons. In particular, the fully automated BASESPEC 320 automates the extraction of decoder function addresses and embedded message structures from target baseband binaries. Syntax comparison literally verifies whether the binary embedded specification matches the specification of the manual. On the other hand, semantic comparison examines whether the underlying logic of the decoder function correctly complies with the specification utilizing symbolic execution. Finally, it reports discrepancies that indicate developer error, which may violate compliance or hint at a potentially weak spot for later analysis. Therefore, only the messages affected by the reported discrepancy need be analyzed.

Embodiments address the aforementioned challenges as follows. First, manually analyze the firmware, especially the L3 message decoder, to identify ambiguities in the firmware. This analysis can be reused for other baseband firmware. That is, it is a one-time operation. Second, the fully automated BASESPEC 320 automatically identifies inconsistencies in numerous L3 messages and exposes potential buggy spots for analysis, thus enabling efficient and pragmatic analysis. In fact, by analyzing the discrepancies reported by the fully automated BASESPEC (320), we found 9 error cases, 5 of which were functional errors and 4 were vulnerabilities including 2 RCE 0-days. Finally, the fully automated BASESPEC 320 is adaptable to a variety of device models or versions with automation, as the main decoding logic hardly changes. It can be applied to firmware from other vendors, even if it requires a one-time manual effort to analyze the decoder.

Choose from a variety of protocols in cellular networks to target standard L3 messages. These messages cover a variety of protocols and play an important role in cellular core procedures. Since the L3 protocol has numerous complex logic and data structures, several vulnerabilities have been discovered. Therefore, we focus on the standard L3 message analysis listed in [Table 1]. Not all messages in the L3 protocol are represented as standard L3 messages. These other messages are outside the scope of this invention.

In the case of cellular baseband, according to embodiments, the focus is primarily on one of the top three mobile processor vendors (ie, vendor 1). Analyze baseband firmware on several modern device models with architecture ARM.1. However, the approach according to the embodiments can be applied to other baseband firmware, but considerable manual effort may be required to uncover firmware ambiguities. In addition, we successfully applied BASESPEC by analyzing the firmware of one of the top three vendors (i.e., Vendor 2).

4 is a flowchart illustrating a method of automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention.

Referring to FIG. 4 , a method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to an embodiment of the present invention is based on comparing baseband characteristics for network communication. It includes the step of comparing and analyzing the baseband software with the cellular standard by using it as a modem (S110), and the step of comparing and analyzing with the cellular standard message structure is implemented in the baseband software using the standardized message structure of the cellular standard. The message structure can be checked automatically.

In addition, according to an embodiment, a step of identifying a mismatch that does not comply with the cellular standard in the message structure of the baseband software through comparative analysis (S120) may be further included.

In addition, according to the embodiment, a step of analyzing the inconsistency to determine whether a functional or security bug can be generated (S130) may be further included.

A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention takes a system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document as an example. Can you please explain in more detail.

5 is a block diagram illustrating a system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention.

Referring to FIG. 5 , a system 500 for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention may include a comparison and analysis unit 510 . According to an embodiment, the system 500 for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document may further include a mismatch identification unit 520 and a bug generation confirmation unit 530 .

In step S110, the comparison and analysis unit 510 may compare and analyze the baseband software with the cellular standard by utilizing the characteristics of the baseband as a modem for network communication. At this time, the comparison and analysis unit 510 may automatically check the message structure implemented in the baseband software by utilizing the standardized message structure of the cellular standard.

More specifically, the comparison and analysis unit 510 analyzes the baseband software to identify a message decoder, extracts a message structure embedded in the baseband software, and converts the message structure embedded in the extracted baseband software into a cellular standard message. structure and comparative analysis.

The comparison and analysis unit 510 may compare and analyze the baseband software with the cellular standard syntactically and semantically. The comparison and analysis unit 510 may compare and analyze whether the built-in protocol structure is syntactically identical to the cellular standard. In addition, the comparison and analysis unit 510 may compare and analyze whether the function of the message decoder complies with the cellular standard in which the basic logic semantically utilizes symbol execution.

In step S120, the mismatch identification unit 520 may identify a mismatch that does not conform to the cellular standard in the message structure of the baseband software through comparative analysis. More specifically, the mismatch identification unit 520 may report remaining information elements (IEs) that are not mapped from the message structure of the baseband software to the message structure of the cellular standard as a missing mismatch or an unknown mismatch.

At this time, the inconsistency identification unit 520 may automatically identify inconsistencies in layer 3 (L3) messages of a plurality of baseband software and display possible bug points for analysis.

In step S130, the bug creation check unit 530 analyzes the inconsistency to determine whether a functional or security bug can be created.

A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to another embodiment of the present invention includes a message structure in baseband firmware having specifications and binary-specific metadata. It may include extracting and syntactically comparing the message structure of the specification with the binary embedded message structure of the baseband firmware and semantically analyzing the implementation logic using symbolic execution.

Further, the method may further include identifying discrepancies between the message structure of the standard and the message structure of the baseband firmware through comparison and analysis.

A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device according to another embodiment of the present invention is a mobile communication standard performed by a computer device according to an embodiment described above. A method for automatically comparing and analyzing mobile communication baseband software based on documents and a detailed description thereof will be omitted because the configuration is redundant. For example, specifications may include cellular specifications, and baseband firmware may be included in base software.

Below, a method and system for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document according to an embodiment of the present invention will be described in more detail.

Manual discovery of firmware ambiguity

Here, we detail an approach for identifying ambiguity in baseband firmware. It describes how to handle some problems, find L3 decoding functions, and determine how message structures are embedded in a state-of-the-art static analysis tool called IDA Pro. Due to the ambiguity and complexity of baseband firmware, manual analysis is mandated. However, the analysis procedure is a one-time operation, the results of which can be reused for multiple messages, models or versions within the same vendor. Here, we mainly share the firmware analysis experience of vendor 1. However, a similar approach can be applied to firmware from other vendors, although significant effort may be required to determine the L3 message decoding logic.

First, obtain the firmware.

According to the embodiments, baseband firmware was selected as the target of analysis because of its applicability and accessibility, without requiring a physical device. There are mainly two ways to obtain baseband firmware: memory dump and firmware image. Previous studies (Non-Patent Document 1) relied on memory dumps because firmware initialization includes runtime memory states, memory layouts, and global variables that do not require complex analysis. However, this method requires a real device to dump memory, so scalability and applicability are greatly reduced. Furthermore, according to embodiments, it was found that the hidden menu for triggering a memory dump or hardware debug interface such as JTAG has been disabled on recent devices.

So, I decided to use a third-party website that maintains firmware images for updates. You can also download the latest firmware image from the vendor's cloud storage. However, third-party repositories provide well-organized lists of firmware images by product model and version. Among them, the images of the latest flagship models listed in [Table 2] were selected. For initial firmware analysis, only one image needs to be analyzed to resolve the ambiguity. The knowledge can then be applied to other images within the same vendor. Therefore, it was decided to analyze the latest version of the latest model (i.e. model A in [Table 2]).

[Table 2]

And, it includes pre-processing.

Embodiments analyze baseband firmware using IDA Pro, a state-of-the-art binary analysis tool. IDA Pro is a promising tool, but requires additional pre-processing steps for 1) memory layout analysis and 2) function identification. IDA Pro correctly identifies only a few hundred of the 90K features due to multiple run-time mechanisms in the baseband firmware. Such limits are already known to be difficult. IDA's automatic analysis can only detect 450 functions starting from the interrupt handler, a common entry point for embedded devices, without preprocessing (see Table 2). Therefore, we design two preprocessing steps as follows.

First, memory layout analysis can be performed. For analysis, the baseband firmware must be loaded into the appropriate memory layout. Otherwise, data or function pointers in the firmware will point to incorrect memory addresses, which will significantly hinder further analysis. In fact, when I opened the firmware using IDA, the data/function pointers in most functions attempted to access data or call other functions at invalid memory addresses.

Embodiments have found that this bad pointer problem is caused by scatter-loading, and IDA does not support it. Scatter-loading is ARM's loading mechanism that reallocates an initially loaded file into several memory regions at run time. This technology is widely used in ARM-based embedded systems because it supports compression of the data area to reduce firmware size. When building firmware, a component of the ARM compiler named armlink inserts a scatter-loading function to initialize the firmware at runtime. These functions copy, decompress, or zero-initialize memory regions according to a predefined table to set the memory layout correctly. So, if scatter-loading is not taken care of, the entire binary file will be loaded into a single contiguous memory area, making the data/function pointers invalid.

It handles the scatter-loading problem and emulates the scatter-loading process to create the proper memory layout. In particular, the embodiments emulate the operation of a scatter-loading function. That is, the memory area is copied, decompressed, and initialized to 0. These scatter-loading functions are predefined in a highly optimized form of armlink, so most modern ARM embedded devices reuse these functions. Therefore, signatures similar to IDA's FITH can be used to detect these features. After detecting the scatter-loading functions, embodiments analyze their cross-references and identify a predefined scatter-loading table. This table contains information indicating the execution order and parameters of the scatter-loading function. Emulates the scatter-loading process specified in the table.

Second, functional identification can be done. An object according to the embodiments (ie, vendor 1's firmware) is based on an ARM structure. In order to identify the functions of the firmware, the bytecode must be disassembled beforehand. However, disassembling an unknown byte in ARM is error-prone because the ARM architecture supports two instruction sets: ARM and Thumb. The ARM instruction set is the default mode for executing 32-bit instructions, and the Thumb instruction set supports small 16-bit instructions to reduce code size. Direct decomposition can lead to a lot of bad decomposition code, because the same bytes can be decomposed into two different instructions.

To solve this challenge, we designed two simple techniques: i) frequent function prologues and ii) taking advantage of the properties of function pointers in Thumb mode. First, a function prologue signature that can distinguish between ARM mode and Thumb mode is prepared by examining the confirmed function. These prolog signatures consist of PUSH instructions in both ARM and Thumb modes. It then searches for that signature, and if a matching signature is found, it tries to parse it in matching signature mode. To reduce false positives in signature-based matching, we check whether the prolog function handles registers normally. For example, most functions push LR registers onto the stack but don't push PC registers, so discard prologs that push PC registers or prologs that don't push LR registers.

After detecting the function prologue, the function pointers in the data section are analyzed to further identify the function. To this end, the characteristics of Thumb mode are utilized. Function pointers for Thumb mode functions use odd addresses. In particular, the least bit of a pointer value is always 1. Most data is aligned to even addresses, so odd addresses pointing to sections of code can be Thumb mode function pointers. Therefore, embodiments can find functions that are called indirectly through such pointers.

This preprocessing technique greatly improves the function identification performance of IDA. The initial number of features identified by IDA Pro was 450 for Model A, as shown in Table 2. Memory layout analysis and function identification consisting of prolog detection and pointer analysis were applied to the same firmware. The memory layout analysis according to the embodiments found 504 new functions, and the function identification techniques, that is, function prologue detection and function pointer analysis according to the embodiments, discovered 31,955 and 2,526 new functions, respectively. If you give IDA Pro a newly identified function, it will recursively find more functions by further analyzing each function's code reference. As a result, the pre-processing step according to the embodiments helped IDA Pro eventually identify 91,481 features. The pre-processing is only a one-time operation and can be applied to the firmware of different device models without any other manual work. In fact, other state-of-the-art models listed in Table 2 can be successfully preprocessed. The average time taken for the entire preprocessing including the automatic analysis of IDA was 2,557 seconds. In some cases, IDA found more functions before preprocessing (for model B), or required more time for automatic analysis (for model A). Examples investigate these outliers.

Also identifies a layer 3 decoder.

To examine standard L3 messages, we first need to find the decoding logic through binary analysis. A function that implements this decoding logic as a decoder function is called a decoder function. Here, we focus on the decoder function because it has machine-friendly information about the L3 message structure. As described above, the L3 protocol message has a standardized structure. To parse messages correctly, developers embed the message structure of the specification into a machine-friendly format. Thus, you can systematically analyze the embedded structure and understand how the firmware decodes L3 messages.

It utilizes debug information (eg logging messages) left by the developer in the baseband binary to identify the decoder. This debug information is different from information inserted by the compiler with the -g option, which disappears when the binary is removed, and is described in more detail below. Since debug information is generally used to find a specific function in a corrupted binary when analyzing an embedded device (Non-Patent Document 1), this approach is selected from various methods of binary analysis. Finding the L3 decoder without this information is quite difficult, as the baseband firmware is corrupt and is very large (more than 30MB) with a lot of features over 90K. Therefore, the embodiments use the debug message and share the details below as an example for further study. Similarly, I found an L3 decoder function using debug information from another vendor's firmware, although the structure of the debug information is different. On the other hand, the final goal according to the embodiments of performing comparative analysis on a standard L3 message does not depend on how the decoder function is identified. Other techniques can also be used for this process.

First, it retrieves all the debug information from the baseband binary, and then analyzes functions that only reference that debug information. While retrieving debug information, the firmware uses a specific structure to log debug messages and information. A structure starting with the magic value DBT contains the debug message along with the file path and line number being referenced. Therefore, we first retrieve all the debug information using DBT. Since a large number of functions indirectly reference debug information (about 100,000), embodiments perform lightweight inverse slice analysis to accurately match functions with debug information. Next, the embodiments classify each function based on the file path of the debug information, since functions in the same layer or library can share the path. After classification, L3 functions are found using path and debug messages containing keywords such as L3, SS, EMM or NAS. It then uses keywords such as decode, codec, and names of different IEs to find features related to decoding incoming messages. Consequently, we have identified a function that parses a standard L3 message according to embodiments. Embodiments have found that a single decoder function decodes all standard L3 messages regardless of protocol. This is because these messages have the same standard structure. Therefore, even one decoder can be sufficiently processed.

And, get the binary embedded message structure.

6 is a diagram showing a message structure according to an embodiment of the present invention.

Finally, it determines how the standard L3 message structure is embedded into the baseband binary. To do this, we analyze decoder functions and data references. A simplified structure of the embedded message structure 620 is shown in FIG. 6, and the EMM, ATTACH REJECT message structure of the specification message structure 610 can be taken as an example. The embedded message structure 620 is hierarchically encoded with four types of lists.

First, the protocol list (Protocol List, 621) is the topmost list of the hierarchy. It holds a pointer to each L3 protocol's message list (Msg List, 622) and is indexed by the PD. Since the PD of the EMM protocol is 7, the 7th item in the protocol list is accessed.

Second, a Msg list 622 is defined for each protocol. It holds a pointer to the Msg IE list 623 of each message of the protocol, indexed by message ID value. In this example, the message ID of the EMM, ATTACH REJECT message is 0x44, so the corresponding Msg IE list 623 is accessed using 0x44.

Third, a Msg IE list 623 is defined for each message. The message contains the command flag and index for each IE in the message. The command flag indicates whether the IE is encoded as a command or non-command in the message and the index indicates the IE's position in the global IE list 624. As in the example, the first three IEs (PD, Security Header Type, and Message Type) of the EMM, ATTACH REJECT message are common IEs for all messages, so they are not listed in the Msg IE list.

Fourth, the global IE list 624 includes information on all IEs used in the L3 protocol and is accessed through an index assigned to each IE. This information consists of the length of the IE and the IEI. Here, the length represents only the size of the value part, but the length of the specification represents the entire size of the IE.

Iterate through this list to extract all embedded message structures (620). Through firmware analysis, we can see how to obtain L3 decoder address and message structure information in firmware. Use this knowledge to automate BASESPEC as described below.

BASESPEC DESIGN

Here, the design of BASESPEC is explained in detail. Figure 3 described above shows an overview of BASESPEC. BASESPEC automatically reports discrepancies by comparing the message structure of the baseband firmware with the message structure of the specification. To do this, BASESPEC first extracts the message structure from firmware with specifications and binary-specific metadata. Then, the structure of the specification is syntactically compared to the binary embedded structure, and the implementation logic is semantically reviewed using symbolic execution. Based on these comparisons, BASESPEC reports various types of discrepancies between specifications and MPs. BASESPEC reports suspicious IEs that exist only in binaries (i.e. unknown mismatches) or specifications (i.e. missing mismatches). It also reports IEs of different lengths (i.e., invalid mismatches). After obtaining discrepant results, the examples can be further analyzed for their implications.

First, the message structure is extracted from the specification.

To examine the L3 message structure of the baseband firmware, BASESPEC extracts a reference structure from the specification. 3GPP and its partners provide specification documents on their websites. BASESPEC downloads the latest specifications listed in Table 1 and converts them to raw text format. Then, the message structure is extracted from the transformed raw text using regular expressions. As shown in FIG. 6, the message structure of the specification includes two parts: message content, which is a list in IE format, and message type list for each L3 protocol. BASESPEC automatically parses these structures for each standard L3 message.

Although this text processing may seem trivial, BASESPEC should address several problem situations listed below.

First, conversion errors must be resolved. Converting the specification to raw text format introduces several types of errors. The specification is written in a human-friendly format such as Microsoft Word (eg DOC) or Adobe (eg PDF) format. Visual richness (eg, tables and diagrams) helps readers understand these documents more fully. However, BASESPEC needs to convert documents into a machine-understandable format for systematic analysis. Error-prone methods such as OCR are needed to convert these human-friendly documents into raw text format. Therefore, these conversions often result in several errors including incorrect or missing words/sentences.

To mitigate these conversion errors, BASESPEC uses different document formats together. 3GPP and ETSI provide the same specifications in two formats: 3GPP's DOC file and ETSI's PDF file. We found that the conversion errors of each format are deterministic and complementary. For example, when processing the specifications of EMM and ESM messages (Table 1), the conversion of the tables for message types in DOC files failed, but conversion to PDF files was successful. In contrast, converting tables for message content showed the opposite case. Therefore, BASESPEC checks the number of rows in the converted table to select the correct raw text among the different conversion results. Tables with more rows are more likely to have correct text. Surprisingly, this approach produced no errors. For conversion, BASESPEC uses antiword and pdftotext for DOC and PDF files, respectively.

Second, word mismatches must be resolved. BASESPEC has to deal with many inconsistent words in the specification for text processing. Since specifications are written manually by many people, such contradictions are unavoidable, making it difficult to systematically analyze specifications. These discrepancies included 5 duplicated and/or missing words, 14 incorrect spaces between words, 5 uses of abbreviations, 14 incorrect delimiters, and several other terms with a single meaning. For example, the RR message SYSTEM INFORMATION TYPE 15 is sometimes written as SYSTEM INFORMATION 15. In addition, there are four different names for downlink (DL) message indications transmitted to cellular devices: UE, base station, MS, and DL. Also, the DTM ASSIGNMENT COMMAND message has a missing delimiter '-' in one IE format length. Some table names have duplicate words, such as service request message content. Embodiments resolved all these discrepancies and successfully retrieved message information for comparison. We have reported the problem to 3GPP so that it can be corrected for future research applying text processing in this area.

Third, the irregular IE format needs to be addressed. While extracting the message structure from the specification, I found several nested IEs and invalid IE formats. For example, some SMS messages may have overlapping messages, so you should check IE for overlapping messages. I flattened the nested IE to properly compare the message structure. Also, the TLV format is invalid because there is no IEI in the CN-MS transparent information IE of the INTER SYSTEM TO UTRAN HANDOVER COMMAND message. IEs with TLV format must contain IEIs. However, this was an exceptional case defined in the standard. An exception is made here to handle the above cases when comparing results.

Next, metadata for each binary is extracted.

For further analysis, BASESPEC extracts binary-specific metadata such as binary embedded message structure information for syntax comparison and L3 decoder address for semantic comparison. This is differentiated across different baseband binaries. However, BASESPEC can extract this information regardless of the baseband binary and can be applied to multiple baseband models or versions.

Given a firmware image, BASESPEC performs all firmware analysis procedures and extracts binary-specific metadata. For firmware pre-processing automation, BASESPEC retrieves pre-written signatures of functions related to scatter-loading, similar to IDA Pro's SCIT. Then, it emulates copy, decompress, and zero-initialization functions. BASESPEC then scans the loaded firmware to detect function prologues and pointers to Thumb mode functions. For automating L3 decoder identification, implement forward and backward slicers to correctly identify L3-related debug structures. The L3 decoder can then be identified by cross-referencing the debug structure. Finally, BASESPEC looks up the address of the message structure in the decoder when the function references the structure while decoding the L3 message. The message structure is used for syntactic comparison and the information about the decoder is used for semantic comparison.

Then, the syntax of the message structure is compared.

BASESPEC first syntactically compares the message structure extracted from the baseband binary at the granularity of the IE level with the message structure extracted from the specification. For each message in the specification, BASESPEC fetches that message from the binary using the PD and message type. Next, BASESPEC recursively maps the IE of messages in the specification from binary according to type (i.e., command or non-command). Finally, BASESPEC compares the mapped IEs and reports mismatches, which we call syntactic mismatches. This syntactical inconsistency can directly identify a developer's mistake in embedding the message structure in the baseband binary. The syntax comparison procedure is explained in detail as follows.

7 is a diagram illustrating an example of syntax comparison according to an embodiment of the present invention.

1) Retrieving message: For each message in the specification, BASESPEC first fetches the corresponding message structure from the baseband binary using the PD and message ID. As shown in FIG. 7, BASESPEC uses PD (0x7, 710) and message ID (0x44, 720) as indexes of the protocol list and Msg list, respectively, to bring the Msg IE list corresponding to the EMM ATTACH REJECT message.

2) IE mapping: Next, BASESPEC maps each IE from the Msg IE list to the IE of the specification. BASESPEC is a command IE that does this mapping according to the IE type, and non-command IEs have their own format. In the case of the command IE, BASESPEC has a fixed order in the message and therefore is order dependent. For example, in FIG. 7 BASESPEC concludes that the first entry in the Msg IE list represents the EM cause IE, which is the first IE for which the command flag is set. The Msg IE list contains only the IE after the message ID because the message's header IE (i.e. PD and Message ID) is already used to get the Msg IE list. For non-command IEs that can appear in any order, BASESPEC uses the identifier IEI. For example, BASESPEC regards the second item of the Msg IE list in FIG. 7 as an ESM message container IE. This is because the IEI (0x78) matches the IE in the specification.

After the mapping process, BASESPEC reports the remaining unmapped IEs as missing or unknown mismatches. A missing inconsistency indicates an IE that exists in the specification but is not implemented as a binary. On the other hand, an unknown mismatch indicates IE present in binary. For example, BASESPEC cannot map the value of T3346 in FIG. 7 because IEI (0x5F) does not exist in the Msg IE list. BASESPEC therefore reports this as a missing discrepancy. Similarly, since IEI (0xff) has no corresponding IE in the specification, BASESPEC reports the third IE in the Msg IE list as an unknown mismatch.

3) Compare IEs: BASESPEC compares pairs of IEs in the mapping and reports discrepant results. BASESPEC must first convert the IE of the specification into a similar format for binary. In particular, BASESPEC adjusts the IE length of the standard because the binary and standard lengths are different. Length in binary only considers the value part of the IE (ie the length of the value), whereas length in the specification also includes the IEI and LI (ie the length of the IE). BASESPEC subtracts the size of IEI and LI according to the format of the standard). For example, as shown in Figure 7, BASESPEC uses the ESM message to calculate its value length because its format contains a 1-byte IEI (T) and a 2-byte extended LI (L with -E). Subtract 3 bytes from the IE length of the container IE. Similarly, BASESPEC subtracts 2 bytes to the length of the T3346 value IE, where IEI(T) has 1 byte LI(L). BASESPEC does not adjust the IE length of the EMM cause IE because it only has a value (V).

BASESPEC then compares the adjusted IE. If the lengths differ, BASESPEC reports this as an invalid mismatch. For example, in FIG. 7 , BASESPEC does not report a mismatch because the value length of the EMM cause IE is the same in both standard and binary. On the other hand, the minimum value length of the ESM message container IE in the specification (3 bytes) is different from the length of the binary (0 bytes), so BASESPEC marks it as a false mismatch.

It also compares message structures semantically.

Besides syntactic analysis, BASESPEC also performs semantic analysis. Although syntax analysis can identify obvious inconsistencies in message structure, the actual decoding logic for a given message in baseband binary may differ from the syntax format. To this end, semantic analysis focuses on how incoming messages are parsed in the decoder function. BASESPEC exposes semantic flaws in decoder functionality by finding discrepancies in message handling between implementations and specifications. We call this discrepancy a semantic discrepancy. Such semantic inconsistency may mean an unintended operation of a baseband that is different from the standard.

For semantic analysis, BASESPEC symbolically executes the decoder function that provides the address. BASESPEC then converts the constraints obtained in symbolic execution into IEIs and LIs using their own roles. IEI distinguishes non-command IE, while LI specifies the size of the value part. Next, BASESPEC builds a message structure based on the identified IEI and LI, compares it with the structure of a similar standard for syntax comparison, and finally reports a discrepancy.

8 is a diagram illustrating semantic analysis according to an embodiment of the present invention.

Referring to FIG. 8, an overall procedure of L3 decoder semantic analysis 810 using a sample EMM ATTACH REJECT message is shown.

1) Symbolic Execution: BASESPEC analyzes decoder functions instead of full baseband binaries according to the concept of unconstrained symbolic execution. Unconstrained symbolic execution directly analyzes individual functions without executing the full binary for extensibility. Therefore, BASESPEC performs symbolic execution from the entry of the decoder function until it returns. For efficient analysis, BASESPEC processes one L3 message at a time by integrating PD and message type. The message body, i.e. the IE, is not restricted to consider possible IEs. For example, the message of FIG. 8 has specific values for PD (0x7) and message type (0x44). This represents an EMM ATTACH REJECT message. However, the message body consists of unrestricted symbolic variables (v1-v4).

Symbolic execution creates symbolic variables and constraints. These variables include the decoding semantics of IEI and LI. Each symbolic variable represents one of the IE fields (i.e., IEI, LI, or value), and each constraint dictates how the decoder processes the field. Conditional branches associated with symbolic variables in the decoder create constraints on these variables. These constraints can be made by verifying the IEI in the case of non-command IE or by validating the LI based on the embedded message structure. For example, the program state of Figure 8 includes different constraints of symbolic variables depending on the path followed. An S1 state containing the constraint of v2==0x5F could have followed the path of decoding an IE with 0x5F as the IEI value.

2) IEI and LI identification: When the symbolic state reaches the end of the decoder function, BASESPEC identifies the IEI and LI from the collected symbolic variables and constraints. First, BASESPEC uses the purpose of memory addressing to identify LIs. As LI specifies the size of the value part, the decoder function uses LI in address calculation to access the next IE. For example, assume that v3 in FIG. 8 is an LI located at address A. Then, v4 and the bytes following it are the value part of length v3. Therefore, when the decoder function wants to access the next IE, it will use A+v3+1 as the address of the IE. Thus, symbolic variables for LI can be identified by checking whether they are used in addresses. Also, a 2-byte LI with the -E suffix format can be similarly identified. The last IE's LI cannot be identified in this way, but here we can assume the last unresolved symbol variable to be the LI after the other parts have been identified.

Next, the IEI of the non-command IEI must be compared with the predefined IEI value in the decoding routine, so it can be identified in a simple way. Therefore, if a symbolic variable is not LI, it is identified as IEI, and there are constraints that strictly limit its value. As shown in FIG. 8, some constraints strictly limit the value of v2 to possible values of IEI such as 0x5F, 0x78, or 0x16. So v2 is the IEI part. The value part of the IE is implicitly identified because it is not constrained in the decoding routine. If the decoder function does not read the actual value and only stores the address of the value part as output, then the symbolic variable cannot be accessed. If values are accessed and copied to other memory areas, these operations can be identified and value parts determined during symbol execution.

3) Handling on path growth: During symbolic execution, BASESPEC performs state pruning to prevent path growth, which is a well-known problem of symbolic execution-based approaches. In particular, BASESPEC removes the path to the error handling logic. When the decoder function detects an obvious error in the message, it invokes complex error-handling logic. This error handling logic has nothing to do with legitimate message decoding, but causes path growth. Therefore, this route can be discarded and route growth can be prevented. These paths can be distinguished by the flag variable because the decoder function sets the flag variable to indicate an error. Therefore, BASESPEC prunes the path with the flag variable set.

It also limits the number of non-command IEs analyzed in each state to prevent path growth. Non-command IEs can appear in any order in a message. Thus, numerous combinations emerge in symbolic execution, which in turn creates numerous states with complex constraints. To prevent state growth, BASESPEC analyzes each non-command IE separately in an independent state, since most non-command IEs are optional and unrelated to each other. Specifically, BASESPEC periodically identifies the IEI in each active state and removes the state if it has constraints on multiple non-command IEs. All commands IE are analyzed in each state as they must be displayed in the message.

4) IE comparison: For comparison, BASESPEC constructs a semantic recognition message structure based on the identified IEI and LI value of the message. Each state of symbolic execution contains information about all instruction IEs and some non-command IEs. BASESPEC first builds a list of possible IEs by gathering information from various states. A pair of IEI and LI constitutes a non-command IE, and a LI without an IEI constitutes a command IE. BASESPEC analyzes the semantics of the IEI and LI parts, and does not identify command IEs without LIs because such IEs only have value parts. For example, in Fig. 8, state S1 constitutes a non-command IE with v2 as IEI (0x5F) and v3 as LI. The S2 state consists of a non-command IE where v2 is an IEI (0x78) and v3:v4 is an extended LI. The ATTACH REJECT message also has a command IE with v1 in all states, but it is not identified because there is no LI and only a value part. Then, BASESPEC organizes the message structure into the table on the right of Figure 8. It embodies LI to show an explicit range of lengths. The message structure is semantically recognizable because it reflects the internal logic of the decoder.

Finally, BASESPEC compares the message structure to the specification, similar to syntactic comparison. Because command IEs must appear in a fixed order, BASESPEC compares their LIs sequentially, skipping command IEs without LIs. For non-command IEs, BASESPEC first matches them using the IEI and then compares their LIs. BASESPEC reports inconsistent differences or remaining IEs as semantic mismatches.

An implementation analysis is described below.

BASESPEC automatically detects discrepancies between specifications and binary implementations, but requires additional manual analysis to understand the impact of discrepancies. Given a message, the decoder function parses the message and passes the message's IE to the corresponding handler function for further processing. BASESPEC utilizes the systematic structure of the message to automatically analyze the decoding routine. However, handler functions have complex semantics (eg, session management or call control), making it difficult to automatically verify correctness. Thus, embodiments rely on manual analysis to analyze it. Nevertheless, it is worth noting that discrepancies reported by BASESPEC may provide hints to this analysis. Embodiments have to analyze only the routines corresponding to the inconsistent IE, not the entire function with complex logic.

Figure 9 shows the relationship between the decoder mismatch and the effect of the processor function according to one embodiment of the present invention.

Referring to Fig. 9, the relationship between decoder 910 inconsistencies and processor 920 functionalities is shown, in particular, missed mismatches and unknown mismatches directly indicate functional errors in the baseband firmware. Like 911, missed mismatches result in a decrease in positive IE. If a command IE (i.e., a required field) is dropped due to a mismatch, it indicates that the firmware is not compliant (i.e., a functional error). Also, unknown mismatches are closely coupled to missed mismatches. If a developer accidentally inserts an incorrect IEI value, unknown mismatches and missing mismatches appear at the same time. In this case, an unknown mismatch directly indicates a functional error.

Also, an invalid mismatch can have two effects. That is, it can cause functionality errors or memory corruption because it essentially indicates that the decoder did not properly verify the length of a particular IE. If the decoder's length limit for the IE is more stringent than that defined in the specification, then further analysis is not required since rejecting a benign IE indicates a functional error (912). A bug may occur (913). For example, buffer overflows can occur if developers blindly assume the length of a particular IE according to the specification, even though the actual length may be greater. Handler functions may be subject to additional scrutiny, so manual analysis of the handler is required to determine the effects of false mismatches. Notably, these invalid mismatches provide useful insight into the mistakes of developers embedding message structures into baseband firmware, which can lead to the discovery of several important security vulnerabilities.

The devices described above may be implemented as hardware components, software components, and/or a combination of hardware components and software components. For example, devices and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA), It may be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions. A processing device may run an operating system (OS) and one or more software applications running on the operating system. A processing device may also access, store, manipulate, process, and generate data in response to execution of software. For convenience of understanding, there are cases in which one processing device is used, but those skilled in the art will understand that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it can include. For example, a processing device may include a plurality of processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. You can command the device. Software and/or data may be any tangible machine, component, physical device, virtual equipment, computer storage medium or device, intended to be interpreted by or provide instructions or data to a processing device. can be embodied in Software may be distributed on networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer readable media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program commands recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. - includes hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler.

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the method described, and/or components of the described system, structure, device, circuit, etc. may be combined or combined in a different form than the method described, or other components may be used. Or even if it is replaced or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents of the claims are within the scope of the following claims.

Claims (18)

A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device,
The step of comparing and analyzing the message structure implemented in the baseband software with the standardized message structure of the cellular standard by using the characteristics of the baseband as a modem for network communication.
including,
The step of comparing and analyzing the message structure implemented in the baseband software with the standardized message structure of the cellular standard,
A method of automatically comparing and analyzing mobile communication baseband software by automatically checking a message structure implemented in the baseband software by utilizing a standardized message structure of the cellular standard. According to claim 1,
Identifying a mismatch in which the message structure implemented in the baseband software does not conform to the standardized message structure of the cellular standard through the comparative analysis.
Further comprising, a method for automatically comparing and analyzing mobile communication baseband software. According to claim 1,
The step of comparing and analyzing the message structure implemented in the baseband software with the standardized message structure of the cellular standard,
analyzing the baseband software to identify a message decoder and extracting a message structure implemented in the baseband software; and
Comparing and analyzing the extracted message structure with a standardized message structure of the cellular standard
A method for automatically comparing and analyzing mobile communication baseband software. According to claim 3,
The step of comparing and analyzing the extracted message structure with the standardized message structure of the cellular standard,
Comparing and analyzing whether the protocol structure embedded in the baseband software is syntactically identical to the cellular standard
Characterized in, a method for automatically comparing and analyzing mobile communication baseband software. According to claim 3,
The step of comparing and analyzing the extracted message structure with the standardized message structure of the cellular standard,
Comparatively analyzing whether the function of the message decoder complies with the cellular standard, which has a basic logic that semantically utilizes symbolic execution.
Characterized in, a method for automatically comparing and analyzing mobile communication baseband software. According to claim 2,
analyzing the discrepancy to see if it could create a functional or security bug;
Further comprising, a method for automatically comparing and analyzing mobile communication baseband software. According to claim 2,
The step of identifying the discrepancies is:
Reporting remaining information elements (IEs) that are not mapped to the standardized message structure of the cellular specification in the message structure implemented in the baseband software as missing discrepancies or unknown discrepancies.
Characterized in, a method for automatically comparing and analyzing mobile communication baseband software. According to claim 2,
The step of identifying the discrepancies is:
Automatically identifying discrepancies in Layer 3 (L3) messages of a number of said baseband software and flagging potential buggy points for analysis.
Characterized in, a method for automatically comparing and analyzing mobile communication baseband software. In the system for automatically comparing and analyzing mobile communication baseband software based on mobile communication standard documents,
Comparison and analysis unit that compares and analyzes the message structure implemented in the baseband software with the standardized message structure of the cellular standard by using the characteristics of the baseband as a modem for network communication
including,
The comparative analysis unit,
A system for automatically comparing and analyzing mobile communication baseband software that automatically checks the message structure implemented in the baseband software by utilizing the standardized message structure of the cellular standard. According to claim 9,
A mismatch identification unit identifying a mismatch in which the message structure implemented in the baseband software does not comply with the standardized message structure of the cellular standard through the comparative analysis.
Further comprising, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 9,
The comparative analysis unit,
Analyzing the baseband software to identify a message decoder, extracting a message structure implemented in the baseband software, and comparing and analyzing the extracted message structure with a standardized message structure of the cellular standard.
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 11,
The comparative analysis unit,
Comparing and analyzing whether the protocol structure embedded in the baseband software is syntactically identical to the cellular standard
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 11,
The comparative analysis unit,
Comparatively analyzing whether the function of the message decoder complies with the cellular standard, which has a basic logic that semantically utilizes symbolic execution.
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 10,
A bug creation confirmation unit that analyzes the inconsistency and checks whether a functional or security bug can be created.
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 10,
The mismatch identification unit,
Reporting remaining information elements (IEs) that are not mapped to the standardized message structure of the cellular specification in the message structure implemented in the baseband software as missing discrepancies or unknown discrepancies.
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. According to claim 10,
The mismatch identification unit,
Automatically identifying discrepancies in Layer 3 (L3) messages of a number of said baseband software and flagging potential buggy points for analysis.
Characterized in that, a system for automatically comparing and analyzing mobile communication baseband software. A method for automatically comparing and analyzing mobile communication baseband software based on a mobile communication standard document performed by a computer device,
extracting a message structure from the baseband firmware having specifications and binary-specific metadata; and
Syntactically comparing the message structure of the standard with the binary embedded message structure of the baseband firmware and semantically analyzing the implementation logic using symbolic execution.
A method for automatically comparing and analyzing mobile communication baseband software. According to claim 17,
Identifying discrepancies between the message structure of the standard and the message structure of the baseband firmware through the comparison and analysis.
Further comprising, a method for automatically comparing and analyzing mobile communication baseband software.

Images