SOS! Amon does not scan NISIDE runtime packers!! (but the scanner does...)

Discussion in 'NOD32 version 2 Forum' started by Ainur, Dec 26, 2003.

Thread Status:
Not open for further replies.
  1. Ainur

    Ainur Guest

    I'm testing Nod32 and have come accross a most alarming issue.

    I tested Amon on a program called Ghost Mail 5.1 (GM51.EXE).

    Yes, I know it's not a virus/worm, only a blacklisted app, but since I'm only checking out Nod's signatures verification, using a known virus or a known non-viral application amounts to exactly the same thing...

    Problem is simple: when I tried to access, create or run GM51.EXE, Amon popped in, detected and blocked it. So far, so good.

    Now here's where the horror started: I PACKED the gm51.exe file with upx and called the second, packed app 'gm51_upx.exe'.

    -> when I ran this new file, AMON DID NOT DETECT & BLOCK IT! :mad:

    On the other hand, Nod32's on demand(/i] scanner did detect the app in both its original AND packed form.
    But NOT AMON.

    And it's true, as advertised on the site, Nod32 CAN scan inside packed files(upx, and others I hope). But what they mean is that ONLY the on-demand scanner can do that. Amon can't.

    And that's dangerous. EXTREMELY dangerous.

    The problem is that no AV's resident monitor protects the MEMORY. Only the FILES are scanned on access. Memory can only be scanned on-demand. In fact, the only 2 programs whose monitors scan the memory are 2 Anti-TROJANS called TDS and TrojanHunter.

    And I discovered something very interesting about runtime packers, which very few are probably aware of: RUNTIME PACKERS UNPACK DIRECTLY INTO MEMORY, unlike self-extracting archives.

    So the upshot of this is that since Amon does NOT scan inside the packer when it is being accessed, and since on the other hand Amon (and no other AV monitor for that matter) CANNOT scan the memory itself, this makes packed virii/worms or even packed trojans or other malware particularly deadly in the case of Amon, even if the virus or app is known, ie. listed in the definitions base.


    So my question (for ESET technicians preferably) was, are there any plans to make AMON able to either scan inside runtime packers, or EVEN BETTER protect the memory itself?? Given the way that runtime packers work (ie. unpacking into memory), this matter appears to be most urgent. Any positive substantial feedback would be greatly appreciated :doubt:
     
  2. embower

    embower Registered Member

    Joined:
    Dec 19, 2003
    Posts:
    46
    I also had this circumstance :oops:
     
  3. sir_carew

    sir_carew Registered Member

    Joined:
    Sep 2, 2003
    Posts:
    884
    Location:
    Santiago, Chile
    Hi,
    I test with yaemb, a mail bomber. I compress this with UPX and you've reason, AMON don't caught this, however the scanner detect this.
    I believe that ESET is working on this.
     
  4. Ainur

    Ainur Guest

    MAYBE, but which of the 2 options are they considering?

    - If they choose to give Amon the ability to scan "everything", ie. even inside UPX files, then the users are in deep sh*t. Let me explain:
    Amon does not use Advanced Heuristics. But there are some trojans such as Xenozbot that can ONLY be detected this way IF the signature test fails. And in the case of this trojan, it does fail, as Amon only detects this trojan in ONE (not all) of its PACKED upx forms. If I unpack it and/or repack it with another upx method, Amon does not detect it (SHAME! They should only store the UNPACKED signatures in the definitions base).
    So suppose that they do give Amon the ability to scan inside upx, aspack, etc... packers. EVEN SO, THERE WILL ALWAYS BE SOME PACKER FORMATS WERE AMON FAILS - it is...inevitable. Even AVs such as DrWeb and KAV, whose memory monitor's engines have an extensive database of packer methods, fail with the signature scan on some packers, because as I said NO AV monitor can cover ALL methods.

    SO THE ONLY ALTERNATIVE IS TO STORE ALL THE UNPACKED SIGNATURESIN THE DATABASE AND LET AMON SCAN THE MEMORY DIRECTLY!!!

    And don't anyone tell me that this will slow it down - on the contrary, it might even speed it up: Take Trojan Hunter for example - its memory guard (THguard) DOES scan the memory itself, yet it is much faster than TDS. And since it scans the memory, no trojan whose unpacked, true signature is in the definitions base can escape THguard, no matter what packing method, present or future, is used!

    So any ESET wizard plz answer me - knowing that runtime packers unpack directly into memory (if I know this, I'm sure the Eset guys also do, don't they? ;)), won't they give Amon the ability to 1) scan memory and 2) scan according to file HEADERS (type) - like DrWeb does - and just just according to mere file extension?

    Awaiting positive feedback. I'm sure the technicians are aware that this is pone of the most urgent matters, if not the MOST urgent matter, to attend to. If they do nothing, then the Virii win - all the hacker has to do is pack his virus/known trojan using an UNKNOWN method and voila, the virus cuts through Amon (or any other AV present AV monitor) like a knive through butter...
     
  5. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    This was posted a while ago:

    Cheers :D
     
  6. sir_carew

    sir_carew Registered Member

    Joined:
    Sep 2, 2003
    Posts:
    884
    Location:
    Santiago, Chile
    I'm not agree.
    I agree that some files like zip aren't dangerous until you decompress this, however the packed files like UPX, asPack, etc. are dangerous, because no action to decompress is needed, you can be infected only executing them.
     
  7. blaster14

    blaster14 Guest

    Its same as to compress yaemb mail bomber with UPX, then with ZIP and then with RAR. AMON dont cought this :D And I hope, that ESET working on more important things :D

    On-access scanner (AMON) must be fast and the best chance is to make new signatures for packed form of virus.

    This is main thing, why Rokops AV tests (and their "brilliant" packer tests) and others lamer tests will be still gimcrack.
     
  8. Ainur

    Ainur Guest

    U still don't get it, do you? :mad: Read my previous posts - the difference between runtime packers and simple archives is that RUNTIML E PACKERS UNPACK DIRECTLY INTO MEMORY, making a packed virus extremely deadly.

    So the only way to avert such threats is to 1) Include the true, non-packed signatures in the definitions list and 2) give Amon the ability to scan inside packers AND MOST IMPORTANT of all: give Amon the ability toscan memory itself!!!
     
  9. ano5

    ano5 Guest

    @Ainur

    You are basically right. But this is old news. Currently, NOD32 is one of the fastest AV scanners on the market. If it had an on-access scanner /w unpacking support it would probably be one of the slowest AV scanners (since NOD32 advanced heuristic scanning is very slow). In other words, NOD32 would lose its uniqueness ...

    If you use NOD32 as a pure AV scanner ( = for detecting replicating malware like viruses and worms) you will not miss an unpacking engine that much. Eset will simply create a new signature for every compressed ITW virus or worm. This will not take very long since replicating malware spreads itself quickly and, therefore, gets known to Eset. (Trojans are a completely different thing of course.) On the other hand, an unpacking engine would facilitate heuristic scanning and protect users even more quickly. In summary, the question is whether an on-access unpacking engine is worth the speed penality. Personally, I do not use an on-access scanner at all ...

    I fully agree that every AV scanner should have a sophisticated memory scanner. Currently, a few AV software producers try to develop a mem scanner ... let's hope they will be succesful. This would encourage others to do the same.


    @Blackspear

    You are basically wrong since you fail to distinguish between self-extracting archives (like WinZIP, WinRAR, WinACE) and run-time compressors (like UPX, ASPack etc.).

    @blaster14

    You are basically a troll, aren't you?
     
  10. Ainur

    Ainur Guest

    Re:SOS! Amon does not scan INSIDE runtime packers!! (but the scanner does...)

    ano5 >

    You are correct when saying that such countermeasure might slow down the Nod - but the speed loss would be kept to a minimum - I believe that adding an unpacking engine to Amon (ie. letting it use the same engine as the on-demand scanner) would take MUCH LESS time than adding compressed signatures as U suggested - imagine, just for UPX, there are several settings for UPX packing available. I you count all the other unpackers out there, along with their own various settings, that would add to over 1000 signatures for each virus!!!!!

    Not to mention custom-made packers ... and against these, only MEMORY SCANNING (for the AV resident monitor) can effectively parry against such threats. That's how THguard works, and yet TH is one of the fastest ATs out there, if not the fastest. On the other hand, THguard uses no unpacking engine, but this is not needed as it scans memory itself, TH only has UNPACKED signatures in its database.

    So even though I deem that UNPACKED signatures, and only these, should be added to the base, and that the use of an unpacking engine should be added to Amon, this is still not enough. Even KAV does not comprise ALL the packing methods that exist out there (although it can handle over 600 packer types).

    So memory scanning (for Amon) should be considered a foremost priority. I'm sure that the Eset guys know how runtime packers works (I hope! :mad:) and thus how dangerous they can be...

    You mean every AV resident monitor, I think (ie. Amon for Nod) - since every AV scanner already has the ability to scan mem. Which is not of much use, since a user can't guess WHEN an infection will occur. What AVs do you know of whose memory guards also scan the memory, and not just the accessed files? There are none that I've heard of so far..


    PS. too funny about the 'troll' part - a cave-troll, more like :D
     
  11. ano1

    ano1 Registered Member

    Joined:
    Dec 20, 2003
    Posts:
    27
    @Ainur

    1.
    Yes. I have nothing against a resident mem scanner. But also see http://www.wilderssecurity.com/showthread.php?t=18473 ;-)

    2.
    " that would add to over 1000 signatures for each virus!!!!!"

    No. I was talking about replicating ITW malware. Eset would only add a signature for those compressed variants which are actually found ITW. This dramatically decreases the number of sigs required. By contrast, the current Eset unpacking/heuristic engine is terribly slow. Eset does not have a faster one & it takes a lot of time to develop one.

    In summary, I do like scanners with unpacking engines. But I believe that Eset would actually lose customers if they slowed down NOD32 since incredible speed is its distinctive feature. Moreover, Eset's concept can't be that wrong since they constantly get the VB100 award.
     
  12. Ainur

    Ainur Guest

    True, an unpacking enginefor Amon could slow down the AV. But then, one can always say that what an AV gains of one hand (extra speed, for Nod), it looses on the other hand (no unpacking for Amon).
    So in the end, no AV is perfect... :'(
    And don't forget, between a ZOO virus and an ITW virus, the margin is but thin. Custom-made runtime-packers are bound to give the bad guys ideas, it's just a question of time.

    Interesting thread about CPM-II - so even the memory can be encrypted...

    But still, anything HAS to be unpacked/decrypted in memory at some point. So a memory scanner for the resident monitor would still be of some help. A nd as I said, unlike an unpacker for Amon, memory scanning for Amon would hardly slow down thee AV, if at all on a noticeable level
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.