This is the fourth day of my participation in Gwen Challenge

Recently, I met some contents related to IPA re-signature in my work, so I checked some information on the Internet.

This article only describes the common iOS re-signature tools and operations, excluding the RSA encryption principle and the knowledge of using public and private keys to verify certificate signatures.

There are two main types of re-signature:

Full resignature

The information about the certificate, Mobileprovision, and Bundle ID is the same. The effect of using Xcode is the same. Advantages: The validity period and stability are the same as using Xcode for signature; Disadvantages: High maintenance cost. Each re-signed IPA must change the Bundle ID and match the corresponding signing certificate and mobileprovision description file. Scope of application: signature stability requirements;

Incomplete re-signature

Ensure that the certificate and Mobileprovision are consistent, regardless of whether they are consistent with the Bundle ID of the original IPA. Advantages: Looks easy to maintain; Disadvantages: Only the original IPA signature is replaced, the signature file and the Bundle ID are matched, so it is easy to fail verification and the signature is invalid, so it needs to be re-signed. The stability is not high, so use with caution! Scope of application: stability requirements are not high;

Re-signing knowledge & tools and steps for re-signing in two ways

Before introducing how to re-sign, let’s take a look at the iOS signature mechanism and what it does

The purpose of the signature mechanism

Before iOS came out, developing and running software on the mainstream operating systems (Mac/Windows/Linux) did not require a signature, and software could be downloaded from anywhere. As a result, the platform was difficult to control third-party software and piracy was prevalent. Apple hopes to solve this problem. It has absolute control over third-party apps on the iOS platform. It must ensure that every APP installed on iOS is officially approved by Apple. Through the signature mechanism.

Implementation of signature mechanism

Say to the realization of signature mechanism, will have to carry all kinds of certificates, mobileprovision, Entitlements, CertificateSigningRequest, p12, AppID these conceptual things every out is need a large space, Here we briefly describe how they work together to implement ipA signature functions.

IOS signature main use of the certificate and mobileprovision these two files and other documents (CertificateSigningRequest, AppID) is to generate the two files, or the two files in derivative file (P12, Entitlements), When signing code, will certificate file signature information, mobileprovision written together, at the same time in order to control other permissions of APP, Xcode will generate Entitlements file, Entitlements these files, resources and code will eventually be exported in the form of IPA file; The final signature is essentially the result of encrypting the HASH value of the IPA using the public key

Some problems can also be seen by unpacking the ipA file structure:

  1. Resource files: such as images, HTML, etc.

  2. CodeSignature/CodeResources: this is a file, the text view are available, and the content is in the package (not including Frameworks) all documents signed. Notice all the files here. This means that once your program is signed, nothing in it can be changed, including the resource file and the executable itself. IOS checks these signatures;

  3. Executable: This file needs to be signed just like a resource file;

  4. Mobileprovision: This file verifies the certificate file and Bundle ID and is generated from the Apple Developer Center.

  5. Frameworks: Nonnative Frameworks that an application references. Each of these Frameworks is an app, and should have the same structure as an app, including the CodeResources file for the signature message

    These files are combined to implement the signature function of ipA.

### Understand the principle of signature, let’s understand the iOS system to verify the validity of the signature process, only understand this process can better re-signature

  • Procedure for the iOS system to verify the validity of a signature

  1. Unpack the ipa;
  2. Take out embedded. Mobileprovision and verify whether it has been tampered with the signature.
  3. Verify the signatures of all files, including Frameworks;
  4. Verify that the authorized device complies with the information in embedded. Mobileprovision.
  5. Check whether the BundleId in info. plist matches the information in embedded. Mobileprovision.

Now that we know how to sign and validate signatures, we’re ready to re-sign

Re-signature implementation

Since signing is implemented by both the certificate and Mobileprovision, re-signing is the process of replacing the old file with the new certificate and Mobileprovision. However, the system also randomly verifies the authorized device list and Bundle ID when verifying the validity of the app. Therefore, you must change the Bundle ID to be consistent with the information in the new Mobileprovision. Otherwise, the verification may fail. Complete re-signature is the use of complete replacement, so in the face of Apple’s legitimacy verification, there will be no problem; Incomplete re-signature because the Bundle ID verification is ignored, the signature is unstable and easy to verify, but the signature fails!

This section describes how to re-sign a signature

Full resignature

Full re-signing is now available with many tools, such asFastlaneIn theresignFeatures, here is a more lightweight GUI tooliReSign, the use is very simple, a picture can explain.

Note: When selecting the re-signed description file and re-signed certificate file, it must be matched. At the same time, it must check the modify ID and change the App ID to be consistent with the App ID in the re-signed description file, remember!

Incomplete re-signature

Partial re-signing requires the use of an older tool iOS_resign_scripts which provides three re-signing scripts, but in my personal practice only. The third method is valid, the first two scripts can not implement the re-sign function… Methods:

  1. Put the iOS_RESign_WITH_IPA script and ipA and Mobileprovision used in the re-signing process in the same directory.
  2. Execute the script in the folder directory
$sh ios_resign_with_ipa $source_ipa_file $Developer_code_sign $mobileprovision $target_app_related_path
Copy the code

Source_ipa_file: ipA name to be re-signed.

Target_app_related_path: ipA name generated after re-signing;

$Developer_code_sign: the name of the certificate used to re-sign;

$Mobileprovision: description file name used for re-signing

Example:

$sh  ios_resign_with_ipa Testerhome.ipa "iPhone Developer: hengjie chen (XXXXXXXX)" embedded.mobileprovision Testerhome-resigned.ipa
Copy the code

The above two re-signature tools have their own advantages and disadvantages, and need to be adopted according to the specific situation.