Assigned Antikeylogger + Chrome, cant type...

[reystar]

Hello guys

i just purchased the Antilogger from Zemana...but, after installing it i found out that, i can not type anything in Chrome, is there any fix for that?

 

[Deleted member 2913]

Hello guys

i just purchased the Antikeylogger from Zemana...but, after installing it i found out that, i can not type anything in Chrome, is there any fix for that?

Are you running Kaspersky too? Or security software that too has Anti-Logger feature?

 

[Wave]

Try restarting your computer and then check if the issue has been resolved - normally you should restart your system after installing security software so it can set itself up properly at boot, however if this does not resolve the issue then I recommend you request assistance from Zemana themselves from the following link: Bug Report

If you are using other security software which has anti-keylogger protection also (as @Yash Khan mentioned) then there is most likely a compatibility problem. Since both products would be setting hooks over each other and re-mapping the keys, it could have resulted in the problem you are describing now.

 

[reystar]

yupp, i use Kaspersky Internet Security 2017 also...

 

[Wave]

yupp, i use Kaspersky Internet Security 2017 also...

Can you try temporarily disabling the protection and then re-try with Chrome to see if the issue was fixed. (just so we can check this - re-enable it afterwards of course).

However both work fine together when you are using another browser (like the one you are using now)? If this is the case then still speak to Zemana themselves about it.

 

[reystar]

Can you try temporarily disabling the protection and then re-try with Chrome to see if the issue was fixed. (just so we can check this - re-enable it afterwards of course).

However both work fine together when you are using another browser (like the one you are using now)? If this is the case then still speak to Zemana themselves about it.

Yup, i tried disabling AntiLogger and i was able to type back again in Chrome...damn, and i just purchased 3 years license haha. And yes, as you said, FireFox works fine

 

[Wave]

Yup, i tried disabling AntiLogger and i was able to type back again in Chrome...damn, and i just purchased 3 years license haha. And yes, as you said, FireFox works fine

Please speak to Zemana about it here: Bug Report

I don't see why it should work on other browsers and not Chrome with both enabled. Maybe it is really a bug, since this behaviour is very strange for me - it should not work on any of them when they are both enabled, not just one of them.

You can also request a refund, but this may not be necessary in the end. Just speak to Zemana and get their opinion on the situation... Please!

 

[Deleted member 2913]

Yup, i tried disabling AntiLogger and i was able to type back again in Chrome...damn, and i just purchased 3 years license haha. And yes, as you said, FireFox works fine

I too noticed the same prob on Chrome with KIS 2017 & ZAL installed.

 

[reystar]

This is so weird...nobody got a fix on this one? Both products seem really popular here, there must be a fix!

 

[aragornnnn]

If you disable Zemana's ID theft protection it should work.
I heard this module doesn't work properly on 64 bit machines

 

[reystar]

Yes its working now...lol thanks! But, this doesnt give a good impression about the product does it? 90% of the machines today are 64 bit

 

[aragornnnn]

I know alot of updates later its still not fixed...

 

[Azure]

If you disable Zemana's ID theft protection it should work.
I heard this module doesn't work properly on 64 bit machines

That should help but only temporarily.

Zemana AntiLogger
"But Zemana's bug was/is: even if you disable ID Theft Protection, it will turn on after a few minutes/hours, albeit still displaying that it is off. Zemana support confirmed this bug. And so, when you have both software, there would still be problems due to this bug."

 

[Wave]

If you disable Zemana's ID theft protection it should work.
I heard this module doesn't work properly on 64 bit machines

Yes its working now...lol thanks! But, this doesnt give a good impression about the product does it? 90% of the machines today are 64 bit

Windows x64 provides limitations to security software and has done since Windows Vista. It's not the fault of the vendor, some things cannot be done the same on x64, and if they can be re-implemented on x64 then they won't be necessarily as secure as they could have been on x86. For example, self-protection won't be as secure for security software on x64 compared to x86 systems; this is down to changes in the kernel which Microsoft did for "protection" purposes since they dislike manipulation of the Windows Kernel.

Maybe Zemana do SSDT hooking on x86 systems as part of their identity theft, I am not sure without checking - maybe I will actually check sometime in the following week if I have the time. Unless they are doing something in kernel-mode on x86 systems which will either not work/trigger a BugCheck crash on x64 systems, then I myself am unsure on why it wouldn't work okay on x64 systems.

 

[AtlBo]

You might take a look at this on KIS 64 bit functionality too:

Kaspersky x64 bit Protection

Here is a list of restrictions posted by Kaspersky:

Kaspersky Internet Security 2017 restrictions in 64-bit operating systems

Appears security developers have some common issues with 64 bit systems. I am not sure, but is this not a problem to a large degree, where Windows itself provides native security measures, especially the case with Windows 10? Maybe W10 security leaves writers with less need to protect in a particular way?

EDIT: Wave answered the questions. Thanks.

 

[Der.Reisende]

Excuse me if I go off-topic, but the same problem can be had with HMP.A, too.
Two products trying to scramble your keystrokes will conflict. I had this problem with every browser HMP.A was capable to protect in this regards (Chrome x86, x64, IE x86 and x64), fixed by deciding for one soft to take care (HMP.A).

Spoiler: Screenshots

 

[reystar]

Windows x64 provides limitations to security software and has done since Windows Vista. It's not the fault of the vendor, some things cannot be done the same on x64, and if they can be re-implemented on x64 then they won't be necessarily as secure as they could have been on x86. For example, self-protection won't be as secure for security software on x64 compared to x86 systems; this is down to changes in the kernel which Microsoft did for "protection" purposes since they dislike manipulation of the Windows Kernel.

Maybe Zemana do SSDT hooking on x86 systems as part of their identity theft, I am not sure without checking - maybe I will actually check sometime in the following week if I have the time. Unless they are doing something in kernel-mode on x86 systems which will either not work/trigger a BugCheck crash on x64 systems, then I myself am unsure on why it wouldn't work okay on x64 systems.

I what you are saying was correct, i guess, it should apply on all browsers, not just Chrome...

 

[Wave]

Appears security developers have some common issues with 64 bit systems. I am not sure, but is this not a problem to a large degree, where Windows itself provides native security measures, especially the case with Windows 10? Maybe W10 security leaves writers with less need to protect in a particular way?

PatchGuard/Kernel Patch Protection, it gets in the way of my own work as well - the closest solution on x64 systems which is ethical would be the documented kernel-mode callbacks, which is an alternate to kernel-mode hooking from x86 systems. Microsoft implemented it for security purposes since hooking can lead the system to be unstable/not work properly if done incorrectly, and because they just didn't want anyone manipulating the Windows Kernel like they had been, even if it was for security purposes of further protecting the user.

PatchGuard will prevent unsigned drivers from being allowed to load on x64 systems, Kernel Patch Protection works by not exporting KeDescriptorTable, thus making the SSDT protected from modification (since you'll be unable to swap the pointer addresses to the target function you want to hook).

I what you are saying was correct, i guess, it should apply on all browsers, not just Chrome...

I agree with you, this is why I have suspicions as I said earlier - it doesn't make much sense to me why it would work fine on other browsers and not on Chrome. However, maybe they do something different exclusively for Chrome which they do not do for other browsers, since not all browsers work the same. Or, it could just be a standard conflict and not be related to compatibility issues related to limitations between the OS architectures. However, Zemana does utilise device drivers, so it's a possibility... Maybe I will check if I have the time, but speak to Zemana about it. They can provide you better and more information since they own the product themselves and know how it works best.

 

[AtlBo]

True as much so a Zemana is concerned. It does seem it should work on all browsers, unless Chrome itself has some built in protections to do with keylogging.

EDIT: OK, look at the most recent messages. Lesson learned

 

[Wave]

True as much so a Zemana is concerned. It does seem it should work on all browsers, unless Chrome itself has some built in protections to do with keylogging.

EDIT: OK, look at the most recent messages. Lesson learned

We have alike minds, we keep writing similar things and then you notice I was quicker to hit that Post Reply button

And Chrome works differently to browsers like Internet Explorer. To hook the keyboard in Chrome directly you'd need to hook the SSL_ functions in nss3.dll library. E.g. nss3.dll!SSL_Write function. But I doubt it has anything to do with this, probably just a software bug really. Browsers like IE use Win32 functions like HttpSendRequestW which can be hooked for info.

That being said, Google Chrome does have a sandbox container within it to improve it's protection mechanisms against malware attacks, but I don't think it really does the job because malware still has no problem injecting into it and setting local hooks to monitor credentials and log them.

Zemana Anti-Logger most likely blocks logging via Win32 API functions such as SetWindowsHookExA/W also. However, I recon they hook NtUserSetWindowsHookEx (kernel-mode only function, not exported by ntdll.dll) as opposed to user-mode hook on the Win32 API functions. Which may be related to a problem on x86 -> x64. But this is just a quick theory really.

I know Zemana Anti-Logger hook SetWinEventHook (Win32 API function) though, and they also re-map the keys at some point.

Edit: Originally I said PR_ functions (e.g. PR_Write) but this is for Firefox, changed to SLL_Write (since SLL_ functions are for Chrome). Got mixed up originally, my apologies.