Help - Search - Members
Full Version: iChecker - what it does, what it does not
Kaspersky Lab Forum > Beta Testing > KIS\KAV\KTS\KSOS 2015 MR2
armadillo
I am trying to understand why iChecker makes so little difference to scan times.

I have read these threads, in which people make similar points:
http://forum.kaspersky.com/index.php?showt...027&hl=ichecker
http://forum.kaspersky.com/index.php?showt...388&hl=ichecker
http://forum.kaspersky.com/index.php?showt...292&hl=ichecker
and this description of iChecker:
http://forum.kaspersky.com/index.php?showt...319&#entry32319

I find almost no decrease in scan time through the use of iChecker. I wonder if this is because by far the majority of my files are non-executable.

The following is a quote from the Kaspersky Anti-Virus 6.0 Help file:
"There are limitations to iChecker: it only applies to objects with a structure that Kaspersky Anti-Virus recognizes (for example, .exe, .dll, .lnk, .ttf, .inf, .sys, .com, .chm, .zip, .rar)"

I assume .ttf is in that list because fonts are considered to be executable. Therefore .fon would also be included.

When I look at the log file from "Scan My Computer", I see that the only entries which are marked "iChecker" are for files with executable extensions. The majority of my files are non-executable and say "scanned" even though the files have not been changed since the last scan. In fact, I cannot find any example of a non-executable file which is marked "iChecker".

Is this intentional programming by Kaspersky Labs? KAV would surely "recognize" filetypes such as .bmp, .tif, .png, .txt and so on. I can only assume these are scanned because the iChecker database is only populated with entries for executable files (or archives which can contain them). Correct? If so, PCs that contain huge numbers of non-executable files will not benefit much from iChecker.

I have therefore applied some exclusion marks to .bmp files on one of my partitions (which contains tens of thousands of .bmp files) and so greatly reduced the scan times. I could, I imagine, apply an exclusion mask to the whole computer for all .bmp, .tif, .png, .jpg and some other special non-executable types (for example, .bgl). But novice users would not expect to define exclusion masks for non-executable files.

If, for some reason, Kaspersky Lab do not use iChecker for non-executables I wonder if you could include default exclusion masks for non-executable, and hence non-infectable, filetypes. Perhaps the experts could comment on whether this would create a security risk. But it seems to me that the risk would be no greater than from the default list of trusted modules, for example.

Any clarification would be most welcome!
Afrodude
iChecker only works if your databases haven't been updated too.
Its often quicker to scan files than to create the checksums for iChcker, hence why only select files types are "databased".
saso
Afrodude is right, you are assuming that iChecker should not scan files if they don't change since the last scan, this could be true in some cases, but generally this is not the logic by which this technology works. generally it work like Afrodude said, it will not scan files if they don't change AND if there are no new signatures, but actually i feel the real (secret) work of this technology (iChecker and iSwift) is even a bit more complex smile.gif

about iChecker and files like bmp, txt,.. i don't know exactly, maybe you are right and they are not included in iChecker, however there are other things that you seem not to know about. there are three different options for what types of files kav will scan. one of them is (1) all files, the second of they is (2) by file type, with this one kav will scan the file structure and analyze what file type it is, so for example if you have an exe file and rename it to something.txt, kav will still be able to see that this is actually an exe file, and the same is true the other way around. and then it is the third one that will scan files (3) by extensions. in this case for example if you change an exe file to a name like something.txt, kav will not know that this is exe.

the next thing is that when the options scan files by type or scan files by extensions are used, kav will automatically skip several file types that are considered as impossible to be infected/dangerous (for example txt). but kav will still scan differently depending on what option you use (scan by type or scan by extension). for example if you use scan by extension, and rename an exe file that is malware to something.txt, kav will skip it and NOT detect it! if however you use scan by type, kav will not care about the extension, but it will look inside the file to see what type it is, and since it is an exe it will still scan it and detect it.

the default setting is scan by type. so generally when you talk about true txt files, kav, with default options, should not scan them at all regardless of how iChecker works.

and there is more, if you are running kav on an NTFS disk then iSwift will be used most of the time instead of iChecker, because iSwift is faster...

then there is also the option to scan new and changed files only, at first this might sound as that it is the same as iChecker and iStreams, but it is not! and of course then there are also different levels of exclusions that can be set by user....

now this are just few thing you should know about when testing how and what kav scans, and i am sure there are few others smile.gif i guess what i would like to say is that there are several reasons why and when kav scans or does not scan an object.
armadillo
If I might take Afrodude's points first. I should have mentioned that I had not updated the virus database between scans.

I can see the point about about calculating a checksum perhaps taking longer than scanning the file. I expect that the time taken to calculate a checksum depends only on the filesize? So a 5 Kbyte .exe file will calculate much quicker than a 160 Mbyte .tif file. The 160Mbyte .tif file might indeed take longer to checksum than to scan.

Coming now to your points. That is a very clear explanation of the different options for what types of files kav will scan. I was aware of those and I should have realised that they are better than creating a default exclusion mask blink.gif . In particular, it is clear that scanning by content is safer than scanning by extension. But I think that what you say about the default being type 2 (by type) applies only to File Anti-Virus and not to Scan. For Scan, isn't the default type 1 (all files)?

I left the settings for Scan unchanged as "All files" (default for Scan). I then scanned a partition containing about 70,000 files, nearly all .bmp and .bgl files. These were scanned even though the files and the virus definitions database were unchanged, suggesting that my theory is correct about iChecker only applying to executable (or better terminology, infectable) files.

But as an experiment, I then changed the settings for Scan to make it use type 2 (by type). Indeed, the report then indicated "skipped by type" for the .bmp and .bgl files and the scan time reduced from 9'30" to 5'30".

By the way, for reasons which are outside the scope of this forum ( smile.gif ) I am using FAT32 and not NTFS so cannot use iSwift.

There is one thing you say that I do not understand at all:

"then there is also the option to scan new and changed files only, at first this might sound as that it is the same as iChecker and iStreams, but it is not! "

What other method is being used to determine that a file has not changed?
The following is another quote from the Help File, but perhaps I have misunderstood something?

"Enable iChecker technology - use technology that can increase the scan speed by skipping objects that have not been altered since the last scan, provided that scan settings (antivirus databases and settings) have not changed. Information about this is stored in a special database.
or example, you have an archived file that the program scanned and assigned the status of not infected. The next time, the program will skip this archive, unless it has been altered or the scan settings have been changed. If the structure of the archive has changed, because a new object has been added to it, if the scan settings have changed, or if the anti-virus database has been updated, the program will scan the archive again."
saso
ok, before i say anything else i have to first point out that although i know a lot about this i am still not the developer of this so i don't know ALL about it and some of my statement might be not complete or even wrong huh.gif

QUOTE(armadillo @ Jan 16 2006, 07:29 PM)
... about 70,000 files ... I am using FAT32 and not NTFS so cannot use iSwift...


ok i think i know exactly what is going on smile.gif as i remember there was a comment from KL developers (i think it was from Graf) that iChecker only has a limited number of entries in its database, so for example if you have a lot of files the last scanned files will start to "push out" the old entries and so when you do full system scan the iChecker will simple not work. however it should still work good for you with normal file anti-virus (real time protection)... there should be a post from KL developers about this somewhere in this forum, so you might like to search for it to confirm me and for more info about it smile.gif

QUOTE
There is one thing you say that I do not understand at all:

"then there is also the option to scan new and changed files only, at first this might sound as that it is the same as iChecker and iStreams, but it is not! "

What other method is being used to determine that a file has not changed?
The following is another quote from the Help File, but perhaps I have misunderstood something?


ok at first we have to say that there MUST be a difference between this two options since if there would be none then there would be no two options for it smile.gif however this is something i am really not sure about but anyway here is what i thing about it (since it seems logical to me).

by now i hope you understand that iChecker and iSwift have not so simple logic about when an object is scanned and when not. (please read the following sentence twice if needed because i didn't understand it at first by myself smile.gif ) the general idea of both of them is that they will both scan objects for ever, but they will skip it several times in between if some conditions are true (the object does not change, there are no new signatures,...)

on the other side the option "scan new and changed files only" has a much more simple logic, it is exactly what what is says "scan new and changed files only". which means that the objects will be scanned only the first time and then never again as long as they don't change.
Galileo 39
@ saso

I remember that Graf said with regard to iChecker that only a limited number of (file) formats was supported. I can't remember about a limitation with regard to the number of files. unsure.gif

Further I found in my records an extract from a post of Defenestration (some months ago) where he stated more or less the following: "KAV uses a geometric progression, with some randomisation, to decide when to rescan unchanged objects in real-time mode. This method is different to that used in KAV 5.0 where each unchanged object was automatically rescanned if the anti-virus database had changed and the quarantine period (1 year) had not expired." I agree with you, there are some "secrets" about this issue, and for obvious reasons Kaspersky will not teach us about the details.

I'm looking forward to observe the scan behaviour when I will have installed the same version for a longer period of time. wink.gif
saso
QUOTE(Galileo 39 @ Jan 16 2006, 10:04 PM)
KAV uses a geometric progression, with some randomisation, to decide when to rescan unchanged objects in real-time mode.


yes, i remember this, but to be honest i have no idea what does this mean blink.gif but i hope it is what i hope it is as i said above, the the files will be scanned _for ever_, but they be will skipped in between if some conditions are true (the object does not change, there are no new signatures,...). because i did not fully like the idea of kav5 where they would be absolut after 356 days in recomended mode and 14 days in fast mode
saso
QUOTE(Galileo 39 @ Jan 16 2006, 10:04 PM)
I remember that Graf said with regard to iChecker that only a limited number of (file) formats was supported. I can't remember about a limitation with regard to the number of files.  unsure.gif


well i was also not 100% sure but i was right after all, there it is post #13 http://forum.kaspersky.com/index.php?showtopic=6027

thank you my memory still seems to be ok smile.gif
Galileo 39
QUOTE(saso @ Jan 16 2006, 10:29 PM)
... thank you my memory still seems to be ok smile.gif
*

I stand corrected! smile.gif
armadillo
QUOTE(saso @ Jan 16 2006, 08:29 PM)
thank you my memory still seems to be ok smile.gif
*


You didn't need your memory. That was the first link I included in my original post wink.gif
saso
QUOTE(armadillo @ Jan 16 2006, 11:32 PM)
You didn't need your memory. That was the first link I included in my original post  wink.gif
*


smile.gif but i really did not read them, since your post was allredy long enought for me smile.gif but why you did not read it before posting, you would know the answer wink.gif
armadillo
QUOTE
iChecker only has a limited number of entries in its database, so for example if you have a lot of files the last scanned files will start to "push out" the old entries and so when you do full system scan the iChecker will simple not work. however it should still work good for you with normal file anti-virus (real time protection).


I was not convinced by that argument when I saw it in the original thread
http://forum.kaspersky.com/index.php?showt...027&hl=ichecker
and I am still not convinced.

I just tried scanning a single folder containing 11 .jpg files and one .log file. The events report said "ok scanned" for the .jpg files and "skipped by type" for the .log file. I then immediately scanned the same folder again. The report said exactly the same as before. If number of files had been the only thing preventing the use of iChecker, scanning a mere 12 files would have allowed iChecker to be used. But iChecker was not used and the files were rescanned.

I then scanned a folder containing just a .zip file and a .exe file. Event report said "ok iChecker". I immediately rescanned the same folder. Event report again said the same as before. This confirms that iChecker is used for .exe and .zip but not for .jpg.

QUOTE
ok at first we have to say that there MUST be a difference between this two options since if there would be none then there would be no two options for it

Not necessarily. You might choose to enable iChecker so that, having done a scan, you would have the possibility to exclude unchanged files. Whether you actually scan only new or changed files is then a second decision. If I uncheck the box for "enable iChecker technology" but leave "scan new or changed files only" and repeat the scan of the folder that contains the unchanged .zip and .exe, it reports "ok scanned" not "ok unchanged" or anything similar. If I then tick iChecker again and rescan, it says "ok iChecker". I concede that I am applying this experiment to Scan and not to File Anti-Virus. I cannot see any way to produce an event log for File Anti-Virus.

QUOTE
on the other side the option "scan new and changed files only" has a much more simple logic, it is exactly what what is says "scan new and changed files only". which means that the objects will be scanned only the first time and then never again as long as they don't change.


The experiment I have just described proves that statement to be false. The unchanged .zip and .exe were indeed scanned again until iChecker was re-enabled.

These experiments do suggest that the only thing being used to determine if a file has changed is the use of iChecker. And that iChecker is used for only a subset of filetypes.

I can understand if Kaspersky do not "for obvious reasons" (indeed smile.gif ) reveal the exact method of operation of iChecker. For example, I would not expect to see a definition of the checksum algorithm. But it would not present a security risk to know the common filetypes for which iChecker is not used. And this would provide a definite explanation of why iChecker has such a small impact on scan times. (Edit. It would however have a significant impact in a situation where there were a lot of large archives).

Be assured that I am not trying to crack any security here. I simply like to know what I am doing when I tick boxes in settings dialogues smile.gif And all the more so when those settings relate to a feature which is used as a marketing advantage.
armadillo
QUOTE(saso @ Jan 16 2006, 09:45 PM)
smile.gif but i really did not read them, since your post was allredy long enought for me smile.gif
*


True. I do tend to go on too long. tongue.gif Maybe I should stop now ? wink.gif
saso
QUOTE(armadillo @ Jan 17 2006, 12:33 AM)
True. I do tend to go on too long.  tongue.gif Maybe I should stop now ? wink.gif
*


oh no, it is ok, i hope in the end we will all understand a bit more of how exactly this works smile.gif because, as you said, it is good to know if you want to set the right options.
armadillo
QUOTE(saso @ Jan 16 2006, 10:58 PM)
oh no, it is ok, i hope in the end we will all understand a bit more of how exactly this works smile.gif because, as you said, it is good to know if you want to set the right options.
*


Thank you for being so gracious. I am also very aware that I am being verbose in my native language. I have much respect for your patience smile.gif
grnic
QUOTE(armadillo @ Jan 17 2006, 01:33 AM)
True. I do tend to go on too long.  tongue.gif Maybe I should stop now ? wink.gif
*

Hmm... I was not able to read all your long posts.. maybe, tomorrow ...or Graf will help me and give an answer smile.gif .
armadillo
QUOTE(grnic @ Jan 16 2006, 11:32 PM)
.. maybe, tomorrow ...or Graf will help me and give an answer  smile.gif .
*


If so, I shall try not to argue. The time of developers is precious. smile.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.