量子哈希
最近有一些热门话题值得关注。尽管已经是3202年了，但仍然有人在进行越狱、砸壳和逆向工作，这真是无聊啊。相比之下，数码博主们都去美国体验Vision Pro真机了。iOS 17已经发布，checkm8漏洞在手机上已经彻底终结了，只剩下几款iPad可以继续使用一年。另外，前几天有人调侃iOS 17是否会改变动态链接器的格式，这让IDA Pro团队感到气愤。最后，新的iOS版本没有进行大的改动，IDA Pro也在上周五发布了8.3正式版，可以适配新版本。据说还解决了Functions窗口乱刷新影响分析性能的问题。
上个周末，我花了很多时间重写了自己的一个项目，并记录了下来。虽然有点无聊，但我最喜欢引用自己发表的文章。之前我一直在推崇使用mremap_encrypted进行”静态”砸壳，让有需要的读者转向FoulDecrypt。但最近听到一些反馈，综合各种评测，发现我的工具仍然更好用。甚至连Frida的作者oleavr也在群里推荐。说起来，欧洲有这么多会议，如果能和他合影并得到认可，我就可以开启割韭菜的星球了，哈哈哈（开个玩笑）。我刚刚重写了这个工具，非常新鲜。
bagbak -l安装和部署需要运行npm install -g bagbak。需要注意的是，如果使用的Node.js版本过新或过旧，可能无法安装，会遇到类似prebuild-install || node-gyp rebuild的错误。由于Frida包含二进制代码，尽管官方已经努力提供预编译包，但无法覆盖所有的Node.js版本。而且还有Electron插一脚增加了碎片化。建议在安装Node.js时选择LTS版本或官网最新的稳定版本之间，非Windows用户也可以使用nvm。使用方法也很简单。
bagbak Chrome
要查看所有已安装的应用程序，需要提供需要解密的应用程序的bundle id或者在桌面上显示的名称。已知WhatsApp的标题最前面有一个肉眼看不见的空白字符，有可能用来在排序上作弊。建议还是使用bundle id更安全。此外，针对同时连接多个设备的情况，还模仿了Frida一样的参数来根据uuid等指定设备。这个项目的命名真的不是我滚键盘起的名字。在命名项目时，我经常感到词穷，所以干脆随便盗用歌单里的名字。BagBak这首歌来自饶舌歌手Vince Staples，曾在漫威电影《黑豹1》的其中一个预告片中作为背景音乐。当然，我不评价电影如何，但原声带中的大牌rapper真的让人听了很久都不会腻。BagBak的副歌歌词非常粗鄙，”让精英们都去****”，非常满足恶趣味，我非常喜欢。
最近GitHub上有很多问题报告，要么是运行超时，要么是在运行过程中崩溃。我研究了一下，发现与之前的设计有关，所以决定重新编写。只是没想到工作量超过了预期，周日晚上写到三点才完成。具体问题是什么呢？前面提到过，为了解密AppExtension，这种进程不能直接运行，我使用了标准的NSExtension API，并注入了pkd系统服务来解除一些限制。这样的代码写起来很别扭，也容易产生一些难以复现的bug。另外，我不想像frida-ios-dump那样需要手动单独运行一个iproxy进程，也不想使用SSH协议读取文件，而是直接将传输数据的代码放在frida agent中。后来官方的frida-tools工具包中增加了frida-push和frida-pull，实现上与我的有些相似，不知道是否有参考（厚着脸皮说一句）。这样的实现看起来很酷，但实际运行起来就不一样了。前面提到需要注入AppExtensions进程。这些进程的内存限制通常很低，稍微有点花活就会被系统终止，也就是大家在GitHub问题报告中看到的那些”script is destroyed”错误。所以我花了一个周末加上一个晚上重新编写了v3.0.0。Frida前几年集成了lockdown（也就是libimobiledevice使用的）的支持，可以直接与iOS端的服务和socket端口进行通信。这样一来，iproxy只需要两个socket对象之间的pipe调用就足够了。如果使用node的ssh2库（纯JavaScript实现的SSH和sftp客户端）访问手机上的SSH，甚至不需要占用计算机端的本地端口，理论上更安全。checkm8系列默认越狱后部署的是dropbear，而不是openssh。我想配置公钥免密登录，但没有成功（如果有人知道怎么做，请在后台留言）。现在不流行改SSH的默认密码了，反正都是root/alpine，还不如硬编码在程序里。新版本的bagbak会扫描22和44两个端口，自动检测openssh或dropbear。开启shell是高频操作，所以我写了一个命令来一键完成。shell没什么特别的，真正爽的是一键开启lldb。我在另一个GitHub项目中放了这个功能。在dropbear系统上还存在一个不大不小的缺陷，就是SSH传输文件不支持sftp协议，没有sftp-server。那么问题来了，用什么传输文件呢？scp命令有一个被弃用的-O选项，用于启用旧的协议。简单来说，没有sftp的情况下，scp在另一端使用未在文档中写明的参数运行一个scp进程实例，通过标准输入输出（当然是在ssh之上）来实现协议。传输单个文件，我们（用代码）在ssh协议中启动一个dd进程，然后通过读写stdin/stdout来完成。scp的优点是支持文件夹传输。协议大致上是先以文本模式输出文件类型（C表示文件，D表示目录），文件系统的八进制mode值，创建和修改时间（需要加参数），当然还有非常重要的文件长度信息。客户端在读取到文件元数据后，根据长度信息继续接收整个文件。对于感兴趣的读者，可以使用verbose选项运行scp，就可以看到具体的文本协议内容。协议的完整实现可以参考scp.c的源代码，实际上也不是太长。我使用Node.js实现了一个简化版本，花了不少时间。少了一个依赖项也不错。之前的策略是在设备端实现文件遍历和判断是否需要解密，而现在直接将整个目录拖回来，在电脑上离线检查LCENCRYPTIONINFO_64，来决定是否需要运行砸壳。不知道什么时候开始，xpc进程居然也可以直接使用frida生成了，不需要再折腾NSExtension API了。也许与越狱配置有关？总之，这样的实现显然比之前魔改pkd要好得多，不仅代码更简洁，而且减少了神秘bug的可能性。也许读者对这些技术细节完全不感兴趣，那就讲讲一个重大的改进吧。之前砸壳需要注入到应用程序的主进程中进行很多操作。启动进程使用的是SpringBoard，需要保持手机屏幕解锁状态。在运行过程中，还需要确保应用程序在前台运行，否则会被挂起，还有可能被”ate bad food (0x8badf00d)”错误终止。而完全改为spawn实现之后，我忘记解锁屏幕直接运行，结果发现也可以运行，全程在后台无界面完成。暂时还没有遇到崩溃的问题。点击原文可以直接访问源代码。如果我的GitHub仓库对您有帮助，请给个小星星。谢谢！
