鸿蒙应用包基础知识

一、为什么要先理解"应用包"

鸿蒙(HarmonyOS)与传统 Android 的一个显著区别在于:它从设计之初就面向 多设备、多入口、模块化 的场景。这种设计直接体现在它的应用包结构里:

• • 一个应用不一定是一个安装包,而可以由 多个 HAP 组合而成;
• • 资源和代码可以在 编译期静态共享(HAR) 或 运行期动态共享(HSP);
• • 同一个 Bundle 可以根据设备形态(手机、平板、车机、穿戴…)分发不同的模块。

因此,无论是开发还是逆向,看到 .app、.hap、.hsp、.har 这些扩展名,都不能再用"APK = 一个 zip"的旧思路理解它。

下图先给一个整体直觉:鸿蒙应用 = 一个 Bundle ⊃ 多个 Module ⊃ 编译产物 (HAP / HAR / HSP):

二、Bundle / Module / Package:三层概念

鸿蒙的应用打包模型可以分成三层:

可以用一句话概括:一个 Bundle 由若干 Module 组成,每个 Module 编译后是一个 HAP / HAR / HSP。

三、三种核心包格式:HAP、HAR、HSP

1. HAP(Harmony Ability Package)

• • 作用:应用安装和执行的基本单位。
• • 特征:可独立安装、独立运行,内部可以包含 UIAbility、ExtensionAbility、page、资源等。
• • 必需性:每个应用 至少包含一个 HAP(且必须有一个 entry 类型的 HAP)。

2. HAR(Harmony Archive)

• • 作用:静态共享包,编译期 共享代码和资源。
• • 特征:类似 Android 的 AAR——被依赖时,代码会被打到使用方的 HAP / HSP 里。
• • 典型场景:工具类库、UI 组件库、资源包。

3. HSP(Harmony Shared Package)

• • 作用:动态共享包,运行期 共享代码和资源。
• • 特征:多个 HAP 可以共享同一份 HSP,不会被重复打包,降低应用体积。
• • 分类:
• • 应用内 HSP:仅在当前 Bundle 内共享;
• • 应用间 HSP / 集成态 HSP:跨应用共享(需要平台权限,常用于厂商系统组件)。

三者对比记忆:

• • HAP = 可执行单位
• • HAR = 编译期复制
• • HSP = 运行期共享

下图直观展示 HAR / HSP 的差别——HAR 在编译期被"复制"进每个使用方,HSP 则在运行期作为一份共享代码被多个 HAP 共用:

四、Module 类型:entry vs feature vs shared

每个 Module 都要在 module.json5 里声明 type:

一个典型多模块工程的结构可能长这样:

MyApp/├── AppScope/                # 应用级配置│   └── app.json5├── entry/                   # 入口模块(HAP)│   └── src/main/module.json5├── featureA/                # 功能模块(HAP)├── common_har/              # 静态库(HAR)└── shared_hsp/              # 动态库(HSP)

模块依赖关系(以一个常见的电商类 App 为例)可视化:

五、关键配置文件

1. app.json5(应用级)

定义整个 Bundle 共享的属性:

• • bundleName:应用唯一标识符,反域名格式如 com.example.myapp
• • versionCode / versionName
• • 图标、标签、最低 API
• • 国际化、调试标志等

2. module.json5(模块级)

每个 Module 各自一份,描述本模块的:

• • name / type(entry / feature / har / shared)
• • mainElement:UIAbility 入口
• • abilities、extensionAbilities 列表
• • requestPermissions:声明权限
• • deviceTypes:支持的设备形态
• • metadata、dependencies 等

🔍 逆向关注点:module.json5 在编译产物中以 JSON 形式保留,是逆向分析时第一个要看的文件——它告诉你应用有哪些组件、暴露了哪些能力、申请了哪些敏感权限。

3. pack.info

由打包工具自动生成,描述当前 Bundle 由哪些 HAP / HSP 组成,以及每个包的 bundleName、moduleName、deviceType、版本等。安装侧通过它判断分发策略。

六、应用产物形态: .app 与 .hap

它们本质上都是 ZIP 容器,可以直接解包查看。逆向时常用工具有 unzip、官方 app_unpacking_tool,以及社区的 abcde、ohos-decompiler 等。

容器内核心文件:

xxx.hap├── module.json├── pack.info(部分场景)├── ets/                  # 编译后的 ArkTS 字节码(.abc)│   └── modules.abc├── resources/            # 资源├── resources.index       # 资源索引├── libs/                 # so 库(若有 native 代码)└── pack.info             # 打包元信息

把 .app、.hap 容器层级关系画成一张图:

七、ArkTS 字节码: .abc 文件

ArkTS / TS 源码经 方舟编译器(ArkCompiler) 编译后,会变成 .abc(Ark Bytecode)。这是鸿蒙应用最核心的"代码"载体,与 Android 的 dex 类似。

• • 文件位置:常见于 ets/modules.abc、ets/widgets.abc。
• • 解析工具:官方 abc-decoder、社区 abcde、ark_disassembler。
• • 安全意义:逆向时 90% 的精力都在跟 .abc 打交道——找 UIAbility、找 IPC 入口、找加密逻辑。

ArkTS 源码的编译与执行流程:

八、多 HAP 机制(Multi-HAP)

多 HAP 机制是鸿蒙包系统最有特色的设计之一:

1. 1. 解耦发布:一个 Bundle 可以拆成多个 HAP,分别由不同团队维护。
2. 2. 按需加载 / 按设备分发:不同 deviceTypes 的 HAP 可以差异化下发,例如手机版只下手机的 HAP。
3. 3. 共享同一进程上下文:同一应用的多个 HAP 默认运行在同一进程,共享 bundleName 和数据沙箱。

要点:

• • 同一应用的所有 HAP 必须使用同一个证书签名。
• • 同一应用的所有 HAP 必须有相同的 bundleName、versionCode。
• • 入口必须是唯一的 entry HAP;feature HAP 可零或多。

九、签名、安装与运行机制(简述)

1. 签名

• • 鸿蒙采用 应用签名 + Profile(配置文件)双轨机制;
• • Profile 由 AppGallery / 设备厂商签发,绑定 bundleName、能力授权(如系统权限);
• • 没有合法 Profile,即使 HAP 签名有效,也无法在设备上正常安装运行。

2. 安装

• • 安装服务校验签名 → 校验 Profile → 解析 module.json / pack.info → 落盘到沙箱目录;
• • 多 HAP 应用会进行 一致性校验(bundleName、版本、签名一致)。

3. 运行

• • 通过 UIAbility 或 ExtensionAbility 启动;
• • HSP 在运行时按需加载,装载到同一应用沙箱中;
• • ArkTS 字节码由 ArkCompiler 运行时解释 / AOT 执行。

整体安装与启动链路如下:

十、安全研究的"地图"视角

把上面的内容收束到一张安全研究"地图"上:

掌握这套包模型后,后续做组件暴露分析、IPC fuzz、ArkTS 字节码逆向、签名绕过研究等具体题目,就有了统一的坐标系。

最后再用一张"安全研究地图"把攻击面与对应的载体关联起来:

参考

• • 华为官方文档:应用包基础知识(V5)