Welcome to the iOS Reverse series.

  • IOS reverse RSA theory
  • IOS reverse hash theory
  • IOS reverse application re-signature + wechat re-signature combat
  • IOS reverse Shell script + script re-signature
  • IOS reverse code injection +Hook
  • IOS reverse MachO file
  • IOS reverse dyLD process
  • IOS reverse HOOK principle of Fishhook
  • IOS reverse LLDB debugging

Writing in the front

Dyld, as apple’s dynamic linker, is an important part of Apple’s operating system. Dyld is responsible for the rest of the work after the system content is ready for the program. So understanding the loading process of DYLD can be helpful in our reverse journey

Since the dyLD loading process has been covered in the iOS Explore series, this article will only provide a brief overview of the process

A, _dyld_start

_dyLD_START is the starting point for program execution, which can be viewed with the BT directive

_dyld_start
dyldbootstrap::start

Second, dyldbootstrap: : start

The dyLDbootstrap ::start function does some protection and calls dyld::_main

Three, dyld: : _main

3.1 Configuring Environment Variables

As long as these two environment variable parameters are set, relevant parameters and environment variable information will be printed when App starts

3.2 Loading a Shared Cache Library

Call checkSharedRegionDisable to check and load shared cache libraries (iOS cannot disable shared cache libraries)

3.3 Instantiating the main program

InstantiateFromLoadedImage function called

  • isCompatibleMachOCheck machO compatibility
  • instantiateMainExecutable -> sniffLoadCommandsInstantiate the main program

3.4 Loading the Dynamic Library

This is where jailbreak mods tend to shine

3.5 Link the main program

Link the main program to the dynamic library

Now comes the most important part of DYLD

3.6 Initialization Method

Call the initializeMainExecutable initialization method, which is a complex traversal process that processes the dynamic library first and then the main program

InitializeMainExecutable call runInitializers

runInitializers
processInitializers

processInitializers
recursiveInitialization

recursiveInitialization
notifySingle
doInitialization

notifySingle
sNotifyObjCInit
sNotifyObjCInit

registerObjCNotifiers
sNotifyObjCInit

_dyld_objc_notify_register
registerObjCNotifiers

Objc source
_objc_init
_dyld_objc_notify_register

_dyld_objc_notify_register
notifySingle
+load

DoInitialization is called after notifySingle

  • doImageInitTo determinelibSystemInitialize or not

doModInitFunctions

3.7 Entering the Main program

At this point, the dyLD process is over, and the stage is set for the main function

Iv. Dyld flow chart

Fifth, to prove

Create a new dynamic library and add the +load method and c++ constructor to the main program and dynamic library, respectively

+ (void)load {
    NSLog(@" Main program -- load");
}

__attribute__((constructor)) void funcCooci(){
    printf("Main program c++");
}
Copy the code
Framework(Feng) -- load Framework(Feng) -- c++ main program -- load main program -- c++Copy the code

It turns out that the dynamic library executes the +load method and c++ constructor before the main program

  • The order of execution of multiple dynamic libraries depends onGeneral -> Framework, Libraries, and Embedded ContentThe order
  • The order of execution of multiple compilation units in the main program depends onBuild Phases -> Compile SourcesThe order

Write in the back

Due to personal obsessive-compulsive disorder, I chose to add an article about dyLD processes to the iOS Reverse series, but unlike the iOS Exploration series, this article is more concise and easy to understand