OpenHarmony Security Debt Across Reimplementation

Overview

This series examines whether OpenHarmony's independent implementation also changed the security assumptions associated with Android-like mobile-system roles. It follows a portable audit from 450 publications to 116 selected studies and 56 design-level vulnerabilities, then maps comparable capabilities and tests them on stock OpenHarmony 4.1 and 5.1. The reported results—46 applicable cases and 24 vulnerable, including 17 fully and seven partially—show conditional design transfer, not code reuse or a platform-wide verdict. Across permissions, IPC, sensors, shared files, lifecycles, and defaults, the series explains how to retest trust boundaries across releases and where the evidence remains bounded.

Learning outcomes

Different code does not guarantee different security assumptions; comparable roles can preserve the same trust decisions.
Of 56 selected Android DLVs, 46 applied to OpenHarmony; 24 remained vulnerable, 17 fully and seven partially.
The findings concern stock OpenHarmony 4.1 and 5.1 on OHarmPi, not every release or related product.
Secure reimplementation requires role mapping, alternate-interface review, safe defaults, and release-specific retesting.

Keywords

OpenHarmonyreimplementationAndroidDLVspermissionsIPCsensorsBluetoothlifecyclesdefaults

Chapters

OpenHarmony's Inherited Security Debt

Why new code can preserve old trust decisions

11 min · Why new code can preserve old trust decisions

11 min

OpenHarmony Want Receiver Hijacking

Why action matching is not endpoint authorization

12 min · Why action matching is not endpoint authorization

12 min

OpenHarmony's Android DLV Transfer Audit

From selected literature to release-specific tests

10 min · From selected literature to release-specific tests

10 min

What Transfers Between OpenHarmony and Android?

Roles can match even when code does not

12 min · Roles can match even when code does not

12 min

OpenHarmony AccessToken Permission Gaps

Why one protected API is not enough

12 min · Why one protected API is not enough

12 min

OpenHarmony's High-Fidelity Attack Surfaces

How raw signals become inference and control

12 min · How raw signals become inference and control

12 min

OpenHarmony's Security Defaults Over Time

Why fixes must follow releases and state

12 min · Why fixes must follow releases and state

12 min

OpenHarmony Reimplementation Security Test

How to preserve invariants across releases

11 min · How to preserve invariants across releases

11 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

Can a new operating system inherit Android's security vulnerabilities?

Yes. OpenHarmony reproduced some historical Android design-level vulnerabilities where analogous features preserved the same trust decisions.

How many Android design-level vulnerabilities were found in OpenHarmony?

Of 56 selected Android DLVs, 46 were applicable to OpenHarmony and 24 remained vulnerable—17 fully and seven partially.

Does the study show that OpenHarmony is just Android?

No. Code comparisons supported independent implementation, while role-level similarities still allowed some historical design weaknesses to recur.

What are the limits of the OpenHarmony security findings?

They come from stock OpenHarmony 4.1 and 5.1 on OHarmPi and do not certify every release; a later HarmonyOS NEXT check confirmed 20 of 24 findings, while four could not be evaluated.