DYLD — Do You Like Death? (IX)

The lifecycle of a Dynamic Loader from its creation to its termination.

This is the ninth article in the series about debugging Dyld-1122 and analyzing its source code. We will introduce RuntimeState which APIs are used for tracking process-related data, such as threads or loaded Mach-Os.

Please note that this analysis may contain some errors as I am still learning and working on it alone. No one has checked it for mistakes. Please let me know in the comments or contact me through my social media if you find anything.

Let’s go!

WORKING MAP

As last time, we begin our journey by decompiling the Dyld using a Hopper.

hopper -e '/usr/lib/dyld'

We are in the dyld`start analysing the Memory Manager. In the fourth article, I introduced pseudo-code, which you can see below. Based on this, we finished creating the allocator, then we set the ProcessConfig in this allocator and now we follow with RuntimeState initialization:

In the last episode, we finished collecting ProcessConfig properties with ProcessConfig::PathOverrides. Now, we are going to execute RuntimeState:

The starting point in the assembly (ending point is just after returning from it).

Dyld GitHub repository:

• Start: RuntimeState in dyld-1122.1 — dyldMain.cpp#1242
• End: externallyViewable.init in dyld-1122.1 — dyldMain.cpp#1246

LLDB breakpoints:

# Start - dyld`start+1552
settings set target.env-vars DYLD_IN_CACHE=0
br set -n start -s dyld -R 1552
# END - dyld`start+1572
br set -n start -s dyld -R 1572

The next article will start at the exact point where this one finishes.

START — RuntimeState

The RuntimeState is a constructor function that initializes the object of that class. Before we execute the RuntimeState, we set up three arguments:

X1 = 0x1004fd910 # ProcessConfig: we set up earlier 
X2 = 0x16fdff1b0 # RuntimeLocks: prevent concurrent access to resource
X3 = 0x1004fc000 # Allocator: -> 0x0000000100099ee0 -> 0x000000010003b480

The constructor set up the members of the RuntimeState class object using this to refer to the object itself, accessing its member variables:

• It sets quite a few class members that are difficult to comprehend by looking only at the decompiled code.
• The first member is set to off_1000A5290 , which is a pointer to the finalizeListTLV function (TLV stands for Thread Local Variable).
• Additionally, in line 17, there is a call to a function using
  *(*Allocator_ptr + 16LL))(Allocator_ptr).
• Furthermore, in line 38, we can see a FileManager, which appears to be another constructor function, but this time for a FileManager class.

To find the class member names, we can review their declaration in the DyldRuntimeState.h#L345-L681 header file:

DyldRuntimeState.h#L345-L681

I will not copy-paste the full code here because it's long. For the full code →link.

In IDA, there is a handy functionality Create new struct type… by clicking PPM on the given code block, we may create a new structure for this class:

Unfortunately, the automated structure created by IDA does not contain properly renamed members. This must be made manually:

However, it is not so straightforward to just copy-paste each member one by one from the source code repository and rename it in IDA decompiled code. This is because the assembly code slightly differs from the C code in the repository.

For instance, the first member (already renamed by me below) is a pointer to a RuntimeState::_finalizeListTLV instead of a config member.

DyldRuntimeState.h

The second member was renamed to SyscallDelegate instead of config, because it is only referenced once by fileManager using &config.syscall:

DyldRuntimeState.h

I will not analyse it so deeply here, but for sure we will run into some parts of it later on. They are used by the DyldAPIs.cpp and the DyldRuntimeState.cpp.

What is `(*Allocator_ptr + 16LL))(Allocator_ptr)` ???

We can access the function call while debugging at RuntimeState+132:

# dyld`dyld4::RuntimeState::RuntimeState
br set -n RuntimeState -s dyld -R 132

The blraa x8, x17 branches to the address stored in register x8 using the address stored in register x17 as the return address (signed with PAC):

So, the hidden function here is lsl::PersistentAllocator::memoryManager. When we step into it, we see it consists of a single instruction:

It loads a value from the memory x0 + 0xF0 into register x0. In our case, it changed the value in x0 from 0x1004fc000 to 0x1004fcd10. It points to:

It looks like the very beginning of the MemoryManager object. We can find a part of the function code in the repository:

Allocator.cpp

The pointer to this memory is later stored in the 0x1004fdc40 (x19+0x80):

We set MemoryManager by calling PersistentAllocator. It was described in the previous article of the series: DYLD — Do You Like Death? (IV).

FileManager

The FileManager is the second function called inside the RuntimeState. It is a constructor which invokes another constructor UniquePtr in line 17:

# dyld4::FileManager::FileManager
br set -n RuntimeState -s dyld -R 220

We can find FileManager source code in the repository:

FileManager.cpp

In line 47, the function takes as arguments a reference to an Allocator object and a pointer to a SyscallDelegate object:

In line 48, we can see FileManager class members which are:

• _syscall(syscall): Initializes the _syscall member variable with the value passed as syscall.
• _allocator(&allocator): Initializes the _allocator member variable with the address of the allocator parameter.

• _fsUUIDMap(_allocator->makeUnique<OrderedMap<uint64_t,UUID>>(*_allocator)): Initializes the _fsUUIDMap member variable with a unique (smart) pointer to an OrderedMap<uint64_t, UUID> object created by calling makeUnique method of the Allocator object.

lsl

At this stage, I am unsure of the exact purpose of _fsUUIDMap. However, judging from the rest of its code, and as it maintains a mapping between file system IDs (fsids) and UUIDs. It may allow the FileManager to retrieve the UUID associated with a given file system ID and then retrive other info about the file.

States Overview

In the last 3 articles, DYLD — Do You Like Death? (VI-VIII) we have analyzed ProcessConfig. Now we introduced RuntimeState. These classes make up the Global state of the process we are running. Here is a brief overview:

dyld4.md#global-state

Based on this, we may conclude that config stores fixed data while state stores dynamic data. This is partially true, as the state stores a structure called PermanentRanges. It is well described in the repository:

We should be aware of that structure as it is lock-free. This means access to it can be performed concurrently by multiple threads without locking mechanisms, so there could be some vulnerabilities such as Race Conditions.

END

In this article, we initialized a state object of the RuntimeState class. This will be used as APIs for tracking process threads, loaded Mach-O images (for instance Dylibs loaded in the following steps), interposed functions, and other things related to the process that are dynamic(changes its state).

We can inspect all its members using the address in the x0 register after returning from its constructor function:

# dyld`start + 1572
br set -n start -s dyld -R 1572

In the decompiled code, we returned to the dyld::start and finished here:

We are still in the code related to the Memory Manager:

In the Dyld source code, we finished here:

dyldMain.cpp

In the following article, we will get the idea what is ExternallyViewableState.

To be continued …