just a quick update / mea culpa.
although i stand by the general sentiment expressed in my previous post about research not always being victimless, i've finally gotten a chance to look at the specific example of the polypack service (i was unable to before because the site was down and i had to go by what was written about it rather than what was actually on the site).
i don't know if this is a change from how things were previously, but the polypack service is currently not open to the public. that's great news. although it's still possible that some among the select few who do gain access will be untrustworthy, at least it's not a free-for-all, the people behind it did put some thought into the potential consequences - something that's all too rare these days.
it would still be better if they weren't creating new malware at all (why not pack the eicar standard anti-malware test file instead?), but i felt obliged to at least give them credit for not being completely naive about openness.
3 comments:
the following comment will be me pasting a comment i received in. i don't feel comfortable publishing the comment as is because of the included urls combined with my past statement of intent with regards to linking to malware friendly domains. as such i'm reposting a copy of the comment with the urls removed.
it's not that i outright distrust this person, but there is a clear philosophical difference on the matter of malware creation and i don't know what one might expect to see on that domain in the future.
Kurt,
The reason we didn't just pack the EICAR test file is the same reason
we originally did the research: both the antivirus engines and the
packer tools have great diversity in their capabilities and efficacy.
Our results show that even though an advanced packer like Themida is
the single best packer overall, it's not the best on every binary,
every time (over 40% of the time). Therefore, a system like PolyPack
allows you to automatically select the best packer for your specific
binary.
Anywho, I'd recommend looking over the materials. I've posted the paper
and the presentation I gave this week at WOOT:
[urls removed]
Regards,
Jon Oberheide
@jon oberheide:
fair enough - if i understand your implication correctly then some packers do a piss-poor job of obfuscating the eicar file.
i wonder if that holds true for all the modifications one can make to the eicar file while still conforming to the specification for that file (the specification states what the file must start with but literally anything can be appended at the end). then again, your statement about variance in av efficacy could apply there as some may do a piss-poor job of detecting the eicar file with a jpeg (for example) appended to the end.
Post a Comment