Fuzzing Shannon Baseband Firmware
Shannon firmware is a proprietary baseband firmware developed by Samsung for its range of mobile devices. This firmware plays a critical role in managing the baseband processor, which is responsible for all communication functions between a mobile device and a cellular network.
Jan 26
About Shannon Firmware
Shannon firmware is a proprietary baseband firmware developed by Samsung for its range of mobile devices. This firmware plays a critical role in managing the baseband processor, which is responsible for all communication functions between a mobile device and a cellular network. It handles crucial tasks such as signal processing, voice and data transmission, and error correction. The firmware operates at a low level, directly interacting with the device's hardware, making it an integral part of the mobile communication ecosystem.
Application Process vs Baseband
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 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.
Platform Abstraction Layer (PAL):
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.
Setting Up the Emulation Environment for Shannon Firmware
Download the firmware shared from the below to reproduce CVE-2020-25279.
This will automatically recognize the firmware, unpack it, and select a loader and machine to run it. You can also load firmware from a URL to get started
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().
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().
Next, we'll explore the process of capturing a snapshot by emulating the firmware and executing the harness, which involves invoking the target function.
After loading the firmware, FirmWire sets up a dedicated workspace for analyzing it. This workspace includes several important files: logs, a configurable machine definition, and a qcow2 image integral to FirmWire's snapshotting mechanism.
Additionally, it contains various vendor-specific files and directories.
Additionally, it contains various vendor-specific files and directories.
Harness code
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.
This fuzzing harness if targeting the pal_MsgSendTo() function.
Creating the snapshot
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.
We will use the address pal_SmSEvent() address that we got previously and use that as the --snapshot-at parameter.
Search for a notification indicating 'snapshot completed!'. If this message isn't appearing, revisit our previous steps until you receive this confirmation.
Creating the fuzz inputs
Create a directory for fuzzing inputs using the command ‘mkdir fuzz_input’.
Next, let's proceed with creating the 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.
• 3030303030303030: Called party BCD number
• 3030303030303030: Calling party BCD number
• 0B: Length of the bearer capability field
• 04: Bearer capability, indicating that this is a call setup message
• 0333: Audio bearer capability, indicating speech
• 9001: Radio channel requirement, indicating a full rate traffic channel
• 214365C287: Called party number in IA5 (ASCII) format – in this case,214365
• 0A: Length of the called party subaddress field
• 0033: Called party subaddress type, indicating that this is an extensionof the called party number
• 33: Extension of the called party number – in this case, 3
Running the fuzzer
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.
Firmware Extraction
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.
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.
Snapshot
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.
Run the Firmwire Fuzzer
Now we have reproduced the crash with our extracted firmware using the harness.
Conclusion
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.
Upcoming articles will delve into replicating the CVE-2020-8899 crash in the Skia library, offering detailed insights and guidance on this specific vulnerability.
Want learn advanced fuzzing and exploitation? Check out our courses, “Android Userland Fuzzing and Exploitation” and “Android Kernel Fuzzing and Exploitation” or do some of our free labs.
Check out our training:
https://www.mobilehackinglab.com/course/android-userland-fuzzing-and-exploitation
References
- https://firmwire.github.io/docs/index.html
- https://github.com/grant-h/ShannonFirmware
- Fuzzing Against the Machine - Antonio Nappa and Eduardo Blázquez
Copyright © 2024
Company
Registration:
89905814
VAT:
NL004770321B63
89905814
VAT:
NL004770321B63