When I've seen malwarish code distributed by security resources, it has always been at least one of these:

• Already in the wild
• Solutions to thwart it are already available
• The code has been very carefully modified to introduce several subtle bugs
• It is intentionally very vague, intentionally leaving out some key ideas required to make it work
• It is a reaction to some other organization not dealing with a security issue in a manner that was considered acceptable by the distributor of the malware

And this last item I find close to the concept that "cracking is good because it gets people to increase their security". Although I think that you can do some very careful cracking to bring home a point about a lack of security, I find it immoral to do damage while doing that. And handing out tools that can be used by others who probably don't agree with me on that is not a good idea in my book.

I never said "don't talk about it". I don't find the working code very interesting. The concept is simple enough that I don't think the working code adds much to it. To stop such a virus you need to prevent/detect modifications to files. The details about how the modifications are done are mostly irrelevant and concentrating too much on them gets you a solution that isn't robust anyway.

It is like untainting variables by trying to think up which characters you want to exclude. You are bound to miss some. Instead, specify which characters that you know aren't going to be a problem. For a virus, you need to figure out ways that scripts can be modified safely and how to prevent/detect all other modification, not just the modification methods highlighted by a proof of concept.

        - tye (but my friends call me "Tye")