Venturing into the Deep

While we can consider most of the recent updates to RAMalyzer as quality-of-life updates, there has been one update that is truly new, and this new feature is what we shall look at today. This new feature is called “deepscan” and is used to show all tasks found in memory, regardless of its run state. To understand what is meant by this, we should first look at the mechanism within an operating system that chooses what runs next, and by extension we can examine when we consider a task to be running or not.

Providing multi-tasking

One of the main parts of a multi-tasking operating system is to provide the ability to run multiple tasks at once. The way that this multi-tasking is achieved is by switching the tasks after a short interval, thus providing the illusion of many tasks operating at once on a device. The actual switching is performed by the context switch, which is used to save the state of the current task that is running, and to load the state of another task so that it may run. The context switch is used many times a second but only switches between two tasks at any time, Figure 1.0 is a visual representation of this process.

 
Figure 1.0

In this example, we can see that we begin with Task 1 being executed. Task 2 and Task 3 are considered Idle while Task 1 Is running. At time t1, the context switch will save Task 1 and load Task 2, which then begins executing, and Task 1 and Task 3 can be considered idle. At time t2 the context switch will save Task 2 and load Task 3, which will begin executing and Task 1 and Task 2 can be considered idle. Finally, the context switch will load Task 1 and save Task 3, which will begin running and Task 2 and Task 3 can then be considered idle. All three tasks appear to be running all the time, but in reality, they are each given small slices of time.

Scheduling the next task

The job of choosing which task should run next falls on the scheduler, which is used to schedule which tasks run in which order. There are many algorithms that can be used to provide scheduling, dependent on the priorities of the system in which the operating system is running. For example, Figure 1.0 shows each task being run in order, using the round-robin algorithm. Here, we are less interested in how it chooses which task to run, but how it knows which tasks require CPU time so that it should be scheduled. The tasks which require CPU time are placed within a list, the task list, which we can examine when we use the “list” command within RAMalyzer.

When we look at the task list, we can be confident that all the tasks we see are either currently running or waiting to be run (idle). This means that when a program is started, a task is created for that program and this task is placed in the task list and receives CPU time based on the priorities chosen by the scheduler. We are then able to examine the state of this task, and the program the task represents via RAMalyzer.

When the program is completed, for whatever reason, it no longer requires CPU time and is removed from the task list. The scheduler is no longer aware of the task and can no longer assign CPU time to it and it can then be considered unscheduled. Using the new deepscan feature within RAMalyzer we are also able to examine these unscheduled tasks in the same way we can examine scheduled tasks.

Deepscan

We can now use the “deepscan” switch within some of the commands used by RAMalyzer to examine these unscheduled tasks. As an example, in Figure 2.0 we can see how the output shows scheduled tasks for the following command:

ramalyzer list –deepscan –file osaka.xry

Figure 2.0

But further down in the output we can start to see tasks marked as unscheduled as shown in Figure 3.0:

Figure 3.0

These are tasks that are now complete, but we can find them again. Figure 4.0 shows a task that appears to manage WiFi configuration (com.sec.epdg) and we will look at further:

Figure 4.0

We can use a regular expression to dump all of the strings from the task and look for any potential connections that were made from this task as shown by the following command with the result shown in Figure 5.0:

Ramalyzer regex –pattern “[\x20-\x7E]{4,}”–pid 12492 — deepscan –file osaka.xry > strings.txt

Figure 5.0

From the output file (we used a pipe to output to a file), we can see that we have indeed connected to “MarriottBonvoy_Guest”, but we can also see the access point MAC addresses: 84:18:3a:5f:f7:b8 and 0a:20:6a:47:07:a2, one of which potentially belongs to the handset and one potentially belongs to the access point that was being used.

Later in the strings we can see that the Wi-Fi was used as shown in Figure 6.0:

Figure 6.0

Which shows that the Wi-Fi signal was upgraded with a time and a date that corresponds with internet activity as documented in this handsets testing.

Please join the conversation on the MSAB Forum in our dedicated RAMalyzer section, looking for tips? Want to share some interesting insights with fellow examiners? Head to the forum now!

Customer Forum 

If you want to learn more or have any questions, don’t hesitate to get in touch with us.   

Contact us 

About the author:
Dave Lauder is a Security Researcher at MSAB.