昨天去参加了mosec2020的安全会议，这也是我第一次参加mosec，议题质量比预料中的要高，因此在这记录一下其中几个有意思的议题。

IO80211Family

第一个议题是王宇师傅(@keenjoy95)关于苹果WiFi子系统的安全研究分享，其实王宇在前一段时间就提了一大波苹果蓝牙子系统的漏洞，看来手里的料还是挺多的。之所以去撸WiFi子系统，也是因为“之前的一个0day在升级系统后不work了”，……说回思路方面，研究入口的寻找个人认为比较有启发性，利用Kemon的内核挂钩能力，确实可以做到往上拳打daemon process，往下脚踢kernel driver或firmware。

IO80211Family V1/V2的这些漏洞，也是因为在接口上发现有巨大的参数传入。一方面通过修改Kemon实现Passive Fuzzer，另一方面去逆向对于这些参数的处理和校验从而优化样本。效果怎么样呢？也就是“每天和panic打交道，对于一些品相不好的panic都懒得去分析”的地步吧。

另外，对于这些复杂的设备驱动，可以参考开源代码(AppleIntelWiFiMVM)，甚至自己去实现一遍，这样可能在分析时会有不一样的理解。

像WiFi、蓝牙、NFC这些攻击面其实影响是很大的，而这部分驱动或者firmware的开发者由于自恃功能复杂天知地知或者抱着能用就行的心理，对一些不可信数据没有意识添加完善的边界检查，导致实现往往在遇到非预期输入时存在bug或者漏洞从而引起内存破坏。这部分分析一个绕不过的门槛是逆向的基本功，安全研究人员做好头发的保养工作还是很有必要的。

另外王宇也提到了他在macbook touchbar图像驱动中也是有0day的，感兴趣的同学也可以尝试去撞一下:)

DroidCorn: 无源码Android Binary Fuzzing

这个议题是flanker(@Flanker_017)介绍了他(们？)做的一个无源码fuzzing框架。说到无源码fuzz，常见的两个流派就是binary patch和dynamic instrument，而DroidCorn听名字也大概能猜到了，就是基于Unicorn开发的动态插桩式执行引擎。

该引擎架构大致分为以下部分:

• Crash Triager
  • Trace Recorder
  • Symbolizer
• Mini Runtime
  • ELF linker
  • Mini Heap
  • Mini Hooker
• Mini Kernel
  • Memory Layer
  • Syscall Handler
• Processor
  • Unicorn(patched)
  • ForkServer
  • Tracer

无源fuzz的思路和AFL-unicorn类似，在QEMU执行Translation Block的时候插入afl_maybe_log记录执行覆盖率。Unicorn本身只是QEMU中CPU Emulation部分代码提炼出来的可编程框架，要实现二进制程序的加载和运行还需要依赖于linker和内核的正确处理。DroidCorn中在这部分做了不少工作，实现自定义的ELF Linker、Runtime以及根据不同应用实现不同的内核系统调用(~20个)，这让我想起了另一个类似的框架qiling.io。最后作为PoC，展示了三星手机图片库中找到的一些漏洞，不过工具想必近期是不会开源了，自己动手丰衣足食吧。

也许以后这类更偏向实战的无源fuzz会是一大热点。CPU指令的软件模拟运行的虽然可以做很多优化，但性能终究是比不上原生虚拟化的支持，ARM Server FTW？

深入浅出JSC优化措施

大宝(@S0rryMybad)的议题，讲得太深，而且又是我的知识盲区，所以不多介绍。唯一的收获是学会了面向RCE的“倒序挖洞法”，针对类型混淆去搜寻JS Array类型改变和检查的地方并寻找潜在的非预期状态。C/C++的代码审计和php有很大不同，但是现在网上更多的资料是关于后者，这个未来有时间也值得谈谈。

暗涌2020

slipper的议题，光听名字完全不知道说啥，副标题是小米5c中国产自研手机芯片澎湃S1分析，其实我觉得标题应该改成“小米5c: 年轻人的第一个fullchain” :)。

虽然标题说是芯片，不过和芯片本身没什么太大关系。议题本身还是很精彩的，从头到尾介绍了如何实现one-click获得小米5c的持久化root权限(准确来说可以达到S-EL1的权限)。

由于安卓的碎片化，小米ROM中其实还是Android7.1，所以在攻击链中有几部分使用了n-day，比如webview和sepolicy的问题。小米5c使用了OP-TEE作为TEE的实现，从其中某个TA里发现漏洞函数，通过在用户态发送消息可以触发。一般TA中都是没有现代mitigation的，所以直接栈溢出+ROP来返回内核并进行patch从而获取了root权限；最后则是通过分析firstboot(LK+aboot)发现特殊入口绕过SecureBoot从而实现持久化。

最近中美关系紧张，可能会出现更多的国产芯片。除了芯片本身的硬件实现外，软件设施也需要跟上时代。华为海思是个很好的例子，虽然其TEE(iTrustee，之前是Trusted Core)也曾经有过漏洞，但至少是和国际持平的。开源实现也不是不能用，不过开发者移植的时候最好先有个全面理解，这样也不至于把开源项目的测试接口原汁原味编译进release版本中，然后被安全研究员在大会上公开diss了:)

攻击SEP的安全启动

徐昊(@windknown)的压轴议题，这也是我觉得最有干货的一个议题了。在checkm8出来后，攻击者号称这是ROM的代码漏洞无法被修复，但是苹果计划在iOS14中修复这个问题，修复方法之一就是通过SEP。SEP是安全处理器(Secure Enclave Processor)，与ARM提供的Truszone总线隔离不同，而是使用了一个独立的处理器来专门处理敏感信息。

关于SEP的公开信息并不多，曾经在2016年BlackHatUS中的议题“Demystifying the Secure Enclave Processor”介绍过，此后很长一段时间都没有相关的安全分析。SEP同样也是一个ARM处理器，拥有独立的RAM和外设，如加密引擎(GID/UID)和TRNG，但同时也有部分和应用处理器共用的资源，比如电源管理(PMGR)、Mailbox和共享内存。

Mailbox是SEP和AP之间唯一的通信信道，基于双方都能访问的映射IO寄存器实现。AP端的映射基地址是0x20da04000，SEP端映射的虚拟地址是0xcda00b80(物理地址为0x20da00b80)。Mailbox信息(messages)的大小是8字节，其中4字节为data，数据结构如下:

struct __attribute__((packed)) sep_message {
	unsigned __int8 endpoint;
	unsigned __int8 tag;
	unsigned __int8 opcode;
	unsigned __int8 param;
	unsigned int data;
}

这个议题本身更多关注与安全启动部分，作者逆向分析了SEP ROM中的代码，分析地址映射和地址保护初始化的逻辑，并寻找其中的攻击点，最终在部分型号下实现SEP的memory读写。可能由于作者还没有完全撸完，所以后面留了一手，不过总的来说也算给其他研究者提供了一个指引方向，后面应该会针对SEP有个小爆发。

Baijiu Con

会后的环节是白酒Con，想上台讲的喝一杯白酒讲五分钟，挺新颖的形式。其中也有一些有趣的议题，比如:

• 王宇介绍了SEP研究的一些其他相关资料和最新进展
• 王勇(ThomasKing2014)介绍了一种名为Arch-flip的奇淫技巧，在运行时切换ARM32/64位的运行环境，可用来辅助写chrome exp或者反逆向
• Rancho介绍了Windows打印驱动的安全研究
• redra1n介绍了供应链攻击，red on red，用魔法打败魔法(●—●)
• 360的小哥介绍了奔驰汽车安全研究，进入汽车系统后发现一个越权远程控制任意奔驰的漏洞(还好买不起)
• iOS in 2020: 秀了一把最新iOS 14的越狱，不说了，盘古NB
• Chromium Series in TCTF: 分享CTF中遇到的Chromium的漏洞利用技巧

虽然会议视频和slides没有公开，但是CTF主播slipper在斗鱼直播间中直播了Baijiu Con部分的演讲，感兴趣的可以去看看，直播间号码是7851291