HarmonyOS Next 应用加密 安全性分析

发表于 分类于 阅读次数：

HarmonyOS Next支持应用加密，本文尝试分析其安全实现.

Android 加固回顾

在我们熟悉的Android生态中，APK较容易被逆向分析，查看反编译代码. 不少应用为了所谓的“安全性”，通常采用加固/加壳手段，尝试保护自己的代码“不被人看到”.
实际上，客户端程序运行在终端，一定会释放到内存中，而且APK基本不挑设备，什么模拟器、root的设备都可以运行，所以我们看到脱壳方案层出不穷，加固厂商也在不断提升加固手段，运行环境安全性检测，一代二代三代壳、VMP、Java2C，各种新的加固技术也在不断迭代.
也就是说，应用程序如果将自己的安全性，完全寄托在这层壳上，将是巨大的安全隐患，因为这层壳一旦被脱掉，程序将被一览无遗，，，这层壳，不过就是皇帝的新衣罢了. 而且，加固可能对应用带来崩溃、兼容性、性能等负面影响. 对于安全要求较高、纵深防御的应用来说，首先要假设的，便是客户端代码、算法完全暴露在攻击者面前，然后通过安全方案设计，提升应用安全性.
不过话又说回来，加固确实能提升应用程序的逆向难度，挡住不少刚入门的新手，所以，这个猫鼠游戏，还在不断进行.

HarmonyOS Next 应用加密

官网资料

我们从华为开发者官网，可以看到应用加密章节.
为了保护应用代码安全，保护开发者的核心资产，HarmonyOS提供了端到端的应用代码保护机制，该机制以系统安全为基础，构建内核级应用生命周期内的代码安全保护能力.
应用加密

开发者向应用市场提交上架申请，上传应用包后可选择是否加密.
选择加密的应用，在经过应用市场审核后，应用市场会对上架应用做代码加密.
应用在设备上安装时，安装文件落盘后仍是处于加密状态，有效的保护应用程序；
当应用程序启动时，通过内核加载的应用文件是加密状态，因此这些文件会在内核中按需解密执行.

应用加密采用标准AES加密算法，解密后的明文只存在于内存中，不会存储到设备，形成端到端的加密方案，有效的保障应用程序的安全性.

系统级应用加密具有如下优点：

  • 应用端到端加密，应用启动后在内核内按需解密执行.
  • 系统级的解密优化，相对于传统加壳等加固方式对性能的影响更小.
  • 解密密钥经过安全传输后存储在系统TEE环境中，更加安全.

加密效果：
加密对象为应用内编译后的代码文件，覆盖.abc文件，加密前的代码文件可被反编译，加密后的代码文件不可被分析，保障应用代码防逆向分析、防破解.

个人理解

总结下来，华为为应用提供了一套系统级的加固方案:

  • 应用可选加密.
  • 覆盖.abc文件（JS/TS/ArkTS代码，通过方舟编译器，编译为方舟字节码，存放在abc格式的文件中；类比Android apk的Java/Kotlin代码——>dalvik字节码——>dex文件）.
  • 加密算法AES.
  • 下载、落盘的abc文件是密文.
  • 解密密钥经过安全传输，存储在TEE安全环境.
  • 解密过程发生在内核(指鸿蒙/Linux内核?还是指代方舟运行时?).
  • abc明文只存在内存中.

我们可以理解为，这套方案的安全性，依赖于系统的安全性（提权可dump内存、CA可被调用）、TEE环境的安全性（存储明文密钥）.
由于解密能力并没有开源到OpenHarmony，目前也没有非华为设备运行HarmonyOS Next（OpenHarmony+HMS），而且华为新的设备并没有开放解锁BootLoader，因此在当前HarmonyOS Next发布初期这个节点，对应用加密逻辑的分析难度直接buff叠满.
而且，我个人认为，这套方案，极其依赖HarmonyOS Next的生态的封闭性：

  • 商店上架的加密应用，将和商店绑定，密钥需通过HarmonyOS Next应用商店与HarmonyOS Next的TEE环境端到端安全传输，OpenHarmony并没有开源相应能力，因此无法侧载到OpenHarmony;
  • 应用如果上架到其他无加密的应用商店、或者在官网提供OpenHarmony安装包，那么HarmonyOS Next应用商店的加密将被绕过;
  • 希望共享HarmonyOS Next应用生态的厂商，需接入封闭的HMS、并实现与华为终端相同的TEE、加密内核等能力.

同AOSP&GMS类似，接入GMS的应用无法在AOSP运行，AOSP的应用可以在GMS设备运行.
OpenHarmony的生态共享，也是单向的，OpenHarmony的应用，可以通过开发者签名侧载到HarmonyOS Next的设备（或上架商店安装），而接入HMS的应用、接入应用商店加密的应用，无法在OpenHarmony运行.

分析

获取固件

我们通过抓包，不难获取到HarmonyOS Next的固件包，其中主要分析update_full_base.zip这个包.

1
2
3
4
5
6
7
8
9
Mate60 NEXT.0.0.71 beta1
https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/24/v3/fThYWevRQueNuU8HO4XqWw/full/filelist.xml
https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/24/v3/fThYWevRQueNuU8HO4XqWw/full/update_full_base.zip

https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/2d/v3/yFXbndBIQkCMcFJhLHlkXQ/full/filelist.xml
https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/2d/v3/yFXbndBIQkCMcFJhLHlkXQ/full/update_full_cust_BRA-AL00_all_cn.zip

https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/9a/v3/WsDTBim-Ru2ZxOcdTPJtyw/full/filelist.xml
https://update.dbankcdn.com/download/data/pub_13/HWHOTA_hota_900_9/9a/v3/WsDTBim-Ru2ZxOcdTPJtyw/full/update_full_preload_BRA-AL00_all_cn_R8.zip

解包方法也不难.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//下载解包工具
$ git clone https://gitee.com/openharmony/update_packaging_tools.git
$ cd update_packaging_tools
//解压下载到的zip包，update.bin文件将被解压到update_full_base目录
$ unzip update_full_base.zip -d update_full_base
//创建输出目录
$ mkdir out
//python3 venv环境，个人习惯，安装依赖包
$ python3 -m venv venv
$ source venv/bin/activate
$ pip3 install xmltodict cryptography asn1crypto
//执行解包，解包完成后，out/unpack_result_xxxxxx目录下能看到boot.img、system.img等镜像
$ python3 build_update.py out update_full_base -unpack update.bin
$ deactivate

我们通过mount命令，便能看到system中的内容

1
2
3
4
5
6
7
8
9
10
11
12
13
//创建system目录，用于挂载
$ mkdir system
//挂载
$ sudo mount -o ro,loop system.img system
//可以看到我们要分析的应用商店目录存在多个hsp、hap
$ ls system/system/app/AppGallery
BackgroundTaskFramework.hsp  entry.hap             testDistributionLib.hsp
businesslib.hsp              GlobalConfig.hsp      uiextension.hap
commonlib.hsp                OperationManager.hsp  uilib.hsp
DownloadInstall.hsp          ServerRequestKit.hsp
enterpriseapp.hap            service.hap
//拷贝完成你需要的文件，然后就可以卸载system了
$ sudo umount system

抓包

我们通过对应用商店抓包，了解到一些很有意思的信息（已移除部分无用信息）：
按照通常理解，应用有包名、版本号等信息，而在应用商店，应用还有一个很关键的信息，叫做appoid.
从fetchHarmonyFiles获取下载地址的接口 https://store-drcn.hispace.dbankcloud.cn/hwmarket/harmony/client?method=client.fetchHarmonyFiles&ts=，可以拿到如下响应:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
  "rtnCode": 0,
  "rtnDesc": "success",
  "harmonyApps": [
    {
      "pkgName": "com.tencent.wechat",
      "origionSha256": "38c5d1e0731b82d9cbf641fd3d82b9470b5b4494113386be9066b54f1a3200bb",
      "versionCode": 1048614,
      "hapFiles": [
        {
          "filePath": "",
          "packageUrl": "",
          "sha256": "4d960828e8da0921d8936a99e163ecdd27f41dd8669baaced840662dbbcac879",
          "fileSize": 330579568,
          "hapId": "193372d2887346b7907dd80d00a62b1d",
          "fileType": 4,
          "versionCode": 1048614,
          "pkg": "com.tencent.wechat",
          "featureName": "entry",
          "appId": "C5765880207854244859",
          "moduleType": "entry"
        }
      ],
      "appoid": "1e2b570768404e26be3cf5ff754db454"
    }
  ]
}

这个appoid将参与很重要的两个网络请求：
getCloudChallenge
https://store-drcn.hispace.dbankcloud.cn/hwmarket/harmony/client?method=client.getCloudChallenge&ts=

1
2
3
4
5
{
  "ver": "1.1",
  "scene": 0,
  "apps": "[{\"bundleName\":\"com.tencent.wechat\",\"versionCode\":1048614,\"appoid\":\"1e2b570768404e26be3cf5ff754db454\",\"originSha256\":\"38c5d1e0731b82d9cbf641fd3d82b9470b5b4494113386be9066b54f1a3200bb\"}]"
}

拿到成功的响应，会携带cloudChallenge

1
2
3
4
5
6
7
8
9
10
11
{
  "rtnCode": 0,
  "rtnDesc": "success",
  "cloudChallenges": [
    {
      "bundleName": "com.tencent.wechat",
      "cloudChallenge": "0123456789ABCDEF0123456789ABCDEF",
      "type": 0
    }
  ]
}

紧接着的getNegotiationKey请求，就更有意思了，携带了上一个请求拿到的cloudChallenge，来自服务端的挑战，以及设备公钥，设备证书链，签名：
https://store-drcn.hispace.dbankcloud.cn/hwmarket/harmony/client?method=client.getNegotiationKey&ts=

1
2
3
4
5
6
{
  "ver": "1.1",
  "scene": 0,
  "apps": "[{\"bundleName\":\"com.tencent.wechat\",\"versionCode\":1048614,\"appoid\":\"1e2b570768404e26be3cf5ff754db454\",\"cloudChallenge\":\"0123456789ABCDEF0123456789ABCDEF\",\"devicePubKey\":\"==\",\"signature\":\"\"}]",
  "deviceCertChain": "[\"-----BEGIN CERTIFICATE-----\\n=\\n-----END CERTIFICATE-----\",\"-----BEGIN CERTIFICATE-----\\n==\\n-----END CERTIFICATE-----\",\"-----BEGIN CERTIFICATE-----\\n=\\n-----END CERTIFICATE-----\",\"-----BEGIN CERTIFICATE-----\\n==\\n-----END CERTIFICATE-----\"]"
}

这是在干什么呢？通常来说，这是服务端在挑战客户端，发起客户端的设备证明，要求客户端证明自己的合法性，才会吐一些敏感数据回客户端. 经过服务端的一系列验证，拿到如下响应:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "rtnCode": 0,
  "rtnDesc": "SUCCESS",
  "appSecretMetaList": [
    {
      "bundleName": "com.tencent.wechat",
      "versionCode": 1048614,
      "secretMetaInfo": {
        "ver": 1,
        "encMessage": "==",
        "cloudPubKey": "=="
      }
    }
  ]
}

这里的appSecretMetaList、secretMetaInfo，不难猜测，这个信息是应用核心的秘密信息，而cloudPubKey，顾名思义，是服务端的公钥，那encMessage呢，自然而然，则是服务端传给客户端的核心加密数据. 根据我的猜测，可能有着服务端的签名（通过cloudPubKey验签，防篡改），以及与设备公钥关联的安全协议的加密.

而上述用法，实际上就是华为设备证书的设备真实性证明的标准用法，参考设备真实性证明能力简介.

逆向分析应用商店

目前网络上逆向abc（方舟字节码）的工具都还不太成熟，我找到了abcde和基于JADX的abc-decompiler.
由于比较熟悉jadx，所以使用abc-decompiler尝试反编译应用商店.

我们解压system/app/AppGallery/businesslib.hsp，拿到ets/modules.abc，拖到abc-decompiler工具中：
我们跟踪上面的两个请求，发现相关代码：
com.huawei.hmsapp.appgallery.businesslib.ets.utils.DownloadManager.keynegotiation.server.utils.StoreUtils
StoreUtils
com.huawei.hmsapp.appgallery.businesslib.ets.utils.DownloadManager.keynegotiation.tasks.keyNegotiationTask
keyNegotiationTask
keyNegotiationTask
这里会调进NegotiationProxy
com.huawei.hmsapp.appgallery.businesslib.ets.utils.DownloadManager.keynegotiation.proxy.NegotiationProxy
NegotiationProxy
NegotiationProxy
NegotiationProxy这里面很明显是Binder进程间通信，获取”@hms:security.codeProtect”系统服务，调用对应的接口.

难怪，这个security.codeProtect服务属于HMS，不属于OpenHarmony. 这个服务的实现位于

1
2
3
4
5
6
7
8
9
10
11
12
13
//服务实现
/system/lib64/module/hms/security/libcodeprotect_napi.z.so
//服务的init文件，类似于Android中的init.xxx.rc
/system/etc/init/code_protect.cfg
//服务的属性配置文件，类似于Android中的build.prop
/system/etc/param/code_protect.para
//system ability配置
/system/profile/code_protect.json
//相关API、SDK封装的Manager
/system/lib64/libcode_protect_mgr.z.so
/system/lib64/libcode_protect_mgr_sdk.z.so
//所谓CA，是与TEE中运行的TA对应的，CA在HarmonyOS侧，与TEE环境的对应TA通信
/system/lib64/libcode_protect_ca.z.so

从上面的分析来看，基本符合华为开发者官网的表述.
整个密钥的下载过程，用到基于设备证书的设备真实性证明，提供基础的设备安全性保障.
从服务端与APP通信，APP调用hms的security.codeProtect的API，通过binder Proxy，调用到codeprotect的service，再到codeprotect的ca，codeprotect的ta，由此，服务端与TEE建立端到端的安全通信链路.

其他

本文通过常规的技术手段对HarmonyOS进行安全性分析，仅为纯技术探讨，目前的分析也无实质性进展，如果有侵犯您的权益，请联系删除.
希望上面的内容能帮助感兴趣的同学，并且可以开展进一步的安全性分析，欢迎一起进行安全技术探讨.