CK is correct; these systems are insecure by design. Diebold uses the Jet Database engine (and an older version of MDAC, which is the attack root of a large number of recent viruses) which many of you probably know as Access (a front end to Jet). Jet has been plagued through its' iterations with such glaring security faux-pas as clear-text passwords. Even the latest versions can be cracked fairly easily, but that's a moot point, since the voting is done in Access '97 (which essentially adds a number to (XORs) its' plaintext password). OTOH, you don't even need to do that; the systems have Access installed, so you can just change votes with that. (Psst . . . the Supervisor Password is '1111' but you won't need it since they don't implement it, in the field.) Not sure about all this? Kids, you can try this at home.

Even if the multitude of die-hard Bush fanatics who are creating these things in the dark (where even the election officials can't look at them) weren't pursuing nefarious ends, the code for these monstrosities is inherently insecure. Diebold (who blast open-source software as insecure) is based on WindowsCE for embedded systems (reportedly using a modified version of Wine to emulate a full win session on the embedded system, in violation of Wine's LGPL copyright); the only possible worse choice for a platform, would be to cobble one together, yourself, which both ES&S (which uses QNX) and Sequoia claim to have done. Sequoia says that Windows is well known and understood by computer hackers and therefore uses proprietary systems that you would know as . . . (wait for it) . . . VBScript on MS Windows

<Hexhead Sidebar>
Windows, beyond all you might know about its' vulnerabilities to viruses, has an inherently broken messaging substructure, that cannot be fixed.

Imagine that the different parts of the operating system communicate back and forth via semaphore; different routines receive the semaphore sent to them, and follow the orders. Now imagine that the routines don't actually check where the message comes from - so any code passing by can send semaphore to, say, the highest security routines, and tell them to change data or code - the security system sort of zombying along to do the passerby's bidding. If you're with me, then you're probably wondering when we will move on to how Windows functions; we have. That's exactly how Windows functions. That is exactly how a 'shatter' attack takes over, say, your virus scanner, and uses it to build viruses. It can't be fixed, because it would break every existing piece of Windows software.

Software is also easily 'hooked' in memory (even in Visual BASIC) which allows you to change the function of the code on-the-fly without leaving a trace - this is not only possible, it is daily programming practice. You have to do these things just to write normal software that runs.

BTW, these things can be done without any special equipment - a high-end script-kiddie could create these effects just with the debug and text tools included in the OS.
</Hexhead Sidebar>

Why would you need to protect source code that simply counts? (It would be synonymous with trying to protect your writing by making pencils a trade secret.) How bad a programming house are you running if copying your 'addition code' can impact your business? Computers essentially can't perform any other function -- counting is the basis for everything they do. The Republican attempts to suppress recounts on DREs would indicate that they think they can steal this election -- but only if they think the Florida effort will be supported other places . . .

The purported 'securities' that are supposedly in place, are no more than window-dressing. Hash codes, for example (replace all the text in this note with it's numerical equivalent (1-26) and add them all up - assume it adds up to '5'. If you add them up later and it doesn't equal '5', you know the text has changed.) provides zero security when there is neither transport nor strong encryption involved. Storing images of the screen is possibly the biggest hoax security of all -- the system has to generate the screen image, so why does it have to actually have to match the data that it is storing? The two are completely unrelated.