- Status
Even though it is installed in C:\Programs (x86) directory, all the modules are 64 bit. There's a reason for it, but damn if I can remember exactly. I think it might be something as simple as Emsi not changing the install directory in the installer. No big deal.
You will also notice in Task Manager that any EAM processes show 32-bit. They are 64-bit in reality.
Search Emsi support forum for all the gory details... Fabian Wosar provides explanation(s).
Yes, but some security settings are turned off by default - like detection of PUPs ! Why, precisely, Kasper does this I do not know.
Yes, but why would you want to do that? You are just going to get double alerts form WSA's and EAM's antivirus modules in a lot of cases - unless you turn one off or disable settings. This defeats the whole purpose of the combo in the first place.
A combo should compliment each other - not duplicate protections - which is nothing but a needless consumption of resources and an administrative hassle for the user.
The incremental increase in protection might be offset by a whole lot of issues or finagling of the configs.
While EAM has always been compatible with other security softs, Emsi's stance is that combining EAM with another AV is not recommended. I would imagine Webroot would recommend the same.
Just food for thought...
PUP I always enable in any AV. So Kas AV/IS is totally automatic with default then I will look into it. Actually I am looking for good security software for my family shared laptop of average users thats why I want one thats fully automatic & requires no user interaction & low FPs. Kas I know gives low FPs but never tried it.
Currently running Avast AV Pro on family laptop as got 1 year free from the promo mentioned here. Its working fine. But after boot on reaching desktop Avast takes little time to settle down & till then the system runs slow. And little worried about their Evo-Gen Suspicious detection as it seems to give quite a few FPs, occasionally on popular software & windows files too read in their forum.
Both EAM and EIS are very well-suited to anyone - from the first-time novice to the super-user.
There's not a whole lot a user can break using either EAM or EIS - although they can unwittingly disable the internet or block the execution of a critical system file. Of course either one can be achieved using most AVs.
EAM and EIS are high in learnability = user will figure things out relatively quickly even if they don't know a great deal about IT.
Emsi states the typical EAM\EIS subscriber is 50+ years old. I'm part of that old, decrepit bunch of hooligans that learned arithmetic with a slide-rule. If I can figure it out so can anyone else...
KAV is nothing more than a fancy scanner.
In that case, Avira Free will meet your needs at no cost - and provide the same level of detection as KAV. Plus, it is easy to use.
Either one will work for shared computer - but, if there is a lot of downloading and installations, then system is going to get some sort of malware infect.
If lots of unwanted downloading, maybe use anti-executable to lock-down system. I use NVT ERP and kids can't install anything.
Avira + NVT ERP = both free.
You can configure Avira Free to auto-quarantine and run NVT ERP in Stealth Mode.
Just some ideas...
Why KAV is a fancy scanner? Isn't protection of KAV & KIS the same with the difference of FW?
No anti-executable on their system plus dont like Avira.
Among Avast, Avira & AVG Free I find Avast better.
You never know what they will do on the system. But they are good & safe users in my opinion as its been 10-12 years on internet with Windows FW + Free AV (MSE, Avast, Avira, Bd Free, Comodo V2 AV, Unthreat, etc...) & the system was never infected.
No. KAV has some of the advanced features of KIS, but not all of them.
For example, no Application Control, Parental Control, Safe Money, etc, etc.
Besides, you don't need any of that for what you are trying to achieve. KAV has all that you will need... AV, web-protections, Anti-Exploit and System Watcher.
You're right... KAV seems like better choice.
- Mar 23, 2015
- 555
Thank you. I have searched support.emsisoft.com on this topic with Google, and reviewed the results in the first 5 pages.
I have not found Fabian Wosar's reply on this topic.
However, I find that, Christian Mairoll said "All Emsisoft products work very well on 64 bit operating systems from Win 7 onwards. What benefit do you expect from a native x64 build? ".
I guess this implies that EAM and EIS are not "native x64 build".
By the way, I also find that GT500 said "our product has 64-bit binaries and drivers that will be installed on a 64-bit edition of Windows".
But I do not know how to verify this statement, as EIS processes shows to be 32-bit in the task manager
Thank you. I have searched support.emsisoft.com on this topic with Google, and reviewed the results in the first 5 pages.
I have not found Fabian Wosar's reply on this topic.
However, I find that, Christian Mairoll said "All Emsisoft products work very well on 64 bit operating systems from Win 7 onwards. What benefit do you expect from a native x64 build? ".
I guess this implies that EAM and EIS are not "native x64 build".
By the way, I also find that GT500 said "our product has 64-bit binaries and drivers that will be installed on a 64-bit edition of Windows".
But I do not know how to verify this statement, as EIS processes shows to be 32-bit in the task manager
Yeah. GT500 is correct... I just could not recall what the deal was. Now, I remember.
Emsi developed a unified driver that is 64 bit and some modules are 64 bit. Someone questioned Emsi about the 32 bitness shown in Task Manager. Fabian Wosar also explained about the 64 bit binaries.
It's been at least 4 or 5 months since that post on the forum. Maybe longer.
It works rather well on 64 bit W8.1 in my experience. The bitness will not be an issue...
Last edited by a moderator:
- Mar 23, 2015
- 555
I would appreciate it if you could provide some more details on this "unified driver".
In my opinion, I think the bitness issue will affect the capability of behavior blocker.
I heard that, in 32-bit OS, the behavior blockers of many antivirus products relies on some specific "hooks", which are no longer supported in 64-bit OS.
This actually weakens the capability of behavior blocker. For example, as I know, Bitdefender's IDS module cannot work in 64-bit OS (this problem may be solved in 2016 version), and Avira's "Proactive Defense" module cannot work in 64-bit OS, either.
To solve this problem, some antivirus products adopt a technique called "hardware virtualization", including comodo and 360 Guard (not 360 IS or 360TS. 360 Guard is designed for Chinese users). I think all these imply that bitness is a significant and challenging issue for behavior blocker. Therefore, I wonder that whether the behavior blocker of EAM/EIS has a satisfactory performance in 64-bit OS.
Emsi just combined the EAM and EIS drivers into one for the sake of ease of maintenance on their part. Hence "unified driver."
Emsi would state if the BB was unable to detect some behaviors on 64 bit systems. One thing I know about Emsi is that they are forthright.
To address the very issue that you raise regarding detection on 64 bit systems is the reason, I would think, Emsi includes 64 bit binaries.
However, I am not a programmer nor Windows system expert, so I do not want to misstate exactly how both EAM\EIS work in this regard. I am not sure as to the exact programmatic and functional details of Emsi kernel mode drivers.
It would be best if you posted your question on the Emsi support forum to get a direct explanation from Emsi staff.
Perhaps @kram7750 might have a better explanation as he has rather advanced programming and Windows OS knowledge.
Sorry I don't have a better answer...
Comodo uses a setting called "Enhanced Protection Mode" for 64-bit systems. The only infos I, or anyone else who I know has searched, could find is that enabling this setting solves problems related to hooking on 64-bit systems.
In other words, it allows Comodo HIPS to hook 64-bit processes - thereby permitting full functionality of the HIPS module... at least one hopes that is the case, but with Comodo, you just never know...
@kram7750 please help out here.
How exactly does hardware virtualization enable a security soft to "hook" the kernel on W8\8.1 and 10 system?
Thanks.
In other words, it allows Comodo HIPS to hook 64-bit processes - thereby permitting full functionality of the HIPS module... at least one hopes that is the case, but with Comodo, you just never know...
@kram7750 please help out here.
How exactly does hardware virtualization enable a security soft to "hook" the kernel on W8\8.1 and 10 system?
Thanks.
- Mar 23, 2015
- 555
Comodo uses a setting called "Enhanced Protection Mode" for 64-bit systems. The only infos I, or anyone else who I know has searched, could find is that enabling this setting solves problems related to hooking on 64-bit systems.
In other words, it allows Comodo HIPS to hook 64-bit processes - thereby permitting full functionality of the HIPS module... at least one hopes that is the case, but with Comodo, you just never know...
@kram7750 please help out here.
Thanks.
As I know, enabling "enhanced protection mode" is just enabling the "hardware virtualization" module.
I'm sorry, this time I cannot actually answer your question properly to what you would expect from me - I do not know a lot about Comodo products and how they work.
Although, I can tell that kernel patching can occur on 64-bit systems, just it's not something the average device driver developer would know how to do. Kernel patching with e.g. SSDT hooking (System Service Discriptor Table - although you may hear it known as the "System Service Dispatch Table", as well) is blocked from occuring on x64 systems. In the past, there have been ways to bypass PatchGuard to set SSDT hooks.
Microsoft do try to patch things up, especially in the cases of PatchGuard being bypassed. However, I am not convinced that Comodo make use of SSDT hooking on x64 systems. I'm not sure they would even allow an AV vendor to make use of bypassing PatchGuard to set SSDT hooks, since on x64 systems, kernel patching is prevented via PatchGuard.
For example, in the past when PatchGuard was bypassed (unsigned driver loaded on x64 systems) via the use of the Master Boot Record, it was patched as soon as Microsoft could patch it.
Although, kernel patching does not just mean the use of SSDT hooking (sorry if this post made it sound like this already). On an x86 system, kernel patching is referred to as SSDT hooking. On x64 there are other methods for kernel patching. Malicious software (as examples, for example, Carberp) may use techniques to patch up the kernel on an x64 system.
You can create callbacks on the system to get a notification of a certain event and then take action. For example, on a x64 driver, you can work with a callback to monitor process execution and termination. The callback for this would be PsSetCreateProcessNotifyRoutine/Ex suffix can be at the end depending on the Windows version on the system. This is an effective technique, although some people wouldn't consider it as "kernel patching", although it's still useful and good, and it occurs in ring0 (drivers) which is where the kernel runs. You can take advantage of callbacks to protect processes running on ring3, for example with the callback ObRegisterCallback.
Usage of "mini-filter drivers" are also used in products to do specific things.
In case you were wondering why "Ex" is at the end of Windows API functions, it represents a newly updated version of the function in the Windows API. I'll explain this now since I introduced this note... So, let's say we have a function (this is a non-existing function by the way, I'm making it up as an example) called PrintHello which took in a few parameters (one for the text to be displayed, one for the caption of the alert and the other for the buttons displayed), which when called with correct parameters would display the alert on e.g. the Desktop. However, what in older versions of Windows, this function needed to be updated (maybe a change in parameters or big changes)? Well, what would happen is in the new versions, the function would be changed to PrintHelloEx. The "Ex" suffix at the end would represent that the function has been updated, and that there is a function which is older for older Operating System versions.
Now for the example fo the above theory with a real existing function. In kernel-mode, as I mentioned earlier, you can work with callbacks. Well, there is a callback which can be used called CmRegisterCallback. This is a callback used to monitor the registry. However, on newer versions of Windows Operating System, since it was updated, it would be CmRegisterCallbackEx... So if we used this on e.g. Windows 8, we use the newer version (CmRegisterCallbackEx). And if it needs to be updated again, either Microsoft will change the function name and then re-document it with the new function name and the changes on e.g. MSDN, or they will add another "Ex" suffix to the end, so there would be 2 Ex's at the end.
There are also functions which are very useful on user-mode, although not a lot of people know about them I do not think. I say this because even I did not know of them until recently (I am still learning all the time), although the function KiFastSystemCall could be very useful. When you call a function from user-mode, in the end, KiFastSystemCall is called. It will move the API call onto kernel-mode via use of SYSENTER. Via SYSENTER, it allows an entry to the kernel (ring0), meaning the API call is pushed onto kernel-mode, where the function you called happens in ring0. Or at least, this is my understanding of it so far, since I am still studying the function (along with other functions). While only very high-end malicious software would hook it, simply because it's so deep that not many people would know if it, certainly not inexperienced people, it can be very powerful. So if a security product used it, it could do all sorts such as filter out certain API function calls. This can be used for something like a Behaviour Blocker, Host Intrusion Prevention System, process protection.. Of course if a rootkit used it, then that would be quite deadly in my opinion. Since only a few out of a large amount of people in a estimated ratio would know of it, it could be either difficult to discover/unhook, etc. While this may not be related to your question, I thought it'd be useful for the information.
As far as I am aware, there are only 2 people on this forum who know of this API function, and that is before I mentioned it here... Me, and @Cowpipe. (I also tagged @Cowpipe here, not just because of this KiFastSystemCall information, but because he is more experienced than me with things regarding kernel-mode (and a lot of other things), and he is actually one of the people I would go to if I was stuck with something, maybe when he returns to MT and see's this post he might be able to help improve it and correct things). (KiFastSystemCall is or x86 systems though - on x64 there are functions like Wow64SystemServicesEx, I highly doubt you'll find information about it online, or much information. It's undocumented, a friend told me about it recently).Although, there is much undocumented stuff out in the sea.. Which takes lots of experience to analyze the functions enough to understand how they work, how to use them, etc. Comodo clearly have experts working for them, people far more experienced than I am. You could try contacting them, although I doubt they'd release such special information regarding the inner-workings and development of their product. They could probably explain things better than I currently can as well.
It's possible Comodo don't even use kernel-patching. I mean, they could use other techniques like even IAT hooking through remote detouring/inline hooking - so instead of injecting DLLs, they could inject code to make it harder to detect and more "advanced" in a way. I am actually not sure myself, since as I said, I don't know a lot about Comodo products since I don't really have an interest in them too much.
Since "virtualization" is metioned here, at the end of the post here, I will mention just some little information about blocking off processes from making changes to the system, but still allowing execution. I won't actually go into proper "virtualization", or at least as we think of how Antivirus software does it... I do not know too much information about it myself as I am not that experienced myself, I am still learning. Anyway, without further adue:
You do not actually have to use techniques such as "real virtualization" or, "code emululation", with making code execute on a "virtual processor". Something like this could happen:
1). A process is executed. The Antivirus software gives this process specific permissions, to prevent if from doing things like accessing/deleting system files, personal documents, etc... As well as preventing it from escaping, so it is executed, pretty much "isolated" in a way of phrase.
2). It maps the target program (let's say malicious software for this example), into the process with the "permissions" to restrict it from doing specific things, etc.
3). It then analyzes what the malicious software tries to do (and due to permissions, it's restricted).
As for injection into processes, I've seen security software (recently when I did some tests), use DLL injection into them. This could be for things like hooking functions to alert the user of suspicious activity (for example, Behaviour Blocking, they might alert the user when specific functions are used to see if the user allows such activity or not and can allow/block), although I think Code Injection is more secure. But the security software can use both techniques, I guess.
As for blocking things like DLL injection, you could hook a function like LdrLoadDll. This is a native API function, it's undocumented also. For more information about the native API, read these: www.osronline.com/article.cfm?article=91 https://en.wikipedia.org/wiki/Native_API http://undocumented.ntinternals.net/ (good information here, really, I use it all the time!)
I hope this was informative and helped, although if it didn't really answer your question, then I do apologize. I did note at the beginning I cannot answer your question properly, but if I did, let me know! I'm pretty sure I put in way to much information in this post, a lot not even necessary. Regardless, enjoy!!
Cheers.
- Status
