In response to the interrupt, the ARM11 interrupt handler walks through the list of opened channels (smd_ch_list in the Figure 2 below) and checks the status flags of each one. If there has been a change, the callback function associated with the channel is called. The callback procedure is bound by the caller when the channel is opened and can be any function.

Figure 2: Interrupt handling flow chart

This general-purpose mechanism allows for synchronous and asynchronous message passing to take place between the processors.

For asynchronous message passing, the user sets up a callback routine that does something simple, such as sets a flag. When the interrupt is handled and the callback routine is called, the flag gets set. Some time later, the user's other processing can query the flag, and perform appropriate actions: The user calls smd_open() to allocate a channel and register a callback function. The interrupt service routine will asynchronously call the callback routine. It's up to the user of this channel to arrange the details between the callback routine and the foreground processing.

For synchronous message passing, the situation is almost identical. Instead of modifying the value of a flag and having the user function periodically check the flag, the callback routine posts to a semaphore, and the user function blocks, waiting on that semaphore.

At a slightly higher level, a few more APIs are built on top of this general-purpose mechanism, for example, traditional remote procedure call (RPC) functionality. RPC allows software on one processor to call software on the same or another processor. Simply put, the caller's RPC protocol stack is responsible for marshalling the call parameters into a message and somehow waking up the other processor (the "callee"). The callee processor wakes up, unmarshalls the data and sets up the call to the actual target subroutine. When the called subroutine returns, the return parameters are marshalled into a message, and the callee processor sends the message to the calling processor. The calling processor unmarshalls the data and returns it to the caller, as if it were a local (albeit longer executing) subroutine call.

Since RPC messages can be an arbitrary length, software exists to perform packet assembly/disassembly on the messages travelling between the processors. This packet assembly/disassembly is performed by a foreground thread that waits on a semaphore to tell it that data has arrived.

This is part of the RPC interface functionality:

Click on image to enlarge.

Figure 3: RPC packet assembly and dequeue

The diagram above (Figure 3) illustrates packet assembly. The function do_read_data() is responsible for assembly of the packet. It spends most of its time waiting on a semaphore (via the rr_read() subroutine). As data comes in, the semaphore gets posted and rr_read() unblocks, returning the packet data. When the packet is assembled, the type of packet is checked, and either a control message is processed, or data is delivered via another queue within RPC.

Now let us have a look at a handset that is based on the same Qualcomm MSM 7200 chipset, but runs Windows Mobile operating system. Because the chipset is the same we were able to leverage our understanding of the IPC mechanism used on Android in order to find similar software under Windows Mobile.

We knew where the shared memory region was on the chipset, allowing us to search for code that used that region. We found code that implemented a similar IPC mechanism as on Android--in fact, it was even more interesting because it appears that there was a REX (a proprietary Qualcomm OS) emulator running under Windows Mobile! So, it appears that the commercial version of the software started out under REX and was later ported to Windows Mobile.

The following screenshot (Figure 4) illustrates a disassembly of the initialization function that maps the virtual address to the physical address corresponding to two of the MSM 7200 memory regions (MSM_CSR_PHYS and MSM_VIC_PHYS).

Click on image to enlarge.

Figure 4: Function to establish virtual addresses

Reverse engineering software is a bit like solving a puzzle, where each iteration of the solution introduces new constraints and imposes others. Having knowledge of the open source Android software allowed Semiconductor Insights to understand the Windows Mobile closed proprietary platform with greater ease.

Robert Krten is senior software analyst at Semiconductor Insights, a division of TechInsights. He is responsible for reverse engineering software and mapping the derived architecture against claim elements of customers' patents.