How to make sense of RTOS in firmware?

Question

I am reverse engineering a firmware which has a Linux and an RTOS component. I used binwalk to easily locate the Linux filesystems, extract them, mount them, and now I have binaries which I can open in IDA Pro and continue working on.

However, I am having a much more difficult time doing this with the RTOS side of the firmware. In my target firmware image, I was able to identify that the RTOS sits above the Linux filesystems in memory address, by performing some string searches for common RTOS-related things. The code is definitely ARM, likely 32 bit, little-endian. This is a Cortex-A7. I saw artifacts which indiciate that it is also likely an ITRON RTOS or perhaps FreeRTOS. But essentially, binwalk extracted 3-4 chunks of "data" files which contain all of this. So I am able to get some useful info from looking at string offsets in these chunks. Seeing as most of the data appear to be strings and ARM instructions, I've opened them in IDA Pro. IDA Takes A LONG TIME to parse, but once they're parsed, everything is just data and needs to be manually turned into code. This is where I'm hung-up. I have 2 main questions:

1. Does an RTOS system like this have a proper "file system" that I could "mount" to view the binaries like I did with the Linux ext and squashfs ones? All filesystems I've ever worked with using binwalk have been Linux ones. What are common RTOS file systems if this is the case?
2. If not, how can I go about viewing the ARM disassembly of these chunks in a legible way using IDA Pro?

Answer 1

Most RTOS code is usually a single monolithic binary and is not split into separate binaries like a high-level OS. Usually there is some startup code, some library routines and user-provided code in forms of tasks which are nothing more than simple functions performing the necessary work in a simple infinite loop. The “main function” called by the RTOS startup would register the tasks, set up the shared resources like timers, queues, semaphores etc. and invoke the RTOS entry point which starts dispatching the tasks, switching between them periodically so that each gets a chance to run.

While there is no file system, there may be other useful information in the binary. Most RTOSes allow you to give names to tasks so you may be able to find some strings and from the references discover task creation/registration functions. Sometimes a table of structures is used(e.g. a pointer with name and pointer to the task function).

To force disassembly of a big chunk of code in IDA you can use selection, e.g.:

1. Go to the potential start of code (e.g. beginning of the code segment)
2. Drop selection anchor (Alt-L)
3. Go to the end of code (e.g. by clicking in the navigation bar, scroll bar or via keyboard) do that the whole chunk is selected.
4. Press C and pick Analyze or Force (you may need to experiment and see which one works better)

Note that in some cases data may also be interpreted as valid instructions, so you might get false positives (especially with the “force” option), which may require you to fix things up afterwards. But this should help you get started and discover some valid code.