The application encryption feature can effectively increase the difficulty in reverse engineering of application code. However, defending against reverse engineering is a continuous attack-defense confrontation process. Other security hardening measures need to be taken for higher levels of code protection.
Introduction
To protect application code security and your core assets, HarmonyOS provides an end-to-end mechanism to protect the kernel-level application code throughout its lifecycle based on system security.
You can submit an application release request to AppGallery Connect and choose whether to encrypt the uploaded package.
Then the application code will be encrypted by AppGallery Connect after the release request is approved. When the application is installed on a device, the installation file is still protected after being stored on the device, which effectively guards the application. When the application is started, it is decrypted as required.
The system-level application encryption stands out with the following features:
Kernel-level security protection and end-to-end encryption enable applications to be decrypted and executed as required.
System-level decryption optimization has less impact on performance than traditional packing.
Encryption Impact
The encrypted application may slightly increase performance overheads during startup and running.
The encrypted application is larger in size than the unencrypted one and may slightly increase the download and installation time.
The impact of application encryption has been optimized at the system level. In certain enhanced versions, the performance and package size of the application stay nearly the same with or without encryption.
Protection Effect
The application encryption feature protects core assets (for example, .abc files) in the application package. Unencrypted code files can be decompiled. After encryption, the security of the code files is greatly enhanced, increasing the difficulty in reverse engineering.
Procedure
The application encryption feature allows applications to be encrypted in the release process and decrypted on demand at runtime. It enhances application security while minimizing your adaptation work, ensuring a seamless and secure user experience.
Currently, the widgets.abc file of the ArkTS widget service does not support encryption.
The following outlines how the application encryption feature is utilized throughout the application lifecycle:
Development: No special operation is required.
Release: You can determine whether to encrypt the software package to be released.
For details, see Selecting a Package to Be Released.
Distribution: The application is encrypted and distributed in AppGallery Connect to prevent reverse engineering.
Installation: The application code is protected in the installation phase.
Running: The application code is decrypted as required during the runtime.
FAQs
Q1:Are additional code protection measures necessary for the applications safeguarded by the official code encryption feature?
A1: The application encryption feature can effectively increase the difficulty in reverse engineering of application code. However, defending against reverse engineering is a continuous attack-defense confrontation process. Other security hardening measures need to be taken for higher levels of code protection. For example, you can enable the obfuscation capability or third-party security hardening capability.
Q2: What other measures can be used to protect application code if code encryption is not used?
A2: You can enable the obfuscation capability or third-party security hardening capability. For details, see Protecting Application Code..
Q3: What is the impact of code encryption on application packages?
A3: An encrypted application may slightly increase performance overheads during startup and runtime. Compared with an unencrypted application, an encrypted application is larger in size, and may slightly increase the download and installation time.