Maybe everyone is born thinking that the world exists only for him, and when he finds out that he is wrong, he begins to grow up
If you avoid detours, you will miss the scenery. Anyway, thanks for the experience
Notice of transfer publishing platform: new articles will no longer be published on the CSDN blog, please move to Knowledge Planet
Thank you for your attention and support to my CSDN blog, but I have decided not to publish new articles here. In order to provide you with better services and more in-depth exchanges, I have opened a knowledge planet, which will provide more in-depth and practical technical articles. These articles will be more valuable and can help you better solve practical problems. question. Looking forward to you joining my knowledge planet, let us grow and progress together
The Android security paid column is updated for a long time. For the latest content of this article, please go to:
0x01 APK application signature abnormal detection method
To install the APK on Android, it must be digitally signed. The digital signature is used to verify the identity of the owner of the application update. The purpose of the verification is to prevent the APK application from being tampered with or modifying the APK to contain malicious code.
When signing the APK, a public key certificate is attached, which associates the APK application with the developer and the developer's private key
Note : When building an application in debug mode, the Android SDK will use a debug key specially created for debugging purposes to sign the APK application we want to package. It should be noted that applications signed with the debug key will not be included in most APKs. Accepted and allowed in the app store
The final release version of the application (the live production version) must be signed with a valid release key. In Android Studio, APK can sign the APK of the application manually or by creating a signing configuration assigned to the release build type
On Android prior to Android 9 (API level 28), all app updates need to be signed with the same certificate, so developers can consider using a validity period of 25 years or longer
Note : Note that apps published on Google Play must be signed with a key whose expiration date ends after October 22, 2033
Three APK signature schemes:
- v1 scheme: JAR signing
- v2 scheme: APK Signature Scheme v2
- v3 scheme: APK Signature Scheme v3
Compared with the v1 scheme, the v2 signature supported by Android 7.0 (API level 24) and higher versions provides higher security and performance. V3 signing, supported by Android 9 (API level 28) and above, enables apps to change their signing key as part of an APK update, this feature guarantees compatibility and app compatibility by allowing both new/old keys to be used continuous availability. It should be noted that for each signature scheme, the release APK version should always be signed by the previously internally evaluated scheme
When doing static analysis (of course, dynamic analysis is the same as this, export the APK and use the jarsigner or apksigner tool to verify whether the APK signature is abnormal) APK, we need to confirm several important information, such as the release version of the APK is Android 7.0 (API level 24) and higher v1 and v2 schemes and all three schemes of Android 9 (API level 28) and higher, and the signing certificate in the APK application belongs to the developer
We can use the apksigner tool provided in revision 24.0.3 and later of the Android SDK build tools to sign the APK and ensure that the signature of the APK can be successfully verified on all versions of the Android platform supported by the APK, here we are Mainly use the apksigner tool to verify whether the signature of the APK belongs to the correct developer, and the location of the apksigner tool is here [SDK-Path] /build-tools/[版本]. It is located [SDKPath]/build-tools/[version], for more details, please go to: https://developer.android.com/studio/command-line/apksigner?hl=zh-cn#usage
We can use the apksigner tool to verify the signature of the APK. The default installation location of apksigner is under: C:\Users\xxx\AppData\Local\Android\Sdk\build-tools\33.0.0\lib, and then execute the following command:
$ java -jar C:\Users\xxx\AppData\Local\Android\Sdk\build-tools\33.0.0\lib\apksigner.jar verify --verbose vuls.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Of course, we can also use the jarsigner tool to check the content of the APK's signature certificate, but we need to pay attention to the Common Name (CN) property to be set to "Android Debug" when debugging the certificate
The output of the APK signed with the debug certificate. Here we use the jarsigner tool that comes with JAVA to do the signature. The command for how to sign is as follows:
$ jarsigner -verify -verbose -certs vuls.apk
sm 14112 Fri Nov 30 00:00:00 CST 1979 AndroidManifest.xml
>>> 签名者
X.509, C=US, O=Android, CN=Android Debug
[证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
sm 6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.core_runtime.version
>>> 签名者
X.509, C=US, O=Android, CN=Android Debug
[证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
sm 6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.lifecycle_livedata-core.version
（... ...此处省略一堆内容）
>>> 签名者
X.509, C=US, O=Android, CN=Android Debug
[证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
s = 已验证签名
m = 在清单中列出条目
k = 在密钥库中至少找到了一个证书
i = 在身份作用域内至少找到了一个证书
- 由 "C=US, O=Android, CN=Android Debug" 签名
摘要算法: SHA1 (弱)
签名算法: SHA1withRSA (弱), 1024 位密钥 (弱)
jar 已验证。
警告:
此 jar 包含其证书链无效的条目。原因: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
此 jar 包含其签名者证书为自签名证书的条目。
SHA1 摘要算法被视为存在安全风险。此算法将在未来的更新中被禁用。
SHA1withRSA 签名算法被视为存在安全风险。此算法将在未来的更新中被禁用。
RSA 签名密钥的密钥大小 1024 被视为存在安全风险。此密钥大小将在未来的更新中被禁用。
此 jar 包含的签名没有时间戳。如果没有时间戳, 则在其中任一签名者证书到期 (最早为 2048-05-29) 之后, 用户可能无法验证此 jar。
签名者证书将于 2048-05-29 到期。
You can see above that there are many "CertPath not validated" errors. This error is only available in Java SDK 7 and above. If you want to ignore this error, we can use the Android SDK build tool revision 24.0.3 and above. The apksigner tool provided is to sign the APK instead of the jarsigner tool that comes with JAVA JDK to verify the certificate chain of the APK, as follows:
- Check that the APK's signature can be validated on all Android platforms supported by the APK:
$ apksigner verify vuls.apk
- Check that the APK's signature can be validated on Android 4.0.3 (API level 15) and higher:
$ apksigner verify --min-sdk-version 15 vuls.apk
In addition, the signing configuration Android Studiocan build.gradlebe managed through the signingConfig block in or . To activate both v1 and v2 and v3 schemes, the following values must be set:
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true
In the official Android developer documentation, several best practices for configuring application releases are provided
Android Studio Signature Version V1/ V2：
- V1 (jar Signature)
- V1: Jar Signature comes from JDK, the signed file can be properly modified and recompressed
- V1 signatures do not protect certain parts of the APK, such as ZIP metadata. The APK verifier needs to process a large number of untrusted (not yet verified) data structures, and then discards data that is not protected by the signature. This results in a sizable attack surface. Also, the APK verifier has to decompress all compressed entries, which takes more time and memory. To solve these problems, APK Signature Scheme v2 was introduced in Android 7.0
- V2 (
Full APK Signature)- V2: A new signature scheme introduced by Android 7.0 (Nougat), which cannot make any modifications to the signed APK, including re-decompression. Since it is signed for bytes, any changes will affect the final result
- V3
- V3: In Android 9, the v2 scheme was updated to the v3 scheme (also known as v2+) to include additional information in the signature block, but otherwise works the same, the scheme hashes the contents of the APK processing and signing, and then inserting the resulting "APK Signature Chunk" into the APK
For details of the APK signature scheme, please refer to the introduction on the Android official website: https://source.android.com/docs/security/apksigning?hl=zh-cn
Only check the v1 signature and all models can be used. If you only check the V2 signature, models below 7.0 will be displayed as not installed after the direct installation. Models 7.0 and above use V2 to verify the successful installation, and check V1 and V2 is successfully installed for all models, or modified in the Gradle file, as follows:
signingConfigs {
debug {
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true
}
release {
v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true
}
}
Let's talk about why we recommend using v1 and v2 together? Because the "Janus" vulnerability announced by Google in 2020 allows attackers to attach Dex to the original apk, bypass signature verification, and give priority to executing the attached dex file during execution. This vulnerability directly affects Android 5.0~8.0all Based on signature scheme V1signed APK. Here, the signature is indeed unique for the APK application. It is used to prove whether the APK is a pirated or malicious APK. Signatures can be installed on Android, and various APK application stores and mobile application assistant tools on the market often use the package name and signature to determine whether an APK application is a pirated or malicious APK application.
Note : In the official Android developer documentation, the official provides several ways to configure application publishing. For details, please move to: https://developer.android.com/studio/publish/preparing#publishing-configure
Reference link :
https://www.cnblogs.com/daemon369/p/3227309.html
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md
https://support.google.com/googleplay/android-developer/answer/9848633?hl=zh-Hans
https://blog.csdn.net/beyond702/article/details/56281068
https://www.jianshu.com/p/271474cd1d91
You think you have many paths to choose, but you only have one path to take