View previous topic :: View next topic |
Author |
Message |
buraktamturk Newbie cheater Reputation: 0
Joined: 29 Jun 2014 Posts: 18
|
Posted: Tue Jan 26, 2016 6:55 pm Post subject: interrupt 1 hook does not fire *sometimes* |
|
|
Hello,
I am hooking interrupt 1 using DBVM with my kernel mode driver and placing my *local* breakpoints to the thread using TRAP_FRAME defined in KTHREAD (I know this isn't the best way, since undocumented structs comes help here). I don't use global debugging at this point.
When my Interrupt 1 handler is getting called, I look over a linked list and tell what to do to my usermode process. I am successfully managed to modify the thread registers from the usermode process. With the help of ReadFile and KeWaitForMultipleObjects (I do something like CE driver does).
I place the breakpoints for 1 thread. And I think my interrupt won't get called %1 of the time, the original windows routine is getting called instead. For example it works 9999 times then fails for 1 time (by mean failing, windows routine is getting called instead), and the thread I placed breakpoints gets Single Step Exception, if it would hit my routine EFlags should have resume flag set and the thread should be fine.
I hook int1 using KeIpiGenericCall, I am sure all cores got hook. I tried to lock the game to the CPU 0 by setting affinity (I thought maybe not all of the cores got the hook) but the result is still same.
What could be the problem? Is there any advice you could give me given the situation?
Thanks.
|
|
Back to top |
|
|
Dark Byte Site Admin Reputation: 458
Joined: 09 May 2003 Posts: 25288 Location: The netherlands
|
Posted: Wed Jan 27, 2016 4:40 am Post subject: |
|
|
do you have a check to see if the interrupt generated came from your target process or not? Perhaps that check mistakenly skips it
my initial thought would be the affinity, telling dbvm to redirect interrupts goes on a per cpu basis, so if you only called it for cpu0 any interrupt on the other cores would not be redirected
perhaps windows doesn't take the suggested affinity as strict as it should. (which may explain why offloading tbe cpu at runtime gets trickier when done too quick on some systems with a lot of cores) so try to make sure every cpu is set to redirect
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
Back to top |
|
|
buraktamturk Newbie cheater Reputation: 0
Joined: 29 Jun 2014 Posts: 18
|
Posted: Sun Jan 31, 2016 2:09 pm Post subject: |
|
|
I thought there could be a problem where i send the registers to user-mode and get response back then return int1. So I ported my hack entirely to kernel-mode, seemed easier at first.
The problem is now evolved and I get CLOCK_WATCHDOG_TIMEOUT after a few minutes. This happens when the function I breakpointed earlier runs a lot of time (50-100 per fps). If I hook less-used functions i stay a lot longer.
I don't hold any lock in the routine, just some plain "if (stackpointer[si_eip] == THE_FUNCTION_I_HOOKED) {stackpointer[si_eflags] |= 1 << 16; return 1; }"'s. I can't get valueable information from the crash dump, can't even get the registers the core who failed.
Could it be connected to DBVM? As far *i think*, it happens when int1 is called so frequently.
EDIT: I am so sorry, I had a case where i return this handler without disabling interrupt... I corrected it and the bluescreen thing is gone now.
Thank you so much for the DBVM, i find it more valueable than gold.
|
|
Back to top |
|
|
|