HarmonyOS Next でのアプリ作りと静的解析の初歩 - ラック・セキュリティごった煮ブログ

はじめに
HarmonyOS Nextアプリのファイル構成
静的解析
- HAPファイル形式の分析
  - HAPの構造概要
  - module.json の解析
- Ark Bytecodeの逆コンパイル
おわりに

はじめに

どうも、でぃーぴーぶの魚脳です。みなさん、HarmonyOS Nextのことはご存知でしょうか。HarmonyOS Nextは、中国Huaweiが2024年10月22日に発表した独自のOSです。これまでHuawei製品に搭載されてきたHarmonyOSとは異なり、Androidを使用せず、完全に独自のシステムを基盤として開発されています。今回はそのHarmonyOS Next向けの簡単なアプリを作成し、そのファイル形式などの基本情報を紹介します。また、現時点で可能な静的解析の手法についても説明します。

HarmonyOS Nextアプリのファイル構成

まず、簡単なアプリを作成します。現時点では、HarmonyOS Nextのアプリを開発するために専用のIDE「DevEco Studio」*1を使用する必要があります。DevEco Studioは、Android Studioと同じくIntelliJ IDEAをベースとしたIDEで、古いバージョンのAndroid Studioと見た目や機能が非常に似ています。

プロジェクトのフォルダ構成もAndroid Studioと類似しており、チュートリアルに沿って作成したプロジェクトのフォルダ構成は以下のようになります。

├── AppScope
│   └── app.json5
├── entry
│   ├── src
│   │   ├── main
│   │   │   ├── ets
│   │   │   │   ├── entryability
│   │   │   │   ├── entrybackupability
│   │   │   │   └── pages
│   │   │   ├── resources
│   │   │   └── module.json5
│   │   ├── build-profile.json5
│   │   ├── hvigorfile.ts
│   │   ├── obfuscation-rules.txt
│   │   └── oh-package.json5
├── build-profile.json5
├── hvigorfile.ts
├── oh-package.json5
└── oh_modules

ここでは、重要なファイルやフォルダを抜粋して解説します。

app.json5
- HarmonyOSアプリのグローバル設定ファイルで、アプリレベルの設定情報を定義します。Androidの AndroidManifest.xml の <application> タグに相当します。
module.json5
- 各モジュールの設定ファイルで、Abilityの設定情報を定義します。Androidの AndroidManifest.xml の <activity> や <service> タグに相当します。
ets
- Extended TypeScript（ArkTS、拡張子 .ets） のソースコードが配置されるフォルダ。
  - pages 配下にはUI関連の .ets、.html、.css などのファイルが含まれます。
  - ○○ability フォルダには、HarmonyOS Nextの基本コンポーネントである「Ability」に関連するソースコードが格納されます。これはおそらくAndroidのActivityに相当します。
entry
- Android Studioの app フォルダに相当し、主要なソースコードや設定ファイルが含まれます。

静的解析

HAPファイル形式の分析

作成したサンプルアプリ*2はシンプルなもので、2つの画面間を行き来する機能のみを備えています。ビルドの手順もAndroidと似ており、メニューからビルドを選択すると、拡張子 .hap のHAPファイルが生成されます。

HAPの構造概要

HAPファイルは ZIP圧縮ファイル であり、unzip や 7z を使用して解凍すると、その内部構造を確認できます。通常、HAPファイルには以下のようなディレクトリやファイルが含まれます。

├── lib/             # ネイティブライブラリ（.soファイル）
├── ets/             # ArkTS Bytecode（拡張子 .abc）
├── module.json      # モジュール設定情報
├── resources.index  # リソースインデックス
├── pack.info
└── resources/       # リソースファイルを格納

見た目はAndroidアプリの内部構造と似ています。解凍されたアプリには module.json があり、これは AndroidManifest.xml に相当する役割を果たします。中身は app.json5 と module.json5 を統合し、さらにコンパイラ情報などが追加されたものになっています。

また、Androidとは異なり、ets フォルダには .dex ファイルではなく、ArkTSをコンパイルしたバイトコードである .abc ファイルが配置されます。

`module.json` の解析

module.json はHAPファイルの中心的な設定ファイルであり、アプリの基本情報（パッケージ名、権限、エントリーポイントなど）を含みます。

権限の宣言に関して、サンプルアプリでは設定されていませんでしたが、公式ドキュメント*3を参考にmodule.json5への権限宣言を追加してみました。.hapファイルのmodule.jsonにおける権限宣言の該当部分は以下のようになります。

"requestPermissions": [
    {
        "reason": "$string:reason",
        "reasonId": 16777230,
        "usedScene": {
            "abilities": [
                "EntryAbility"
            ],
            "when": "always"
        },
        "name": "ohos.permission.LOCATION"
    }
]

Androidの権限宣言と比較して、より詳細な情報を含んでいることが特徴です。

reason：権限許可をユーザーに要求する際の説明文が記載されます。この仕様はiOSの実装方式に類似しています。
usedScene：権限の適用範囲とタイミングを事前に定義可能です。これにより、宣言した権限を必要とするAbilityが特定のタイミングでのみ利用するように細かく制限でき、最小権限原則の実践形態と言えます。

もう一つ気になるのはHarmonyOS NextにおけるIntent機構の存在です。公式ドキュメント*4によると、Intentに類似する機構は「Want」と呼ばれ、明示的/暗黙的の2種類の起動方法をサポートし、データの受け渡しも可能です。Androidのintent-filterに相当する要素は、module.jsonでは「skill」として設定されます。

Androidでの典型的なIntent設定例：

<activity android:name="ShareActivity" android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
</activity>

これに対応するHarmonyOS Nextの設定例：

{
  "module": {
    "abilities": [
      {
        "name": ".ShareAbility",
        "exported": false,
        "skills": [
          {
            "actions": ["ohos.want.action.sendData"],
            "entities": ["entity.system.default"],
            "uris": [{ "mimeType": "text/plain" }]
          }
        ]
      }
    ]
  }
}

主な対応関係：

abilities要素 ↔ Androidのactivity要素
exportedプロパティ ↔ Androidのandroid:exported 属性
skills設定 ↔ intent-filterブロック
- actions ↔ action要素
- entities ↔ category要素
- uris ↔ data要素

設定形式に若干の差異はあるものの、設定ファイルを対象とした静的解析のアプローチはHarmonyOS Nextにも適用可能と考えられます。特に権限宣言とコンポーネント公開設定の解析方法は、Androidアプリの解析経験を流用できる点が特徴です。

Ark Bytecodeの逆コンパイル

前述の通り、HarmonyOS Nextは ArkTSを主要なプログラミング言語 として採用しており、アプリビルド時にArk Bytecodeにコンパイルされます。

開発ツールのSDKには逆アセンブル用のツールが含まれています(DevEco Studio\sdk\default\openharmony\toolchains\ark_disasm.exe )。それを使用して、解凍した .hap ファイルの ets フォルダにある .abc ファイルを逆アセンブルできます。

以下は、その出力結果の一部です。

.function any &entry.src.main.ets.entryability.EntryAbility&.#~@1>#onCreate(any a0, any a1, any a2, any a3, any a4) <static> {
    mov v0, a0
    mov v1, a1
    mov v2, a2
    mov v3, a3
    mov v4, a4
    lda v2
    sta v10
    lda v10
    ldobjbyname 0x0, "context"
    sta v9
    lda v9
    ldobjbyname 0x2, "getApplicationContext"
    sta v8
    lda v8
    …

また、Ark Bytecode（.abc）を逆コンパイルするオープンソースツールとして abc-decompiler *5があります。これはHarmonyOS Next向けの逆アセンブルツール abcde *6と、JavaのUI型デコンパイルツール jadx を組み合わせたツールです。そのため、最終的にはJavaのコードとしてデコンパイルされます。

ただし、現状では abc-decompiler の解析結果の可読性は低く、文字化けや不自然な文法が散見されます。しかし、前後の文脈を読み取ることで、ある程度元のコードを推測することは可能です。

おわりに

今回は、勢力を拡大しつつあるHarmonyOS Nextアプリの基本的な情報と、現状で可能な静的解析のアプローチについて調査しました。リリースされてまだ日が浅く、これからどんどん発展していく勢いや意気込みがドキュメントなどから垣間見えました。今後、動的解析の手法についても調査し、共有したいと思います。

*1:Introduction-DevEco Studio - HUAWEI Developers(なお、HUAWEI IDの登録が必要)

*2:Building the First ArkTS Application in Stage Model-Quick Start-Getting Started - HUAWEI Developers

*3:module.json5 Configuration File-Application Configuration Files in Stage Model-Development Fundamentals-Getting Started - HUAWEI Developers

*4:Want-ability-Dependent Elements and Definitions-ArkTS APIs-Ability Kit-Application Framework - HUAWEI Developers

*5:GitHub - ohos-decompiler/abc-decompiler

*6:GitHub - Yricky/abcde: openHarmony逆向工具包