DMON

OK, I hacked my cookies and got to the MSFT document.

The MSFT document is irrelevant to the question I asked.

The MSFT API just facilitates access to the files, it's got nothing to do with what goes on during a scan.

It is alleged that DMON does something that AMON does not do.
ESET has to know what that is.

 

It's the weekend so ESET replies usually dry up.

Hopefully on Monday you will get some responses from the likes of Marcos, Agoretsy or Blackspear.

You pose a good question as to exactly what DMON provides different from AMON in the context of MS Office files. I have often wondered that myself.

 

Howard,

Where exactly is that stated?

I don't see it doing anything distinct from AMON mentioned anywhere. I do see circumstances in which combinations of AMON settings and/or operational requirements (i.e. disable AMON for whatever reason) where DMON could provide protection specifically against malware using Office based documents as an infiltration vector, but that's it.

Blue

 

See my lead posting in this this thread.

The MSFT AV API just provides a hook that allows AV programs to be notified when an Office document is being opened.

This allows the AV program to intercept the open, but it is up to the AV program to decided what it wants to do in a scan.

If the AV program decides that the file should not ber opened, perhaps, after getting a response from the user, the AV program notifies the MSFT API, and MSFT fails the open.

My ultimate quesion is what does DMON do in addition to AMON to justify the wording I found at the ESET web site.

More disappointing is how difficult it has been to get an answer.

 

We may have just a (poor) documentation issue.
But, it's important to find out.

 

Howard,

Any reasonable reading would allow basically the same thing in addition to a clear extension in functionality. In any event, the former which would render the additional layer purely duplicate functionality or not depending on overall program settings.

Ultimately, if a precise answer is to be had, it certainly does have to come from Eset....

Blue

 

Fer shure!

It is troublesome that this very straightforward question has not been previously addressed, as I am, not, nor should I be, the only one interested in the answer.

I'vealready called and exchange some email with custoer support.
All they had to do was forward the question back to the development team, and a lot less time would have been wasted.

 

DMON checks your Word documents for any macro/OLE etc. viruses and ActiveX objects installed/being installed in your browser (IE).
It will also remove them (if you choose to, or automatically) depending on your settings.

 

THat does not answer the question I asked.

Let's wait for a response from ESET.

 

We might consider, for a moment, that this may be no more than an issue with semantics. The phrase "extra layer of protection" does not necessarily indicate that DMON provides a DIFFERENT kind of protection than does AMON. The term extra may simply mean "something additional of the same kind". In point of fact the dictionary definitions indicate nothing about the term meaning something additional of a DIFFERENT kind.

If I have two protective modules doing THE SAME THING in a multi-threading OS, as opposed to having only one of them enabled, it can certainly be said that I have an additional or extra layer of protection enabled. This would be true particularly in the case where the two modules were triggered into activity by two different types of events, each of them giving its respective module a chance at detecting malware.

 

Howard,

I tried to send you a private message, but it appears you have this feature disabled. I will try contacting you by email, instead.

Regards,

Aryeh Goretsky

 

The email I have received from Aryeh Goretkst leads me to the following conclusion.

In effect DMON serves the same function as the Office plug-in in NAV.
If NAV's Autoprotect is enabled, AFAIK, the Office plug-in offers the same protection for Office stuff as idfAutoProtect had been enabled, with the downside, at least in past versions of NAV, of causing problems using VBA/VB.

So, if my conclustion that DMON serves the same function, then DMON offers NO additional protection, it is just gives an ALTERNATIVE entry point to the very same code used by AMON, etc.

"additional layer of defense" implies that the protection might be
different using DMON.

 

How about, "an additional, but somewhat redundant, layer of defense"?

It can be argued that AMON, DMON, and even IMON all use the same scanning engine (so they are the same), but they scan at different entry points (which makes them different... kind of). In this sense, the different entry points constitute different "layers", though the modules still use the same basic scanning engine.

Another interpretation of "layers" could be scanning using signatures versus scanning using heuristics. Of course, NOD32 uses both these methods, but they are not called "layers" or split up into modules in the Eset parlance.

I suppose one thing that DMON does do (that AMON does not) is to scan within archives. AMON does not scan within archives because the performance hit would be too great. Instead, AMON waits until files are actually extracted from archives before scanning them. AMON is the only module that does not scan within archives in real time.

 

There are two issues:

1. The point of entry to the code that scans office documents.
2. What is done when entering each point of entry,

According to AG, and I believe this to be so, the scanning is identical whether done via AMAON or DMON. In the case of an Office document, one goes in and scans the project components.

In the case of KAV, KAV uses bad termimology, and refers to each Office project as an archive, but it does scan each project component. Hopefully, DMON does the same. AMON would have to do the same.

Bottom Line: AFAIK, there is NO difference in the scanning of an Office document, be it via DMON or AMON.

I suspect that DMON was included in NOD for the same reason that the Office plug-in was included in NAV,i.e., certain apps could not run wit hNAV's AutoProtect enabled, and I suspect those same apps could not run with AMON enabled.

In the case of NAV's Office plug-in, due to its larger matket share, this issue was banged out years ago and is mentioned in both the Symantec and MSFT KBs.

In the case of NOD, the inadequate description is likely due to marketing/documentation/language issues.

I raised this issue onl;y because I saw what KAV is doing in their #$%%%@$% Office Guard. See http://www.standards.com/Index.html?OfficeStuffExamples.

 

This has been interesting. I, too, have wondered what the heck DMON did that was so different, when most answers to all questions always seem to boil down to "if you have AMON enabled you'll be okay".