Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: How does ZASS increase scan speed THIS much on subsequent scans?

  1. #1
    lalittle Guest

    Default How does ZASS increase scan speed THIS much on subsequent scans?

    I've noticed that when I scan certain files, it can take quite
    a long time for the scan to finish -- I've seen large exe files take from 4 to 20 minutes.
    When the same file is scanned a second time, however, it can take only ONE second to scan the same file.
    At first I figured this was due to caching, but even with caching, this just seems like TOO much difference in time.
    It appears that ZASS is either 1)
    not
    actually "scanning" the file on subsequent scans, or 2) that something was "wrong" the first time it scanned the file, and it should have scanned much, MUCH faster
    in the
    first place.
    It "feels" like
    it's just reiterating the result from the previous scan.
    I can even reboot the system and copy/rename the file, and re-scanning these files STILL only takes a second or two.
    Once the file is scanned, NOTHING
    appears to
    make ZASS go back to taking several minutes to scan this file.
    What is ZASS doing such that it can scan a file in one second that took several minutes the first time, and how can it do this after a reboot or copying/renaming the file?
    Something really doesn't seem right here.
    I've noticed this behavior on more than one system (a P4 2.5 and a dual P3 1Gig), so it's not related to the system.
    Thanks,
    Larry

  2. #2
    lalittle Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    Based on the behavior, it appears that ZASS is simply NOT scanning these files now.
    Once files have been scanned, it behaves similar to the way it behaves when you scan network drives, where it simply does not scan them.
    It's as if ZASS remembers the files that it's scanned, and skips them if it's already scanned them.
    Once again, this is NOT an issue with the files being cached in memory since it still scans these previously scanned files
    INCREDIBLY fast after a boot, and it scans copies of these files just as quickly, even if they are renamed or the extension is manually changed.
    Any feedback on this would be appreciated since the behavior is a bit troubling.
    I've never seen this behavior with other scanners, which in my experience always
    re-scan files EVERY time you scan them, which takes the same amount of time on subsequent scans.
    It really "feels" like something is wrong -- i.e. it seems like a malfunction that these file is not actually re-scanned, which they clearly are NOT.
    The increase in speed is WAY more than can be
    caused simply
    by caching.
    Thanks,
    Larry

    Message Edited by lalittle on 12-03-2007 09:29 PM

  3. #3
    lalittle Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    I've done a lot of reading on this, and I've found references to the fact that the Kaspersky engine creates some sort of database based on the checksum of files and checks this database when it scans a file.
    If the checksum is the same as it was the last time the file was scanned, it determines that the file does not need to be scanned again and skips it.
    This would explain the behavior I'm describing above, but I'm unclear if ZA incorporates this feature, and if it DOES do this,
    it brings up some other questions.
    First, if a file is renamed, wouldn't it change the checksum, thereby flagging the file to be scanned the next
    time?
    I thought that the checksum was changed every time the file was modified at ALL.
    Wouldn't renaming the file quality?
    At this time, changing the name of the file and/or the extention does NOT make ZA scan it again the next time -- it continues to be skipped.
    Second, why don't subsequent scans take VASTLY less time?
    The VAST majority of files on a system do NOT change from one scan to the next, so it would follow that a HUGE portion of the files would NOT need to be scanned on subsequent full scans.
    This, however, does not appear to be the case -- subsequent full scans still take quite a while to finish, which would indicate that "most" files are re-scanned every time.
    I've read that only certain file types are "skipped" via this checksum method, but I'd still think that the time should decrease more than it appears to on full scans.
    I'm trying to more fully understand the "overall" system here, and I can't seem to get it to fully make sense -- I can't make
    ALL the behavior traits line up into a single, coherent picture.
    For example, if the checksum makes the scanner skip files that haven't changed, then why did these files take such a long time to scan earlier today even though I have done
    several full scans on this system already?
    Does the checksum only get set when doing "On-Demand" scans?
    Thanks again for any feedback on this,
    Larry

    Message Edited by lalittle on 12-03-2007 10:57 PM

  4. #4
    prof_fate Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    Perhaps The Fact that Kaspersky AV is Rated the
    #1 Best AV in the world is one reason Checkpoint chose to Include Kaspersky SKD AV Engine into the Zone Alarm ZAAV & ZASS product..
    Here is some more Research Data for you..
    Here is aThe best protection compared to Symantec, McAfee, Trend Micro, CA and Microsoft!
    http://usa.kaspersky.com/products_se...-in-action.php
    ---------------------------------------
    Here is My XP Configuration:
    Operating System: Windows XP SP2 Home with IE7 MS Outlook 2003
    HP Pavilion - Intel Pentium IV 3.0 GHz 2GB DDR2

    ZoneAlarm Security Suite version:7.1.078.000
    TrueVector version:7.1.078.000
    Driver version:7.1.078.000
    Anti-virus engine version:3
    Anti-virus signature DAT file version:20071130175000
    Anti-spyware engine version:5.0.162.0
    Anti-spyware signature DAT file version:01.200712.2945
    AntiSpam version:5.0.0.8843


    Message Edited by Prof_Fate on 12-04-2007 07:40 AM

  5. #5
    zulu Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    That's how Kaspersky iSwift works. When scanned, each file is assigned a unique ObjectID (a type of NTFS Extended Attribute), which is stored in the NTFS index. Kaspersky also uses a separate iSwift database (fidbox.dat) which is used to store all of the ObjectIDs plus other information about each file. A Kaspersky driver keeps an eye on the entire filesystem, and whenever a file is changed this information is entered into the iSwift database. During scanning the Kaspersky engine looks at the information in the iSwift database and matches it up with each file's ObjectID in order to skip unchanged files. At least, that's how I understand it. This is not official Kaspersky information, rather it's an understanding that I have pieced together after a great deal of reading and personal testing. I may be a little off, but I think it's generally correct.

    Editing or renaming a file doesn't seem to change its ObjectID, so I assume that the KAV engine uses the ObjectIDs simply as a way of uniquely identifying each file. All of the "heavy lifting" is apparently done by the driver and the fidbox.dat database. One can only assume that the Kaspersky driver does not consider renaming a file to be a virus threat, and thus the file is not marked for rescanning. However, try editing one of those files and see what happens!

    The situation is complicated by the fact that new antivirus definitions are being added at regular intervals (i.e. hourly), and thus the rescanning of unchanged files also needs to occur in order to test them for newly discovered threats which may have been missed by the previous scan. I'm not sure which particular logic the Kaspersky engine uses to handle this scenario. My guess is that each entry in the fidbox database also lists the particular version of the antivirus database that was used to perform the most recent scan of each file, and by using this information the scanning engine somehow decides which files can be safely skipped. There has to be some sort of a tradeoff, otherwise it would need to rescan every single file each time a new virus definition was added.

    I'm not saying that all of this embedded KAV technology is a good thing. In fact, it has caused me all sorts of trouble and I ended up uninstalling ZoneAlarm because of it. I couldn't get chkdsk to run properly until I removed ZoneAlarm and manually cleaned out all of the ObjectIDs, and it took me weeks to figure out how to do it.

  6. #6
    lalittle Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?


    <blockquote><hr>Zulu wrote:
    That's how Kaspersky iSwift works. When scanned, each file is assigned a unique ObjectID (a type of NTFS Extended Attribute), which is stored in the NTFS index. Kaspersky also uses a separate iSwift database (fidbox.dat) which is used to store all of the ObjectIDs plus other information about each file. A Kaspersky driver keeps an eye on the entire filesystem, and whenever a file is changed this information is entered into the iSwift database. During scanning the Kaspersky engine looks at the information in the iSwift database and matches it up with each file's ObjectID in order to skip unchanged files. At least, that's how I understand it. This is not official Kaspersky information, rather it's an understanding that I have pieced together after a great deal of reading and personal testing. I may be a little off, but I think it's generally correct.

    Editing or renaming a file doesn't seem to change its ObjectID, so I assume that the KAV engine uses the ObjectIDs simply as a way of uniquely identifying each file. All of the &quot;heavy lifting&quot; is apparently done by the driver and the fidbox.dat database. One can only assume that the Kaspersky driver does not consider renaming a file to be a virus threat, and thus the file is not marked for rescanning. However, try editing one of those files and see what happens!

    The situation is complicated by the fact that new antivirus definitions are being added at regular intervals (i.e. hourly), and thus the rescanning of unchanged files also needs to occur in order to test them for newly discovered threats which may have been missed by the previous scan. I'm not sure which particular logic the Kaspersky engine uses to handle this scenario. My guess is that each entry in the fidbox database also lists the particular version of the antivirus database that was used to perform the most recent scan of each file, and by using this information the scanning engine somehow decides which files can be safely skipped. There has to be some sort of a tradeoff, otherwise it would need to rescan every single file each time a new virus definition was added.

    I'm not saying that all of this embedded KAV technology is a good thing. In fact, it has caused me all sorts of trouble and I ended up uninstalling ZoneAlarm because of it. I couldn't get chkdsk to run properly until I removed ZoneAlarm and manually cleaned out all of the ObjectIDs, and it took me weeks to figure out how to do it.
    <hr></blockquote>Thanks Zulu -- that pretty much fills in all the
    gaps in my understanding of why it behaves the way it does.
    One question on the last part of your response:
    I had read about that chkdsk issue, but the information I saw said that this issue was resolved, and that it wasn't an error with KAV after all, but rather an issue with the way windows worked.
    I also read that
    as long as you did the disk scan on
    reboot -- which windows seems to do by default now -- this shouldn't be an issue.
    Is there more to this issue that I should be concerned about?
    Is there some
    way to avoid this issue and still do
    scandisk or chkdsk
    scans?
    Thanks,
    Larry

    Message Edited by lalittle on 12-04-2007 04:40 PM

  7. #7
    zulu Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    Well, there's quite a lot to discuss. First of all, have you read this thread?
    http://www.dslreports.com/forum/r186...t-me-at-ISwift

    There's also a very long thread on the Kaspersky forum, here:
    http://forum.kaspersky.com/index.php?showtopic=14995

    These threads started out as ordinary discussions, but unfortunately the topic morphed into a battle between a number of angry computer users who felt betrayed by Kaspersky Labs and the many Kaspersky loyalists who chose to defend their chosen product and company, and you will see quite a lot of emotional discussion between these groups in the two threads, along with quite a bit of useful information (if you can see through the smoke). Over time the heat has died down a bit, but the issue remains the same. Anyone who has done a full virus scan with any of the affected Kaspersky or ZoneAlarm products (plus the old version of AOL &quot;AVS&quot; and several other products that use the Kaspersky 6 or 7 engine) will have tens of thousands of ObjectIDs added to their NTFS indexes, and these ObjectIDs will be non-removable by any ordinary means, even if you uninstall the program that created them. (However, there are at least two unofficial and fairly experimental ways to get rid of them, if you dare.)

    I don't consider the issue to be resolved, and it's obvious to me that Kaspersky Labs caused the problem due to their improper usage of extended attributes. The ObjectIDs were never meant to be added to every single file in the NTFS filesystem, and chkdsk was never written with the expectation that they would be. Kaspersky Labs also erred in failing to provide a removal tool.

    In most cases the ObjectIDs seem to be relatively harmless, serving only to increase the chkdsk scanning time (the primary symptom will be a significant pause at the beginning of Stage 2), but some users have found that chkdsk won't even run properly until the ObjectIDs are removed. There has also been some conjecture that the excessive numbers of ObjectIDs might be causing other issues as well, but so far this hasn't become a major topic of discussion.

    If all you are seeing is the Stage 2 pause and nothing else seems to be going wrong then you are probably fine and you should be able to ignore the entire issue. That would be my advice. However, if you are in the minority that has experienced worse symptoms, then welcome to my world. In this case you will probably want to try running the fsutil procedure that is described in the DSLReports thread.

    Incidentally, you mentioned that on your computer chkdsk is running on reboot. Do you mean it is doing this automatically? This does not normally occur unless your drive has been marked as &quot;dirty&quot;, and that's not good. (This is different than manually scheduling checkdisk to run on the next reboot, which is fine.)

  8. #8
    lalittle Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    Thanks for the info -- I'll take a look at those threads.
    <blockquote><hr>Zulu wrote:Incidentally, you mentioned that on your computer chkdsk is running on reboot. Do you mean it is doing this automatically? This does not normally occur unless your drive has been marked as &quot;dirty&quot;, and that's not good. (This is different than manually scheduling checkdisk to run on the next reboot, which is fine.)
    <hr></blockquote>Sorry -- I didn't mean that it was doing scans automatically on reboot.
    What I meant was that when you run a scan with the &quot;Automatically fix errors&quot; option checked on a drive that has files locked (i.e. the system drive), it will ask to schedule the scan the next time the system is booted.
    This is normal behavior when scanning the system drive, or (as far as I know) even another drive if files are currently locked on it..
    Larry

  9. #9
    lalittle Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    I just found these statements from one of the ZA gurus in another ZA thread.
    This was in response to people concerned about potential &quot;corruption&quot; issues from the iSwift technology that we've been discussing here:
    &quot;the problem is that iswift/ichecker is NOT implemented in ZASS&quot;
    and
    &quot;ZASS/ZAAV does NOT use any iSwift technology... its simply not there in the SDK KAV OEM package. Its a separate add-on....
    If this is the case, than how can subsequent scans be instantaneous on files that have not changed?
    Based on the behavior of the AV in ZASS, it seems like the iSwift technology HAS to be being used by ZA.
    Does anyone have the straight story on this?
    Thanks,
    Larry

    Message Edited by lalittle on 12-04-2007 07:58 PM

  10. #10
    zulu Guest

    Default Re: How does ZASS increase scan speed THIS much on subsequent scans?

    <blockquote><hr>lalittle wrote:
    I just found these statements from one of the ZA gurus in another ZA thread. This was in response to people concerned about potential &quot;corruption&quot; issues from the iSwift technology that we've been discussing here:&quot;the problem is that iswift/ichecker is NOT implemented in ZASS&quot;and&quot;ZASS/ZAAV does NOT use any iSwift technology... its simply not there in the SDK KAV OEM package. Its a separate add-on....If this is the case, than how can subsequent scans be instantaneous on files that have not changed? Based on the behavior of the AV in ZASS, it seems like the iSwift technology HAS to be being used by ZA.Does anyone have the straight story on this?Thanks,Larry

    Message Edited by lalittle on 12-04-2007 07:58 PM
    <hr></blockquote>

    I have heard several denials by both gurus and technical support personnel, but I believe they're wrong. Run a search for fidbox.dat and fidbox.inf on your C drive. Those are the iSwift database files, installed by ZoneAlarm's Kaspersky-based antivirus component. They're active, too. Also, the iSwift-related ObjectIDs will be created whenever you run a scan, and I can show you how to check for those if you like. This was all in place when I last ran ZASS v7 (several months ago), and even then the gurus were claiming that ZoneAlarm didn't have iSwift. OK, maybe it didn't have iSwift's user interface, but the feature itself was installed and active. Of course, it's always possible that this has all changed since I last examined ZoneAlarm. Why don't you have a look for yourself and see if those files are there? I'd like to know.

    edit: Typo. Instead of fidbox.inf I meant to say fidbox.idx.

    Message Edited by Zulu on 12-05-2007 02:29 AM

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •