Description: http://events.ccc.de/congress/2011/Fahrplan/attachments/2022_11-ccc-qcombbdbg.pdf
The tasks communicate with each other by the mean of signals and buffer queues. A command buffer is pushed on a FIFO queue and a signal is sent to the task for processing.
Regarding the memory allocation management, the operating system mainly uses two kinds of heaps. The first heap has a classical free blocks-tracking structure where tasks can allocate arbitrary memory blocks using the malloc/free functions. Another kind of heap is also used on top of the former to represent the memory as a contiguous stream of data that tasks can produce and consume (suited for network data flow).
Code execution and debugging
Static analysis of the whole operating system is possible, but the code is pretty massive and a lot of interactions between different tasks are involved at run-time. Since code execution is possible on the device, I investigated how to dynamically debug system code. I present here the architecture of the debugger I am currently writing (this is still a work in progress).
The main point is to be able to debug the operating system with the fewest possible side-effects. In a nutshell, the debugger has to be real-time compliant as much as possible. For the communication with the debugger, I decided to reuse the diagnostic task channel over USB by implementing custom command handlers. The debugger then relies on the GDB server protocol implemented over the diagnostic channel protocol, itself being over USB.
We have access to the interrupt vectors, and we can put BKPT instructions anywhere as well (everything is running in ARM supervisor mode and we can disable the MMU if necessary). If the exception address is a watchpoint, we dump the state of registers and stack, and set up a DPC to acknowledge the debugger of the event. Then execution is immediately resumed. If the exception address is a breakpoint, then we set up a DPC for the debugger and put the task into a wait state allowing other tasks to be immediately scheduled. The execution for the waiting task can be resumed by the debugger by sending it a special signal.
The debugger is making use of its own separated heap and queue at a high address, not to interfere with other operating system tasks while processing debug events.
Of course some tasks will need to process code at timely events, especially those at the lowest layers, so specific care has to be taken not to put breakpoints that would possibly break the RF processing.
ARMv5 has no native support for single-stepping the code. Single-step is implemented by predicting the next PC address and putting a breakpoint at it.
Notes and further thoughts
Information about the code execution environment on basebands is clearly lacking in the literature. On the contrary of previous presentations on the same topic, this presentation focuses on the details of a proprietary baseband operating system, in this case Qualcomm's. I intend to do a demonstration of the debugger for the presentation, and to release the source code later on.
Future areas of work may include a study of the proprietary DSPs and the possibility to locally fuzz the baseband without using a base station.
Tags: securitytube , Confidence , hacking , hackers , information security , convention , computer security , 28c3 , 28c3-2011 ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.