Beta AMON keeps scanning outpost.ini

[guessed]

i noticed the beta version keeps scanning the outpost.ini file (i use agnitum outpost 2 firewall). i added the agnitum folder to the exclusion list, i even excluded outpost.ini, but amon keep scanning it, say, 80% of time.
is this normal behaviour?

[manOFpeace]

As mentioned elsewhere mine repeatedly scans Anti-Trojan BOClean in the way you describe. Now and then another file gets the works there as well.
But last version had the same problem.
I am posting this again to keep these things together so ESET can see a better picture. ::)

[Marcos]

Guys,
would you please try copying the eicar test file (www.nod32.com/eicar.com) to a directory excluded from scanning to see if AMON will spring into action though?

[guessed]

i'll try that and will let you know. so far it hasn't been detected...

[guessed]

nope, eicar is not detected when located and/or executed in excluded folders. IMON caught it prior download though, and AMON got it while trying to save it to an excluded location.

hope this answers your question.

keep up the good work

[manOFpeace]

Hello Marcos, the second I clicked on the link it all turned red, so I haven't done anything until I see what you have to say. :o

[ramponge]

Hi there

Same here about outpost.ini, nod32 keeps scanning if or not the file is excluded and also the directory.

Strange thing because I excluded another file (something.dll) and it works fine ::)

Any ideas !!

[DiGi]

And where is trouble? You are running Outpost firewall and that program still opens and read/write that INI. Cou can add that ini to exclusions list (or whole firewall folder) - but you must use short path format (because Outpost using short path format in own links)

use this path for AMON exclusion:

C:\PROGRA~1\AGNITUM\OUTPOS~1\outpost.ini

[DonKid]

Well my outpost is still been scanned.My Windows XP is Brazilian Portuguese, and the folder here is C:\Arquivos de programas\Agnitum\Outpost Firewall.
And the shortcut should it be: C:\Arquiv~1\Agnitum\/outpost~1\outpost.ini.
But Nod32 is still scanning it.

Any ideas ?

Best Regards,

DonKid.

[ronjor]

You went to Imon, setup, advanced, exclusion, edit, and entered the application?

[ramponge]

Hi Digit

You are right about the short path format, it works good.

BTW I read in the Outpost forum that it was recommanded to exclude from scanning 3 files : op_data.mdb op_data.ldb and... outpost.ini

Thanhs for your help ;D

[ramponge]

@ DonKid

C:\Arquiv~1\Agnitum\outpost~1\outpost.ini.

with no T at outpost.

Bye ;)

[DonKid]

Hi guys,

Ronror, yes I checked it out.

Ramponge,

I wrote wrong. It is without T.

I have tested shutting it down, looking at AMON module, and start Outpost again. And when it started, AMON scanned it.Is it normal ? There's a log of scanned files ?

Best Regards,

DonKid.

[spm]

OK, so when are Eset actually going to fix this 'exclusion' bug?

It is irrelevant that Outpost accesses its configuration file using short path names - what is relevant is that *NOD32* accesses the file, and fails to recognise that textually different long and short path names of the same file are actually the same file.

This bug has been around since NOD32 1.0, and it has been reported countless times on this forum. It really is not rocket science for NOD32 to use effective filename comparison, and it is inexcusable that it can't. I trust Eset will pull their finger out and nail this once and for all before the current beta programme ends.

[DiGi]

spm - this is not Nod/Eset's bug...

There are two ways to wrote paths, long names and short. Short names aren't unique (format disk, create folder "Program Files for stupid programs" and install Windows) ;)

Short names: "Progra~1" is "Program Files for stupid programs" and "Progra~2" is "Program Files". I think that Outpost will install to "Program Files" and try to start services from "Progra~1" (different folder) - so cry at Agnitum - on here at Eset ;)

All windows programs should use ony full length paths - there can be only many troubles with this short-ones...

ramponge:
Personaly I add whole Outpost folder as exclusion (non-recursive) and I'm fine ;)

[spm]

{QUOTE-> spm - this is not Nod/Eset's bug... <-QUOTE}
It most certainly is.

{QUOTE-> There are two ways to wrote paths, long names and short. Short names aren't unique ... <-QUOTE}
You clearly do not understand what short names really are, and why they are unique, nor the historical reasons why Windows needs to support short filenames. In any case, it is irrelevant to the issue whether you think they should be used or not: it is sufficient that the use of short names is perfectly valid under Windows, and that the bug (for that is definitely what it is) in NOD32 causes it to fail to implement exclusions properly for a number of files and folders, not just for Outpost's configuration file.

[redgrave]

Here nod32 beta keeps scanning gbieh.dll, even though I did everything to erase this, erased all traces in the registry and erased the file.

[DonKid]

Hi Folks.

Now I could stop scanning my outpost.ini file, using the default directory like this:

C:\Arquivos de programas\Agnitum\Outpost Firewall\outpost.ini .

Best Regards,

DonKid.

[tosbsas]

Don't know if oyu guys have checked this post concering Exclusion in Amon:

Taken from my post on another thread...

"...here are the exclusions I've worked out to keep Amon from constant scanning of Boclean [v4.11] files on my system. You're welcome to try them.

C:\PROGRAM FILES\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.EXE
C:\WINNT\BOC411.INI
C:\PROGRA~1\NSCLEAN\BOCLEAN\BOCLEAN.DLL

The first two are tricky! I realize they appear to be redundant, but I have confirmed I need both and [humbly] suggest you to try BOTH simultaneously."

But it worked for me using both paths, long and short

Ruben

[Alec]

Personally, I'm with spm on this one. Excluding files by requiring exact, short/long pathname syntax is a bug. NOD32 should convert all exclusions entered into the long pathname version using the Win32 GetLongPathName (http://msdn.microsoft.com/library/en-us/fileio/base/getlongpathname.asp?frame=true) function; and then whenever it sees a filesystem "open", "create", or "execute" call, it should once again convert the pathname in question to the long version prior to comparing it against the exclusion list. Short pathnames still have a unique, one-to-one mapping with long pathnames, it's just that they are cryptic and few people would expect to be forced to use both forms in setting exclusions. I don't see why this is even an issue.
???

[Blackspear]

{QUOTE-> Personally, I'm with spm on this one. Excluding files by requiring exact, short/long pathname syntax is a bug. NOD32 should convert all exclusions entered into the long pathname version using the Win32 GetLongPathName (http://msdn.microsoft.com/library/en-us/fileio/base/getlongpathname.asp?frame=true) function; and then whenever it sees a filesystem "open", "create", or "execute" call, it should once again convert the pathname in question to the long version prior to comparing it against the exclusion list. Short pathnames still have a unique, one-to-one mapping with long pathnames, it's just that they are cryptic and few people would expect to be forced to use both forms in setting exclusions. I don't see why this is even an issue.
??? <-QUOTE}
Agreed, a customer should not have to learn how to make a short name, they should just be able to browse to the file and click on it...

Cheers ;D

[DonKid]

I agree too..

I tried this configuration:

C:\Arquiv~1\Agnitum\outpos~1\outpost.ini.

But it´s funny, because I stopping scanning using the old way:

C:\Arquivos de programas\Agnitum\Outpost Firewall\outpost.ini .

But I think it could be done automatically, only chosen the files.
Anyway, I hope Eset fixes not only this bug, as the lsass.exe bug for our friend Blackspear.

:D

Best Regards,

DonKid.