This post is inspired mostly by an interesting post that was posted to the Computer Hope Forum. To summarise, this individual is looking to effectively re-enable Window’s ability to run USB flash drives automatically. There is quite a bit of griping about change, about how the user should be in control, etc. Fairly understandable.

While There is certainly some merit to the idea that a user should be able to configure their system how they want, to implicate that it is not possible is rather silly. Though the software as provided has had that feature removed, there is always the option to write your own solution. Of course without programming expertise, you may be lead to ask for such a program on a forum. In fact, that is exactly what the post is about- It’s asking for a free segment of batch script based on slightly vague but mostly understandable requirements which are unfortunately interspersed in some personal, contrived rant about how things just aren’t what they used to.

Security is not something that should only concern people in top secret facilities, working for governments, etc. It should concern any person that uses a PC. While the ability to toggle an option in order to force USB Flash Drives to autorun (via autorun.inf) like CD-ROM drives when they are detected certainly makes sense from the standpoint of somebody who requires or wants that feature in their everyday computing, it does not make sense at the grander scale. An option exposed to the user is an option any program can change at will.

That is less of a concern, when you think about it- if a program has already run and is able to change those settings, than it doesn’t really need to change those settings- since you are already compromised. And this is true. However software has a habit of interacting in unexpected ways. In fact the very feature being discussed was never explicitly added; the feature was for CD-ROM installations, which in those days were stamped and always provided by the manufacturer. There was little reason to ever suspect such a disc may contain malware, and in those days, making things smoother and easier to use was considered fairly important. With Burned discs, there were further concerns- this is why Windows XP and Vista Display a prompt. The addition of USB Flash drives were the same deal. The biggest issue is simply attack surface. There are a number of attacks which exploit the autorun capabilities that are vulnerable by default. For example, Conficker was one such program. Autorun would automatically install and infect any system that the flash drive was plugged in to. It would then reach across the network and infect further systems, which would infect any flash drives plugged into them, etc etc. Even wit hteh addition of a ‘Default to not enabled, but allow people to disable it” feature only goes so far. OS Security is about reducing attack surface; various exploits could easily trick the system into running the autorun program. A prompt or dialog of options is not a security solution by any stretch of the imagination, particularly if it isn’t running from a secure desktop.

That is, at least, why they have been so far unable to create the functionality they desire, which, as I understand, is through simple modification of a batch script. Eve nso, there are some ways to provide this feature. For one, while it is not possible to enable autorun functionality for anything other than CD-ROMs or DVD-ROMs, this doesn’t prevent Emulated CD-ROM and DVD-ROM Drives from working in that manner. This is how U3 Smart drives work, for example- unfortunately, U3 Smart enabled drives don’t work as-is and would require modifying the protected areas of the Flash Memory. I am unsure if that is possible.

In their postings we see they found and used one alternative, AP USB 47. The claim, however, is that it is very limited for what they are looking for. This seems- odd. It can be configured to automatically launch and it can be configured on all their systems, so it would run just fine for exactly what they want- it supports the same autorun.inf features as well. IIf I was to reply I might inquire as to how it falls short of their requirements, because they didn’t specify how it did so- since it does exactly everything they described.

The best I can gather is that they think the capability should not require running an additional program. This is a rather shallow, and perhaps even ignorant perspective because the capabilities of an OS are usually better kept to a minimum. When Microsoft was loading Windows with bells and whistles, that was, security wise, the worst time for them. And we aren’t just talking about corporations; the fact that any XP machine can be infected, instantly, by plugging in a USB Flash drive is exactly that sort of problem. By removing that capability entirely, it reduces the attack surface by removing the surface entirely rather than trying to coat it with armour-all and hoping the water keeps beading. That is the reason. Whether they want to accept it is their problem, But suggesting that your issue with some very specific requirement involving a side-hobby that has nothing to do with actually running a business is suddenly the problem fo a vendor who’s software is designed for solving real-world problems is somehow of paramount importance and that not being able to do it “makes you sick” is perhaps astigmatic.

We see their requirement, somewhat more pronounced- and particularly why they don’t want to run the program in question, here:

i can save time not clicking buttons. And limiting how much software is installed and starting up on my little duo.

As such we see their requirement is that they don’t want to click buttons (and yet they don’t want to simply launch a program when the drive is inserted, so I’m not sure what they want here) and more importantly they “want to limit how much software is installed and starting”).

That second requirement is always baffling. the Program in question perfectly duplicates the older Autorun.inf behavior- I am unsure why they keep referring to it as autorun.ini, I hope is because they are misspelling in posts and not trying to create the wrong file this entire time. The only reason they don’t want to use it is because they don’t want to use disk space- a full- what, 100KB? ANd they don’t want to use processor power on the extra program running in the background. The first is invalid- disk space of such small amounts is simply inconsequential when you have this sort of issue. And the later is not really valid either. They are working, I believe, on the assumption that more processes means a slower system, which they cannot support with any sort of evidence because no such evidence even exists, because it is not true. Particularly in this case, a program is going to spending almost all of it’s time sleeping- in fact, almost all of it. It is just listening for the same system events that the OS listens for for it’s own autorun features, but instead of ignoring attachments of Fixed disk type drives, it will emulate the standard autorun.inf capabilities and attempt to autorun them.

Thus I am left to conclude that this individual is either a troll- supported somewhat by the fact that their first post is practically the furthest thing from actually making people want to help them, all the while effectively feeling that they are entitled to that assistance because hey it’s the internet, as well as making grandiose false analogies to support their ill constructed perception of “how it should work”, or is simply a poor communicator, because based on what they’ve written I have no idea what tehy want- particularly given that the aforementioned program they already tried, hits every single one of their points; save the one, implied point that is found between the lines.

The problem, in this case, is not with the software they are using. It is, In my opinion, with their approach to what they think is the problem. In their eyes, the problem is clearly the autorun. But why can the problem not be something further back that has led them to somehow require that they be able to arbitrarily plug in USB drives in order to use and run software. This is particularly true since they cannot seem to tell the difference between autorun, the features of AutoRuns (which has nothing to do with autorun at all) and features like the local registry options to auto-start applications- something which ironically is used specifically by the program they reject for specifically the purpose they claim to require. From my gathering, they just want a USB flash drive that triggers an action, and they really don’t need any software on said drive at all. That software is easy to write. I could write it now; just have it register a listener to watch for Device added and device removed events and parse and operate on the autorun.inf contents if present respectively, and irrespective of whether that drive is an optical drive or not.

However, I’m not going to, because that isn’t going to solve the problem, which is a rather loose and I might even say poor understanding of the underlying technologies involved such that their question doesn’t really make completely sense particularly given the rejected options.