Unpacking ability of some AV's

Discussion in 'other anti-virus software' started by Blackcat, Nov 12, 2005.

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

    BlueZannetti Registered Member

    Joined:
    Oct 19, 2003
    Posts:
    6,590
    Folks,

    No posting of malware links in the forum, it's against the TOS. OK?

    Thanks,

    Blue
     
  2. ,.--.,

    ,.--., Guest

    I have compressed the Nimda variant (which is identified as Nimda A by NOD32 and Nimda C by Ewido), which can (still) be downloaded from VX Heavens (if you know where ;-). The compressor used was UPX 125w.

    NOD32 (signatures as of 18 May 2005) can detect it regardless of whether /AH is turned on or turned off.
     
  3. Happy Bytes

    Happy Bytes Guest

    BUMMER :rolleyes:
    This leads us to which conclusion?
    Yes right... TO HERE :rolleyes:
     
  4. Firefighter

    Firefighter Registered Member

    Joined:
    Oct 28, 2002
    Posts:
    1,670
    Location:
    Finland
    Thanks for the link. At least Jotti's has found something about it.

    Best regards,
    Firefighter!
     

    Attached Files:

    Last edited: Nov 13, 2005
  5. steve1955

    steve1955 Registered Member

    Joined:
    Feb 7, 2004
    Posts:
    1,384
    Location:
    Sunny(in my dreams)Manchester,England
    But surely if the AV can detect the malware it will be detected as soon as the run-time packer(no matter which one) executes?
     
  6. rdsu

    rdsu Registered Member

    Joined:
    Jun 28, 2003
    Posts:
    4,535
    @ avast! forum: Comparison of the speed of the leading antiviruses
    It seems that, beside you should be more likeable, you still have to learn something...
     
  7. gigaman

    gigaman Guest

    I don't think so. I don't know if any AV actually tries to scan an executable after it's been really started - but even if it does, it may be too late. As soon as the malware gets activated, it may e.g. kill the AV, delete files on disk, etc. - before getting scanned.
     
  8. Happy Bytes

    Happy Bytes Guest

    I sum it up: it's a "ScumTest". Thats it. I mean this guy doesn't have any technical expierence to make trustworthy av tests. And as confirmed from Nautilus the testresults are deadly wrong. How else is it possible that NOD32 detects this UPX packed Nimda? In the test results the georgeous av tester says: Nod32 was only able to detect the unpacked file" - SO MY QUESTION IS NOW: How do you explain the fact that the sample was detected with exactly the same runtime compressor you used? Tell me, i'm waiting...

    Then the next thing is: How can he ask a developer/researcher (me) to make a virus test for this rubbish website? Do you really think i go down to the level of amateurs to make rubbish virus tests? Besides, you should know that it wouldn't be a independed test if you ask someone from an AV company to do a virustest. Alone this fact disquallificates you. Period. E'nuf said.
     
  9. steve1955

    steve1955 Registered Member

    Joined:
    Feb 7, 2004
    Posts:
    1,384
    Location:
    Sunny(in my dreams)Manchester,England
    If thats the case the same would apply to ANY unpacked threat:-they could cause the same problem as a packed threat actually being unpacked either manually(Zip,Rar etc) or the execution of a run-time packer,I'm talking about real time monitoring,and not the deliberate scanning of an object,jumping on the threat
     
  10. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,432
    We kindly ask the tester to provide all the samples tested to Eset and an independent tester IBK who will test it against a July version of NOD32 with runtime packers and advanced heuristics enabled.

    You should have no objections if you are 100% sure your test was not flawed intentionally.
     
  11. ,.--.,

    ,.--., Guest

    @Michael

    I think your comments ("scum test") are too extreme. In principle, it is possible that the NOD32 installation was screwed up at the date the test was performed. Moreover, it cannot be ruled out that I made a mistake and that my non-conforming test results are wrong. There are many possibilities.

    It is my opinion that everybody is entitled to make mistakes. AV developers do. And testers as well. I think that IlyaOS did the right thing when he disclosed the Nimda version and the version of the packer. Other reviewers refuse to do that so that nobody can prove that they made a mistake. Consequently, we should not call this a "scum test".
     
  12. Stefan Kurtzhals

    Stefan Kurtzhals AV Expert

    Joined:
    Sep 30, 2003
    Posts:
    702
    Well but how do you 100% guarantee that the sample is not damaged by the packer? Even if it runs on the first look, some sub function might be trashed for example.

    There is no way for you to tell if the packer maybe damaged a part of the sample that is required for the detection by the av program. This can be even specific to a single sample, if you take another sample you might get other results.

    There is *no* reliable way to test unpacking, peroid. You actually need in-depth knowledge how AV programs actually do detect malware, and I seriously doubt that anyone except the engine programmers have this knowledge.
     
  13. Firefighter

    Firefighter Registered Member

    Joined:
    Oct 28, 2002
    Posts:
    1,670
    Location:
    Finland
    :oops:

    Best regards,
    Firefighter!
     
  14. Happy Bytes

    Happy Bytes Guest

    I do, because the guy wrote in the same time statements which are completely untrue. Such as "Nod scans with special sigantures over runtime packed files" - major bullshit.

    Next thing, that he asks me to make a av test does backup it.
    Then, posting this things across different forums and insulting readers ( just read the Vampiric_Crow reply in the AVAST forum ) is a bit too much. I started very "polite" in this thread by just replying with " :eek: :eek: :eek: ".

    But that this guy is trying to play the fool with me - sorry, i cannot accept this. I mean of course everybody makes mistakes (me included) but you should know when you have reached a level where it is better to admit that you did make a mistake instead of continuing to play the fool.
     
  15. ,.--.,

    ,.--., Guest

    @Skeeve

    "Well but how do you 100% guarantee that the sample is not damaged by the packer? Even if it runs on the first look, some sub function might be trashed for example."

    If I compress a sample (as you may know I am mainly interested in non-replicating malware) I use the corresponding server and try to connect and perform basic functions.

    You are correct that some (useless) subfunctions can be trashed. Actually, some hackers intentionally trash useless sub-functions (like the AV-killer function) because they know that some AV/AT developers pick signatures from such non-essential parts of the file. (In my opinion, it is a mistake to pick signatures from redundant parts of a file unless you use them as back-up sigs.)

    "There is no way for you to tell if the packer maybe damaged a part of the sample that is required for the detection by the av program. This can be even specific to a single sample, if you take another sample you might get other results."

    There are many reliable ways. For example, you can use a file splitter in order to extract the signatures used by a specific scanner. In such case, you know EXACTLY what's going on. Moreover, I have parts or even the entire signature database of scanners like Ewido, TDS or Trojan Hunter ;-)

    "There is *no* reliable way to test unpacking, peroid. You actually need in-depth knowledge how AV programs actually do detect malware, and I seriously doubt that anyone except the engine programmers have this knowledge."

    I agree that a perfect test would involve the engine programmers of the respective scanner. Unfortunately, they usually refuse to cooperate (i.e., they prefer telling lies etc. ;-).
     
  16. Happy Bytes

    Happy Bytes Guest

    And here is finally the screenshot - everyone can make up its own mind.
    I highlighted the important things.

    I'm switching into FireFighter-Mode now :D
     

    Attached Files:

    • upx.jpg
      upx.jpg
      File size:
      72.4 KB
      Views:
      30
  17. RejZoR

    RejZoR Registered Member

    Joined:
    May 31, 2004
    Posts:
    6,426
    No it's not that easy.

    ZIP extraction process:
    ZIP archive -> HDD -> Memory

    UPX decompression process:
    UPX packer -> Memory

    Now runtime packers lack the middle step and that is HDD. And without that middle step it's nearly impossible to detect it at runtime point except with Intrusion Prevention like Panda's TruPrevent or KAV2006 Proactive Defense.
    There you execute the malware and AV monitors what that program is doing.
    So basically you don't need packer support for it. But again this are only heuristics. Signatures still have to work regular way.
     
  18. IlyaOS

    IlyaOS Registered Member

    Joined:
    Nov 13, 2005
    Posts:
    29
    What version of Nod32 was in your test?
    May be you have used another engine that already can work with UPX.
     
  19. Firecat

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    8,192
    Location:
    The land of no identity :D
    The latest version of NOD32, version 2.50.25 (Win32), version 2.51.8 (Windows XP 64-bit) was used.

    This version DOES unpack UPX, as well as a lot more packers. I dont know about the previous versions, but this one does unpack UPX,ASPack, FSG, Petite, YodaCrypt and some more as well.
     
  20. Firefighter

    Firefighter Registered Member

    Joined:
    Oct 28, 2002
    Posts:
    1,670
    Location:
    Finland
    Cool! :cool: And thanks a lot! :)

    Btw, the Jotti's snapshot I've showed before in this thread was made to the sample itself, I just unzipped that file.

    Best regards,
    Firefighter!
     
  21. ,.--.,

    ,.--., Guest

    I used:

    NOD32 antivirus system information
    Virus signature database version: 1.1100 (20050518 )
    Dated: Mittwoch, 18. Mai 2005
    Virus signature database build: 5616

    Information on other scanner support parts
    Advanced heuristics module version: 1.013 (20050303 )
    Advanced heuristics module build: 1078
    Internet filter version: 1.002 (20040708 )
    Internet filter build: 1013
    Archive support module version: 1.030 (20050419 )
    Archive support module build version: 1117

    Information about installed components
    NOD32 For Windows NT/2000/XP/2003 - Base
    Version: 2.50.19
    NOD32 For Windows NT/2000/XP/2003 - Internet support
    Version: 2.50.19
    NOD32 for Windows NT/2000/XP/2003 - Standard component
    Version: 2.50.19

    Operating system information
    Platform: Windows XP
    Version: 5.1.2600 Service Pack 2
    Version of common control components: 5.82.2900
    RAM: 1024 MB
    Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992 MHz )


    What did you use?
     
  22. IlyaOS

    IlyaOS Registered Member

    Joined:
    Nov 13, 2005
    Posts:
    29
    That's it! In my test was used Eset NOD32 Antivirus System 2.12.3 [1.1130 (20050606) definitions] And may be this version didn't support UPX.
     
  23. Happy Bytes

    Happy Bytes Guest

    UPX implementation started with NOD v1.0
    Now please don't tell me that you did test the 1998 version :D
     
  24. Happy Bytes

    Happy Bytes Guest

    2.12 does unpack UPX. So what now? There's nothing else left what you can blame except wrong test conditions. :rolleyes:
     
  25. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,432
    It seems my appeal goes ignored:

    We kindly ask the tester to provide all the samples tested to Eset and an independent tester IBK who will test it against a July version of NOD32 with runtime packers and advanced heuristics enabled.

    You should have no objections if you are positive the test was not flawed intentionally.
     
Loading...
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.