DYLD — Do You Like Death? (III)

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

This is the third article in the series about debugging Dyld-1122 and analyzing its source code. We will start from the getUuid function in dyldMain.cpp, which is the exact point where we finished the last article.

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 after the conditional jump in handleDyldInCache:

When you look at the image below, it is this else at the beginning.

In this episode, we will continue the exploration of the handleDyldInCache function. We are starting just before the 7th conditional check — exactly on the getUuid function and finish after executingrestartWithDyldInCache:

The starting and ending points in the decompiled pseudo code.

Starting point in the assembly.

Ending point in the assembly.

Dyld GitHub repository:

• Start: getUuid() in dyld-1122.1 — dyldMain.cpp#L1057
• End: RuntimeLocks in dyld-1122.1 — dyldMain.cpp#L1219

LLDB breakpoints:

# START - dyld`start+1140
settings set target.env-vars DYLD_IN_CACHE=0
br set -n start -s dyld -R 1140
# END - dyld`start+1264
br set -n start -s dyld -R 1264

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

START — Hidden Environment Variable (7,8,9)

We compare the Dyld’s UUID from the Shared Cache mapped in step 5 with the currently running Dyld. If they match, we retrieve the value of the DYLD_IN_CACHE environment variable and proceed to the 10th branch:

dyldMain.cpp

All the functions should be familiar to us as we analyzed them before. Therefore, I will not describe them again. However, there is one new thing DYLD_IN_CACHE.

I was unaware of this particular variable before analyzing the Dyld loading process. It appears to be unique and is not documented:

I could not find any references to it in the source code repository or on the internet. The only person who mentioned it publicly was theevilbit:

That’s almost true. There is a way to set breakpoints, as we will find out later.

The question is, why exactly we cannot hit the breakpoints?

restartWithDyldInCache (10,11)

If DYLD_IN_CACHE is not set or its value is set to 1, we will fall into the 10th branch where we eventually trigger the restartWithDyldInCache:

However, first things first. We did not use the DYLD_IN_CACHE. Thus, we run into the switchDyldLoadAddress, kdebug_trace_dyld_cache, and eventually executes final restartWithDyldInCache. There is also HAS_EXTERNAL_STATE a preprocessing conditional branch that is not shown in the decompiler:

dyldMain.cpp

The HAS_EXTERNAL_STATE is always true because BUILDING_DYLD is set to 1 when Dyld is compiled, and TARGET_OS_EXCLAVEKIT was checked before.

Defines.h

The switchDyldLoadAddress takes a pointer to a Mach-O file representing Dyld we mapped in the cache and use it to update the load address of Dyld:

ExternallyViewableState.cpp

We can inspect in lldb that we pass a pointer to Dyld from a cache to the function in x0, and we store this address in dyld_all_image_infos+0x20:

The dyld_all_image_infos stores all images loaded for the current process. We can inspect them in lldb using image list command:

In our current stage of loading, there are only two images: executable and dyld. The Dyld will later load all libraries and their dependencies.

Then we got kdebug_trace_dyld_cache, a kernel-level tracing mechanism that traces events related to the Dyld cache, if kdebug_trace_dyld_enabled is enabled. As previous kdebug trace, this is off by default, so we skip it.

Finally, we execute restartWithDyldInCache, which restarts the process described here by setting SP on the original kernArgs but jumping to the Dyld we mapped in cache instead of the one we used from /usr/lib/dyld:

After the br x2 we jump to __dyld_start we saw in the first article of this series, but using 0x18db847a8 address which is a Dyld in cache:

As we can observe, this is the Dyld startup code. However, we do not have symbols for it, so to set a breakpoint, we need to operate on addresses:

When we continue execution, the breakpoint is hit despite restarting the loading process using Dyld in Cache. What happened?

We lost symbols in lldb because we are using addresses for Dyld in Cache, so the loaded symbols for Dyld are not rebased. We can double-check that:

However, the code we execute is the same Dyld code, but this time, we would not run into the else branch we analysed through this article. Instead, we would run into if — the first one marked above on the image.

Nonetheless, this does not mean we cannot hit our breakpoints without using DYLD_IN_CACHE=0. We just hit a different loading path.

Yet, debugging the rest of the process would not be easy without symbols. Fortunately, there is a way to rebase them:

• Calculate the starting address of the Dyld image in the cache:

• Reload the image of Dyld from the filesystem using the 0x00 slide to get the new (“broken”) base address of the image in the virtual memory:

target module load --slide 0x0000000000000000 --file /usr/lib/dyld

There may be a way to omit this step and calculate the slide straightforwardly. I could not find the reason why Dyld uses a different virtual address than during the first loading, which was 0x0000000100010000. It looks like it takes the unslid Dyld from cache here. Still, my method works ^^, so let's move on.

• Calculate the slide:

• Reload the image once again using the correct slide:

target module load --slide 0xdac8000 --file /usr/lib/dyld

As we step through the restartWithDyldInCache and the __dyld_start, we land in the start function with working breakpoints and symbols:

No need to use DYLD_IN_CACHE to debug this part of the loading process. However, to not fall into the 10th branch as theevilbit said, we must use:

settings set target.env-vars DYLD_IN_CACHE=0

END

By doing this, we will continue the execution flow to the RuntimeLocks:

In the Dyld source code, this red arrow takes us exactly to the line 1219:

dyldMain.cpp

In the next article, we will proceed with the above path using the environment variable DYLD_IN_CACHE=0 to not use Dyld from cache.

Continued in DYLD — Do You Like Death? (IV)