最近不少热点话题可以追。3202 年了还搁这越狱砸壳逆向呢，无不无聊啊……

你看数码博主人均都去美国体验 Vision Pro 真机了。

iOS 17 出来，checkm8 漏洞在手机上彻底 end of life，只剩在几款 iPad 上还可以再战最后一年。

另外前几天调侃 iOS 17 会不会又改动态链接器的格式，气死 IDA Pro 团队。最后新 iOS 没有大改，IDA 也在上周五发布了 8.3 正式版，可以适配了。据说还解决了老大难的 Functions 窗口乱刷新影响分析性能的问题。

上周末狂肝重写了自己的一个项目，还是记录一下。确实挺无聊。

本号最喜欢就是引用自己的发的文章。之前砸壳这件破事就已经在鼓吹 mremap_encrypted “静态”砸壳，让有需要的读者赶紧转移到 FoulDecrypt 上去。

但最近偶尔听到一些反馈说，综合一通测评下来，还是我的好使。连 frida 作者大胡子叔叔 oleavr 本人都在群里推荐。说来欧洲这么多会议，要是什么时候能搞到他合影背书，我就可以开星球割韭菜啦啊哈哈哈（不是）

厚颜无耻地贴这个工具，新鲜的，刚重写一轮。

https://github.com/chichou/bagbak

安装部署之需要 npm install -g bagbak

需要注意的是如果 nodejs 版本太新或者太旧，都有可能装不上，遇到形如 prebuild-install || node-gyp rebuild 之类的错误。

因为 frida 有二进制代码，虽然官方已经在努力提供预编译包，但 node 版本很多，很大概率没有覆盖全。甚至还有 Electron 插一脚增加碎片化。

建议安装 node 的时候在 LTS 和官网最新的稳定版大版本之间选择，非 Windows 用户也可以用 nvm。

用法也很直白。

bagbak -l

查看所有已安装的 app

bagbak Chrome

需要解密的 app 的 bundle id 或者在桌面上显示的名字。已知 WhatsApp 的标题最前面有一个肉眼看不见的空白字符，有可能用来在排序上作弊。建议还是用 bundle id 最保险。

此外针对同时连接多个设备的情况，还模仿了 frida 一样的参数来根据 uuid 等指定设备。

这项目真不是脸滚键盘起的名字。在项目起名的时候经常词穷，干脆就随便盗用歌单里的名字。

BagBak 这首歌来自饶舌歌手 Vince Staples，漫威《黑豹1》的其中一个预告片曾用作背景音乐。当然电影怎么样不做评价，原声带全是大牌 rapper，听了好久都没腻。BagBak 的副歌歌词非常粗鄙，“让精英们都去****”，低级趣味。不由得让我想起老乡暴龙哥，极大地满足了恶趣味，非常喜欢。

最近 GitHub 很多 issue 来报告各种错误，不是运行超时就是跑到一半崩掉。我研究了一下，跟之前的设计有关系。干脆还是重写吧。只是我没想到工作量超过预估，周日晚上卷到三点还没写完。

具体什么问题呢？

前文里就提到过，为了解密 AppExtension，这种进程不能直接运行，我就用了标准的 NSExtension API，加上注入 pkd 系统服务解除掉一些限制。这样代码写起来很别扭，也容易产生一些难以复现的 bug。

另外我不想像 frida-ios-dump 那样需要手动单独跑一个 iproxy 进程，也就没有用 SSH 协议读文件，而是直接把传输数据的代码都放进 frida agent 里做。

后来官方的 frida-tools 工具包里多了 frida-push 和 frida-pull，实现上和我的有点相似，不知有没有参考（厚着脸皮打下这句话）

这样实现表面看起来很酷炫，跑起来就不一样了。前面提到要注入 AppExtensions 进程。这些进程内存限额（jetsam）通常给的很低，随便玩点花活就被系统终止了，也就是 GitHub issue 里大家看到的那些 script is destroyed 错误。

花了一个周末再加一晚上重写了 v3.0.0。

frida 前几年集成了 lockdown（也就是 libimobiledevice 用的）的支持，可以和 iOS 端的服务和 socket 端口直接通信了。这样一来 iproxy 也就只需要两个 socket 对象之间 pipe 调用就够了。

如果用 node 的 ssh2（纯 js 实现的 SSH 和 sftp 客户端）库访问手机端的 SSH，那么连计算机端的本地端口都不用占用了，理论上还更安全。

checkm8 系列默认越狱之后部署的是 dropbear，而不是 openssh。我想配置公钥免密登录，但是没成功（有知道怎么弄的求后台留言）。现在不流行改 SSH 默认密码了，反正都是 root / alpine，还不如硬编码在程序里呢。

新版的 bagbak 会扫描两个端口 22 和 44，自动检测 openssh 或者 dropbear。开 shell 是高频操作，我干脆写了个命令去一键干这事。

shell 不算什么，真正爽的是一键开 lldb。我放另外一个 GitHub 项目了。

在 dropbear 的系统上还有个不大不小的缺陷，就是 SSH 传文件不支持 sftp 协议。没有 sftp-server。那就奇怪了，用什么传文件呢？

scp 命令有一个 deperecated 的 -O 选项，用来开启旧的协议。

https://github.com/openssh/openssh-portable/blob/master/scp.c

简单来说，没有 sftp 的情况下，scp 在另一端用文档没有写的参数运行一个 scp 进程实例，通过标准输入输出（当然，是在 ssh 之上）来实现协议。

传单个文件，我们（用代码）在 ssh 协议里启动一个 dd，然后读写 stdin / stdout 就完事了。scp 的优点是多了文件夹的支持。

协议大体是先用文本模式输出文件类型（C 是文件，D 是目录），文件系统的八进制 mode 值，创建和修改时间（需要加参数），当然还有很重要的文件长度信息。客户端读取到文件元数据之后便可以根据长度信息继续接受整个文件。

感兴趣的读者可以用 verbose 选项运行 scp，就可以看到具体的文本协议内容。协议的完整实现可以参考 scp.c 的源码，其实也不算太长。

我用 nodejs 实现了简化的版本练手，在上面耗了不少时间。少一个依赖项也不错。

之前的策略是在设备端实现文件遍历、判定是否需要解密；而现在直接把整个目录拖回来，在电脑上离线检查 LC_ENCRYPTION_INFO_64，来决定是否需要运行砸壳。

不知什么时候开始，xpc 进程居然也可以用 frida 直接 spawn 出来了。不需要对着 NSExtension API 折腾了。也许和越狱配置有关？总之这样实现显然比之前魔改 pkd 强多了，不仅代码更简洁，还减少谜之 bug 的概率。

读者可能对这些技术细节完全不感兴趣，还是讲讲一个重大的体验上的改进。

之前砸壳需要注入到 app 主进程干很多事。启动进程用的是 SpringBoard，需要手机屏幕保持解锁状态。在运行过程中，还需要保证 app 在最前台，否则会被挂起，还有被 ate bad food (0x8badf00d) 错误干掉的可能。

彻底改为 spawn 的实现之后，我忘了解锁屏幕就直接运行，发现居然也可以用，全程在后台 headless 完成。崩溃的毛病暂时还没遇上。

点击原文直达源码。如果我的 GitHub 仓库对您有用，烦请点个小星星。么么哒