Any Reported Conflicts with Other Security Softs ?

Started by HJLBX, April 02, 2016, 10:56:10 PM

Previous topic - Next topic

aDVll


Umbra

i have access to their closed-beta forum; if needed.

paulderdash

Thanks @aDVII and @fixer! That is tangible info.
I hope the Emsisoft devs can soon provide a response, and a fix!

fixer

It's OK, everybody makes mistakes, that's what testers are for :) Regardless of Emsisoft devs response, I'll try to devise some workaround for the ReHIPS to work even in these conditions.

Mr.X

Quote from: fixer on April 19, 2016, 04:01:52 PM
Actually as Shadow Defender doesn't restrict driver loading in any way, it won't be able to protect anything from kernel-mode threats. SCSI_INQUIRY is a standard read-only command and poses no threat, besides it's issued by a driver, so I don't know why they did it, most likely they just didn't implement all the possible codes (some of which are usually not used).
Has anyone looked into this already? I mean report this to Tony?

Umbra

Quote from: Mr.X on June 06, 2016, 05:45:46 AM
Quote from: fixer on April 19, 2016, 04:01:52 PM
Actually as Shadow Defender doesn't restrict driver loading in any way, it won't be able to protect anything from kernel-mode threats. SCSI_INQUIRY is a standard read-only command and poses no threat, besides it's issued by a driver, so I don't know why they did it, most likely they just didn't implement all the possible codes (some of which are usually not used).
Has anyone looked into this already? I mean report this to Tony?

Shadow defender isn't you to protect you during your session, it is supposed to cancel all changes made during the said session at reboot; so it doesn't matter if you are hit by hundreds of malwares; one reboot later they are gone.

fixer

I think he meant compatibility with ReHIPS which uses SCSI_INQUIRY for HWID generation as ReHIPS gives wrong HWID when executed in shadow mode.

Quote from: umbrapolaris on June 06, 2016, 07:56:04 AM
it is supposed to cancel all changes made during the said session at reboot; so it doesn't matter if you are hit by hundreds of malwares; one reboot later they are gone.
Since we brough it up actually it won't be able to protect from certain malware which uses kernel-mode drivers. Shadow defender doesn't restrict driver loading in any way so it'll be driver vs driver, it's a fight it can't win. So yes, kernel-mode malware may persist after reboots.

Umbra

Quote from: fixer on June 06, 2016, 11:20:52 AM
I think he meant compatibility with ReHIPS which uses SCSI_INQUIRY for HWID generation as ReHIPS gives wrong HWID when executed in shadow mode.

Quote from: umbrapolaris on June 06, 2016, 07:56:04 AM
it is supposed to cancel all changes made during the said session at reboot; so it doesn't matter if you are hit by hundreds of malwares; one reboot later they are gone.
Since we brough it up actually it won't be able to protect from certain malware which uses kernel-mode drivers. Shadow defender doesn't restrict driver loading in any way so it'll be driver vs driver, it's a fight it can't win. So yes, kernel-mode malware may persist after reboots.

SD create a copy of the whole system (MBR included) so the writes are redirected to a virtual partition, shouldn't the kernel-mode malware infect only the virtual system (hence disappearing when the virtual system is deleted upon reboot)?

fixer

If some malware uses conventional disk write mechanisms like CreateFile/WriteFile, you're right, all writes will be redirected. But kernel-mode malware has the same access rights and privileges as SD, it can always bypass any redirection by direct disk access, by patching SD, by disabling SD-lots of options, let alone some sophisticated malware that persist using BIOS, video card memory or some other exotic stuff.

Umbra

Quote from: fixer on June 06, 2016, 01:10:14 PM
But kernel-mode malware has the same access rights and privileges as SD, it can always bypass any redirection by direct disk access, by patching SD, by disabling SD-lots of options,

i see what you saying.

Quotelet alone some sophisticated malware that persist using BIOS, video card memory or some other exotic stuff.

against those SD is helpless, as well with simple keyloggers, since SD doesn't block .

Mr.X

Quote from: fixer on June 06, 2016, 11:20:52 AM
I think he meant compatibility with ReHIPS which uses SCSI_INQUIRY for HWID generation as ReHIPS gives wrong HWID when executed in shadow mode.
Thanks fixer, that's exactly what I meant to say. About kernel-mode malware drivers bypassing Shadow Defender I'm aware of it, same suffers Sandboxie as well. There's a potential bypass awaiting to happen but afaik is hard to accomplish. In the meantime I rely upon it's protection and I like/really need the undo changes features after reboot. Hence I need Shadow Defender to work alongside ReHIPS but the latter not being deactivated because of changing HWiD.

fixer

Added workaround for Emsisoft Anti-Malware issue. Should work fine now.

aDVll

#72
Quote from: fixer on June 09, 2016, 04:37:53 PM
Added workaround for Emsisoft Anti-Malware issue. Should work fine now.
That's good because support said it's probably fine they do things the way they do because not many programs have compatibility issues with Emsisoft. Still waiting for their dev feedback. If something changes will let you know.

Their last msg
QuoteI've received a response. It boils down to the following:
We do use some third-party libraries in our software, and we don't have control over what functions those libraries call.
While it is possible to eliminate those dependencies, it requires a great deal of work that will take a very long time (so it won't be easy to do and it wouldn't happen anytime soon).
Even if we do eliminate those dependencies, there is no guarantee that doing so (and removing any calls to the functions mentioned by the ReHIPS dev that happen to be in out own code) would actually resolve the issue.
Our software has been calling these functions for years without any real issues, and the vast majority of security software does play nice with ours.
So basically we can either spend a ton of time trying to eliminate these functions from our software without any guarantee that it will even help, or ReHIPS can see if they can work around the issue. I'm sure that's not the answer you were looking for, however software development always seems to be more complicated than you would think it should be. ;)

paulderdash

Quote from: fixer on June 09, 2016, 04:37:53 PM
Added workaround for Emsisoft Anti-Malware issue. Should work fine now.
Thanks fixer! I have Emsisoft uninstalled on that machine now, but will test it (with EIS) soon ...

fixer

Looks like Emsisoft posted their final answer. If they think that coding explicitly against official documentation is OK because they break just minority of other software, it's up to them. At least I've done everything I could informing them and coding workaround.