Recently, we received some false positive (good emails marked as SPAM) and false negative messages (spam emails not detected) from our partners in Japan. It seems that our Antispam engine did not cope well with some messages written in Japanese. Fortunately, the problems were minor and easy to fix.

A large part of messages had a Message-Id header rewritten by an intermediary mail server which made the antispam engine think that those messages were forged (pretending to be sent by Microsoft Outlook Express). Theoretically, the Message-Id header should uniquely represent an email message all over the world. In order to make it unique, Outlook Express generates a Message-Id header having a certain pattern. That’s why, when we met the rewritten Message-Id header, which did not look like generated by Outlook Express at all, we thought that the messages were forged, and thus spam.

A small percent of the messages had a subject header that seemed strange to us, because it would use the same encoding many times. It looked like : Japanese(…) – Japanese(….) – Japanese(…) instead of simply Japanese(……….). Another method is to double encode the subject, like this: Japanese(… Japanese(….) …). After reviewing lots of legit messages written in foreign languages more closely, we concluded that this was not such an abnormal behavior, even though this pattern is often met in spam.

Another problem was with messages that were sent encoded with base64, without specifying the content type in the header. The content could have even been represented by 7-bit characters, so, it did not need any encoding. Spammers often use this pattern, in order to hide the message from Antispam filters that cannot handle base64 encoding. Instead of simply writing VIAGRA, they encode it in base64, the result being VklBR1JB. Normally, messages in foreign languages need to be encoded in base64, because the contents cannot be represented by ASCII characters, and most foreign language encodings need 8bit data. But the Japanese messages did not need base64, because they use a special encoding, iso-2022-jp. This encoding can handle both normal characters (ASCII) and Japanese characters, through a special symbol that switches modes. Apparently, the sender of the message did not know that, so they encoded the messages in base64 anyway.

An interesting fact with the spam emails written in Japanese is that they tend to be plain text (with the charset=”iso-2022-jp”) and also providing a rich content. These emails contain formatted text in form of paragraphs, bulleted lists and ASCII art, as can be seen in the picture below.

Fig. 1: Japanese spam mails.

Extrapolating, based on the spams we received, it seems that more than a half of the spams received by the Japanese are written in their language. The rest is in English.

Vlad Dinulescu
Software Engineer

Sorin Mustaca
Manager International Software Development

While fixing the false positive detection from a few days ago, PCTools managed to add a new false alarm in their Google Pack version of Spyware Doctor: Today, the program alerts the user that Avira’s ccev.dll contains the Backdoor.Bandok. Of course this is a false alert, the Avira software is clean.

We contacted PCTools again and hope that they remove the faulty signature as soon as possible. Until an update is available please deactivate Spyware Doctor from Google Pack.

Update:

PCTools published an update that remidies the issue. You can update Spyware Doctor and reactivate it again.

Dirk Knop
Technical Editor

Users of PCTools’ Spyware Doctor have gotten a false alarm: The Antispyware detects Avira’s aecore.dll as the Trojan CDur with a recent update. This is of course a false positive detection – something that Antimalware specialists try to avoid. We contacted PCTools to make sure they remove the false detection as soon as possible.

Anyhow, this false positive detection appeared and lead some users to block their aecore.dll which prevents Avira AntiVir from working correctly. As countermeasure, please deactivate your Antispyware solution, unblock aecore.dll and as soon as PCTools manages to remove the false detection, update and reactivate the Antispyware. Further information can be found in our forum.

Update:

The false positive detection was caused by the Spyware Doctor version from the Google Pack. In the meantime, an updated signature database is available. Users of the Google Pack/Spyware Doctor should update their database and reactivate the software.

Dirk Knop
Technical Editor

Tonight, we encountered an odd problem. Four MD5-sums displayed on our homepage didn’t match the “fingerprint” of the actual files on the servers. As precaution, we took our servers offline to analyse the servers and to see what has happened.

To our relief this was a false alarm. While uploading new installer-files to the servers, the responsible person forgot to properly update the checksums that help verifying that noone tampered with the files. We thoroughly checked every file on every server and could verify that all of them are in the state they’re supposed to be. Everything is back to normal operations now.

Dirk Knop
Technical Editor