preface

As iOS developers, we’re all familiar with certificates and description files. We know that they play some role in the process of App installation on the phone, so how do they authenticate our phone? Can we tamper with these things to do something special? 😈

Below we slowly introduce apple’s double signature mechanism and today’s highlight — double signature.

  • Apple’s requirements for App installation on mobile phones.
  • Apple’s dual signature system.
  • Manually re-sign the App.
  • Re-sign the App using a script.

I. Apple’s demand for App installation on mobile phones

Imagine if apps could only be installed through the App Store, and Apple only needed a pair of public and private keys (RSA) to sign the App (the private key on the Apple server, and the public key on the iOS mobile system to verify the signature) to ensure that all apps were installed under their authorization. If the principle of RSA asymmetric encryption and signature don’t understand can look at my front two articles – > RSA encryption | signature principle

It goes on to say that, but in reality, apps are not only installed through the App Store.

  1. Xcode runs the installation.
  2. Adhoc internal test setup.
  3. Enterprise certificate distribution.
  4. Wait…

So what if Apple has to get its own license to install apps in order for these channels to do the same?

Ii. Apple’s double signature mechanism

Schematic diagram of double signature:

Here’s what you need to know before signing

Public and private keys:

  1. Apple server and iPhone have A pair of RSA public and private keys, named public key A and private key A. Apple server keeps private key A, and public key A (the same as all phones) is stored in an unknown space on each iPhone before it leaves the factory.
  2. Each Mac also has a pair of RSA public and private keys named public key M and private key M.

Description file:

The configuration description file is an XML file that contains the following: security policies and restrictions for the device, VPN configuration information, wireless LAN Settings, email and calendar accounts, and authentication credentials that allow iPhone, iPod Touch, and iPad to be used with your enterprise system. Configuration description files can quickly load Settings and authorization information onto the device. Some VPN and WLAN Settings can only be set using configuration description files.

The description file mainly contains the following contents:

  1. The certificate.
  2. The bundle ID of the App.
  3. Udid of the trusted device.
  4. Permission files (e.g., Apple Pay, notifications, VPN, iCloud, etc.)

1. Apply for a certificate through the CSR file

CSR is the English abbreviation of Certificate Signing Request, that is, when the Certificate applicant applies for digital Certificate, the CSP(encryption service provider) generates the private key and the Certificate Request file. As long as the Certificate applicant submits the CSR file to the Certificate authority, The certificate authority uses its root certificate private key signature to generate a certificate public key file, which is the certificate issued to the user.

Simply put, Xcode wraps the Mac’s public key M into a CSR file and sends it to the Apple server. After receiving the CSR file, the Apple server takes out the public key M, uses the private key A saved by the Apple server to digitally sign the public key M, and the certificate is obtained. We then add the certificate to the description file and send it to our Mac. Everything else in the description file is what we fill out on the developer site, and Apple servers can access it directly.

2. Mac pack apps

After the Mac has the description file, we can package the App. The packaging process mainly includes:

  • Compile the project into the executable MachO.
  • Use Mac localThe private key MSign all MachO files. (ALL machos are highlighted because not only projects are compiled into MachO files, but also framework static libraries used in projects have corresponding MachO files.)
  • MachO file, signature file of MachO file and description file are packed and compressed into an. Ipa package.

3. Install the. Ipa package

The ipA package is installed on the iPhone, and the iPhone needs to verify the IPA package to see if it is allowed to open.

  1. Take out the description file, take out the certificate, use the one on your iPhonePublic key ADecrypt the certificate so that it can be obtainedPublic key M.
  2. There are thePublic key M, we can passPublic key MVerify that MachO files have been tampered with and verify the integrity of MachO.
  3. Verify that everything else in the description file is satisfied.
  4. After everything is verified, the iPhone can open the App normally.

That’s how Apple’s double signature works, isn’t it? Everything was just right. It was apple.

Manually re-sign the App

As can be seen from the above principle of double signature, iPhone mainly verifies before opening the app:

  • The bundle ID of the App.
  • Describe the file.
  • The App’s signature.

When the App is uploaded to the App Store, the App Store will encrypt the IPA package you upload once, which is called a shell. Every IPA package downloaded from the App Store comes with this shell. Re-signing requires the use of a cracked IPA, which can be downloaded from some assistants such as Ace’s. (PP assistant no longer supports iOS)

This time, it is wechat 7.0.2, which has been broken into a shell (I use this App purely for learning security knowledge, and will not be used elsewhere 😄). Specific steps:

1. Decompress wechat7.0.2.ipa

Right mouse button wechat7.0.2. ipa select Use Archive Utility to open. Decompress the CD and go to the payload directory in the decompressed folder.

cd~ / Desktop/Wechat7.0.2 / contentCopy the code

2. View the certificate information of App

// Use the command codesign-d -vv WeChat.app
Copy the code

3. Check whether the App is cracked

If we are not sure whether the IPA has been cracked, we can use the command to view the WeChat executable file in WeChat. App:

otool -l WeChat | grep cryp
Copy the code

4. View the local certificate

security find-identity -v -p codesigning
Copy the code

I won’t take screenshots because of privacy concerns. Check your local certificate and use one later when you re-sign. It’s up to you which one you want to use.

5. Delete unsignable items

Some things in the WeChat. App folder cannot be signed, so we delete them. Typical examples are PlugIns and Watch folders (not all apps have them, so don’t worry about them), so let’s just delete them.

6. Re-sign Framework

Find the Frameworks folder in WeChat. App and open it. All Frameworks in it will be re-signed.

Codesign-fs [Certificate name] [file to sign]Copy the code

I won’t take a screenshot when it comes to the certificate name. Note that the “file to sign” in the above command is not the. Framework in the Frameworks folder. For those of you who have known, the essence of the framework is still a folder, and the qr code really needs to be re-signed is the MachO executable file in the framework. Must pay attention to, signed wrong no effect, who stepped on the pit who knows. 😂 😂 😂

Add executable permission to MachO file

MachO is itself an executable file, and generally has executable permissions, which can be added manually just to be safe.

// Check MachO's permission ls-lWeChat // Set permission chmod 755 WeChatCopy the code

8. Re-sign the App

8.1 create a project with the same name as WeChat (WeChat), in order to distinguish the following are called MyWeChat. Select the team where you re-signed the certificate and run it on your phone first.


// Embedded. Mobileprovision Enter the path to the embedded. Mobileprovision file Security cms-d -i embeddedCopy the code

Find the Entitlements field and copy its contents.

<dict> </dict> 

// --no-strict not strict // --entitlements=entitlements. Plist permission file is entitlements. Plist codesign-FS signature certificate --no-strict --entitlements=entitlements.plist WeChat.appCopy the code

The Payload folder is compressed as ipA. Then run the following command:

Zip - ry WeChat. Ipa contentCopy the code

9. Install ipA

There are many ways to install ipA, Xcode, iTunes, etc. After successful installation, there will be two wechat messages on the phone. Bundle IDS are different.

10. The easy way

Does step 8 feel like a hassle? An easier way to do this is to create a project with the same name after performing step 7 above – adding executable permissions to the MachO file, run it on the phone first, and then

Re-sign the App using a script

Do you feel that the simple method in step 10 is easy? Don’t worry, there’s an even easier way to re-sign your App using a script. If we look closely, we can find that the above steps are actually some fixed processes, no matter what App, the steps of re-signing are those, so we can write a script to re-sign.

As for how to write this script, there is no need for us to write, the predecessors have written, you can find it on the Internet, I also attach the script code here:

# ${SRCROOT} this is the directory where the project files are located
TEMP_PATH="${SRCROOT}/Temp"
We will create an APP folder under the project directory in advance and put the IPA package in it
ASSETS_PATH="${SRCROOT}/APP"
# Destination IPA packet path
TARGET_IPA_PATH="${ASSETS_PATH}/*.ipa"
Clear the Temp folder
rm -rf "${SRCROOT}/Temp"
mkdir -p "${SRCROOT}/Temp"

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# 1. Decompress IPA into Temp
unzip -oqq "$TARGET_IPA_PATH" -d "$TEMP_PATH"
Get the path to the unzipped temporary APP
TEMP_APP_PATH=$(set -- "$TEMP_PATH/Payload/"*.app;echo "The $1")
$TEMP_APP_PATH = $TEMP_APP_PATH

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# 2. Copy the extracted. App into the project
# BUILT_PRODUCTS_DIR Path to the APP package generated by the project
# TARGET_NAME Target name
TARGET_APP_PATH="$BUILT_PRODUCTS_DIR/$TARGET_NAME.app"
# echo "app path :$TARGET_APP_PATH"

rm -rf "$TARGET_APP_PATH"
mkdir -p "$TARGET_APP_PATH"
cp -rf "$TEMP_APP_PATH/" "$TARGET_APP_PATH"

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# 3. Delete extension and WatchAPP. Personal certificate cannot sign Extention
rm -rf "$TARGET_APP_PATH/PlugIns"
rm -rf "$TARGET_APP_PATH/Watch"

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# 4. Update the info.plist file CFBundleIdentifier
# Set :"Set: KEY Value"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $PRODUCT_BUNDLE_IDENTIFIER" "$TARGET_APP_PATH/Info.plist"
# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

# 5. Grant execute permissions to MachO files
Get MachO file path
APP_BINARY=`plutil -convert xml1 -o - $TARGET_APP_PATH/Info.plist|grep -A1 Exec|tail -n1|cut -f2 -d\>|cut -f1 -d\ < `# execute permission on
chmod +x "$TARGET_APP_PATH/$APP_BINARY"

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
# 6. Re-sign the third-party FrameWorks
TARGET_APP_FRAMEWORKS_PATH="$TARGET_APP_PATH/Frameworks"
if [ -d "$TARGET_APP_FRAMEWORKS_PATH" ];
then
for FRAMEWORK in "$TARGET_APP_FRAMEWORKS_PATH/"*
do

Sign #
/usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" "$FRAMEWORK"
done
fi

Copy the code

There are comments on the script code, which is more or less the script implementation of our re-signing step above.

Here is a brief introduction to the usage of scripts:

  1. First, create a project at random and name it as you want, not necessarily the same as the App to be re-signed.
  2. Then go to the Targets > Build Phases of the project and click the + sign to add a Run script and copy the above script into the Run script.
  3. Create a folder APP under the root directory of the project, and put the. Ipa package of the APP to be re-signed in this folder, as shown below.

All that’s left is to run the project on your phone.

conclusion

This article mainly introduces the principle of Apple double signature, aiming at this principle, we find the vulnerability of double signature. The bug is that Even though Apple requires every App to be authorized by Apple to run on the iPhone, it still can’t prevent us from replacing the signature of the developer certificate.

Speaking so much, I don’t know if anyone will doubt why to re-signature?

Re-signing is all about having someone else’s code plus our own certificate debug and run on the phone with Apple’s permission. Once we can debug LLDB, we can use a variety of tools and methods to find vulnerabilities in other apps. Through code injection (to be covered in the next article) to achieve the purpose of other people’s App to call our code logic.

twist

Through the process of cracking other people’s code, think about whether your App has the same problem, and then add some protective means to your App to protect your App, which is the ultimate goal. 😄

This paper addresses https://juejin.cn/post/6844904098030944264