OpenHarmony CTF arkts+ezAPP_And_SERVER 详细解析<\/h1>

一、题目概述<\/h2>

这是一个关于鸿蒙(HarmonyOS)应用程序分析的CTF题目，包含两部分内容：<\/p>

arkts部分 - 分析鸿蒙hap文件中的加密逻辑<\/li>

ezAPP_And_SERVER部分 - 分析应用程序与服务器交互的认证机制<\/li> <\/ol>

二、鸿蒙应用程序分析基础<\/h2>

1. HAP文件结构<\/h3>

HAP文件是鸿蒙应用程序包，类似于Android的APK<\/li>
本质上是ZIP格式，可以直接解压<\/li>

核心代码位于

task_4\ets\modules.abc<\/code>中<\/li>
<\/ul>
2. ABC文件解析<\/h3>

ABC文件是"ArkCompiler Bytecode"(方舟编译器字节码)的缩写<\/li>
是鸿蒙应用源代码经过ArkCompiler编译后生成的字节码文件<\/li>
类似于Java的.class文件或Android的DEX文件<\/li>
可以使用abcdecompiler<\/code>工具反编译(基于jadx开发)<\/li>
<\/ul>
三、arkts部分详细解析<\/h2>
1. 主函数分析<\/h3>

主函数逻辑位于pages<\/code>下的index<\/code>文件<\/li>
定义了多个属性，包括加密函数enc<\/code><\/li>
<\/ul>
2. 加密函数分析<\/h3>
enc<\/code>函数使用了多种加密和编码方式：<\/p>

RC4加密(被魔改过)<\/li>
RSA加密(单字节加密)<\/li>
Base64编码(自定义码表)<\/li>
<\/ol>
(1) RC4加密分析<\/h4>
两个关键点：<\/strong><\/p>

密钥有伪装 - 不是声明时的初始值，在页面展示时会重新赋值<\/li>
算法被魔改 - 包括S盒生成和加密操作<\/li>
<\/ol>
S盒生成魔改：<\/strong><\/p>

正常RC4的S盒生成中，交换前的计算部分i<\/code>和i3<\/code>的位置互换了<\/li>
<\/ul>
加密计算魔改：<\/strong><\/p>

原本的异或(XOR)操作变成了加法(ADD)<\/li>
<\/ul>
自定义RC4解密代码示例：<\/strong><\/p>
def<\/span> custom_rc4_decrypt<\/span>(data, key):
<\/span><\/span>    # 实现魔改后的RC4解密逻辑<\/span>
<\/span><\/span>    # 注意S盒生成和加密计算的修改<\/span>
<\/span><\/span>    ...<\/span>
<\/span><\/span><\/code><\/pre>(2) RSA加密分析<\/h4>

单字节加密 - 对RC4加密结果逐个字节进行RSA加密<\/li>
密钥是小整数，容易分析<\/li>
题目中N=75067<\/li>
使用factordb分解：75067=271*277<\/li>
计算私钥进行解密<\/li>
<\/ul>
(3) Base64编码<\/h4>

使用自定义码表<\/li>
需要从代码中提取实际的码表<\/li>
<\/ul>
四、ezAPP_And_SERVER部分详细解析<\/h2>
1. 服务器接口分析<\/h3>

直接访问会返回Error<\/li>
真实路由隐藏在代码中<\/li>
需要分析common\/Utils<\/code>中的代码<\/li>
<\/ul>
2. 请求认证机制<\/h3>
请求需要两个关键Header：<\/p>

Authorization<\/code> - JWT令牌<\/li>
X-Sign<\/code> - 签名<\/li>
<\/ol>
3. 加密字符串分析<\/h3>

代码中存在多个加密字符串<\/li>
加密方式为简单的异或(XOR)<\/li>
密钥在代码中可见<\/li>
<\/ul>
解密示例：<\/strong><\/p>
def<\/span> xor_decrypt<\/span>(ciphertext, key):
<\/span><\/span>    return<\/span> bytes([c ^<\/span> key[i %<\/span> len(key)] for<\/span> i, c in<\/span> enumerate(ciphertext)])
<\/span><\/span><\/code><\/pre>4. 接口发现<\/h3>
通过解密得到两个关键接口：<\/p>

\/api\/v1\/getflag<\/code> - 获取flag的接口<\/li>
\/api\/v1\/contacts?uid=<\/code> - 查询联系人接口<\/li>
<\/ol>
5. JWT令牌生成<\/h3>

需要分析Authorization<\/code>参数的生成逻辑<\/li>
是标准的JWT令牌<\/li>
包含三部分：header、payload和signature<\/li>
<\/ul>
关键点：<\/strong><\/p>

payload中的uid<\/code>是动态传入的<\/li>
可以从UserList<\/code>文件中获取多个uid<\/code><\/li>
需要解密JWT的Secret<\/code>密钥<\/li>
<\/ol>
JWT生成代码示例：<\/strong><\/p>
import<\/span> jwt
<\/span><\/span>
<\/span><\/span>secret =<\/span> "解密得到的密钥"<\/span>
<\/span><\/span>payload =<\/span> {"uid"<\/span>: "admin的uid"<\/span>}
<\/span><\/span>token =<\/span> jwt.<\/span>encode(payload, secret, algorithm=<\/span>"HS256"<\/span>)
<\/span><\/span><\/code><\/pre>6. X-Sign生成逻辑<\/h3>

使用RSA2048加密{"action":"getflag"}<\/code>字符串<\/li>
将加密结果作为data<\/code>字段的值<\/li>
对整个JSON对象进行MD5哈希<\/li>
哈希结果作为X-Sign<\/code><\/li>
<\/ol>
关键点：<\/strong><\/p>

RSA公钥可以从代码中的一大串数据获取<\/li>
需要构造完整的请求：

Header包含Authorization<\/code>和X-Sign<\/code><\/li>
POST请求的body包含RSA加密后的data<\/code><\/li>
<\/ul>
<\/li>
<\/ul>
五、解题步骤总结<\/h2>
arkts部分：<\/h3>

解压HAP文件，获取modules.abc<\/code><\/li>
使用abcdecompiler<\/code>反编译<\/li>
分析enc<\/code>函数中的加密逻辑<\/li>
实现魔改RC4解密<\/li>
分解RSA的N，计算私钥解密<\/li>
使用自定义Base64码表解码<\/li>
<\/ol>
ezAPP_And_SERVER部分：<\/h3>

解压HAP文件并反编译<\/li>
解密所有加密字符串，发现隐藏接口<\/li>
从UserList<\/code>获取uid<\/code>列表<\/li>
解密JWT的Secret<\/code>密钥<\/li>
为每个uid<\/code>生成JWT令牌，尝试获取admin权限<\/li>
分析RSA公钥，构造X-Sign<\/code><\/li>
发送完整请求获取flag<\/li>
<\/ol>
六、工具准备<\/h2>

abcdecompiler<\/code> - 反编译鸿蒙ABC文件<\/li>
JWT调试工具 - 生成和验证JWT令牌<\/li>
RSA计算工具 - 分解N、计算私钥<\/li>
编程环境(Python等) - 实现各种解密算法<\/li>
<\/ol>
七、注意事项<\/h2>

注意RC4算法的魔改部分<\/li>
确保JWT的uid<\/code>尝试完整<\/li>
X-Sign<\/code>的生成步骤不能遗漏任何一步<\/li>
请求的Header和Body格式要完全正确<\/li>
<\/ol>

OpenHarmony CTF arkts+ezAPP_And_SERVER 详细解析<\/h1>

二、鸿蒙应用程序分析基础<\/h2>

三、arkts部分详细解析<\/h2>

四、ezAPP_And_SERVER部分详细解析<\/h2>

五、解题步骤总结<\/h2>

七、注意事项<\/h2> 注意RC4算法的魔改部分<\/li> 确保JWT的uid<\/code>尝试完整<\/li> X-Sign<\/code>的生成步骤不能遗漏任何一步<\/li> 请求的Header和Body格式要完全正确<\/li> <\/ol>

七、注意事项<\/h2>

注意RC4算法的魔改部分<\/li>
确保JWT的`uid<\/code>尝试完整<\/li>`
`X-Sign<\/code>的生成步骤不能遗漏任何一步<\/li>`
`请求的Header和Body格式要完全正确<\/li> <\/ol>`