Huh? I didn’t say they didn’t perform any testing (the article clearly indicates otherwise), I said that they didn’t perform any regular AV detection/exploit testing as your response seemed to imply (with the BETA status, security layers, exploit question, etc…).
I get that Kail. I was not talking about your comment. I’m talking about that guy who done a review about it. His so called ‘analysis’ is something I call into Q. Never mind.
Quick note for those who followed this thread.
We recently released ExploitShield beta2 version 0.8.1. Among other things it now works under non-admin accounts.
Good! Thanks. Saw that last night before your post here 
One Q you prob get asked a lot. You have no date for RC? You not sure yet when it will leave stage BETA?
Edit: The new beta 0.8.1 expires March 31, 2013. I hope after that you might start to look at RC.
Actually you’re the first to ask 
We put a longer-than-expected expiration date on this beta 0.8. If all goes well we expect to release something new before that date.
I see. Great! Can’t wait! Keep up the good work guys
We are getting quite a few reports from users saying that Comodo Defense+ is blocking certain parts of ExploitShield, probably the hook injection. This is causing some issues like slow browsing, browser crashes or icon in traybar not showing when both programs are installed at the same time.
Is there a channel in this forum to report these issues to Comodo devs, support or QA departments?
Hook injections will get blocked by default when the program is automatically sandboxed:
In addition to the Sandbox restriction level set for an application, Defense + also implements the following restrictions. A sandboxed application cannot:Source: Unknown Files: The Sand-boxing and Scanning Processes from the CIS online Help pages.Access non-sandboxed applications in memory
Access protected COM interfaces
Key log or screen capture
Set windows hooks
Modify protected registry keys (if virtualization is enabled)
Modify EXISTING protected file (if virtualization is enabled).
If hooking is the problem then the users could change to run Exploit Shield as a Trusted File (it will no longer be sandboxed).
Bug reports can be submitted in Bug Reports - CIS board. The bug report format will be strictly moderated. Reports in the requested format will have the best chances of being seen.
Perhaps it’s because of files which are not yet trusted by Comodo. The best thing to do may be to submit any unknown files in this topic.
Thanks, I submitted the form. However it says they will look at it and fix it “for the next release of CIS”. How often does Comodo release new versions and can’t the white-listing be pushed out as an update instead of upgrade?
No issues like that here. Thank God
White listing has a cloud component as well as a local component. Once a file is white listed it will get to the user. You will be reported back by the Comodo staff member who took up your request.
If people are still facing problems with ExploitShield after they let it run as a Trusted File they can try adding ExploitShield executable (or the complete installation folder of ES) to the Exclusions of Detect shellcode injections (i.e. Buffer overflow protection).
On the topic of hooks and other things to consider. CIS injects a dll file in each running process. The dll file is called guard32.dll on 32 bits systems and guard64.dll on 64 bits systems. It gets started during boot as a wininit entry. The function of this dll is to reduce the amount of alerts.
Thanks for the clarification Eric.
I’ve been contacted by Comodo already and they are looking into it. Very nice and fast response from Comodo :-TU
??? why do we need an app like expoitshield when we have Cis … does Cis not already protect against exploits?..would installing exploitshield just be overkill and a waste of resources??.
Regards
Dave1234.
Because it’s called layered security. You can’t just rely on 1 product. I saw CIS get bypassed by Java exploit (not that the PC got infected but still bypassed) here where ExploitShield comes in before anything done to your system.
The latest Java jre 1.7.10 gives the opportunity to control if and to what extend (security levels) applets are allowed to run in browsers.
Since Java is hardly used on web site I suggest to switch it off for browsing and only enable it for a site that needs it and when running the applet run it a high security level.
Unfortunately the default configuration seems to be the insecure configuration, so the vast majority of users will still be at risk.
Hence my advice to run at a high security level… :-\
Simply disabling it will keep quite a few exploits at bay while surfing. Finding a web site that needs Java is an odd thing so disabling seems a good strategy.
Agreed best is to remove Java altogether.
EMET is getting on my nerves these days. Blocking so many legitimate system applications. Thank God I have a choice to use ExploitShield instead Java or not java CIS can’t protect you against all exploits. Look at offensive security tests. That’s where you need something else to back up CIS. ExploitShield.