Classic VB Corner

Are You Safer Now?

Virus detectors can detect more than just bugs -- Karl encounters one such system set off by his code, and shares how he worked around it.

• By Karl E. Peterson
• 01/29/2008

I was happily coding away on a new utility a couple of weeks ago and had just recompiled it when my virus checker threw me one of those nasty dialogs saying it had just deleted my new creation. I immediately blamed the IT department, of course, as they had just pushed out a new version of McAfee VirusScan Enterprise. Curse them and the ePolicy Orchestrator they rode in on, anyway! Natural reaction, right?

Well, because I didn't have time to figure out how to break their newest security implementation just so I could continue the job at hand, I had to instead start thinking what I might have done that could've triggered the virus alert. McAfee was telling me I'd created a "Keylog.gen" Trojan -- apparently, a keylogger of some sort. I was able to disable McAfee long enough to compile, ZIP and upload the executable to my Web site so I could ask others to take a look at it. Of course, I sent an appeal immediately to McAfee's vendor questions e-mail alias asking them to update their definitions as this was obviously a false positive.

Keylogger, hmm? I disabled the hotkey detection, as that was really the only keyboard interaction this utility used. Recompiled to no avail. What could it be? I had added a slew of new features to the utility that afternoon, naturally. My past experience with false positives was that they were often set off by seemingly random byte sequences, most often far outside the control of the developer, as they were simply the compiler output. I tried resetting some of the compiler options, recompiling -- and was again thwarted.

Had to think: What characteristics of a virus/trojan did my little utility bear? A friend who was testing it for me -- AVG didn't jump to the same erroneous conclusion on his machine as McAfee did on mine -- happened to ask how I coded up the autorun feature. (Insert light bulb joke here.) Duh! My globals class module contained the following statement:

Const RunKey As String = _
   "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Call it a wild hunch, but I modified the routine that was actually writing to the registry and recompiled. End of dilemma! Listing 1 shows what the final routine looks like. Turns out, all I had to do to avoid the security alarms was to build the troublesome string at runtime, rather than hardcode it.

You can use this code in your applications to tell Windows to start them up (or not, depending on the value assigned to the optional Enabled property) every time the current user logs in. If you were running with administrative privileges and used HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER, Windows would start your application for every user that logs on. A well-behaved application will always offer the user an obvious method to toggle this setting, and preferably not default to autorun.

As you've seen, sneaking through the security screening process can -- and often is -- as simple as rearranging a few characters in a string. Basically, it's like crawling under the velvet rope when the guards gaze away. The simple truth is, from an API perspective, Windows is no more secure now than it was 10 or 15 years ago. All the hand-waving (wringing?) over the "New & Improved!" security features is just that, and not all that different from the gratuitous hassle you endure each time you have to fly; the underbelly of the plane is still stuffed with uninspected cargo. So the question remains: Are you any safer now than you were four years ago?

Postscript: McAfee never did respond, so their definitions remain suspect.