Frequently Asked Questions

A: Signature is a mechanism used to identify app developers and ensure the integrity of apk. Google requires every app to have a signature.

A: The reinforcement function prevents secondary packaging. You need to advance the original signature of the apk for verifying the correctness of the signature after reinforcement.

A: After reinforcement, the original signature of apk will be damaged. Therefore, you need to re-sign the signature. Otherwise, the installation cannot be completed.

A: If they are not the same, the reinforcement anti-secondary packaging function is triggered and cannot work properly.

A: The Basic version includes a minimum level of app protection and is available for one free trials. There is no manual after-sales service to fix problems.

A: The standard version includes dex overall protection, java code virtualization, anti-dump, anti-debugging, anti-repackaging, code tamper-proof, no trial support, support for manual post-sale problem solving.

A: The following situations can be solved by using the standard version:

• 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.

A: Professional can be used in the following situations:

• 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.

A: List all important classes that require special protection, for example: com.android.app.Activity.

A: Give the protection list according to the following rules:

• If the so to be protected is in the lib folder of apk, give the full file name, for example:libabcdef.so.
• If you need to protect the so in the assets folder, then give a full path, such as:assets/so/x86 /libabcdef.so,assets/so/armeabi - v7a/libabcdef.so

A: No

A: No

A: The reinforcement does not support anti-packet capture

A: reinforcement does not support anti-external hanging

A: Currently, dex039 only supports machines running Android 9.0. Its universality is too poor, so the reinforcement is not supported at present.If this app needs to be hardened, please turn down the minsdk version in the androidstudio project.

A: Please make sure that all functions of the app are normal before reinforcement. If the app crashes only after reinforcement, report it to the after-sales service and ask technical personnel to handle it.

A: The reinforcement report contains the description of all enabled protection functions and detection methods.You can follow the steps in the report to verify whether the protection function is effective.

A: reinforcement does not change the app call stack.

A: AndroidManifest.XML in the Application, removeextractNativeLibs="false" or addandroid:extractNativeLibs="true"

A:

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

A:

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.

A: Find a configuration like-weak_library /usr/lib/libxxx.dylib inOther Linker Flags and change it to the form-weak-lxxx, For example, change-weak_library /usr/lib/libstdc++.dylib to-weak-lstdc++

A:

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 arelibSDK.a and SDK.framework, and they are stored on the Desktop in the directory~/Desktop

• 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

A: The token is returned in two cases: size=40 The risk control background generates the token. If size>40 is used to generate the token locally.Both tokens are valid tokens and can be used for services.

A: In a non-risk environment, the token has a local cache in the SDK. Generally, the duration is 24 hours.In a risk-free environment, the device requests the back-end to obtain the latest token.

A: A fingerprint is a unique device identifier that exists only on the back-end server.A token is a timeliness product of the communication between the client and the back-end. The device fingerprint corresponding to the token can be obtained through the Server API.

A:

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.

A:

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

A:

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.

A: The first fingerprint request is no data collection request. It depends on whether there is cache in the request header. If the first fingerprint request is returned as empty, a second request for data collection is automatically initiated, and the token is cached in the request.

A: Check whether the assets file is integrated and whether the confusion configuration is correct. If the log displays:I/libjdi sdk init cache failed, if yes, please check whether the assets file of SDK is integrated.

A: directly use theandroid.os.Process.killProcess(android.os.Process.myPid())way to exit the app will be stuck. Need to close all the activity to performandroid.os.Process.killProcess(android.os.Process.myPid()).

A: please in AndroidManifest Application new add:android:usesCleartextTraffic="true"

A: You can configureparams.put("PRIVATE_CLEAR_TOKEN", "clear");

A: As shown below: Please configure the corresponding shelving script. For the access script, see "Configuration Packaging Script" in the access document:

A: Please use the web version Script for processing. In Build Phases, please place the Run Script after the Copy Files to run

A: Modify the Validate Workspace in the project configuration to Yes, and then recompile