样本信息：
文件名 Phigros_4.0.0.apks
样本来源 Google Play
包名 com.PigeonGames.Phigros
版本 4.0.0(155)
SHA-256 b62d3d1a6fe9b0a834b47222b730c13d250ebe421dfc72cee3a1a47281ca7f76

〇、我真的是穷怕了

Phigros，我从小玩到大的音游，也在最近迎来了主线最终章。

讲真，这么一款陪了自己好几年的游戏突然完结了，心里总是有点空空的。

依稀记得很久之前，Data 不够用之时，我都是直接去改游戏存档，来给自己拿足够解锁歌曲的 Data。

（现在我真的没有改了，没事打歌攒出来的 10 个多 GB 的 Data 够我用到天荒地老了）

时过境迁，现在的存档怎么样了呢？

也许该去探望一下这位老朋友了。

一、旧地重游，物是人非

Phigros 作为一款 Unity 开发的游戏，根据 Unity 官方文档 的介绍，Android 端默认位置是在 /data/data/<包名>/shared_prefs/<包名>.v2.playerprefs.xml。

回到这个熟悉的地方，果然这位老朋友还在那里静静的等着我。

满心欢喜地打开这位老朋友，眼前的景象却让我感到陌生：

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="RAxss7MtEi68v2JOObh1mg%3D%3D">84nt4CDG41fhF5EXHkVpow%3D%3D</string>
    <string name="xaHiFItVgoS6CBFNHTR2%2BA%3D%3D">84nt4CDG41fhF5EXHkVpow%3D%3D</string>
    <string name="Cgw4SttKwRFIjb68TF8z5EC%2FLwVpK8KjKmjcm9T3M78%3D">%2Bpyf2R4Qt4zJE6UG3UUydn0ltWNFpXzVDKoi8cnw5gWJGqNfIK4bx8bwl8iZ4y%2Fe</string>
    <string name="RF7IYRhPKOOGn7Qea60lKexh7u7Uqrzkqc1fw%2FiLFYE%3D">Nj0hx6%2B2z%2BpWeORt16R4VMepzdKiDJCP%2FQavEe2O%2BHTm2IFSUZugJjoTcLQL4XnT</string>
...

很明显，这是加密了。

二、见其心性，窥见其心

Phigros 是一款本地游戏，存档的加解密肯定是在本地进行。

但我之前只听说过这是一款 Unity 游戏，详细的技术细节我从未了解。

没办法，发挥一下老手艺吧——开拆！

分析包体特征与反编译

apks 文件内含多个 apk 分包，我决定先在 split_config.arm64_v8a.apk 里面找找线索。

等下，为什么不是 base.apk？你是不是开了？

通常 Unity IL2CPP 的 native 部分会以 .so 的形式存在。对于 Google Play 的 App Bundle 构建，ABI 对应的 native library 往往会被拆分到 ABI split APK 中；这份样本的 base.apk 没有 lib 目录，因此需要到 split_config.arm64_v8a.apk 中寻找。

这就是老一辈艺术家的自信。

打开 /split_config.arm64_v8a.apk/lib/arm64-v8a/ 目录，我们能看到其中包含 libil2cpp.so 与 libunity.so 。

这是很典型的 Unity IL2CPP 特征。

这让我想起了一位老朋友—— Il2CppDumper 。

把在 /assets/bin/Data/Managed/Metadata/ 下的 global-metadata.dat 一起喂给 Il2CppDumper。

我们能得到 script.json 和 il2cpp.h 这两个文件。

然后启动我们的另一位老朋友 IDA，打开 libil2cpp.so。

等待 IDA 分析完成后，我们在 IDA 内执行 Il2CppDumper 自带的 ida_with_struct_py3.py 脚本，选择 script.json 和 il2cpp.h 来恢复符号。

寻找 SharedPreference 保存逻辑

既然是保存存档，那么可以试着搜索关键字 save。

很快，SaveManagement 进入了视野。

先打开最容易理解的 SaveManagement$$SaveString，按 F5 看看。地址是 0x1CA8D70。把自动生成的类初始化代码略过去，真正做事的只有三句：

v5 = SaveManagement__Encrypt(keyName, ...);
v7 = SaveManagement__Encrypt(value, ...);
UnityEngine_PlayerPrefs__SetString(v5, v7, 0);

这佐证了我们打开存档时，看到的 key 和 value 都被加密的事实。

这里的 SetString 是 Unity 的 PlayerPrefs 接口；在 Android 上，相关数据会落到应用自己的 shared_prefs XML 中。整份 XML 的标签还是明文，并不是整个文件被 AES 一把梭。

接下来顺着 SaveManagement__Encrypt 点进去。

一路跟到 AES，但密钥在哪？

SaveManagement.Encrypt(string) 的地址是 0x1CA81B8。

IDA 生成的伪代码比较长，主要是 IL2CPP 的对象分配、虚函数调用和释放资源。节约时间，只看关键的这几句——它们在函数的不同位置，中间省掉了对象创建和资源清理：

aes = v4->static_fields->aes;
System_Security_Cryptography_CryptoStream___ctor(v8, (System_IO_Stream_o *)v3, v6, 1, 0);
v18 = System_Convert__ToBase64String(v17, 0);

其中 v6 是通过 aes 的 _20_CreateEncryptor 得到的。str 经 StreamWriter 写入 v8，密文字节从内存流取出成为 v17，最后转成 Base64。

原来 XML 里的那些长字符串并不是直接显示 AES 的二进制密文。游戏先把字符串写进 CryptoStream，再把得到的密文字节转成 Base64，最后才写入 PlayerPrefs。

知道了存档用了 AES，那当然要去找找 Key 和 IV 了。但是这里的 aes 已经存在于 SaveManagement_TypeInfo->static_fields，Encrypt 只是取出来使用。密钥不是在这个函数里生成的。

静态字段是什么时候赋值的？

看看 SaveManagement$$.cctor。这个名字里的 cctor 是静态构造方法，地址 0x1CAA238。这里先创建了两个 AES 对象：

SaveManagement_TypeInfo->static_fields->aes = System_Security_Cryptography_Aes__Create(0);
v1 = System_Security_Cryptography_Aes__Create(0);

第二个随后赋给 aes2。刚才 Encrypt(string) 取的是第一个 aes，所以只追它。

还有两句关键调用，分别位于 Key 和 IV 的赋值前：

ASCII = BinaryUtils__LoopReverseXor(v6, 0);
ASCII = BinaryUtils__LoopReverseXor(v8, 0);

在各自前面，v6 来自 StringLiteral_7107，v8 来自 StringLiteral_7291；变换后的 ASCII 分别被传入 aes->klass->vtable._12_set_Key.methodPtr 和 v7->klass->vtable._10_set_IV.methodPtr。

那么 StringLiteral_7107 和 StringLiteral_7291 又是什么？

查 Il2CppDumper 给出的 stringliteral.json，再与 APK 内 global-metadata.dat 对照，得到：

StringLiteral_7107 → Phigros.enc.j57vnvr8wlZssXM7eWpa
StringLiteral_7291 → Q4zHm5vUEMJJ3iS9

哦我的上帝，这不就是 Key 和 IV 吗！

我知道你很急，但是你先别急——

这两串还不能直接塞进 AES。

静态构造方法在 ASCII.GetBytes 之后又调用了 BinaryUtils__LoopReverseXor。

只在 metadata 中搜到字符串，最多能证明它存在；跟着 IDA 里的赋值走到 set_Key / set_IV，才能说明它到底怎么被使用。

LoopReverseXor 在干什么

在 IDA 中进入 BinaryUtils$$LoopReverseXor，按 F5 获取 Pseudocode。

函数里有一长串移位和掩码，看着有点绕。

先不管那些细节，盯住 F5 循环中的关键部分：

v6 = (2 * v2->m_Items[v5]) & 0xFFAA | (v2->m_Items[v5] >> 1) & 0x55;
v7 = (4 * v6) & 0xFFFFFFCF | (v6 >> 2) & 0x33;
data->m_Items[v5] = v2->m_Items[v5 + 1] ^ (((unsigned __int8)v7 >> 4) | (16 * v7));
++v5;
v8 = v2->max_length - 1;
v9 = (__int64)(max_length + 1) < v8;
LODWORD(max_length) = v2->max_length;

从 v2->m_Items[v5] 与 v2->m_Items[v5 + 1] 的读取，以及最后写入 data->m_Items[v5]，可以对照当前字节与下一个字节的作用。函数末尾还有单独处理最后一个字节的分支。

它不是把整串字符倒过来，而是把每个字节内部的八个 bit 倒序，再和原料中的下一个字节 XOR。最后一个位置则绕回原料的第一个字节。

拿开头两个字节算一下：

P 是 0x50，二进制为 01010000；

bit 倒序得到 00001010，也就是 0x0a。

下一个字符 h 是 0x68。

所以最终 Key 的第一字节为 0x68 XOR 0x0a = 0x62。

对两段原料全部执行，就得到真正传给 AES 的参数：

Key
627ff1942185e011c815e81e639b9a00001c766b826c29bd96578589f19a6fd6

IV
be56167f83da3befeff81861a5c5f3cd

往回看读取路径

Key 和 IV 都有了，让我们回到 SaveManagement$$Decrypt（0x1CA9258）。

它先用 Convert.FromBase64String 把文本还原为密文字节，再用同一个静态 aes 创建解密器，经 CryptoStream 和 StreamReader 读回字符串。

SaveManagement$$LoadString（0x1CA9C5C）则把这一步和 PlayerPrefs 接起来：

v5 = SaveManagement__Encrypt(keyName, (const MethodInfo *)defaultValue);
if ( UnityEngine_PlayerPrefs__HasKey(v5, 0) )
{
  String_60782072 = UnityEngine_PlayerPrefs__GetString_60782072(v5, 0);
  if ( !SaveManagement_TypeInfo->_2.cctor_finished )
    j_il2cpp_runtime_class_init_0(SaveManagement_TypeInfo);
  result = SaveManagement__Decrypt(String_60782072, v7);
  if ( !result )
    return v3;
}

这里还有一个兼容旧数据的分支：找不到 AES 键时会试 EncryptDES(keyName)，如果读到旧值，再 DecryptDES 并用当前 AES 写回。这应该就是旧 DES 格式的键值迁移为当前 AES 格式的逻辑。

实践才是检验真理的唯一标准

我们已经获得了完整解密流程。

从 XML 拿到一个字符串，解密顺序是：

URL 编码反转义
  → Base64 解码
  → AES-256-CBC 解密
  → PKCS#7 去填充
  → UTF-8 读回字符串

那么我们按刚才得到的内容，写个 Python 脚本，验证一下结果吧。

为了方便脚本对内容进行加密，我顺便保存了原内容。

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map phigros_research_count="1654">
    <string name="1keyzhanshi2" phigros_research_v1="WyJlR0ZJYVVaSmRGWm5iMU0yUTBKR1RraFVVaklsTWtKQkpUTkVKVE5FIiwiT0RSdWREUkRSRWMwTVdab1JqVkZXRWhyVm5CdmR5VXpSQ1V6UkE9PSIsIjAzMTI1N2NhNTk3ZDk3MmIxNWU0MTNhODA3YmIyY2UwMmEwYzYwNTYyNmI4OTBjYjhhOTFiMTIzY2UyNTM3YTEiXQ==">1</string>
    <string name="GetBack.CAP3.0.Record.IN" phigros_research_v1="WyJVa1kzU1ZsU2FGQkxUMDlIYmpkUlpXRTJNR3hMWlhob04zVTNWWEZ5ZW10eFl6Rm1keVV5Um1sTVJsbEZKVE5FIiwiVG1vd2FIZzJKVEpDTW5vbE1rSndWMlZQVW5ReE5sSTBWazFsY0hwa1MybEVTa05RSlRKR1VXRjJSV1V5VHlVeVFraFViVEpKUmxOVlduVm5TbXB2VkdOTVVVdzBXRzVVIiwiNWU2YWU1ZDdiYzMwNDIzOGU4M2RkY2NjM2Q1M2E4OTkxNDIzODcxNWE0ZjAxY2E3OTI0NzUyNzhiMDI1Y2M0MCJd">{"s":996886,"a":99.6539535522461,"c":1}</string>                        <!--这一行就是 Get Back IN-->
    <string name="MARENOL.LeaF.0.Record.EZ" phigros_research_v1="WyJRMmQzTkZOMGRFdDNVa1pKYW1JMk9GUkdPSG8xUXpKb1NGSk1Ta2REYkNVeVFrTTBOV3BFTTFnNFYyMDBKVE5FIiwiVVRsQllsaHhiRlpqYzBaYVozUllNblpTU0ROU2JFdHpUMUpJZVc5ek5FRTRNRVpqY0dNNFJXdE9TVmxQWkVSdVFXaHZSRUZFY0dOdk5ISlVOWFp3ZVE9PSIsIjVlMzM4MzZmMzdlMWY0OGViM2Q5Y2JkODIyN2FhNmE4OTNiMzExNTc1ZjA3ZDczZTdkMWY3ODA1MGU0ZDkwNDciXQ==">{"s":996684,"a":99.63157653808594,"c":1}</string>
    <string name="magicballballCollectionTextOpened" phigros_research_v1="WyJjbTlEYkUweWFIQm1WMWRVTUhSMWNVeFVNR1pUZVZoRVNFbDNOWFpxTUc5MU1HZFBUV0pCWVV4dVlYbGlVVnBSWTFWTU1FMWtNMGN4WVZOQlQwY3djZz09IiwiT0RSdWREUkRSRWMwTVdab1JqVkZXRWhyVm5CdmR5VXpSQ1V6UkE9PSIsImY1OTk3NGM2ZDY2MzI1ZTdlMjBkMTYwN2E4MjExOGU4NGYxMzZiMjM1Y2JkNDg1ZmRhNDBjYTg0NmZiODhiNzIiXQ==">1</string>
...

可以看到我 Get Back IN 的成绩是 996886 分，ACC 是 99.6539535522461。

这和我游戏内的成绩一致。

让我们把 Get Back IN 的成绩改成 1000000 分，ACC 改成 100.0，并试着加密：

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="xaHiFItVgoS6CBFNHTR2%2BA%3D%3D">84nt4CDG41fhF5EXHkVpow%3D%3D</string>
    <string name="RF7IYRhPKOOGn7Qea60lKexh7u7Uqrzkqc1fw%2FiLFYE%3D">kqfwO1uMaucCSyOs3f6pHGjYkZEn9aTrYVErEemEy30%3D</string>                        <!--这一行就是 Get Back IN-->
    <string name="Cgw4SttKwRFIjb68TF8z5C2hHRLJGCl%2BC45jD3X8Wm4%3D">Q9AbXqlVcsFZgtX2vRH3RlKsORHyos4A80Fcpc8EkNIYOdDnAhoDADpco4rT5vpy</string>
    <string name="roClM2hpfWWT0tuqLT0fSyXDHIw5vj0ou0gOMbAaLnaybQZQcUL0Md3G1aSAOG0r">84nt4CDG41fhF5EXHkVpow%3D%3D</string>
...

嗯，好像没什么问题。

导入游戏看看（导入前记得停止游戏，并检查应用数据文件的所有者、权限和安全上下文）：

三、有福同享，有难同当

Python 脚本我已开源至 GitHub，有需要的可以前往查看。

https://github.com/Sevtinge/Phigros-Save-Crypto

开源出来的目的是为了一起讨论，而不是满足 yyw 的一己私欲。

爱护圈内环境，你我有责。

7 年过去了，Phigros 也迎来了完结，当年对着破破烂烂的板子打歌的音游人现在又在哪呢。

前言

HyperCeiler，我的一个 Xposed 模块，风风雨雨已经走过了 3 年。

虽然说有一定前瞻的项目设计，以及后期的几次大大小小更改，为它续了好几次命。

但有个问题，是所有 Xposed 模块都逃不掉的——

在宿主更新后，Hook 极其容易失效。

对于一个 Xposed 模块而言，Hook 本身通常并不复杂（如果你在讲 HyperOS Runtime Hook 那当我没说），真正麻烦的是宿主在不断变化：类名、方法名、混淆结果，甚至项目重构，都能让之前所针对的 Hook 前功尽弃。

虽然已经出现了 DexKit 之类的反混淆与定位工具，但也是只能针对部分版本进行非常局限的匹配。

传统 Xposed 模块对此的处理方式通常是修改模块代码，重新构建 APK，然后发布一个新的模块版本。

这也就意味着一个很小的 Hook 修复，也可能需要经历：

发现问题
  ↓
逆向新宿主内容
  ↓
修改 Hook
  ↓
测试和编译
  ↓
发布新版本
  ↓
用户更新模块

这一漫长过程。

而 HyperCeiler 作为一个有着数百 Hook 特大项目，短时间内多次发包进行修补显然是不现实的。

于是我开始思考一个问题：

如果 Hook 本身不一定要跟着 APK 一起发布呢？

这是我最近游玩 Rizline 的时候突然冒出来的一个想法。

理论上，如果这套逻辑能够顺利落地，那 APK 本身将会成为一个 Hook 和配置工具，而 Hook 本身可以解耦出来。

而这，就是目前我正在考虑的 HyperCeiler Next——Remote Hook。

一、为什么要让 Hook 分家？

传统的 Xposed 模块基本是：

Module.apk
 ├── Hook A
 ├── Hook B
 ├── Hook C
 ├── Hook D
 └── ...

在编译的那一刻，所有 Hook 都永久固定在了 APK 当中。

如果某个宿主更新导致 Hook A 失效，那么通常只能等待开发者修复后安装新的模块版本解决。

但实际上，很多时候变化的只是某一个版本，甚至某一个点位的实现。

如果 Hook 主体逻辑没有发生变化，只是目标类发生移动，那么为了修改这几个类名而重新发布整个模块，并不是一个十分理想和划得来的做法。

至于 CI 构建版本，对于普通用户而言风险又实在太高——我可不能保证我一个错都不犯。

更何况最近越来越多的声音在说 HyperCeiler 看起来有些臃肿，大量用不到的宿主的 Hook 也存在于模块当中（虽然可以在管理器内取消应用作用域，但是用户心里的那个满足机制并没有被激活）。

因此，可以考虑把针对每个宿主的 Hook 都拿出来并拆分：

Module.apk
 ├── Hook Loader
 ├── Hook Tools
 └── ...

Remote Hook
 ├── com.example.a (version 1)
 ├── com.example.b (version 2)
 └── ...

这样主程序只需要提供运行环境，而具体的适配和 Hook 则可以独立且灵活的更新。

二、一个最初的设想

最简单的架构大概是

   Module.apk
       |
       | 请求当然宿主及其版本的 Hook 配置
       ↓
      API
       ↓
Hook Repository
       |
       ├── com.example.a
       |          ├── version 1
       |          ├── version 2
       |          └── ...
       ├── com.example.b
       |          ├── version 1
       |          ├── version 2
       |          └── ...
       └── ...

服务器根据客户端提供的信息返回所需的 Hook 功能列表。

例如客户端提供：

{
    "moduleVersion": 100,
    "androidVersion": 16,
    "systemVersion": 4,
    "device": "xxx",
    "targetPackage": "com.example.a",
    "targetPackageVersion": 1,
}

服务器返回：

{
    "hookVersion": 12,
    "minModuleVersion": 24,
    "targetPackage": "com.example.a",
    "targetPackageVersion": 1,
    "config": "https://api-hyperceiler.sevtinge.com/hook/com.example.a/1/12.json",
    "hook": "https://api-hyperceiler.sevtinge.com/hook/com.example.a/1/12.dex",
    "sha256": "...",
    "signature": "..."
}

然后模块验证完整性后执行即可。

这样，Hook 的更新就不一定需要等待整个 APK 的更新。

三、为什么选择 Dex？

Android 本身就提供 Dex 热加载机制。

传统 APK：

Module.apk
 ├── assets
 ├── lib
 ├── META-INF
 ├── res
 ├── classes.dex         ← 这里通常是 Hook 的所在位置
 ├── resources.arsc
 └── ...

而这种方案可以变成：

Module.apk
 ├── assets
 ├── lib
 ├── META-INF
 ├── res
 ├── classes.dex         ← 这里只留存 Runtime 和部分 Built-in Hook
 ├── resources.arsc
 └── ...

Remote Hook
 └── hook.dex

通过 ClassLoader 加载额外的 Dex 后，再由 Xposed 对目标进行 Hook。

从架构上来看，相当于：

            HyperCeiler
                 │
           Hook Runtime
                 │
       ┌─────────┴─────────┐
       │                   │
   Built-in Hook       Remote Hook
       │                   │
       └─────────┬─────────┘
                 │
             Xposed API
                 ↓
                App

这样，Dex 就成为了一种相对独立的 "Hook 插件"。

四、本地缓存

光有云端下发逻辑可不太够。

如果每次启动宿主的时候都需要联网下载 Hook，显然是不现实的——这会导致宿主需要等待 Hook 下载完成才可以执行，本地配置也会随时更新，进程可能也会出现阻塞而被 Android 杀掉。

更何况按 HyperCeiler 现在的日活数据，我怕是掏空了钱包也支撑不起如此体量的下载。

所以我们应当设计本地缓存机制。

本地缓存路径应处在私有目录下，目录结构可参考服务器端。

启动流程则应变为

启动
  ↓
读取本地 Hook
  ↓
验证是否可用于当前宿主
  ↓是           ↓否
加载 Hook      更新 Hook
  ↓
后台检查可用更新

这也就意味着大幅降低云端依赖度和请求数量，满足了离线时也可 Hook 的需求。

五、安全问题

Hook 的权力特别大，可以随意更改宿主的任何可执行内容。

更何况 HyperCeiler 部分功能依赖 Root 权限，那么我们在面对安全问题时，应当更为谨慎。

动态加载远程 Dex，这意味着：

服务器可以改变模块实际执行的代码

这和普通的远程配置完全不是一个风险等级。

例如，服务器遭受远程攻击，dex 被替换，那么所有在线客户端都会被执行恶意代码。

因此，我初步构思应当在以下几个方面构建安全屏障。

服务器安全

这自然是不必多说的，服务器端即使不干这些活，暴露在公网也应当做好安全防护。

此处不展开讲述技术细节。

服务器权限管理

进一步考虑后，我认为 Remote Hook 的权限应当收到进一步限制。

服务器应当只能决定下发哪个配置，而不能直接执行 Hook、命令、配置。

也就是说，服务器只提供代码，而是否加载应由客户端自行决定。

本地下载前和下载时

本地应当使用 https 获取内容，甚至通过自有加密方式加密内容进行联络。

为了安全，我甚至计划不采用断点续传技术，一是本身文件就不大，二是可能存在一定风险。

本地下载后和加载时

本地通过 https 下载完成后，应当对下载内容进行鉴权。

SHA-256——用于确认下载文件没有发生意外变化。

数字签名——用于确认文件是由 HyperCeiler 发布，而并非第三方替换的恶意内容。攻击者完全可以把 SHA-256 也一并替换以绕过验证，所以数字签名显得格外重要。

视情况，也应加上其他验证。

确保以上内容都无误后，下发内容才允许存储和加载

APK 安全

之前就存在过通过修改 HyperCeiler APK 注入恶意内容的先例，在此之后 HyperCeiler 针对进行了 APK 安全改进。

但对于使用云端 Hook 方案的 HyperCeiler Next 而言，安全需要更进一步。

可能会采取 APK 加壳方式或把 Hook Runtime 全部迁移至 Native，并针对自身完整性进行云端校验。

六、HyperCeiler 的骄傲——主动安全模式

HyperCeiler 开创的主动安全模式也不应该在使用云端 Hook 时失效。也应当做出些许改进。

当检测到宿主发生 Crash 时，应当首先尝试回退上一个版本的 Hook，并可以自动标记此版本 Hook 存在异常。

若 Crash 持续出现，则触发主动安全模式，取消对其的 Hook。

七、踌躇不前

从技术角度来说，这套方案确实可行，也有 Xposed 模块小范围的进行了测试。

但是它会引入大量新的复杂度：

• ClassLoader 和空加载保护
• Dex 分包开发
• 版本匹配和同版本不同 Dex 应对
• 本地缓存管理
• 签名
• 网络安全和远程是否可用
• Xposed API 限制
• Hook 兼容性

所以，它并不是简单的：

"把 Hook 改成云端下发。"

真正需要解决的问题是：

如何让远程 Hook 的可靠性持平甚至超越内置 Hook。

若这个问题无法解决，远程 Hook 比本地 Hook 更为脆弱，上面所说的一切都是纸上谈兵。

八、0.9.24

若这个项目真的可以落地，一定是先做一个非常小的 PoC，而不是让它直接面向大众。

它的测试周期可能很长，HyperCeiler(Cemiuiler) 从 0.9 走向 1.0 正式公开用了 5 个月。

而 HyperCeiler Next 可能需要一年甚至更久。

在热情几乎消磨殆尽的背景下，我可能很难坚持把它做出来并公开给大众。

更何况 HyperOS 在逐渐转向 Rust+Flutter 的垃圾配置，Hook 甚至需要用到汇编，难度直线上升。

结语

对于 Xposed 模块开发而言，宿主更新并不是最麻烦的事。

真正麻烦的是：

宿主更新后，原本写死在模块里的假设可能全部失效。

传统模块把所有内容全部打包在了一起，而云端 Hook 的核心思路是把它们拆开。

这样一来，模块本身就不再需要知道所有未来宿主的实现细节。

APK 所需要的，只是一个完整健全稳定的 Hook Runtime。

这可以是 HyperCeiler 未来的一种架构方向，但目前也仅限于 "可以是"。

期待一下吧，万一这个系列有续作呢。

前言

不少朋友很喜欢开港卡，备一张来自香港的SIM总是好的。

香港，世界第三大金融中心，当地国际电话区号+852，与纽约、伦敦并称为 "纽伦港"，静静的伫立在珠三角的东南，总人口753.42万人，是世界上人口密度最高的地区之一，人均寿命全球第一，人类发展指数全球第四。

二战之后，香港与韩国、台湾、新加坡共称为 "亚洲四小龙"，更成为全球最富裕、经济最发达和生活水准最高的地区之一。1997年7月1日，中国政府对香港恢复行使主权，港英政府的时代结束，香港特别行政区成立。

Club Sim是大名鼎鼎的香港电讯 (即CSL) 于2017年推出的子品牌，主打无合约、性价比高的套餐，是不少朋友的第一张+852。但因其漫游时无法主叫/被叫语音或发送短信，这张卡更适合保号和接码的朋友。

信息概览

KYC

是。短信下发网页端验证或APP内验证。支持中华人民共和国往来港澳通行证。

初始成本

HKD$50.00起。

使用成本

中国大陆
接收短信免费

香港 (或Wi-Fi通话)
主叫/被叫语音HKD$28.00/月
发送网内短信HKD$6.00/月+HKD$0.30/条
发送网外短信HKD$6.00/月+HKD$0.60/条
发送国际短信HKD$6.00/月+HKD$3.00/条
接收短信免费

维护成本及规则

最低维护成本HKD$6.00/年。
每自然年内需订购过至少一个套餐，以套餐订购时间计时。

漫游信号

中国联通4G
中国电信4G

技术细节

Wi-Fi通话 支持 (香港)
eSIM 支持
eSIM转移 APP内转移
号码长度 8
APP管理 支持 (Club Sim)

获取

实体SIM

1. 在香港地区任意csl / 1O1O门店或7-Eleven便利店购买Club Sim卡板；

2. 根据监管要求，需要先进行KYC后才可正常使用，插入SIM到您的设备并启用，您会收到来自 "#ClubSim" 的两条KYC入口短信，进入短信提供的链接，根据提示进行KYC；

3. KYC提交完成后需等待审核，审核通过后方可正常使用。

eSIM

1. 前往 主頁 | Club Sim ，点击右上角 "登入"，并在下一个页面点击 "註冊" 以注册您的Club Sim账户；

2. 选择您注册Club Sim账户的方式，按照提示完成注册流程；

3. 注册并认证完成后的页面如图，可个性化您的设置后，选择 "現在購買新Club Sim"；

4. 选择 "eSIM"，并选择您的设备 (若您的设备不在列表中或您使用eSIM卡板，任选设备即可，此步骤仅确认您的设备支持eSIM)，之后点击 "下一步"；

5. Club Sim要求开卡套餐最低HKD$50.00，选择您所需要的套餐，建议选择 "4.5G 無合約期 本地數據及通話服務" 的 "20GB 4.5G 本地數據及通話服務" 服务，也可按需选择其他服务，并建议关闭 "啟動每月自動續購" 以防计划之外的付费，之后点击 "下一步"；

6. 填写您的信息，此处 "名字" 与 "姓氏" 应填写您用于KYC的真实姓名，"電郵地址" 应填写您用于接收付款回执和eSIM二维码的邮箱地址，确认信息无误后付款；

7. 付款后，页面将显示您的eSIM二维码，其也会同步发送至您登记的邮箱；

8. 根据监管要求，需要先进行KYC后才可正常使用，下载eSIM到您的设备并启用，您会收到来自 "#ClubSim" 的两条KYC入口短信，进入短信提供的链接，根据提示进行KYC；

9. KYC提交完成后需等待审核，审核通过后方可正常使用。

维护

您可以在 我的SIM卡 | Club Sim 或APP内查看您的电话号码、ICCID和套餐使用情况。APP内可管理eSIM或建立密码。

若需最小维护成本，可购买 " 短訊組合 "。

若需在非香港地区使用Wi-Fi通话，请开启飞行模式并关闭设备的定位服务后，使用下述代理规则或全局代理，需要香港原生IP。

DOMAIN,csl.prod.ondemandconnectivity.com

若您是Apple设备，需另行确保countryd和gs处于香港 (访问 https://gspe1-ssl.ls.apple.com/pep/gcc ，若显示HK则gs处于香港)，可尝试下述规则以更改gs。

DOMAIN, gspe1-ssl.ls.apple.com

支持VISA、MasterCard及UnionPay的信用卡和借记卡、Alipay HK、WeChat Pay HK、八達通Octopus、Payme、支付宝、微信付款。

前言

新西兰，当地国际电话区号+64，位于南太平洋的岛国，以其丰富的旅游与自然资源闻名于世。拥有发达的市场经济，被认为是亚太地区最繁荣的国家之一。

2degrees，号段022，作为当地的主要运营商之一，成立于2001年，由新西兰本土投资者创立，旨在打破长期由Spark和Vodafone主导的市场垄断。

信息概览

KYC

否。

初始成本

NZD$8.00起。

使用成本

中国大陆
主叫语音NZD$3.59/min
被叫语音NZD$1.15/min
发送短信NZD$1.50/条
接收短信免费
或购买NZD$8.00/天的附加包，提供基于新西兰本地服务 (Monthly or 14 Day Prepay Plan) 的主叫/被叫、语音信箱、短信、1GB高速数据漫游费用倍率 (超出后限制最高速度为128Kbps)

新西兰/澳大利亚 (或Wi-Fi通话)
主叫/被叫语音NZD$0.49/min (套餐内免费)
发送/接收短信免费
发送彩信NZD$0.50/条
接收彩信免费

维护成本及规则

最低维护成本NZD$10.00/365天。
每365天号码存在余额变动即可。

漫游信号

中国移动4G/5G
中国联通4G

技术细节

Wi-Fi通话 支持 (无IP限制)
eSIM 支持
eSIM转移 Apple Quick Transfer
号码长度 9
APP管理 支持 (2degrees NZ)

获取

1. 前往 2degrees Prepay Plans ，在 "Monthly plans" 表下的 "$8/month" 计划 (或按需选择) 选择 "Join now"，并在接下来弹出的两个窗口中均选择 "$8 to pay today"；

2. 填写您的邮箱，此处填写的邮箱地址将被用作您的2degrees账户和接收eSIM二维码；

3. 填写您的详细信息，Contact number 不做验证，并在接下来的两个单选框中选择 "Select a new number" (若您想要携当地号码转至2degrees，选择 "Bring a number over") 和 "eSIM"，"Refresh list" 可以刷新号码列表，选择您喜欢的号码；

   注意: 此处填写的姓名若需更改，需要提交申请表格和更改证明至 CreditTeam@2degrees.nz
   详情请见 2degrees Help

4. 支付完成后等待一段时间，可能需要1小时以上，eSIM二维码和账号重置密码邮件会发送至您登记的邮箱。

维护

您可以在 My 2degrees 或APP内登录您的2degrees账户并管理内容。

建议在获得eSIM后立刻前往 Mobile - My 2degrees 关闭自动续费，以免产生不必要的费用。

也可禁用您不希望使用的服务。

每365天最少充值NZD$10.00以使号码存在余额变动。

当账户无可用计划时，建议开启Wi-Fi通话以主叫/被叫语音及发送短信，否则可能产生额外费用 (在非新西兰/澳大利亚的国家或地区收取NZD$8.00/天的费用，部分国家或地区不可用)。

Wi-Fi通话暂无IP限制，2degrees也建议在非新西兰/澳大利亚的国家或地区使用时启用Wi-Fi通话。

若直连无法拉起Wi-Fi Calling，可尝试关闭对蜂窝服务的代理，或添加下述规则：

DOMAIN-SUFFIX,epdg.ims.2degrees.net.nz
IP-CIDR,118.148.0.0/15,no-resolve

充值支持Visa、MasterCard及American Express的信用卡及借记卡，由CuscalPaymark提供服务。

前言

美国，互联网的老家，当地国际电话区号使用北美电话区号计划区号 (+1) ，按州分配3位次级区号，移动通信产业十分发达。

T-Mobile在当地市场以其低廉的价格著称。作为美国三大移动运营商之一，其历史可追溯至1994年成立的VoiceStream Wireless。2001年，德国电信旗下品牌T-Mobile正式进入美国市场，并逐步发展壮大。2013年后，T-Mobile通过 "Un-carrier" 战略打破传统运营商模式，以不限流量套餐、灵活资费和积极的市场竞争策略迅速扩张。2020年，T-Mobile完成与Sprint Corporation的合并，成为美国第二大移动运营商。

本文主要介绍来自T-Mobile的$3 PayGo套餐，所有价格均未含税。

2019年7月，T-Mobile将不能带来太大利润的$3 PayGo套餐转给了Ultra Mobile，现如今致电611或T-Life客服均会告知无法开通。但我们仍可利用TOS自动机制来获得此套餐。

信息概览

KYC

否。

初始成本

USD$15.00起。

使用成本

中国大陆
月租USD$3.00 (含30条短信或30min美国国内通话)
主叫/被叫语音USD$3.59/min
发送短信USD$0.50/条
接收短信USD$0.10/条

美国 (或Wi-Fi通话)
月租USD$3.00 (含30条短信或30min美国国内通话)
主叫/被叫语音USD$0.25/min (套餐内免费)
发送短信USD$0.25/条 (套餐内免费)
接收短信USD$0.25/条 (套餐内免费)

维护成本及规则

最低维护成本USD$3.00/90天，但仅前30天可用，最低可用维护成本USD$3.00/30天。
余额低于套餐费用USD$3.00超出180天时，号码将被回收，账户将被删除。

漫游信号

中国移动2G
中国联通3G

技术细节

Wi-Fi通话 支持 (无IP限制)
eSIM 支持
eSIM转移 Apple Quick Transfer或联系客服
号码长度 10
APP管理 不支持

获取

1. 下载T-Mobile Prepaid eSIM应用并打开；

2. 选择 "Explore other plans"；

3. 建议选择 "Limited data" 表下的 "5GB ($15/month)" 套餐，也可按需选择；

4. 输入您的邮箱、PIN和美国邮编，此处填写的邮箱地址将被用作您的T-Mobile账户；

   TIP: 89012为免税州邮编

5. 确认信息并付款；

6. 付款成功后，若您的设备支持eSIM，将会拉起EUICC并下载到您的设备，若不支持则会发送二维码至您登记的邮箱；

7. 在此期间漫游不可用，但可以使用Wi-Fi通话，可前往 T-Mobile Prepaid 设置e911地址后开启Wi-Fi通话；
   Wi-Fi通话可能会被GFW拦截，建议添加下述规则使用：

   IP-CIDR,66.94.0.0/19,no-resolve
   IP-CIDR,206.29.177.36/32,no-resolve
   IP-CIDR,208.54.0.0/16,no-resolve
   DOMAIN-SUFFIX,t-mobile.com
   DOMAIN,epdg.epc.mnc240.mcc310.pub.3gppnetwork.org
   DOMAIN,epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
   DOMAIN,ss.epdg.epc.mnc260.mcc310.pub.3gppnetwork.org
   DOMAIN,ss.epdg.epc.geo.mnc260.mcc310.pub.3gppnetwork.org
   

   

8. 保持账户内余额大于等于USD$3.00且小于你目前的套餐价格，静置等待120天后将会自动转为$3 PayGo套餐，若中间出现任何购买操作将会重置计时。

维护

您可以在 T-Mobile Prepaid 登录您的T-Mobile账户并管理内容。

充值支持Visa、MasterCard、American Express及Discover的信用卡及借记卡。目前风控较为严格，可能会拒绝部分卡的付款。

前言

格鲁吉亚位于高加索地区，当地国际电话区号+995，连接欧洲与亚洲，自古就是丝绸之路的重要节点。苏联解体后，格鲁吉亚逐步建立现代通信体系，移动通信市场也迅速发展。

作为当地主要运营商之一的Cellfie，其前身为Beeline Georgia，最早于2003年进入格鲁吉亚市场。2022年，该公司被本土投资集团收购，并于2023年正式更名为Cellfie。

近年来，Cellfie积极推进4G、5G网络建设和数字化服务发展，成为格鲁吉亚通信行业的重要参与者之一，也见证了该国信息化与移动互联网时代的发展历程。

Cellfie提供前缀501、568、571、574、579、592和597。

信息概览

KYC

是。网页端提供标准护照验证，支持照片上传或网络摄像头捕捉。由identomat提供服务。

初始成本

GEL₾6.00起。含GEL₾1.00起的Number Price与GEL₾5.00的Tariff Price。

使用成本

中国大陆
主叫/被叫语音GEL₾0.60/min (主叫/被叫国际长途语音GEL₾10.00/min)
发送短信GEL₾0.60/条
接收短信免费
数据GEL₾6.00/50MB

维护成本及规则

最低维护成本GEL₾0.10/30天。当每月使用超过GEL₾5.00时，将会加收GEL₾0.40的附加费，用于112紧急救援服务。
每90天需要号码有余额变动。自第91天起，每天将会扣除GEL₾0.50的服务费，直至余额用尽。

漫游信号

中国移动2G
中国联通3G/4G

技术细节

Wi-Fi通话 不支持
eSIM 支持
eSIM转移 联网删除旧设备上的eSIM后，在新设备上扫描原先的二维码以添加
号码长度 9
APP管理 支持 (MyCellfie)

获取

1. 前往 Cellfie 选择号码，并选择eSIM，注意非Standard号码存在附加费用；

2. 选择GEL₾5.00的All Unlimited套餐；

3. 根据提示进行KYC；

4. KYC通过后会识别到你的身份和证件信息，并在下方填写邮箱以接收验证码和eSIM二维码；

5. 阅读并同意TOS，建议选择不发送推广信息 (I do not want to receive promotional messages from any entity)；

6. 付款；

7. 付款后会获取到付款回执、eSIM二维码、LPA，eSIM信息也会同步发送到你登记的邮箱。

维护

您可以在 My Cellfie 找到PIN/PUK及eSIM信息。

充值支持Visa及MasterCard的信用卡和借记卡。

若需最小维护成本，可前往 Additional Service ，激活Number Maintenance，或拨打*110*110#。此服务每30天将扣除GEL₾0.10，当第30天余额小于GEL₾0.10时，将会等待10天再次尝试扣款，若等待10天后再次尝试扣款时余额仍不足，将会自动取消该服务。也可前往My Cellfie或拨打*110*9110#手动取消该服务。

前言

英国，即大不列颠及北爱尔兰联合王国，当地国际电话区号+44，最有资格说英语是自己的语言的国家，对于当地的印象基本只有温带海洋性气候带来的阴冷潮湿和老牌工业城市伦敦的标志性口音。

giffgaff，是一家总部位于英国的移动虚拟网络电信运营商，成立于2009年11月25日，设有营业网点，使用O2的网络，是O2的全资子公司，以低廉的套餐价格而闻名。

与传统的移动电话运营商不同，giffgaff的用户也可以参与公司的部分运营，如销售、客服、营销环节等。作为参与运营的回报，用户从公司的 "Payback" 系统中获得补偿。

作为保号界最高的山最长的河，其+44区号权重较高，保号费用低廉，支持范围广，在此之前也有不少文章对其进行了介绍。本文主要从客观角度出发，简述giffgaff eSIM的获取和使用。

信息概览

KYC

否。

初始成本

GBP£10.00起。

使用成本

中国大陆
主叫/被叫语音GBP£1.00/min
发送短信GBP£0.30/条
接收短信免费
数据GBP£0.20/MB

英国/曼岛/根西岛/泽西岛 (或Wi-Fi通话)
主叫语音GBP£0.03/min (套餐内免费)
被叫语音免费
发送短信GBP£0.08/条 (套餐内免费)
接收短信免费
发送彩信GBP£0.30/条 (至英国/曼岛/根西岛/泽西岛号码) 或 GBP£0.24/条 (至非英国/曼岛/根西岛/泽西岛号码)
数据GBP£0.20/MB (套餐内免费)

维护成本及规则

最低维护成本GBP£0.03/6月。
在6个月内号码存在余额变动即可。

漫游信号

中国移动4G/5G
中国联通4G/5G

技术细节

Wi-Fi通话 支持 (英国)
eSIM 支持
eSIM转移 APP内转移
号码长度 10
APP管理 支持 (giffgaff)

获取

实体SIM

1. 前往 International Free SIM Cads | giffgaff ，选择 "No thanks, I just want a free SIM"，填写你的收件地址，并选择 "Order your free SIM"；

注意: giffgaff配送使用标准邮政服务，即平邮，存在一定丢件概率。

2. 等待寄送实体SIM至您填写的收件地址；

3. 收到实体SIM后，插入SIM卡，前往 SIM Activation | giffgaff 输入卡板正面的6位或背面的13位号码，点击 "Activate your SIM"；

4. 填写您的邮箱，此邮箱地址将被用作您的giffgaff账户，点击 "Next"，在下一个页面输入您收到的验证码，点击 "Confrim"；

5. 创建您的giffgaff账户的密码，点击 "Register"，之后您将会收到欢迎邮件，其中包含您的member name，您可以根据邮件指引更改member name，但请注意您只有一次机会；

6. 个性化您的设置，选择是否接收活动邮件，以及可选的填写您的生日。

7. 选择 "Pay as you go" 表下的 "Pay as you go - No monthly plan" (也可按需选择)，点击 "Continue"；

8. 充值最少GBP£10.00的账户余额，点击 "Pay now"；

9. 确认信息并付款；

10. 付款完成后将会显示giffgaff分配给您的电话号码，等待来自43432的激活短信即可。

eSIM

1. 在支持eSIM的设备上下载giffgaff应用并打开；

2. 登录或创建您的giffgaff账户，进入应用主页；

3. 选择 "eSIM"，点击 "Choose your plan"；

4. 选择 "I don't want a plan" (也可按需选择)，点击 "Continue"；

5. 充值最少GBP£10.00的账户余额，点击 "Continue"；

6. 确认信息并付款；

7. 付款完成后，应用将会拉起EUICC并下载到您的设备。

维护

您可以在 My giffgaff 或APP内登录您的giffgaff账户并管理内容。

可发送 number 至 2020 查询当前giffgaff卡号码，或拨打 *100# 查询可用余额。

giffgaff默认开启语音信箱功能，若拒接将会自动转入语音信箱，产生额外费用。可拨打 ##002# 、 1626 或联系 giffgaff Support 关闭语音信箱 (拨打 **61*443*10*20# 或 1616 可启用语音信箱)。

giffgaff在欧盟地区每月享有14天5GB的免漫游费漫游流量，超出将会收取漫游费用。

Wi-Fi通话仅下列设备支持。

厂商	设备
Apple	iPhone SE (2及之后的版本), XR, XS Max, XS, 11, 11 Pro, 11 Pro Max, 12, 12 mini, 12 Pro, 12 Pro Max, 13, 13 mini, 13 Pro, 13 Pro Max, 14, 14 Plus, 14 Pro, 14 Pro Max, 15, 15 Plus, 15 Pro, 15 Pro Max, 16, 16 Pro, 16 Plus, 16 Pro Max, 17, 17 Pro, 17 Pro Max, Air及之后的版本 需要iOS 17.4及之后的版本，或运营商IPCC 58.0及之后的版本
Samsung	Galaxy A04s, A05s, A13, A14, A15, A23, A24, A25, A33, A34, A35, A52, A53, A54, A55及之后的版本 S21系列, S21 FE, S22系列, S23系列, S24系列, S25系列, S26系列及之后的版本 M33及之后的版本 Tab A7 Lite, Tab A8, Tab A9, Tab 28, Tab 29, Tab S9 FE及之后的版本 Z Flip3 5G, Z Flip4, Z Flip5, Z Flip6, Z Fold3 5G, Z Fold4, Z Fold5, Z Fold6
Nokia	Nokia C12, Nokia XR20, Nokia G22, G60, G85及之后的版本
Google	Pixel 7, Pixel 7 Pro, Pixel 7a, Fold, 8/Pro及之后的版本
Motorola	Cancun 等待来自Motorola确认
Sony	Xperia 1V和10V及之后的版本
Xiaomi	所有搭载高通骁龙处理器的设备

Wi-Fi通话仅在英国可用，若需在非英国地区使用，请开启飞行模式并关闭定位服务，并使用下述代理规则或全局代理。

IP-CIDR,87.194.0.0/19
IP-CIDR,87.194.88.0/23
DOMAIN-SUFFIX,epdg.epc.mnc010.mcc234.pub.3gppnetwork.org

若您是Apple设备，需另行确保countryd和gs处于英国 (访问 https://gspe1-ssl.ls.apple.com/pep/gcc ，若显示GB则gs处于英国)，可尝试下述规则以更改gs。

DOMAIN, gspe1-ssl.ls.apple.com

可在支持eSIM功能的设备上下载giffgaff APP，登录您的giffgaff账户，前往 "Account" -> "SIM" -> "Replace my SIM" -> "Switch to a new eSIM" 将号码转为eSIM，APP将会拉起EUICC并下载eSIM到当前设备。

也可前往 "Account" -> "SIM" -> "Replace my SIM" -> "Switch to a new physical SIM" 或在 Profile and Settings | giffgaff 选择 "Replace my SIM" 将号码转为实体SIM

支持3次随机更换号码，前往 Get number | giffgaff 操作即可。

充值支持Visa及MasterCard的信用卡及借记卡。

本文简要讲述如何使用CloudFlare为自有域名搭建邮件地址，并使用Gmail代收发。

在此之前的准备工作：

• 注册域名
• 使用CloudFlare为域名配置DNS解析
• 开启Gmail账号2FA

---

配置电子邮件转发

前往CloudFlare面板-网站-你想为其配置电子邮件地址的域名-电子邮件，创建一个你想要的电子邮件地址。

• "自定义地址" 处填写希望的电子邮件名；
• "目标地址" 处填写希望转发到的邮件地址。

点击创建并继续后，会要求验证希望转发到的邮件地址，前往你在 \"目标地址\" 填写的邮件地址进行验证即可。

在下一个页面，CloudFlare会要求添加记录，直接点击添加记录即可。

之后等待生效。可以使用其他电子邮件地址往新建的电子邮件地址发送电子邮件，能收到即代表成功。 成功后建议开启Catch-all地址，将所有邮件转发到你填写的目标邮件地址。

---

配置Gmail代收发

首先前往应用专用密码，为你的电子邮件地址生成新的密码。

生成完成后妥善保存。

前往Gmail设置-账号与导入，点击用这个地址发送邮件下的添加其他电子邮件地址。

在新跳转的页面中，填写你的电子邮箱的信息。

• "名称" 处填写希望展示的发件人名称；
• "电子邮件地址" 处填写你的电子邮件地址。

在下一个页面中配置SMTP服务器信息。

• "SMTP服务器" 处填写smtp.gmail.com；
• "端口" 处填写587；
• "用户名" 处填写你的Gmail用户名 (即你的Gmail电子邮件名)；
• "密码" 填写上文生成的应用专用密码。

点击添加账号，Gmail会要求验证电子邮件地址，前往你希望转发到的邮件地址，找到验证邮件进行验证即可。

---

至此，你的全新电子邮箱地址就配置完毕了。