- Oct 30, 2015
- 1,251
If you read my above, I'm particularly mentioning on keylogging protection feature. While it's free on HMP.A it applies only to browser. Which is why I opt for keyscrambler Pro.
ZAL as replacement to HMP.A on Keystroke Encryption
- Thread starter CMLew
- Start date
If you read my above, I'm particularly mentioning on keylogging protection feature. While it's free on HMP.A it applies only to browser. Which is why I opt for keyscrambler Pro.
You don't need to pay for HMP.A keystroke encryption.Why pay for annual subscription on HMP.A when I can pay only once for Keyscrambler?
I'm a cheapskate person.
- Aug 2, 2015
- 4,286
Ummm, no, your wrong, HMPA protects against online, offline and "added Apps" with it's keystroke encryption.
Who ever told you that lied or it was made up.
@Erik Loman
Last edited:
- Dec 12, 2013
- 542
Yes...I agree...there is no better option.You can buy stand alone encryption from SpyShelter now
its called SpyShelter Silent
- Dec 12, 2013
- 542
- Apr 1, 2017
- 1,782
Yandex beta!! it will alert(Has hips) if something wants to access Yandex processes, user profiles, and other places such as history, cookies, keyboard and the browser screen!XD the future is here
PROTECTION
Attachments
Does KeyScrambler protects against form-grabber keyloggers, javascript-based keyloggers, browser add-on/extension keyloggers and web-based keyloggers?
I can understand why this is looked at in a positive way but do you really think it is all positive? If the browser has its own HIPS then this is a worry because security features like HIPS rely on redirecting execution flow for other running software to control them. This can lead to multiple scenarios.
As you can see from the screenshot you uploaded, it has control over Ghostpress.
Last edited by a moderator:
keyscrambler doesn't block any of them, it just encrypts keystrokes, so unless the attacker knows a way to decrypt the datas logged, he can't read them.Does KeyScrambler protects against form-grabber keyloggers, javascript-based keyloggers, browser add-on/extension keyloggers and web-based keyloggers?
If you have security software which can protect the browser processes (memory) and/or sandbox the browser, you'll probably be protected from banking malware which may inject code for web-Inject/form-grabber functionality.
I doubt a sandbox can prevent form-grabber keyloggers
Form-grabbing-based keyloggers log web form submissions by recording the web browsing on submit events. To do that it has to call upon a malicious script tag injected into a targeted web page, and listen for key events. Scripts can be injected via a variety of methods, including cross-site scripting, man-in-the-browser, man-in-the-middle, or a compromise of the remote web site.
Can a sandbox prevent this? I believe a SB can protect such a keylogger from being installed after its reboot but not from preventing it siphoning off data when it encounters the keylogger.
This applies similarly to those web-based keyloggers and browser add-on/extension keyloggers
Agree like SBIE or any virtualization software for that matter? The reason being these javascript-based keyloggers and add-on/extension keyloggers are part of your browser. By trusting your browser you are trusting these keyloggers, no? Can you trust the browser without trusting the add-on/extension or javascript-based keyloggers?
Can a FW/HIPS trust the browser and blocking off the add-on/extension or Javascript-based keylogger?
Last edited:
If you're talking about software-based form-grabbers then a good sandbox should be beneficial in some scenarios. For example, the sandboxed process is restricted from being accessed by other Host processes, preventing code injection which in itself prevents networking-related APIs from being patched in memory to log credentials (e.g. Internet Explorer -> wininet.dll -> which is an example of one of the things that the Zeus banking malware does).
It won't be useful in all scenarios, but some. If you were talking about something completely different then apologies for misunderstanding.
Edit: Only just seen your edit too. If a keylogger is entirely web-based (e.g. no infection to the host for code execution is required) then it would not be useful in that scenario I do not think.
Last edited by a moderator:
I'm not talking of API-based or memory-injection keyloggers. I'm talking of form-grabbing, web-based and add-on/extension type keyloggers
The types of keyloggers are described here
Keystroke logging - Wikipedia
Your original post I quoted is below.
The first you mentioned ("form-grabber keyloggers") can include software-based keyloggers which abuse memory for logging credentials, via code injection and redirecting execution flow of various networking APIs used among different browsers. This is why I brought up memory protection and/or sandboxing. I wasn't referring to add-on/extensions or Java-Script based keyloggers with the suggestion I brought up.
It is an easy misunderstanding because what you said can refer to different types of form-grabbing, however "form-grabbing" can be performed through software-based keyloggers, too. This is what Zeus and SpyEye banking malware does, targeting banking websites for credential theft.
Of course all these while I'm referring to software-based keyloggers. Hardware-based keyloggers is not a discussion subject here.
My focus is more on Javascript-based keyloggers which will include form-grabbers, web-based and browser add-on/extension type keyloggers
The first thing you could try is blocking unauthorised JavaScript, there are extensions for doing things like this. However it can also break web-page functionality... Some JavaScript keyloggers will basically monitor the document for key-press events, and then they'll convert the character code to a readable string to make sense of the logged key-stroke. There's a documented API for this conversion: JavaScript String fromCharCode() Method
You can also find keyloggers in XSS form which can be just as powerful; they can work the same way via monitoring the document for keystroke events. An example would be via document.onkeypress callback handling. The attacker may then submit the logs back to a malicious server setup by the attacker.
It is a lot simpler for attackers to do than some may think. Some Proof-Of-Concept keyloggers take barely any effort at all to be developed and inserted into web-pages... And in the scenario of a genuine, popular website becoming compromised, well that could be catastrophic in reality.
I hope you manage to find suitable additions to help you stay protected against these attacks and the alike. All I can personally suggest is surrounding the blocking of JavaScript without authorisation for these types of attacks.
Its 'Protection against keystroke logging' feature encrypts the user's keystrokes so that data is unreadable even if stolen. Read somewhere ZAL also scrambles besides encrypting keystrokes
Last edited:
