hseoa / ironshield-analysis

> [!NOTE]
> The vendor was notified of these vulnerabilities and provided with a detailed report prior to publication. No response had been received at the time of publication.
# Static analysis of Ironshield anti-cheat
Game studios are building their own anti-cheat solutions to better address the needs of their games and respond more quickly to cheating. A high-quality third-party solution gives studios access to mature detection mechanisms without having to develop them from scratch. However, relying on an external vendor can make it harder to tailor the anti-cheat to a game’s specific needs or respond to cheating as quickly as the studio would like. Bringing development in-house gives studios direct control over what they build and when they deploy it, allowing them to tailor countermeasures to their games and adapt more quickly as cheating techniques evolve[^nc][^eaac][^epic].
As more studios develop their own anti-cheat systems, some of that work can fall to developers with limited experience in systems programming and security. This is particularly risky when kernel-mode drivers are involved, as inappropriate implementation can introduce vulnerabilities that leave players’ systems open to attack[^mhyprot2].
Previously, I shared a work on devirtualizing Zakynthos, PUBG’s anti-cheat, and the Tencent VM from AntiCheatExpert. I have now statically devirtualized every virtualized function in Ironshield’s kernel-mode driver `tvk.sys`. In this article, I examine the driver’s implementation and discuss the vulnerabilities I found during my analysis.
[^nc]: https://about.ncsoft.com/news/article/technology-push-the-boundaries-6
[^eaac]: https://www.ea.com/security/news/eaac-deep-dive
[^epic]: https://onlineservices.epicgames.com/news/epic-online-services-launches-two-new-free-services
[^mhyprot2]: https://www.trendmicro.com/en_us/research/22/h/ransomware-actor-abuses-genshin-impact-anti-cheat-driver-to-kill-antivirus.html
# IOCTL
During my analysis, I found several vulnerabilities in the driver that could cause LPE.
The driver encrypts its IOCTL payloads with LEA cipher [^lea], and clients trying to connect to the driver will be checked on `IRP_MJ_CREATE` for their authority. However, it only checks if `"IRONMACE Co., Ltd."` and `"DigiCert Trusted Root G4"` strings appear in the `WIN_CERTIFICATE` buffer and never parses and validates PKCS blob, so an attacker can simply craft a self-signed certificate containing the strings to bypass the check to gain a full access to the IOCTL.
In order to correctly implement this, I highly recommend using `CI.dll` exports such as `CiCheckSignedFile`, `CiValidateFileObject` and `CiGetCertPublisherName`. However, an attacker can still run their code on the hijacked legitimate process.
The LEA key is statically visible on the code (devirtualized), which can always be derived to the same key.
Additionally, every IOCTL request validates requesting process by performing a check to ensure it matches the process on the con