Net Protector React.exe Download

[Skye Severy]

Encryptionof strings is used to hide the contents of string constants in mobile applications. It is based on a strong cryptographic algorithm with the dynamic keys or White-Box Cryptography. The dynamic keys are calculated during the work of the protected application based on many parameters (context-sensitive), and they can't be extracted from the application's code. As a result, if the code is decompiled, the contents of strings will be hidden and will be inaccessible for static analysis and decryption.

DexProtector allows you to encrypt entire classes.dex including Application, Activities, ContentProviders, Receivers. It also supports multidex configurations (Enterprise version only). Classes protected by this function are encrypted and moved from all original classes.dex files (common storage of all classes of an application in the APK-file). Thus they become "invisible" to APK-file decompiling tools, for example: apktool, dex2jar.

Note: Decryption of classes is an expensive operation. We recommend to use this feature for all your critical classes where you have valuable logic, and other sensitive things you want to hide from third eyes. As the decryption operation takes time, having all the classes encrypted may lead to significant performance impact. But you can easily avoid it by adding only critical classes to the filter, or excluding insensitive. For example, it is not necessary to have open source, or uncritical classes encrypted.

Hiding of method calls allows protecting the critical places of an application from the analysis and modification. This mechanism masks the calls of library methods and application methods with the dynamic functions constructed in a special way. It also hides field types and accesses to fields.

Note: It is recommended using this function only for classes which logic must be protected from analysis and modification, for example, work with the license, mechanism of In-App purchases, etc.

Note: This technique allows you to hide Google API calls or third-party API calls you use in your project, it hides calls to methods with use of our native 'invokedynamic' engine, so that it is almost impossible to decompile protected code, and to figure out which method is going to be called in a certain place. It is also a part of our anti-decompiler technique.

Note: With the use of this function you can easily encrypt an application's internal resources, WebView resources (html, js, css), Cordova/PhoneGap resources (html, js, css). DexProtector Enterprise also supports encryption of game engines resources, video and audio resources, and allows you to access the encrypted resources from external applications.

Integrity control, or tamper resistance is a mandatory part of the protection DexProtector provides and it is turned on automatically; it prevents the protected APK-file from modification. DexProtector Enterprise allows you to manually configure the integrity control function: enable/disable the certificate check. It also allows you to fire a notification of any kind if the application has been tampered with. Still, the low-level integrity checks are performed first. If they are bypassed, which is barely possible, a notification will be fired.

In order to configure the Callback, it is needed to set two methods: the first one will be called when the application has been tampered with. The second one will be called when the integrity checks have passed successfully. These methods should have public static modifier and (Object data) signature.

DexProtector Enterprise allows you to securely and transparently protect your Android applications that use HTTPS communication against MITM attacks (Man-in-the-middle). It is not needed to modify the source code and implement SSL Pinning / HPKP (HTTP Public Key Pinning) manually. The following components and frameworks are supported: WebView, Cordova/PhoneGap, Http/sURLConnection.

In order to perform all the checks, DexProtector Enterprise uses a clean room implementation of getting a server SSL certificate chain and performing its validation. It is important to highlight that OpenSSL and Android Security API are not used in these processes, thus your application will be resistive to attacks aimed to bypass HTTPS certificate validation: modification of OpenSSL, replacing/adding forged CA certificates into TrustStore, replacing TrustManager in Android Security API, imposition of a forget certificate chain when Android Security API is used.

DexProtector Enterprise supports the standard approach of configuring SSL Pinning/HTTP Public Key Pinning - Network Security Configuration, which is available for Android N (see details here) What is crucial, DexProtector Enterprise works with a standard configuration and it works for all the Android versions that are supported by DexProtector, not only for Android N.

An important measure of fighting against MITM-attacks is monitoring of checks that are being executed on HTTPS certificates and HTTPS connections. For that purpose the Reporting Pin Validation Failure mechanism was implemented in DexProtector Enterprise - RFC7469 - Public Key Pinning Extension for HTTP (see details here). If an anomaly is detected the module that is injected into your application could send reports in JSON format to a server that is set in your configuration.

The Probe setting requires a method that has android.content.Context as a parameter. The function that collects and processes environment/device data will be automatically embedded in the beginning of the method.

In order to configure the Callback it is needed to set two methods: the first one will be called when the check has been successful, for example the Root Detection detected that the device was rooted. The second one will be called when the check was unsuccessful, i.e. the Root Detection did not find that the device was rooted. These methods should have public static modifier and (Object data) signature. Depending on the types of checks the required data will be passed as data parameter.

In order to eliminate the negative performance impact, it is needed to consider which classes/strings and resources should be protected. The set of classes/resources that should be protected can be specified with the help of a filter (filter format). If you need more detailed adjustment, for example, protection of class methods or individual fields, you can use the annotations mechanism (annotations). We recommend to set filters for classes where you have sensitive strings for String Encryption, classes where you have valuable logic - Class Encryption and Hide Access, and add filters for valuable resources in the assets folder. And we would also recommend to exclude all the open source libraries.

If no filters specified, DexProtector protects all the strings in all the classes (String Encryption), all the classes and method calls, fields (removes types) and field accesses in all the classes (Class Encryption, Hide Access), encrypts resources (Resource Encryption).

There is a reference configuration file dexprotector.xml in the root folderof the distribution kit. It has exclusions for widespread open source libraries. String Encryption, Class Encryption and Hide Access are enabled in this configuration. If you do not have your own configuration yet, we recommend to start with the reference configuration and then add settings that are relevant to your Android applications.

As an input, DexProtector receives an application APK/AAB-file or Android Library AAR-file. An output is the protected APK/AAB-file, and protected AAR-file respectively. The output APK can be signed in the Debug mode (it is intended for debugging in the emulator), Release mode, or None - the signing can be postponed, for example for Platform/Vendor signed applications. The settings can be specified either in the external configuration file (format) if you use DexProtector via the CLI or its plugins, or in the DexProtector Studio.

In the APK/AAB protection mode DexProtector automatically finds places inside of the Dalvik bytecode where to put its protection initialisation methods, this is achieved owing to the fact that DexProtector works with a final application and its lifecycle is known. There is a special initialization mechanism for AARs, please see Configuration file format and Protecting Android Libraries sections.

Note: You should have a valid license activation code in order to get DexProtector working in full or trial mode. If you do not have a license activation code, please either get a trial activation code, or purchase your DexProtector license(s).

To get a fully functional activation code, purchase the required number of licenses. In this case, registration is obligatory. Your email will be registered automatically during the purchasing process. Further instructions (how to set your password and so on) will be sent to the specified email address.

When purchasing the product via FastSpring, the activation codes are sent within 24 hours after the funds are received. If a contract is signed with a company, the activation codes are sent after the cash receipt to account or after a copy of a payment order is submitted.

The activation codes are single-use. It means that in case the original license file was lost, or if the hardware or software configuration was changed, you have to contact the customer support to get a new code.

Note: DexProtector supports two activation methods: online and offline. If you have an active Internet connection, you may use online activation. Otherwise, if you do not have Internet connection, or if it is limited by various traffic filter systems, you should use offline activation. In this case it is necessary to generate an activation request code using CLI or GUI (Command Line or Dexprotector Studio), and send it to dexpro...@licelus.com via email. You can do it from another computer or a device which has an active Internet connection.

3a8082e126