Frequently Asked Questions
Android App Defender
About app signature
About re-signing after reinforcement
The difference in functionality between the three different versions of Reinforcement
- html/js code protected apps (suitable for cross-platform frameworks like Phonegap, RN, Cordova, etc.)
- Apps with game protection requirements (suitable for frameworks like Xamarin, Flutter, u3d-mono, cocos2dx, c#, lua).
- Normal live apps that balance compatibility and performance.
- Apps with so protection requirements;
- (non-HTML /js code) with resource encryption requirements;
- Need to be on the Google Store;
- Apps with anti-injection, anti-emulator, anti-open, and anti-root requirements.
- If the so to be protected is in the lib folder of apk, give the full file name, for example:
- If you need to protect the so in the assets folder, then give a full path, such as:
assets/so/armeabi - v7a/libabcdef.so
The effect of reinforcement on volume
In the following table, the inclusion size analysis before and after reinforcement for APKs of different sizes in standard version shows that the increment of reinforcement volume is almost negligible.Due to the operations such as log clearing and inclusion compression, the inclusion will become smaller after the reinforcement.
|Increment (%)/volume (M)||<50m||(50, 100m]||(100, 300m]|
Requirements that cannot be met by reinforcement:
android reinforcement other frequently asked questions
[INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]
AndroidManifest.XMLin the Application, remove
iOS App Defender
What is Bitcode?
Bitcode is an intermediate representation in the process of source code being compiled into binary machine code, which is neither source code nor machine code.When Bitcode is enabled, Bitcode is embedded in the binaries that Xcode compiles.Apple introduced the Bitcode mechanism in Xcode7 and turned it on by default. By submitting an ipa containing Bitcode, Apple can use Bitcode to optimize or compile applications for new products or technologies after they are released without developer involvement.
Our reinforcement technology is based on Bitcode for processing, so we need to open Bitcode for packaging. Without Bitcode, we can not perform reinforcement.
You can use the following command to verify whether the binary file in the xcarchive package contains Bitcode. If the output of
segname __LLVM appears, it indicates that Bitcode exists; otherwise, it indicates that there is no Bitcode.
$ otool -arch arm64 -l path_to/xxx.xcarchive/Products/Applications/xxx.app/xxx | grep LLVM
After open Bitcode package failed
The reason is that bitcode is not enabled in the library file that the project relies on
- If the library file with an error has the corresponding source code (developed by yourself or introduced by a third-party library such as Pod, and corresponding source code and Target exist in Xcode), you can find the Target in the above way and open bitcode
- If the library file is a compiled binary file provided by a third party (without source code), you need to contact the third party to provide a version that includes Bitcode. You can also use our iOS reinforcement aid to force it to be enabled.
-weak_library and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) is displayed, it cannot be used together
Other Linker Flagsand change it to the form
-weak-lxxx, For example, change
If enable bitcode is set to yes for all targets, there is still no bitcode in the xcarchive package
-fembed-bitcode=all, then re-archive and to make sure that the xcarchive package contains bitcode.
The effect of reinforcement on volume
A: Different reinforcement parameters will bring about different volume changes, and the same reinforcement configuration on different code is uncertain, depending on the complexity of the code itself.The following is the statistical value based on historical samples, the statistical object is the main program in the APP (excluding bitcode), and the file path is:
Path_to_archive. Xcarchive/Products/Applications/AppName app/AppName, the results are for reference only.
Calculation method: Main program size after reinforcement/main program size before reinforcement (excluding bitcode)
|Type||Volume growth multiplier|
|Base version (limit 30%)||1.1 to 1.5|
|Standard Edition (simple confusion)||1.3 to 1.7|
|Standard Edition (Common confusion)||1.3 to 2.0|
|Standard Edition (Strong Obfuscation)||1.5 to 2.4|
|Professional Edition (full features turned on)||1.4 to 2.6|
After reinforcementthe size of code segments in the main program may exceed the limits of AppStore. For details,see the official documentation of AppStore Connect. Set reinforcement parameters as required.
The reinforcement aid cannot be opened
- If the message "From an unidentified developer" is displayed, please refer to Apple's official instructions to open the application from an unidentified developer
- If the message "File corrupted" is displayed, open System Preferences -> Security & Privacy -> General -> Allow Apps downloaded from the following locations, select Any Source, and try again
- If there is no "any source", run
sudo spctl --master-disablein your terminal first and try again
- If it still does not open, download the auxiliary tool again and unzip it to another path
The Bitcode format is not recognized
Bitcode generated by a third party compiler is not recognized by Apple. Submitting bitcode in the AppStore with Bitcode enabled will be rejected with the message "Invalid Bundle" displayed. However, it does not matter if you do not enable bitcode to commit.
(1) The first case is that ollvm and other third-party compiler toolchains are used to compile the entire project. In this case, you can switch back to the default toolchain built in Xcode.
(2) The second reason is that the project integrates a third-party SDK(static library) compiled by unofficial compilers like ollvm (Apple LLVM). In case of this problem, you can use the following solution to skip the processing of third-party SDK during reinforcement
If there are two third-party SDKS that have this problem, their names are
SDK.framework, and they are stored on the Desktop in the directory
- Back up the original SDK by yourself
- Execute the following command on the terminal to remove the bitcode from the SDK
$ xcrun bitcode_strip -r ~/Desktop/libSDK.a -o ~/Desktop/libSDK.a
$ xcrun bitcode_strip -r ~/Desktop/SDK.framework/SDK -o ~/Desktop/SDK.framework/SDK
- Use our iOS reinforcement aid to force bitcode on for the above SDKS
- Replace the third party SDK used in the project with the SDK processed further above
- Pack and harden it as normal
- For the business interface that needs to be protected, embed the sliding verification code on the page, and the user will get a security token after sliding successfully. The business interface needs to carry the token to the background for token security verification, and then continue the business process after the verification is passed.
- Take login as an example, the business interface without access to the verification code:
Interface: http://domain/login Parameters: User name, password
- Now in the login page access verification code, the user swipes, will get a security token Service interface after access:
Interface: http://domain/login Parameters: User name, password, and security token
- Intelligent insensitive mode: The system will conduct non-inductive model verification to the server according to the collected environment device information, which usually includes device model detection (detecting whether it is a simulator or there is malicious information tampering, etc.), abnormal association detection (detecting whether there is abnormal association, such as device multi-IP association in a short time, multiple verification in a short time, etc.). If the user passes the insensitive model verification, it can be verified without the need for sliding verification.
- Strong verification mode: The user is forced to complete the verification before passing each pass. It is generally recommended that the user select this mode in some business links requiring high verification requirements, such as registration, obtaining SMS verification code and so on.
- About mode switching: Access customers can independently select the required verification mode under the application configuration according to their actual needs.
It is the phase of fingerprint collection and reporting. Due to the slow call to the link card, the interface returns a timeout. The fingerprint sender encrypts the reported data as a temporary token, which is called a degraded token.The web and mobile terminals support the degraded token, but the applet side does not. The degraded token has a long length and can be passed to the back end normally for fingerprint analysis.
The degraded state refers to the current degraded state. If the network is normal after the next call to getToken() and the last degraded state is found, the data will be collected again and submitted to the fingerprint server of the device to obtain the normal token.
If the mobile sdk or web side integrates device fingerprint, degraded token will be generated when the network is not good, that is, the length of token will be very long, and the fingerprint can be resolved.First, if you fail to obtain the token, check the front-end logic and determine whether to capture the degraded token and send it to the back-end for verification.Note Do not customize the token; otherwise, the device fingerprint cannot be resolved. Small program does not degrade token logic, network exception or access error will not get the token.
If the token is empty, check the following
- Check whether the network is connected and whether services can be requested
- Check whether the appid is correct
- Check whether the wrong interface is requested, web side -/c1, mobile side -/m1, applet side -/w1
First confirm whether it is the correct fingerprint token.The normal token length is 40 bits, and the fingerprint can be resolved.
If the token length is 41 bits, the following reasons may be caused
- Failure to integrate js. For example, the private service integrates Saas js
- The token obtained by c1 interface of web side and w1 interface of wechat side is directly requested, but not collected and reported through js
- Messages are lost or wrong for some reasons, and the server cannot decrypt them, which may be caused by js compilation by the client framework or affected by the device environment.If the get request message is too long and the message is lost, the solution is that the front-end supports the post request. Other forged tokens or service custom tokens cannot resolve fingerprints.
I/libjdi sdk init cache failed, if yes, please check whether the assets file of SDK is integrated.
android.os.Process.killProcess(android.os.Process.myPid())way to exit the app will be stuck. Need to close all the activity to perform
Cleartext HTTP traffic to xxx not permitted
unsupported architectures [x86_64, i386],
Building for iOS Simulator, but the linked and embedded framework 'DXRisk.framework' was built for iOS + iOS Simulator.
Validate Workspacein the project configuration to
Yes, and then recompile