Author: crazyball

A preface.

For iOS developers, re-signing technology should be relatively familiar, and re-signing scripts are already available on the Internet, and the implementation logic is basically similar, including some excellent re-signing tools like iOS App Signer.

However, because different business scenarios, different certificates and different packages have different re-signing purposes, it is difficult for one tool to meet the needs of all developers. At present, the testing process of the team is to re-sign the game package and then install it on the test equipment for testing. In the daily re-signing and packaging work, it is found that some game packages have some problems after re-signing (cannot be installed, some permissions cannot be used, etc.). However, the package exported from the Xcode Organizer will not be abnormal after the Archive operation is performed with Xcode. Therefore, the -ExportArchive command of XcodeBuild command of Xcode is used to re-sign, and it is found that the success rate of re-signing and package stability are improved a lot.

2. IOS signature mechanism

Before we look at re-signing, let’s look at the signing mechanism of IPA packets

  1. A pair of public and private keys M of asymmetric encryption algorithm are generated in the developer Mac system, and the public key and developer information are generated and sent to the Apple server
  2. Apple has its own public and private key K, where the public key K is stored on every iPhone device and the private key K is stored on Apple servers. Use the private key K to sign and generate the certificate according to the CSR content, and generate the certificate description file (mobileProvision) according to the information (Bundle ID, permissions, etc.) filled in the developer background.
  3. When packaged on the developer device, the description file is packaged into the IPA and the contents of the package are signed using the private key M
  4. When installed on the device, it is verified twice:
    1. Use the public key K on the device to verify the certificate file in the IPA package (the certificate is signed by the Apple private key K) and verify whether the certificate is valid
    2. After the certificate verification succeeds, the system uses the public key M in the certificate to verify the IPA package (the IPA package is signed by the developer’s private key M) and verify whether the IPA package can be installed

Apple uses the above double verification mechanism to ensure the validity of App installation during the development stage. When submitting an App to the App Store, Apple will re-encrypt the signature of the App, and you only need to verify apple’s signature when installing it.

Re-signing script

The re-signature process can be roughly divided into the following five steps. The key commands are listed below:

#! /bin/sh
set -e

#Here is only an overview of the re-signing script
#Basically, it can be divided into the following five steps


#1. Unpack the game package, remove useless contents (.ds_store, __MACOSX, etc.), and modify resources such as info.plist parameters and ICONS if necessaryUnzip "ipa path" - d "target path" find -d "decompression after path" - name. DS_Store - o - name __MACOSX | xargs rm - rf

#2. Re-sign the content to be re-signedFind -d "inclusions path \" -name "*. App" - o \ -name "*. Appex" - o \ -name "*. Framework \" -o -name "*. Dylib" \ | xargs -i {} /usr/bin/coDesign --continue -f -s "Certificate name" {}

#3. Find the bundle ID in appexFind -d "inclusions path" - the name "*. Appex \ | xargs -i {} / usr/libexec/PlistBuddy - c" Print: 'CFBundleIdentifier "{} / Info. The plist

#4. Modify the XCarchive template information
#Copy the. App file to xcarchive's Products/Applications directory
#Modify info. plist and exportoptions. plist package names, certificate names, description file names and other information in xcarchive


#5. Export the IPA packageXcodebuild-exportarchive \ -archivePath "xcarchive path "\ -exportOptionsplist "ExportOptions. Plist path" \ -exportPath "Export path"Copy the code

1. Decompress the IPA and modify the package

  • Delete unwanted files from the package (.ds_store, __MACOSX, etc.)

  • Read and modify the info.plist parameter (Bundle ID, version number, application name, etc.)

  • If necessary, modify icon and other resource files in the package

2. Re-sign the codesign command

This step is a bit different from other re-sign scripts. Take the iOS App Signer logic as an example, copy mobileprovision into the package and rename it embedded. Mobileprovision. And extract Entitlements related parameters as parameters of COdesign to re – sign.

The current flow is as follows: You do not need to manually replace the embedded. Mobileprovision file in the package, because the subsequent Xcodebuild-exportarchive command will automatically replace the embedded. So the codesign command also does not require the — Entitlements parameter.

3. Read the Bundle ID of appex

What is appex? Appex is actually the content in the Plugins directory, which is the Extension of App. Packages of functions such as VPN and notification need to be realized by plug-ins. An appex can be considered a small App (depending on the App to run), so those of you who have developed Extension will know that appex also has a separate certificate, description file and info.plist. So this step will need to read the Bundle ids of all Appex, which will be used for subsequent signatures.

4. Modify xCarchive

According to the xcodebuild-Exportarchive command in the last step, we need to pass an xcarchive path and exportoptions. plist path. (Xcarchive is the Product of Xcode -> Product -> Archive.)

Xcarchive:

  • BCSymbolMaps: THE mapping table generated by Xcode after Symbol Hiding on the BitCode Symbol table will map to the dSYM file.
  • DSYMs: Stores the debug symbols table compiled this time, which is used to symbolically resolve the crash stack.
  • Info.plist: information about Xcarchive
  • Products: Stores the App package (.app) generated by this compilation.
  • SCMBlueprint: If Xcode has versioning enabled (Preferences -> Source Control -> Enable Source Control), the SCMBlueprint folder stores the compiled version Control information. This includes git versions, repositories, branches, and so on.
  • SwiftSupport: If you are in Target’sBuild SettingsOpen theALWAYS_EMBED_SWIFT_STANDARD_LIBRARIESThe standard library files (.dylib) corresponding to the Swift version used for this compilation will be placed in this folder.

First, we need to change the parameters of the info.plist directory, and replace the app file under Products/Applications with the app that needs to be re-signed.

The other exportOptions. plist file is the parameter we need to export the IPA package, which is also one of the products of the export IPA package using Xcode.

The following fields need to be modified in the exportOptions. plist file:

5. Re-sign the ipA and export the IPA

Finally, simply change the contents of the Xcarchive directory and exportoptions. plis to the contents of the package to be re-signed, using the xcodebuild-exportarchive command to re-sign and export the package body.

Four,

There are so many great iOS re-signing scripts out there that most developers can use them. But building ipA packages using Xcodebuild-ExportArchive is clearly the best solution for now if you want to guarantee retry success rates as accurately as Xcode packaging.

The above is our internal use of the re-sign script implementation ideas, in order to facilitate everyone to understand the detailed implementation ideas, xiaobian also wrote a Mac version of the re-sign tool according to this logic, easy to learn at the same time can also directly use. Finally, welcome to use and make suggestions ~~

  • 37iOS/ easy-signer: Mac re-signing tool for iOS App

Five, the reference

  • DanTheMan827/ios-app-signer
  • IOS APP Security 3 — APP re-signing — Gold digging
  • IOS automatic packaging heavy signature export different certificates IPA explore – simple book