kwhat / jnativehook

Global keyboard and mouse listeners for Java.
Other
1.73k stars 344 forks source link

jnativehook freezes my computer when debugging code in IntelliJ #264

Open ZGorlock opened 5 years ago

ZGorlock commented 5 years ago

I am using jnativehook for a small purpose in a much larger application in IntelliJ. When I am debugging my code with jnativehook registered, my mouse freezes for 10 to 15 seconds before returning control to me. After this it is fine until I step to the next line of code, etc, at which point it does the same thing again. This is very hard to work with and it does not happen when the hook is not registered on the global screen. Is there some setting I can use to prevent this behavior?

EDIT: I am using version 2.1.0 from Maven:

com.1stleg jnativehook 2.1.0
kwhat commented 5 years ago

Hi,

It's kind of the expected behavior when the hook is registered and debugger starts because the debugger will pause the event delivery thread, which in turn blocks the OS event delivery queue on Windows and Mac OS X. Work arounds for this are difficult. Basically, the only way to fix this issue would be to detect the debugger attachment in code, and then unregister the hook before handing off to the debugger. There is no way that I know of to detect debugger attachment in Java, however, there are a number of "anti-debugging techniques" that might work in C. These "techniques" are generally for detecting native debuggers like Ida and SoftICE, so I have no idea if they will work with the Java debugger from JNI. There is already another bug on this bug tracker to address this issue, but it's not a major priority at the moment. After I make another 2.1 release or two, I will play around with this and see if I can get something working; at least for Windows. I do not have access to a mac right now, so development on that side is probably going to be on hold longer. If you have some free time, please feel free to hack around on the code and see if you can get something like a printf or log message to come out when the debugger is attached. There are a lot of debugger detection to prevent reverse engineering articles out on the internet to reference, and I can always answer questions. Hopefully, I will be adding a Dockerfile to create a cross-compiler to the 2.1 branch shortly, so compiling the library from source should get much easier. I hope this explanation helps address some of your frustration.

Best, Alex

kwhat commented 5 years ago

I just did a quick search again, it maybe this easy

 if(IsDebuggerPresent())
 {
     // unregister the hook.
 }

https://en.wikibooks.org/wiki/X86_Disassembly/Debugger_Detectors

patrick-brielmayer commented 4 years ago

Try to only suspend the current thread! Capture

rom4ster commented 7 months ago

Hi,

It's kind of the expected behavior when the hook is registered and debugger starts because the debugger will pause the event delivery thread, which in turn blocks the OS event delivery queue on Windows and Mac OS X. Work arounds for this are difficult. Basically, the only way to fix this issue would be to detect the debugger attachment in code, and then unregister the hook before handing off to the debugger. There is no way that I know of to detect debugger attachment in Java, however, there are a number of "anti-debugging techniques" that might work in C. These "techniques" are generally for detecting native debuggers like Ida and SoftICE, so I have no idea if they will work with the Java debugger from JNI. There is already another bug on this bug tracker to address this issue, but it's not a major priority at the moment. After I make another 2.1 release or two, I will play around with this and see if I can get something working; at least for Windows. I do not have access to a mac right now, so development on that side is probably going to be on hold longer. If you have some free time, please feel free to hack around on the code and see if you can get something like a printf or log message to come out when the debugger is attached. There are a lot of debugger detection to prevent reverse engineering articles out on the internet to reference, and I can always answer questions. Hopefully, I will be adding a Dockerfile to create a cross-compiler to the 2.1 branch shortly, so compiling the library from source should get much easier. I hope this explanation helps address some of your frustration.

Best, Alex

How do you explain me spamming Alt tab and shaking the mouse being able to free the mouse cursor ? Also could this be because the lib despite me not actually reacting to motion, is listening to it? In theory listening to clicks only should ignore motion events right? What point does the addNativeMouseMotionListener function serve if I am going to be listening to those events anyways?

I am on windows btw

rom4ster commented 7 months ago

I just did a quick search again, it maybe this easy

 if(IsDebuggerPresent())
 {
     // unregister the hook.
 }

https://en.wikibooks.org/wiki/X86_Disassembly/Debugger_Detectors

This workaround is sound unless you want to debug something dependent on the actual library.