Hello, I have written some prototype patches that allow EasyAntiCheat.sys's syscall scanner to succeed, but the aren't clean and I'd like some direction on which path I should take for the patch I end up submitting here.
Somebody on github has gone through the effort of reverse engineering this check already, and you can find that code here: https://github.com/adrianyy/EACReversing/blob/master/EasyAntiCheat.sys/servi...
As you can see, the driver reads a ntoskrnl's Zw* syscall export, replaces the syscall id operand with the one it found from reading ntdll, and scans the section for the right appropriate Zw function.
For this to work, we need to have the ids from the syscall thunks that exist in ntdll (on staging from the fake-dlls patchset) match the ids in the thunks we add for the Zw* functions in ntoskrnl.
There are a couple ways of doing this, at first I manually put in the assembly to see if it would work, and it did, but that's a clean solution. My current solution adds all Zw exports from ntdll.spec to ntoskrnl.exe.spec and has winebuild generate the exports in alphabetical order, but this solution requires that ntdll.spec and ntoskrnl.exe.spec be kept in sync, which I'm not sure is a good idea.
Another solution I thought of is having a syscall table be read by winebuild, so that ntoskrnl and ntdll can export different syscall numbers and still share the same ids, but maybe this is over-engineering the problem.
Thank you all for your input!
Typo fixes:
*but they aren't clean
*reads a ntoskrnl Zw* syscall export
*for the matching Zw function
*but that's *not* a clean solution
*current solution involves adding
*can export a different number of syscalls
On Thu, May 23, 2019 at 10:37 PM Derek Lesho dereklesho52@gmail.com wrote:
Hello, I have written some prototype patches that allow EasyAntiCheat.sys's syscall scanner to succeed, but the aren't clean and I'd like some direction on which path I should take for the patch I end up submitting here.
Somebody on github has gone through the effort of reverse engineering this check already, and you can find that code here: https://github.com/adrianyy/EACReversing/blob/master/EasyAntiCheat.sys/servi...
As you can see, the driver reads a ntoskrnl's Zw* syscall export, replaces the syscall id operand with the one it found from reading ntdll, and scans the section for the right appropriate Zw function.
For this to work, we need to have the ids from the syscall thunks that exist in ntdll (on staging from the fake-dlls patchset) match the ids in the thunks we add for the Zw* functions in ntoskrnl.
There are a couple ways of doing this, at first I manually put in the assembly to see if it would work, and it did, but that's a clean solution. My current solution adds all Zw exports from ntdll.spec to ntoskrnl.exe.spec and has winebuild generate the exports in alphabetical order, but this solution requires that ntdll.spec and ntoskrnl.exe.spec be kept in sync, which I'm not sure is a good idea.
Another solution I thought of is having a syscall table be read by winebuild, so that ntoskrnl and ntdll can export different syscall numbers and still share the same ids, but maybe this is over-engineering the problem.
Thank you all for your input!
Hi Derek,
On 5/24/19 4:37 AM, Derek Lesho wrote:
There are a couple ways of doing this, at first I manually put in the assembly to see if it would work, and it did, but that's a clean solution. My current solution adds all Zw exports from ntdll.spec to ntoskrnl.exe.spec and has winebuild generate the exports in alphabetical order, but this solution requires that ntdll.spec and ntoskrnl.exe.spec be kept in sync, which I'm not sure is a good idea.
Requiring ntdll.spec being in sync with ntoskrnl.exe.spec should be fine, I think they match on Windows. tools/make_specfiles could probably be adjusted to ensure that.
Jacek
-
Derek Lesho -
Jacek Caban