Thanks WS. But candidly, if that is their approach to a trial, I am no longer in even fooling with it. I don't really need it, but was just curious. Pete
Pete, What is so awkward about their trial? (i downloaded the free version and installed, to check whether the fixed the bug and they did) Regards Kees
I always hide alls versions in Windows Update, plus i disable Internet Explorer in Windows 7 features, i use Google Chrome 64 bit, why, because i don't like IE (interface mostly). Rules.
Sometimes the trial disables itself after running for about 3 hours, and informs the user it's usability is limited in the trial version. You have to reboot to enable protection again, or purchase it. That was my experience anyways a few builds back. I tried the latest build to run some test 2 days ago, but I did not have it installed for 3 hours so I don't know the behavior of the latest trial.
I still have a couple of days left with the trial, but I don't think it's worth the 55 euro. I didn't even try the "restricted app" feature, because I think Sandboxie does a better job. I also used the "allow Microsoft" setting to prevent problems, but instead they should have white-listed all essential Windows OS processes. It stopped the test from launching IE (with alert), so it worked on my system.
If I remember correctly you have to allow IE to launch to conduct the test. Just launch internet explorer before you start the test, and leave it open. Then if your security software prompts you while you are typing into the box then choose block. It will tell you if your firewall is leaking, or if your firewall passed the test. If you don't get the message of pass, or fail from the test then you are not conducting the test correctly.
I don't understand what you mean. Basically, this test checks if HIPS can monitor for "interprocess communication" with IE. If you click on deny, it can not send the data. If you click on allow, it starts up IE which of course has outbound access, so then you will fail. However, I did discover something else, which is more worrying. It seems that on my system it can't block Zemana's key-logging test. It did pass all the tests of AKLT. Perhaps you can check it out. http://www.zemana.com/LeakTest/keylogger-test.aspx http://www.snapfiles.com/get/antikeyloggertester.html
I just did the test again Rasheed. You need to launch IE before you start the test, or allow the leak test to launch it for you. To make things more simple launch IE before you start the test so it's already open. Then type your keystrokes into the box. It's at that point your security software should intervene, and block the interprocess communication. Online Armor blocks the leak with IE open.
Restricted app is like sandboxie's drop rights or OA's run safe with folder write limitation. I hope you do realize that you are comparing application virtualization witth policy containment. You could set policy containment on the folders where Sandboxie saves files outside the sandbox, but the then ...
I will try those keylogger test when i'm working with an image that has Online Armor installed. I'm testing some other products out right now, and I know they will fail those test. I think Online Armor will pass them though.
I don't know what's so hard to understand. What I'm saying is that if you use SBIE, you don't need the "restricted apps" feature of SS. SBIE's method of isolation/protection is a lot stronger, so why bother with SS. Can you perhaps test SS? It keeps failing, even when after tweaking of a couple of anti-keylogging settings.
Yes correct, but I'm not sure what you mean with "it should intervene when typing". On my system SS will prevent communication with IE, it does not matter if it's already open or not, so I think it passes the test.
For Zemana keylogger test, SpyShelter doesn't alert (which is a bug), but if keystrokes encryption driver is enabled, then for each keypress, it only captures a digits between 0-9, with the digit increasing by one for every keypress (and wrapping once it gets to 0). For Snapfiles AKLT... GetKeyState - captures keystrokes when AKLT has focus, but when you switch to another app a keylogger alert is displayed by SS. *PASS* GetAsyncKeyState - cannot capture keystrokes and when you switch to another app a keylogger alert is displayed by SS. *PASS* GetKeyboardState - captures keystrokes when AKLT has focus, but when you switch to another app a keylogger alert is displayed by SS. *PASS* DirectX - SS alerts immediately. cannot capture keystrokes. *PASS* LowLevel Hook- SS alerts immediately. cannot capture keystrokes. *PASS* JournalRecord Hook- SS alerts immediately. cannot capture keystrokes. *PASS* GetRawInputData - SS alerts immediately. cannot capture keystrokes. *PASS* Screenshot 1 - SS alerts immediately. cannot capture screenshot. *PASS* Screenshot 2 - SS alerts immediately. cannot capture screenshot (it saves a jpg, but it's completely black). *PASS* I got the same results as you - the only failure is with Zemana keylogger test in that SS doesn't alert, but SS keystrokes encryption stops the test from getting actual keystrokes (although it does know when you've pressed a key).
I'm only conducting the test the way the directions says to conduct the test. SpyShelter without the firewall failed the test on my machine even though it prompted me during the test. I chose block when prompted, but SpyShelter still failed the test. I will video tape the test the next time I conduct it with Online Armor, and also with SpyShelter.
IE has to be launch by you, or launched by the leak test application. You are wasting your time conducting the leak test if you block IE from launching. Here is Comodo FW passing the same leak test. The user allows IE to launch because you must to test for the particular leak that is being tested. https://www.youtube.com/watch?v=UeqfHtEL-3k
Now I'm getting to see the same, seems like switching from "encrypt keystrokes of all processes" to "encrypt keystrokes from specified processes", has woken up this feature, it now all of a sudden does work, also without having to protect specific processes. But SS should have given a warning, like you said.
You misunderstood, but I wasn't clear enough. On my system it does not matter if you launch IE yourself, or launch IE with the tool. You can test it yourself, open IE, type the data, and then close IE. Then click on next, and you will see that PCFlank will open IE in the background without any visible window. So as long as you block communication with IE, SpyShelter will pass the test. But actually, there's nothing special about this test, because a lot of tools open the browser after install, this could also be used to transfer data from your system. So HIPS should monitor start up of all browsers or any other "network enabled" tool.
I was going by what you said prior to that. You was saying that if you allow the test tool to launch IE then you will fail the test. That is not the case. You have to allow the test tool to launch IE, or open IE yourself to conduct the test properly. I have tested SpyShelter premium without the FW twice now, and each time it failed the test on my machine. It alerted me each time of the leak test's attempt to piggyback off of IE. I chose block, but it still failed the test. I will test SS again when I have time.
Spyshelter free working fine, see pics of two zemana tests, after start the test PoC generates an error and typed text does not show up.
Windows_security, if your last post was in response to mine then I was talking about PC Flank Leak test. http://www.pcflank.com/pcflankleaktest.htm
Sorry guys but I don't know where is the problem So what sens is to test app like SS without the firewall module? SSFW on my Vista passed easy such test (IE in background).
Based on what I've seen here about SpyShelter, it is the best HIPS and at least as good firewall, extremely configurable, protects against everything, that plus MBAE premium and I'm secure.