Malware Spam Joy

Note: This entry has been restored from old archives.

Malware seems to be getting more straightforward these days, from a short while ago:

We are looking for Consumer opinions of our new software Digital Kittens

This beta testing will enable us to fine tune the software for public
release. For helping out, you will receive a free edition and 5 years of
updates.

1: Download the software  2: Try it  3: Tell us what you think If you
want to participate, just follow the link to our download site:

http://7w.2xx.2y.1zz/setup.exe

Who wouldn’t want free digital kittens?! You can play with beta kittens, help some company out, and get years of free digital kittens as a reward. How do you fight that wetware exploitation? “Don’t accept kittens from strangers.”? I have trouble getting over the point of view that “it’s damn obvious that you don’t execute unsolicited .exe files”, but the fact is this still seems to only be obvious to a minority of computer users. Got to have that AV installed! It’ll give you some protection, though probably wont be much use if you’re in the first wave of recipients of a properly engineered piece of malware that’s been tested against the AV engines.

VirusTotal.com tells me (with engines that failed to do the job edited out):

AhnLab-V3           Win32/Zhelatin.worm.140367
AntiVir             WORM/Zhelatin.Gen
Authentium          Possibly a new variant of W32/Fathom.3-based!Maximus
Avast               Win32:Tibs-BFG
AVG                 Downloader.Tibs.7.X
BitDefender         Trojan.Peed.IGS
CAT-QuickHeal       (Suspicious) - DNAScan
ClamAV              Trojan.Small-3637
DrWeb               Trojan.Packed.142
eSafe               Win32.Zhelatin.hq
eTrust-Vet          Win32/Sintun.AE
Ewido               Worm.Zhelatin.hq
Fortinet            W32/Tibs.GN@mm
F-Prot              W32/Fathom.3-based!Maximus
F-Secure            Email-Worm.Win32.Zhelatin.hs
Ikarus              Email-Worm.Win32.Zhelatin.hq
Kaspersky           Email-Worm.Win32.Zhelatin.hs
McAfee              Tibs-Packed
Microsoft           Trojan:Win32/Tibs.DV
NOD32v2             Win32/Nuwar.Gen
Norman              W32/Tibs.ASFB
Panda               W32/Nurech.AU.worm
Sophos              Mal/Dorf-E
Sunbelt             VIPRE.Suspicious
Symantec            Trojan.Packed.13
TheHacker           W32/Zhelatin.genw
VirusBuster         Trojan.Tibs.Gen!Pac.132
Webwasher-Gateway   Worm.Zhelatin.Gen

This kitten is diseased. Time to back over it’s poor little head with a car.

The Sun Came Back

Note: This entry has been restored from old archives.

The 2006 Summer here in the UK was stunning, endless long sunny days. I was won over for certain. This Summer, however, has been abysmal! Grey, rainy, and even rather cold some days! For a touch of good luck though all three days of the past “Summer Bank Holiday” long weekend were bright and sunny, perfect walking weather. Brilliant timing since Saturday was Kat’s b’day.

It was overcast again today :(

Sigh

Singles Club

Note: This entry has been restored from old archives.

A friend of mine was recently asked to jot down a C++ singleton implementation in a job interview, ah the venerable singleton. I guess we’ve all used it sometime or another, possibly trying to fit it into our designs just because it is cool.

Anyway, this dude is positively allergic to anything that looks inefficient. However, since threads are still considered cool locks become necessary, and locks are slow! So a seemingly common enhancement of the singleton is the “Double-Checked Locking Pattern”. This has the dual goals of supporting threaded client code safely and making optimisation junkies happy.

Singleton* Singleton::instance() 
{
    if (pInstance == 0) 
    {
        Lock lock;
        if (pInstance == 0) 
        {
            pInstance = new Singleton;
        }
    }
    return pInstance;
}

[[copied from the paper below]]

I wouldn’t opt for this myself, but I’ve seen it and would have used it if asked for (or I saw a need for) something more efficient. My default implementation would leave out the top level if wrapper, which is the part that makes it “Double-Checked Locking”.

However! It gets horribly complicated, my friend’s interviewer took issue with this implementation. The explanation being that a compiler implementation has the right to decide to assign pInstance to the allocated memory prior to actually executing the class construction code. This was met with disbelief, and when I was told about it I had a hard time believing it too. But things really can be this bad, for an in-depth coverage of the problems with the “Double-Checked Locking Pattern” have a read of this paper (PDF) by Scott Meyers and Andrei Alexandrescu (found in this DDJ article, page 4).

What a nightmare.

It reminds me of something someone I used to work with always said about the C++ standard: “watch out for the weasel words”. More clearly, watch out for the things the standard doesn’t promise.

My friend did get the job, despite the disagreement, and it sounds like a good one. Congratulations! Todo list for first day: eat humble pie. Or maybe: debate practicality of DCLP given constraints of known compiler and platform behaviour and the possible requirement for performance over portability? ;)


On a totally random note, why do so many well-known artists have (supposedly official) MySpace pages that totally suck? Try reading this, or this. (Ah, the aural fun of opening multiple myspace pages.) Maybe their web designers just can’t handle working without 100% flash?