When it comes to the inner workings of a mobile device, understanding the roles of the mobile application processor and the baseband processor is essential.

The mobile application processor is responsible for handling tasks related to running applications, managing user interfaces, and processing high-level functions that contribute to the overall performance and user experience of the device. It serves as the engine behind smooth app operations and efficient task execution.

On the other hand, the baseband processor plays a crucial role in managing communication functions such as voice calls, data transmission, and cellular connectivity. It ensures that users can seamlessly connect to cellular networks, make calls, and send messages without any disruptions.

However, unlike the mobile application processor, the baseband processor lacks the robust protections and exploit mitigations like ASLR, N^X and others, commonly found in the mobile operating systems like Android and IOS, leaving it more vulnerable to security threats.

In this blog post, we will delve into the realm of baseband vulnerabilities discovered through emulated baseband fuzzing, shedding light on potential security risks associated with the baseband processor.

By exploring these findings, we aim to enhance our understanding of the distinct functionalities of the mobile application processor and the baseband processor, ultimately enabling us to optimize both the functionality and security of modern mobile devices.

The Platform Abstraction Layer, commonly referred to as PAL, is a software layer that provides a consistent interface to the hardware, irrespective of the underlying platform or operating system. In the context of Shannon firmware, PAL serves as the bridge between the firmware and the device's hardware, abstracting the complexities of hardware-specific operations. This abstraction allows the firmware to operate seamlessly across different hardware configurations and platforms. PAL plays a pivotal role in ensuring that the firmware can efficiently execute its tasks by handling the peculiarities and variations of the hardware, thereby enhancing portability and scalability.

Download the firmware shared from the below to reproduce CVE-2020-25279.

This assists in pinpointing the exact address of the target function, which is essential for emulating our harness and capturing the snapshot needed for the fuzzing process.

The function pal_SmSEvent() at address 0x4054df83 invokes the pal_SendMsgto() function. To proceed with snapshotting, copy the address of pal_SmSEvent. The reason we are taking a snapshot from pal_SmSEvent is because of the memory snapshot that will be taken from that point as pal_SendMsgto() function is depended on some initialisation within palSmSEvent().

Below is a sample harness that can be found in the Firmwire repo and we will use this sample fuzzing harness.

This fuzzing harness if targeting the pal_MsgSendTo() function.

Before we can run the fuzzing harness we need to make sure that we take a snapshot of the memory in order to do snapshot fuzzing.

We will use the address pal_SmSEvent() address that we got previously and use that as the --snapshot-at parameter.

Create a directory for fuzzing inputs using the command ‘mkdir fuzz_input’.

Now, let's break down and understand each component of the byte stream that was previously captured and saved in a file. If any terms seem unclear, it is recommended to refer back to the earlier sections about establishing calls between mobile phones, as outlined in the previous bullet points. This step-by-step analysis will help clarify the process and the terminology involved.

We will be employing AFL++ in Unicorn mode for the purpose of executing snapshot fuzzing. AFL++, an enhanced version of AFL (American Fuzzy Lop), offers advanced features and improvements. By utilizing it in Unicorn mode, we leverage the Unicorn CPU emulator to create a more efficient and effective fuzzing environment, particularly suited for running and testing our snapshot.

After few hours , we got the crashes.

In our previous article, we explored the extraction and mounting of the Samsung firmware file system. Building on that, we'll now retrieve the modem.bin file. Following the steps outlined earlier, we'll set up and run the fuzzer for a more in-depth analysis.

For more details, you can read the full article on the Mobile Hacking Lab website.

We will now again take the pal_SmSEvent() address as the snapshot address.

Copy the address of the target function for snapshot purpose.

Lets take the snapshot for the target address.

Search for a notification indicating 'snapshot completed!'. If this message isn't appearing, revisit our previous steps until you receive this confirmation.

Now we have reproduced the crash with our extracted firmware using the harness.

The article discusses advanced techniques in mobile firmware analysis, focusing on Shannon Baseband Firmware. It covers the emulation of this firmware and using Firmwire and AFL (American Fuzzy Lop) for fuzzing. The process involves extracting and setting up the Samsung firmware, particularly the modem.bin file, for detailed analysis. Key steps include creating an emulation environment, snapshotting for fuzzing, and running the fuzzer to identify vulnerabilities like CVE-2020-25279. The article also guides on setting up the necessary tools and running AFL++ in Unicorn mode for effective fuzzing.

• https://firmwire.github.io/docs/index.html
• https://github.com/grant-h/ShannonFirmware
• Fuzzing Against the Machine - Antonio Nappa and Eduardo Blázquez