A first look at app security on HarmonyOS NEXT

HarmonyOS is an operating system developed by Huawei that runs on their smartphones, tablets, smart TVs, smart watches, wireless routers, IoT devices, and personal computers. It was released in 2019 and was initially based on code from the Android Open Source Project (AOSP). It also included a kernel abstraction layer that enabled it to run both the Linux and LiteOS kernel, depending on how powerful the device it was running on was. Initially, it was also able to run unmodified Android apps in addition to native HarmonyOS apps.

However, with Huawei trying to become independent of Western influence in their products, the architecture of HarmonyOS was changed. In 2024, Huawei released HarmonyOS 5.0, which is also called Harmony OS NEXT. In this version, Huawei has switched to their own kernel (HongMeng) and has removed all AOSP code from the operating system, which also meant that support for running Android apps was removed. Since then, HarmonyOS only runs native HarmonyOS apps. Some parts of HarmonyOS have been open-sourced in a project called OpenHarmony, but large parts remain proprietary.

Our products currently support the Android and iOS mobile platforms and since HarmonyOS NEXT seems to be a new up-and-coming platform, we did an initial technical analysis to determine if it is feasible and useful to protect Harmony OS NEXT apps. This analysis is based on public information as well as an analysis of version 5.0.5.310 of the IDE used to develop Harmony OS apps (DevEco Studio) and a device running Harmony OS Next (Huawei Mate 60). It has to be noted that getting access to DevEco Studio and installing Harmony OS Next on the Huawei Mate 60 is only possible from mainland China and with a Chinese Identity Card. This makes it very difficult for Western companies to do any kind of analysis of or development for HarmonyOS NEXT.

Operating System internals

The HongMeng kernel is a micro kernel developed my Huawei. The basic idea behind micro kernels is that only a minimal amount of code runs in kernel space. Everything else is implemented in user-space. The main advantage of this approach is that the attack surface is greatly reduced and that potentially expensive switches between user-space and kernel-space are avoided whenever possible. The following diagram shows this architecture.

Image source: https://www.usenix.org/conference/osdi24/presentation/chen-haibo 

The HongMeng kernel is closed source and we were unfortunately not able to get access to a binary image because the device we have does not give us access to the kernel binary. However, Huawei has publicly presented details about their kernel here. The probably most important take-away for us is probably that the they have a “ABI-compliant shim” which translates Linux syscalls. Also, interestingly, there seem to be so called “Driver Containers”, which enables HongMeng to load Linux drivers instead of Huawei having to re-write existing drivers for HongMeng.

Image source: https://www.usenix.org/conference/osdi24/presentation/chen-haibo 

Looking at HarmonyOS from user-space, we see that it looks and feels very similar to Linux. The libc implementation is a fork of musl libc, which was written for Linux. It implements wrappers for all the syscalls that you would find on Linux. This is possible because of the “ABI-compliant shim” that Huawei has implemented. Musl also includes a (pretty basic) dynamic linker implementation and the linker and libc are merged into one single library (ld-musl-aarch64.so.1).

The HongMeng kernel also exposes the /proc filesystem like Linux does, so we have access to files like /proc/self/maps and /proc/self/status. One interesting detail is that they seem to be installing two seccomp filters by default (vs. only one on Android). We have not looked into dumping them though. It is also noticeable that the (SELinux based) sandbox that the shell is put in is very strict and makes it very hard to get interesting information about the system. In many cases, it is easier to write an app that gathers information than doing it from the shell.

Huawei also has implemented their own filesystems that are used in HarmonyOS (EROFS and HMDFS). They have implemented their adb alternative called OpenHarmony Device Connector (HDC) and adb support was dropped in Harmony OS NEXT. It provides similar functionality to adb, but the interface is completely different. The logging functionality is called hilog and provides logcat like output. Harmony OS does not have system properties like Android, but it has something comparable that they call “parameters.”

Apps

Apps are launched by a process called appspawn which we haven’t looked into yet but which seems to be Huawei’s version of Zygote.

Apps are written using an IDE called DevEco Studio, which is very similar to Android Studio. It uses a build system called Hvigor, which seems similar to Gradle, but it’s written in TypeScript.

Apps are typically written in ArkTS (see below), but can also contain native C/C++ code, which gets compiled to standard ELF shared objects. Huawei has also recently announced their own language called Cangjie, which is supposed to co-exist with ArkTS. The compiler for Cangjie seems to be based on LLVM and compiles Cangjie to native binaries. More information about Cangjie as well as the Cangjie compiler can be found here.

Apps are implemented around the concept of “Abilities”. An ability is “an abstract form of a functionality that an application can provide”. There are two types of Abilities: - Feature Abilities (FA): These are also called “pages” that are used to provide the capability of interacting with users and are pretty much equivalent to Activities on Android. - Particle Abilities (PA): Can either be “Services” or “Data” and are pretty much equivalent to Services and Content Providers on Android.

Apps are distributed as files with the extension .app. Each app contains one or more HarmonyOS Ability Packages (HAP), which is a ZIP file with the extension .hap.

Looking at a hello world app (that also includes native code), we can see these files included in the resulting HAP file:

			module.json
resources.index
libs/arm64-v8a/libentry.so
libs/arm64-v8a/libc++_shared.so
resources/base/profile/main_pages.json
resources/base/profile/backup_config.json
resources/base/media/app_icon.png
resources/base/media/layered_image.json
resources/base/media/background.png
resources/base/media/startIcon.png
resources/base/media/foreground.png
ets/modules.abc
pack.info
		

The interesting parts are the files in ets/, which contain the compiled ArkTS code of the app. Then there is also libs/arm64-v8a/, which contains the native libraries. Lastly, there is a file called module.json, which is the HarmonyOS equivalent of AndroidManifest.xml.

The ArkTS runtime (see below) provides NAPI interfaces that enable ArkTS code to interact with native code (and vice versa), similar to JNI on Android. Below is a simple example:

			#include "hilog/log.h"
#include "napi/native_api.h"

static napi_value Test(napi_env env, napi_callback_info info) {
    OH_LOG_Print(LOG_APP, LOG_INFO, LOG_DOMAIN, "Test", "Called!");
    return NULL;
}

EXTERN_C_START static napi_value Init(napi_env env, napi_value exports) {
    napi_property_descriptor desc[] = {
        { "test", nullptr, Test, nullptr, nullptr, nullptr, napi_default, nullptr }
    };
    napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc);
    return exports;
}

EXTERN_C_END static napi_module demoModule = {
    .nm_version = 1,
    .nm_flags = 0,
    .nm_filename = nullptr,
    .nm_register_func = Init,
    .nm_modname = "entry",
    .nm_priv = ((void*)0),
    .reserved = { 0 },
};

extern "C" __attribute__((constructor)) void RegisterEntryModule(void) {
    napi_module_register(&demoModule);
}
		

The graphical parts of apps are typically developed using a declarative user interface framework called ArkUI and there is also a cross-platform framework called ArkUI-X that additionally supports Android and iOS.

Like on Android, apps are sandboxed and can request additional permissions that are declared in module.json.

Unsurprisingly, HarmonyOS apps need to be signed. This is done using a tool called hap-sign-tool.jar, which is similar to apksigner. The tool is open source and the code can be found here. From a quick look at the tool, signing seems to work similar to Android’s version 2/3 signature scheme in that the signing information is embedded into the ZIP file just before the central directory. When it comes to code signing, Huawei seems to go into a similar direction as Apple. HarmonyOS devices require apps to be signed with a certificate that is part of a valid certificate chain that that goes back to Huawei’s root certificate. In order to have Huawei provide developers with such a certificate, developers need register (unlike with Apple, there is no fee involved). The certificate chain of the developer certificate that we got looks like this:

			Subject: CN="<Developer Name>(<Developer ID>)\\,Development", OU=<Developer ID>, O=<Developer Name>, C=HK
Subject: CN=Huawei CBG Developer Relations CA G2 DRA, OU=HSHK, O=HSHK, C=CN
Subject: CN=Huawei CBG Root CA G2, OU=Huawei CBG, O=Huawei, C=CN
		

HarmonyOS apps are distributed through the Huawei App Gallery store. It is unclear if Huawei would allow other app stores, but it seems quite unlikely. It also looks like side-loading is only possible with certificates that Huawei has provisioned. All in all, it looks like Huawei is going for a rather closed system, similar to iOS.

ArkTS

The main programming language to build HarmonyOS apps (at least until Cangjie becomes more popular) is ArkTS. ArkTS uses TypeScript syntax, but it is ahead-of-time compiled into binary bytecode that is executed by the ArkTS runtime.

The file format that contains the ArkTS bytecode is called PANDA and the files typically have the extension .abc. The format of these files is documented here and the bytecode instructions are documented here.

Interestingly, the HarmonyOS SDK also comes with a disassembler for these files, which is called ark_disasm. It converts .abc files into a text format, that has the .pa extension. Some version of the disassembler is open source and can be found here.

That project also includes an assembler that can convert .pa files into .abc files. It does not seem to be shipped with the HarmonyOS SDK. The open source versions of the assembler and disassembler does not seem to be able to process files produced by the latest HarmonyOS SDK. We did not investigate this mismatch further but tools like these would be very interesting for investigating the repackaging of HarmonyOS apps (both from an attacker and protector perspective).

We can test the disassembler on some example method that looks like this:

			export default class EntryAbility extends UIAbility {
    test(): void {
        hilog.info(0x0000, "Test", "Hello World!");
    }
};
		

The disassembled code looks like this:

			.function any &entry.src.main.ets.entryability.EntryAbility&.#~@0>#test(any a0, any a1, any a2) <static> {
	mov v0, a0
	mov v1, a1
	mov v2, a2
	ldexternalmodulevar 0x2
	throw.undefinedifholewithname "hilog"
	sta v5
	lda v5
	ldobjbyname 0x0, "info"
	sta v4
	ldai 0x0
	sta v6
	lda.str "Test"
	sta v7
	lda.str "Hello World!"
	sta v8
	lda v4
	callthis3 0x2, v5, v6, v7, v8
	ldundefined
	returnundefined
}
		

There is also a third party open source decompiler for ArkTS bytecode called dayu, which can be found here. Unfortunately, it was not able to decompile files produced by the latest HarmonyOS SDK.

The HarmonyOS build system also includes a tool called ArkGuard, which is similar to ProGuard in that it is able to obfuscate names during compilation. It is specifically not intended to do other types of obfuscation, but Huawei also provides the possibility to integrate so called transformation libraries implemented by third parties that get invoked during compilation and can apply further obfuscations. More details can be found here.

Threats

When it comes to determining whether or not it makes sense to protect apps on HarmonyOS, it is important to evaluate how common threats that are well known on other platforms translate to HarmonyOS. Since we have very limited access to the HarmonyOS system and resources, there are still a lot of unanswered questions that we hope to answer in the future. If you have answers to these questions or want to work with us to investigate them further, we would be happy if you got in contact with us.

Pretty much all modern operating systems adopt a variation of sandboxing to prevent apps from accessing each other’s resources as well as from modifications of vital parts of the operating system. To be able to execute a large number of attacks, a mechanism that allows to escape these sandboxes is needed (e.g. rooting on Android and jailbreaking on iOS).

As far as we are aware, no device that can run HarmonyOS allows unlocking their bootloader. This prevents rooting the device by modifying the stock firmware, e.g. like Magisk/KernelSU/APatch does. This makes rooting difficult and the Magisk developers have decided not to support HarmonyOS. We are not aware of any exploits that can unlock the bootloader of HarmonyOS devices, and we are also not aware of any tools that support rooting HarmonyOS devicNes if there was a way to unlock the bootloader somehow.

Also, getting root access using a privilege escalation exploit is rather difficult because attackers would need to focus on the (still rather unpopular) HongMeng kernel and since it uses a micro kernel architecture, the attack surface is also greatly reduced. For now, it looks like getting root access on HarmonyOS is not something that seems to possible anytime soon. This also means that attacks that require root access (e.g. dynamic code injection and hooking) are not viable either until this is the case.

To make it easy to develop HarmonyOS apps, Huawei supplies developers with emulators that can be used to test and debug apps. However, these emulators are still in beta testing and it is currently not possible to register for the beta program. Emulators typically allow more access to the system compared to physical devices or since they are running software, they can be patched to allow elevated access, like root permissions. Having access to an emulator would give us the possibility to evaluate the viability of different attacks much like a rooted device would.

For HarmonyOS emulators, the process of obtaining root is described here. The author of this article also published the patched Windows version of the emulator on Github which requires running the emulator on a physical Windows computer. This emulator image is for the x86_64 architecture and as far as we are aware, HongMeng does not support x86_64. Because of that, the emulator image seems to be using the Linux kernel and might therefore differ from a real HarmonyOS device running on the arm64 architecture and the HongMeng kernel. In order to assess the potential of using emulators to gain deeper insights into both the viability of attacks on the HarmonyOS platform and the system’s inner workings, we will need to wait for access to an arm64-based emulator.

Debugging is a popular way to analyze an app to understand how it works and also potentially to perform runtime manipulations. It is still an open question whether root access is required for debugging applications on HarmonyOS NEXT. Both ArkTS and native code can be debugged from DevEco Studio on a non-rooted device when the app is signed with a debug certificate. We currently do not know if this is also possible with apps that have been published to the Huawei App Gallery. There is no need for such apps to be debuggable and it would only open up the platform for security issues. So it is very likely that Huawei has adapted a similar model to Apple on iOS where it is possible to debug apps that are signed for debugging purposes, but not possible for apps that have been deployed through an app store.

When it comes to static analysis, we already know that the development environment is applying basic obfuscation to ArkTS apps and there is a decompiler and disassembler that can be used to analyze apps statically. However, in order to analyze apps, an attacker would first need to obtain a copy of the app they want to analyze. This has been a problem for attackers on iOS for a long time. Access to iOS apps is not possible on non-jailbroken devices, and in addition, apps that are deployed through the App Store are encrypted.

On HarmonyOS, we see a similar problem: since non-rooted HarmonyOS devices are heavily sandboxed, it seems like there is no way to extract installed apps from them. It might be possible to write similar tools to ipatool on iOS that allow direct access to the App Store. But we are not aware of any efforts to do that on HarmonyOS yet. Furthermore, it is unknown whether apps that are distributed via the Huawei App Gallery are encrypted like on iOS. Until a way to obtain apps on HarmonyOS is found, static protections of apps are less relevant. But since it is possible that ways to obtain apps are found at any point in the future, it still makes sense to add static protections to HarmonyOS apps that require it.

Similarly, while it seems like Huawei is providing tools needed to repackage HarmonyOS apps (though some of them do not seem to work with files produced by the latest HarmonyOS SDK), it does not seem like it is a viable attack at the moment because access to interesting apps might be restricted. In addition to that, Huawei seems to take a similar restrictive approach to Apple when it comes to sideloading. This also complicates the deployment of repackaged apps and makes repackaging attacks less attractive.

In addition to those threats, there are also high-level attacks that do not require root access and that are (ab)using standard functionality of the operating system. This is especially interesting on Android, where malware is notorious for abusing operating system functionality like accessibility services, third-party keyboards, screenshots, screen mirroring, and overlays to perform UI based attacks. We have not investigated that area yet, but it would be an interesting area to explore to determine how effective malware on HarmonyOS would be.