if i had a nickel for every anti-cheat vendor whom implemented functionality in their driver to elevate the calling usermode process to PP/PPL, i would have two nickels. which isn't a lot, but it's weird that it happened twice
@Rairii Denuvo Anti-Cheat hilariously tries to ease concern about it being kernel-mode in their FAQ, with one of the questions asking if it's safe. They basically just say "it's concerning, but we need to do it! And also others do it too!" without actually saying that it's safe 🤣
@TheRogueArchivist still amazed nobody's done VTL1 cheats yet, it's theoretically possible. i guess when you can patch hyper-v itself you don't need vtl1
i guess the interesting feature about this one is it doesn't have a table of EPROCESS offsets for each nt version
no, this one tries to find the most likely EPROCESS offset by statistical analysis
it walks through all processes, and gets the process protection value (by a syscall). it then checks each EPROCESS byte from 0x600-0x1000, for a match it increments a counter in a table, then it uses the offset with the most hits
the issue with ioctl 0x9e6a0594 mentioned in the writeup
this is the "init" ioctl
it attempts to read the calling process exe from disk, and then hashes it by SHA512 and verifies an ECC sig (passed in to the ioctl)
the intent of course is that you need a valid ecc sig for your exe to use the interesting calls (of course you could just find one valid signature then use it by dll injection, or some toctou tricks over SMB, etc)
except the global variable that it sets, is set at the beginning of the sigcheck function, and it's not unset at all after that, not even if the sigcheck failed
@Rairii I mean, I am professionally blue team at this point (common outcome when you've been doing this for a while) and that shit triggers false positives (that are actually true positive detections) all the damn time.
Add comment