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

There is no risk in re-signing (covered in this article), but a letter has a mechanism to detect BundId, so it is recommended not to log in in large size

1. Code signature

Code signature is the digital signature of executable files or scripts to ensure that the software has not been modified or damaged after signing. The principle is the same as digital signature, but the data of signature is code

1. Simple code signing

  1. Apple officially generates a pair of asymmetrically encrypted public and private keys. A public key is built into the iOS system, and the private key is saved by Apple in the background.

  2. When a developer uploads an App to the App Store, Apple uses the private key to sign the App data (that is, first Hash the App to obtain the Hash value, and then use the private key to encrypt the Hash value to “RSAHash”).

  3. After downloading the App, the iOS system uses the built-in public key to verify the signature. If the signature is correct, the App must be authenticated by the Apple background and has not been modified, which meets Apple’s requirement: ensure that every App installed is officially approved by Apple. (The public key decrypts “RSAHash” to obtain hash1, then performs the same hash algorithm on the application package to obtain hash2, and verifies whether the hash values are the same twice.)

But there are many other needs that can’t be met through App Store downloads

2. Apple’s market needs

  1. The installation package does not need to be uploaded to the App Store and can be installed directly on the phone
  • Real machine debugging and installation directly when developing App
  • The APP for enterprise certificate signing for internal distribution should also be installed smoothly
  1. In order to ensure the security of the system, Apple must also have absolute control over the installed apps
  • Install with Apple’s permission
  • Cannot be abused to allow non-development apps to be installed

In order to meet these requirements, the complexity of iOS signatures has also begun to increase, and apple’s solution here is a two-layer signature

3. Double signature

Here’s a quick overview of the iOS two-tier signature process, but it’s not the final process, and Apple’s dad wants to add a little more to the basic process. There are two basic roles in this process: Mac computer and iPhone. Since the iOS APP development environment is under the Mac system, this dependency becomes the basis of Apple’s double-layer signature

  1. Apple has a fixed pair of public and private keys. Just like in the App Store, the private key is stored in the Apple background and the public key is stored in each iOS system. Public key A and private key A. When CSR files are created in the Mac system, a pair of public and private keys of asymmetric encryption algorithms are generated, which are called public key M and private key M. A=Apple M = Mac

  2. Developers apply for certificates from the Developer Center through the CSR file

  3. The Apple server generates A certificate, also known as A developer certificate, by asymmetrically encrypting the public key M with the private key A. After the certificate is requested, the keystring access associates the certificate with the local private key M (better known as p12)

  4. When we Command+B generates an application, Xcode will sign the application with the local private key M, and put the certificate into the app and pack it into an IPA package

  5. The ipA package is installed on the iPhone

  6. Public key A in the iOS system authenticates the certificate

  7. Verify that the public key M in the certificate is obtained

  8. The public key M verifies the signature of the APP. This indirectly verifies whether the installation behavior of this APP is officially approved by Apple (only the installation behavior is verified here, not whether the APP is changed, because the content of the APP is always changing during the development stage, so Apple does not need to manage it).

  1. Once signature: Private key A-> public key M=> certificate

  2. Secondary signature: private key M->app=>app

  3. Once authentication: Public key A-> Certificate => Public key M

  4. Secondary authentication: Public key M-> private key M=> Result

When a CSR file is created, a pair of private keys and a public key are automatically generated. The private key is stored on the Mac, and the private key is stored in the login key string by default. You can view the private key in the key string

What’s another big lump in the picture? So let’s talk about it

4. Describe the file

To address the problem of app abuse, Apple has added two more restrictions

  • Only devices registered in the Apple background can be installed
  • Signature can only be for a specific App, and Apple also wants to control the iCloud/PUSH/ background running/debuggers within the App additional these permissions, so Apple call these permissions switches uniform Entitlements (Entitlements file)

Hence the Provisioning Profile

Description files generally include certificates, APPids, and devices. Certificates are used to prove the security and validity of our programs when we run or package a project on a real machine

The description file is created on the AppleDevelop website (it will be created by filling in the AppleID in Xcode), and Xcode is packaged into the App when it runs. So when we apply for a certificate using CSR, we also apply for one more thing!! That’s the description file!

In development, you compile an App, sign the App with the local private key M, pack the Provisioning Profile from Apple servers into the App called Embedded. Mobileprovision, and install the App on the phone. Finally, the system is verified

Go to the description file directory

$/ Users/username * * * * / Library/MobileDevice/Provisioning ProfilesCopy the code

Viewing the Description file

$ security cms -Di xxx.mobileprovision
Copy the code

Second, re-signature

1. Prepare for re-signature

  1. PP assistant download wechat (jailbroken version)

  2. Decompress the IPA package

  3. The terminal displays the application signature information in the directory shown in the figure

$ codesign -vv -d WeChat.app
Copy the code

$security find-identity -v -p coDesigningCopy the code
  1. Check whether MachO file is encrypted (Step 3 Enter the current directory after displaying package contents)
$otool = MachO-lWeChat // Read MachO message and $otool-lWeChat > ~/Desktop/123.txt // read MachO"cry"Information at the beginning $otool-l WeChat | grep cry
Copy the code

cryptid=0

2. Re-sign the signature

1. Remove PlugIns and.app packages with PlugIns (e.g. Watch, PlugIns)

The normal account cannot sign the plug-in, so it needs to be deleted

Find the Watch and PlugIns folders in the package content path and delete them directly

2. Sign the framework
// Go to FrameWork directory $cdFrameworks // Enumerates current FrameWork $ls // override signature // coDesign-fs"(Certificate Name)"(FrameWork name) $codesign-fs"iPhone Developer: [email protected] (NZJQGFWAYE)" mars.framework
$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" marsbridgenetwork.framework
$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" matrixreport.framework
$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" OpenSSL.framework
$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" ProtobufLite.framework
$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" andromeda.framework
Copy the code

3. Grant executable permissions on MachO

Execute $Chmod +x WeChat in package content path

4. Add a description file

New project, real machine running can get description file

Put the description file in ipA package into the package content of wechat

5. Change the bundid of the application package

Modify info.plist->BundleId in the wechat package content to be consistent with the BundleId in the description file

6. Re-sign the authorization file to the APP package

Review the original description file embedded. Mobileprovision and copy it

$ security cms -Di embedded.mobileprovision

Create a new plist file using Xcode

Open the plist file As code (open As->Source code) and paste the corresponding content

Make a copy and put it in the same directory as the target app

The last step is to sign the app package on the command line

$ codesign -fs "iPhone Developer: [email protected] (NZJQGFWAYE)" --no-strict --entitlements=ent.plist WeChat.app
Copy the code

7. Install the. App package

In Xcode, shift+ CMD +2 displays the mobile phone

Append process with Xcode after app runs

Click “Login” button to print the corresponding information

Here’s one more action — use Xcode to make this a little less tedious

3. The xcode signature

It must be a project with the same name as MachO file (BundId doesn’t matter), otherwise the process is not wechat process

1. Run the APP and install the description file

New WeChat project, same as Command+Run, will describe the file generated

2. Replace the APP package

Copy a new jailbreak package over the original IPA package

3. Delete the plug-in

With this article 2-1

4. Sign the framework

With 2-2 in this paper

5.run

Because Xcode is run directly, you can View the Debug View

Written in the end

Originally wanted to write a little bit more concise, but in order to let the reader of this article have a harvest, I will continue to explain step by step as detailed as possible. I think the purpose of writing blog is half for accumulation, and the other half is to send roses to others, leaving lingering fragrance in hand. I hope that students who have little contact with the principle of re-signature can have a preliminary understanding and even start to operate it