In the previous iOS application script re-signature, we re-signed the shelled wechat installation package and successfully ran it on the real machine, completing the iOS reverse preparation work. This article will give a brief overview of several ways to inject iOS code by showing how to HOOK wechat login event and get user password. Whether doing reverse or forward development, these can give you some ideas on how to attack and defend application security. When you want to HOOK someone else’s method to make a widget, you first need the program to execute the code you wrote, and then you have a chance to use the Runtime runtime mechanism to do your own thing. Please refer to this article for tips on method obfuscating. In order for the program to execute the code we wrote, we need to modify the MachO file, which I explained in detail in this article, which focuses on code injection:

  1. The Framework into

    Add your own Framework:

    Write the test code in theIn the previousAdd a line of code to modify the MachO load path on the basis of the re-signing script:yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/SharonFramework.framework/SharonFramework"The Framework file is named the one you just added yourself. The Run directly!

    And you’re done.

  2. Dylib injection

    Add your own Dylib:

    Note that Dylib for MacOS added in this way requires BuildSetting–>Base SDK to iOS, BuildSetting–>CODE SIGN IDENTITY to iPhone Developer to run on iPhone.

    Also, unlike the Framework, it requires manual addition of associated libraries:

    Also add a line of code to change the path of the MachO executable in the re-signing script:yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/libSharonLibrary.dylib"The dylib file is named the one you just added yourself. The Run directly!

So far we have completed the first step of code injection, let others application at runtime execution we write code, you may encounter in the process of the signature is not successful, etc all kinds of wonderful work problems, don’t panic, calm analysis, no way you can leave a message ^_^ ~ really, then we will try to HOOK WeChat login button events.

Synchronize several consensus:

  • The +load method is called only once when the class or class is loaded by the Runtime (the compiled executable is loaded into memory).
  • The +load method of a subclass is executed after the +load method of all its parents, and the +load method of a classification is executed after the +load method of its main class.
  • If a subclass does not implement the +load method, then the Runtime does not call the +load method of the parent class when it is loaded. Similarly, when both a class and its classes implement the +load method, both methods are called.
  • The order in which the +load methods are called between different classes is uncertain.
  • Based on the above characteristics of the +load method, it is the best entry point for method obfuscation.

Analyze the target Method using viewDebug+ header files

MethodSwizzling several poses

  1. class_replaceMethod

  1. class_getInstanceMethod & method_setImplementation

  1. method_exchangeImplementations

    For those of you who are careful, we’ll see that in this case, there’s a problem with just writing an OC method and then using method_exchangeImplementations with the implementation of the old and new methods:

    Because the self is WCAccountMainLoginViewController my_next, call my_next will find method. The solution is to manually add my_next to WCAccountMainLoginViewController method.

    So we also see that method_exchangeImplementations is more convenient when we swap methods overloaded by the main/parent class in a classification or subclass. So in reverse, we typically don’t use method_exchangeImplementations directly, we prefer the first two ways.