I found some new attack surfaces in the macOS PackageKit.framework, and successfully disclosed 15+ critical SIP-Bypass vulnerabilities. Apple has addressed 12 of them with CVE assigned so far. There are still some reports in the Apple’s processing queue. All of them are interesting logic issues, and of course each has a successful exploit demonstration.

In this writeup, I will introduce a very simple method to bypass GateKeeper , and uncover the root cause through reversing and debugging. Apple had already addressed it as CVE-2022-22616 in macOS Monterey 12.3, and credited the bug to two Jamf researchers (@malwarezoo, @jbradley89) and me. So, make sure you have updated your Mac devices to the latest version.

As well known, iOS14.8 patched two 0 days in the wild, one of which is the pegasus 0-click vulnerability. You can get the root cause and more interesting findings by reading my analysis from here.

Last year, I used the BinDiff plugin normally inside the IDA Pro, but I got a crash due to the plugin issue. Then a dialog prompted and I choosed to Let IDA Continue, then I got another weird crash. Yes, 2 different issues from BinDiff plugin & IDA Pro, just triggered by a bindiff file. Driven by my curiosity, I tried to find the root cause and got this CVE here :

​ 现在许多高效的 fuzz 引擎（AFL，honggfuzz，syzkaller等）都会收集语料执行时的代码覆盖率，并以此为反馈来指导变异和 fuzz 策略。对于开源的项目，通过设置编译选项，编译器就会自动帮忙插桩了。但是对于闭源的二进制文件，问题就显得比较棘手了。当前主流的做法大多还是 DBI （运行时动态插桩，如 Dynamorio，frida stalker 等）。而与此相对的就是SBI （静态插桩）了。毫无疑问，静态插桩几乎可以获得和编译器插桩一样的执行效率，可以把编译器插桩看成是 SBI 的一个特例。但是目前已有的一些 SBI 方案没有大量运用普及，大都有各自的局限性。

My team and I posted the details of the brand new Mac Malware XCSSET last year [1] [2], and disclosed the interesting 0 day tricks used inside. All the XCSSET payload modules were reviewed carefully. However, I was a newbie for hunting macOS vulnerability and I didn’t realize the TCC bypass is a vulnerability at that time until Jamf posted their new blog and detailed the 3rd 0 day used by XCSSET.

As mentioned in my last blog, I can launch any decrypted iOS App on M1 Mac with free developer certificate. Here, I will try to install the decrypted IPA dircectly without re-signing.

Besides the method in my last blog, I keep trying other methods to run the decrypted iOS App. Then I thought of the Xcode Simulator, which had no possibility to run the real iOS Apps before, due to the x86_64 platform restriction. But now, the Simulator from M1 Mac is also the arm64 architecture. Is it possible to run the decrypted iOS App in the simulator now ?

We have no permission to attach the lldb to any other iOS Apps on the M1 Mac, when SIP is enabled. But we couldn’t launch the iOS Apps if SIP is disabled. It seems that fairplayd has a check for the system boot policy security mode and refuses to decrypt the iOS App macho when SIP is disabled.

Just a place holder