DIEBOLD'S VOTE-TALLY SOFTWARE- Security Review Instructions

V.5.0i - by Jim March, 9/17/03 - jmarch@prodigy.net

10/24/03: the links to the big program files ARE BACK!!!

INDEX:

Introduction:

This document is based on the prior reporting of Bev Harris, which can be found here:

http://www.scoop.co.nz/mason/stories/HL0307/S00065.htm

This document describes the files archived at http://www.ninehundred.net/~equalccw/voteprar.html

The purpose of this document is to step you through a brief yet shocking evaluation of the security "features" of the software that Diebold Election Systems uses to tally and record votes at a central location within a county (Registrar of Voter's office, typically). This software is known as "GEMS", for "Global Election Management System" (Diebold bought out Global Elections over a year ago). GEMS is used to tally votes in either touchscreen (TS) or optical scan (OS) Diebold products.

NOTE: all files are downloaded as ".ZIP" files - this is a standard format for packing multiple files into one file, compressing them for disk space and optionally attaching a password. Programs to read and decompress such files can be found all over the 'net, such as at:

http://www.pkware.com/products/free_eval.html

http://www.woundedmoon.org/win32/ultimatezip27.html

http://shareware.search.com/search?cat=237&tag=ex.sa.fd.srch.sa_win&q=zip

And in my opinion, the BEST: http://www.rarlab.com/download.htm

The ZIP reader should be able to put the multi-file contents of each ZIP archive into their own sub-folders, which you create.  Some of these archives contain a LOT of files, so that's the best answer.

Many of the files you'll be downloading are BIG - some in the 50megs range. I recommend use of a "download manager" on a dial-up modem connection or you'll go nuts trying to get these. One of the best is Getright:

http://www.getright.com/get.html

There are others, but too many are "spyware", "adware" or other such crud. Getright has no ill effects on your PC - it allows re-starting a big download if your connection dies halfway through, it will manage multiple downloads at once, and is otherwise a sanity saver.

(NOTE: all of the test procedures shown in this manual for the GEMS 1.17.xx series work the SAME on the GEMS 1.18.xx series.)

These are complete copies of the GEMS applications. You can only install one GEMS version at a time - if you want to switch to a different version, uninstall the previous one with the standard MS-Windows "add/remove programs" function under the Control Panel (under the "Start" button).

The versions are:

GEMS 1.17.15 - this has by far the most complete set of documentation available in Acrobat PDF format - see also the files "AccuVote-TS Users Guide 4.1.pdf", "GEMS Users Guide 1-17-15.pdf" and two documents related to modem settings in the directory/folder for this version (suggesting that these systems can be dialed into and modified remotely).

These manuals for AccuVote-TS (touchscreen) and GEMS itself are a deep look into how the program works. But they're most notable for what's NOT in there: any reference to using MS-Access to open or alter data files, or that this is even possible. If the county elections personnel who are the target audience of those manuals has no idea that a standard copy of MS-Access is a "hack tool" for voting data, then an entire array of security precautions won't be taken.

Download at: http://freespeech.metacolo.com/pimaupgrade.zip - 54megs

GEMS 1.17.23 - this version is currently in use in San Luis Obispo County, California in their Diebold Optical Scan system according to the county's Registrar of Voters, Julie Rodewald. So we can assume it's certified. Few changes.

Download at: http://freespeech.metacolo.com/GEMSIS-1-17-23.zip - 17.4megs

GEMS 1.18.17 - this is a "late model" version, included for those wishing to test it. There don't appear to be many changes.

Download at: http://freespeech.metacolo.com/GEMSIS-1-18-17.zip - 28.9megs

You also need data files to play with:

There is a file for Alameda County with no actual vote data in it (just the setup, candidates, etc.) inside the GEMS 1.17.15 download above, filename is "alameda ca primary election 0302 007.mdb".

Others:

Cobb County (Georgia) test data: http://speakeasy.seattle.wa.us/jmarch/cobb-corrected-100102-backup.zip - about 5megs

San Luis Obispo County LIVE VOTING DATA, from 3:31pm the day of the 3/5/02 primaries!: http://speakeasy.seattle.wa.us/jmarch/sloprimary030502.zip - 53megs - this file should NOT have been on the Diebold website, and has been confirmed as real - according to the SLO County registrar (Julie Rodewald) it is the absentee ballot data? This file is password-protected - the password is "sophia", all lowercase, without the quotes. Any of the better ZIP handlers will let you input a password.

Items needed:

To perform these tests, you need a standard PC running Windows 98, NT, 2000 or XP (note: XP might not have been tested yet, but it should work). You also need the MS-Access program; version "97" should do, I have personally tested all this with the MS-Access built into MS-Office 2000, later versions should be OK too. (Access is usually found packaged with MS-Office "Pro", but is also available standalone.

Load MS-Access on the PC in question.

1) Pick a GEMS version to install. If you're not sure which one to play with, use 1.17.23 as that's confirmed to be in operation in California (San Luis Obispo County). Otherwise, pick one that's closest to what your county actually uses (if known). From the folder for the version you want to load, run the "SETUP" program. This will install GEMS on your PC. Do so with "all the default settings" - it's a very simple process. It will probably call for a reboot of the PC at some point, go ahead and do that.

2) Click the Windows "START" button, and under "Program Files" find the "Global Election Systems" item. IF IT'S NOT THERE, don't panic, go back to the unzipped folder that you ran SETUP from and run that SETUP again - some versions are a "two step install" for some reason. After the second install, no reboot will be necessary.

3) Open up "My Computer" on the desktop (double-click it, or in WinXP it's under the "Start" button), then open the "C" hard drive. From there, open the "Program Files" folder, and in that open the "GEMS" folder, and in there open the "LocalDB" folder.

4) Loading data files: you can drag and drop any .MDB "data file" to that particular folder on "C:" (what a techie would call "C:\program files\gems\localdb"). Once an .MDB file is in that directory, GEMS will "see" it and allow you to load it. If you are unfamiliar with drag'n'drop file copying between two disk sources on a Windows machine, you're going to need some minimal "techie assistance" for all this. IF you hose the data files at this directory, you can always re-load them from the original .ZIP files. If the data file(s) are of the .GBF type (from the original ZIPs), double-click the .GBF data file and GEMS will put the .MDB version of the file into "C:\program files\gems\localdb" automatically. In other words, you can't directly use a "GBF" file as found in the Cobb County and SLO county ZIP files, BUT as long as GEMS is loading, double-clicking a .GBF will "process it" into something usable at C:\program files\gems\localdb

I can't give instructions on unzipping because I have no idea what ZIP reader program you've got. But they're all dead simple.

5) Now we're ready to play. First, fire up the main GEMS program - it's under the Windows "START" button, "Program Files" area, find a "Global Election Systems" area below that, and finally the GEMS program (blue globe icon).

6) You're in the "Connect To Database" screen. You'll see the text "alameda ca primary election 0302 007" and/or the other two databases if you downloaded them - we'll start with Alameda but these instructions apply to any of them. Click on that Alameda database ONCE, then hit the "OPEN" button once.

If you choose a 1.18.xx series GEMS to play with, it will do a "conversion step". This is normal. Once so converted, the data files cannot be used with a 1.17.xx series GEMS. If you jump backwards from 1.18.xx to 1.17.xx (read: unload GEMS 1.18.xx and load 1.17.xx fresh), you must reload the data files from the original ZIP files. Other than that, the instructions are the same.)

7) This next screen wants the password for username "ADMIN". You don't have it yet. Feel free to play with it and guess passwords but basically, the security at THIS point will "hold up" - you can't get into that Alameda data. Not yet.

8) Cancel out of this "Admin password" bit, and get back to the "Connect To Database" screen.

9) Hit the "new" button, and create a new GEMS database with that button.

10) Name the new database whatever you want - we'll use "joke" as an example. Below that, it wants an admin password for this new database. Put in whatever new password you want, and repeat it in the box below that. For our purposes, I'll use "jokepass" in this set of instructions - but YOU use something else, so you know there's no "cheating" on my part.

11) Once you're past the "new" screen, you're actually in GEMS. There's not much here to see because the entire election structure hasn't been built yet for this "new database". But feel free to explore if you want.

12) Now to business: quit the GEMS program completely, get back to just plain ol' Windows running.

13) Fire up MS-Access - it'll be an item under the "START" button, "Program Files" area. At the first MS-Access screen, it'll give you the option of opening an existing database (using the "More files…" item). Take it to the "C" drive (under "My Computers"), the "Program Files" folder, the "GEMS" folder and then the "LocalDB" folder. Access will now "see" the files of it's own "kind" sitting there: the Alameda file, the other two and the one you created (I called mine "joke").

14) Open the Alameda file.

15) OOOPS! Hey, where's the password? THERE AIN'T ONE! Once you fire up MS-Access, you can open and explore all the various bits. If you know where to look, you can change vote totals. You can change anything - it's all wide open to unlimited rape.

That's bad enough, but we ain't done yet, not by a long shot. Close out of the Alameda data file.

16) Now, in Access, open the "joke" datafile (or whatever you called the one you created) the same way you did the Alameda file. (If you quit out of Access in the last step, no problem, fire it up again.)

17) Got the "joke" file up in MS-Access? Good - you'll see a number of different sub-areas within MS-Access, such as "ballot", "card", "region", etc. Find one called "Operator", and open it (double-click on it).

18) You'll see a "password". It won't be the password you typed in, it'll be "scrambled" (random combination of characters) - don't worry about it. Highlight that whole password with your mouse. Make sure you get the WHOLE thing, it might be longer than the "box" it's in and will scroll sideways, you'll have to drag sideways with the mouse to get the whole thing. Got it "highlighted"? Good. Under the "Edit" menu at the top, give a "Copy" command.

19) Close down the "joke" (or whatever filename you used) file, and in MS-Access pull up the Alameda database file. Again, open up the "operator" item and highlight the password for Admin. Highlight the whole thing - and then, under the "Edit" menu, hit "Paste". You'll see the characters change to what they were in the "joke" file.

Now under the "file" menu, do a "save" command.

Got a sick feeling in the gut yet?

20) Quit completely out of MS-Access, and fire up GEMS again (at Start-Programs-Global Election Management-GEMS). Click on the Alameda database. Hit "open". This time, for the "Admin" password, use the password you created and entered twice for the "joke" file - in my case, that would be "jokepass" without quotes.

And bingo…you're in. That is GEMS with the full datafile spread'n'ready before you. You successfully bypassed the GEMS password control system like a hot knife through butter. Note: if you were doing real dirty deeds, you'd save the old Alameda admin password off in a Notepad window or similar, and then when you're done "hacking", splice it back into the file. You would never know what the password really is, but once you were done the system's legitimate administrators would be able to use that correct password normally, without being "alerted to trouble" from their proper password not working.

But wait…it gets worse. A LOT worse.

Go ahead and poke around in this data. Open stuff up, look at it, explore. Done? Good. In GEMS, under the "GEMS" pull-down menu at the top, you'll see the "audit trail" item. Open that, and look at it. It recorded all the poking around you just did, in excruciating detail. Cool. Good feature. Too bad it's worthless.

21) Close GEMS, and open up MS-Access again. Open the Alameda data again (remember, it's on "C", "Program Files", GEMS", "LocalDB").

22) Sitting right there in plain sight is the item "AuditLog". Open it. Okay, this is harder to explain than do: there are un-numbered gray boxes running vertically on the far left edge of this window. Clicking on one of those boxes highlights the entire horizontal audit trail item. Go ahead and click on one of those boxes, and then hit the "delete" (del) key on the keyboard. Access will ask if you really want to delete a record, say yes. Whoa. You just deleted an audit trail item. OK, highlight another row the same way maybe two or three rows down from the top. Now with the mouse, grab the "slide bar" on the right side and drag it all way down to the bottom of the audit trail. Hold down the SHIFT key, and pick another horizontal row (again, you're hitting the gray un-numbered boxes on the far left). What you've done is selected a whole range of audit trail items, leaving only the first few at the top and last few at the bottom. (You CAN delete the whole thing but there's a reason I don't want you to.) Now hit "delete" again, and confirm that you're trashing all this.

23) Save the Access file, and quit out of Access.

24) Run the GEMS program, get into the same data file and pull up the audit trail again.

25) First, you'll see that one hell of a lot of stuff is missing. But second, the items ARE NOT NUMBERED, so there's no way you can now tell things are way out of sequence. All standard reference works for Access note the need for line item numbering in Access, so that you can at least tell when the audit trail has been tampered with. The lack of such line numbers can only be deliberate.

Let's re-cap, shall we?

The net impression is that GEMS was designed to be tampered with in ways that would evade the detection of local elections officials.

California Elections Code 19205(c) specifies that any certified electronic voting system "shall be safe from fraud or manipulation". GEMS doesn't qualify.

Note that we haven't covered any of numerous other possible issues: GEMS contains a large number of DLLs which can have all sorts of hidden, funky features. Worse, Diebold supplies the Windows system to the customer on a pre-set machine; the Windows code itself could be hacked to hell and gone and it wouldn't be tested in a lab.

This program should never have been certified. It is a fraud, and quite possibly part of a literal coup attempt. Whoever certified this thing at the state and/or Federal level should be subject to serious scrutiny and review, as should the entire certification process.

This is NOT hyperbole, or "conspiracy theory" - this is an outright disaster in the works and undermines everything our Republic stands for.

Let's take another look at that file. I'm assuming you've run through the steps above, so you have a GEMS install loaded, and the SLO county data sitting at c:\program files\gems\localdb

26) Start MS-Access, and open up the SLO datafile: "sloprimary2002ORIG.mdb".

27) Go into the "Candidate" item. Remember, this was the Spring of 2002 primaries. So find the entries for Gray Davis, Democrat challengers Charles Pineda Jr, Anselmo A. Chavez and Mosemarie Boyd, and Republicans Richard Riorden, Bill Jones and Bill Simon. You may have to make the "Label" field wider so you can see the whole candidate names - click on the right edge of the gray box where the word "Label" is, and "drag the column fatter" (exactly like how MS-Excel works).

28) Write down the "KeyID" for each of those seven candidates. I've already done so, but make sure I'm accurate:

(Remember, those aren't votes, they're a numeric ID assigned to each candidate.)

29) Now close the "Candidate" window (not the whole datafile) and open "SumCandidateCounter" in MS-Access, in the same SLO county data file.

30) You're looking at the actual votes. The first column appears to be the precinct, so there's actual votes in the last column for the votes in that precinct. The "CandVGroupID" column tells you who the votes are for - that's the "Candidate ID number", or "KeyID" from the candidate table.

31) Let's look at precinct 941, the first one. There were no votes at all for the three "also ran" Democrats, which makes sense with Davis as the incumbent Dem. Davis (number 91) has a vote; Jones (93) and Riorden (98) are neck and neck with 4 votes each.

Now check more precincts. What you'll see is that the numbers MATCH WHAT YOU'D EXPECT of a rural, conservative county. In most other precincts as you scroll through, Simon edges out Riorden by a small amount, Jones runs a distant third, and Davis dominates among the Dems. (Remember, in California you have to be a Dem to vote in the Dem primary and GOP to vote in the GOP primary. "Crossover voting" was banned by the courts fairly recently on freedom-of-association grounds.) Check out precincts 1146, 2349 and many more (those are precincts with sizable vote totals)…you'll see that the numbers "make ballpark sense", but with a "randomness element" you'd expect of early actual results.

So is this sample data, or real?

32) In MS-Access, open the Cobb County datafile. We know that's test data. Go look at SumCandidateCounter there - its just endlessly repeated numbers! ALL the sample data files, Logic & Accuracy test runs and similar that we've seen look like that - no randomness at all, and no connection with actual results.

Conclusion: if the SLO County numbers are a test run, somebody went to one HELL of a lot of trouble to do a fake!!! And at no time have we seen a tendency towards that level of initiative out of Diebold - on the contrary, the various security flaws identified can be most charitably described as extreme laziness!

Now for some fun.

NOTE: the EMail address "support@gesn.com" is a "mailing list" address. When any of these people sent that address EMail, it was bounced (relayed) out to all the rest. This sort of thing is fairly common. In any case, assume that all messages sent to that or a similar address was viewable by a LOT of technical or other staff within Diebold.

Here's one titled "RE: mdb files corrupt" by Ken Clark with 0 relies:

Jim again. Clearly, all the way back in February of 2000, Diebold field staff had realized that MS-Access could be used to open and modify GEMS data exactly as Bev Harris later discovered, and "Principle Engineer" (per other Diebold docs) Ken Clark back at "home base" was attempting to discourage this highly illegal procedure (as MS-Access has NEVER been approved as elections software!!!).

By October of 2001, the Federal testing lab (Metamor Inc, the "Independent Testing Authority" or "ITA") had discovered the same thing - that MS-Access can get into GEMS databases and diddle such details as the audit trail and votes; this was reported back to home base by tech Nel Finberg:

Ken's response indicates that his early attempts to curtail MS-Access use had failed miserably, and he knew there was a problem:

Jim March again. Let's tally the sheer number of "confessions" Ken just made:

* Alteration of GEMS data files with an unapproved product (MS-Access) is common both among Diebold staff and county elections personnel.

* Ken Clark knew about that, and deliberately avoided tightening down security to eliminate the practice because it's "handy".

* Ken admits having the ability to hack elections(!). That means somebody else in Diebold can.

* Ken knew that relying on "operating system security" was inadequate, yet suggested telling the Federal test lab that it was. While not thinking it would work. AND disparaging the technical ability of the lab staff (ref: "Even technical wizards at Metamor (or Ciber, or whatever) can figure that one out").

This all adds up to intent to defraud.

So what was Jennifer Price's reaction to this "story"?

So there you have it. Diebold lied to the Federal testing lab, the only people with access to the source code who can fully evaluate the product, and got away with it.

You can see this discussion as it would have looked on the Diebold internal website at: 

http://www.ninehundred.net/~equalccw/smokinggun.html

It wasn't just Ken Clark that was "just rolling with the madness".

Folks, go download http://www.ninehundred.net/~equalccw/ElectionSupportGuide.pdf - This document was NOT for client/public review! It's written to help the hapless Diebold techie with what they'll encounter and need to deal with on-site the day of the election. Ohhhh GOD, this is just...drop dead, laugh out loud funny in bits...excerpts below.

It's dated Oct. 21st 2002 in the text inside. Filesize is 256k or so.

Early in the manual we see this bit (remember, it's for Canadian staff, eh?):

Jim: Oh ya. Fun ahead. Let's start with travel tips:

Jim: "Work visas? We don't need no steenkin' work visas!"

Quick, somebody call INS!

Jim: Correction, call Scott Adams ("Dilbert" cartoonist), this is HIS territory now!

Jim: translation - "Do try not to step on your genitalia..."

And it bears repeating:

"Do not to offer damaging opinions of our systems, even when their failings become obvious." They might get lucky, have both neurons fire up at once, and dump us like a cheap date...

Jim: How often does THAT happen?

Except from a Diebold hiring ad: "we're looking for people capable of working 48 hours at a stretch...".

Sigh.

These clowns KNEW they were a pack of screwups.

Jesus H. Christ.

More info on these internal memos and documents will be updated at http://www.ninehundred.net/~equalccw/voteprar.html

One of Diebold's best defenses so far has been to explain that physical security ("plant security") is a key part of the process, so that while GEMS may be open to tampering, nobody unauthorized can get into it to tamper.

This isn't a bad argument. Basically, without an "access method" to GEMS, the above steps to "hack the vote" are useless.

Problem: there IS an access method.

Sources: one major source of info, I'm pleased to report, has been SLO County's Registrar, Julie Rodewald.

Per my interviews with her, here's what we've got physically going on at the county central elections office:

The computer running GEMS is relatively high end. It's running Windows NT, and it contains a card called a "Digiboard", which is inside it and has sixteen modest-speed "serial ports". Four of the sixteen ports run across the same room to optical scan readers, to enter the absentee ballots with.

Most of the rest (ten or twelve) ports are connected to external modems. These modems are normally turned OFF.

At the time the polls close (normally 8:00pm), the modems are turned on. For the next 1.5 to 2 hours, optical scan computers at the polling places call into the central GEMS boxes through the modems and report their totals. Given the number of polling places (see also the SLO County instructions above, steps 29 through 31) each "conversation" is moderately short, although they'll perhaps vary a bit due to normal line quality differences and possibly the size of the data tranfer (popularity of a particular polling place).

The phone numbers involved are known to (or at least accessable by) everybody in the office, and the Diebold support staff (per Ms. Rodewald).

This is therefore the most likely avenue of attack.

In February, as part of the set of downloads hackers did on the Diebold websites, the following memo between a Diebold field tech agent and the central support crew was located. We didn't understand it's full significance until we gleaned basic information on the setup from Ms. Rodewald. In it's entirety:

Jim again. Let me try translating:

"Digi PCI X/em" is the 16-port Digiboard - see also "products" at http://www.digi.com

"AVTS" means touchscreen terminals, while "AVOS" is optical scan. Other than the terminal type, the equipment is otherwise the same between a TS system such as Alameda and OS as bought by San Luis Obispo.

They're running GEMS 1.18.14, which is an uncertified version (ask Kevin Shelley's office if you don't believe me) on Windows NT 4.0 (bugpatch set 6A).

"RAS" is "Remote Access Server" - a set of communications software that gives external PCs VERY complete access to the central box running it. Files can be accessed and manipulated over it.

Mr. Chen was able to access the central box over one of these modems, or at least he expected to be able to do so, from an ordinary laptop.

Diebold tech staff know the RAS password to get in.  They know the phone numbers.

Therefore, during that "window" of a couple hours after polls close, an ordinary PC in a Diebold basement somewhere could dial in, run a script, change votes specific to that county and get out again. In about 5 to 10 minutes tops, per county. And it would take only one conspirator among the "techies" to get the data necessary to do actual evil.

We're not done yet: Chen mentioned "I have assigned a ip pool 166.107.248.210 to 220". That means he assigned specific "internal access numbers" to the 10 modems Alameda County uses.

Problem: "IP addresses" are very specific - you can't have two on the same network. That includes the entire Internet - "IP" stands for "Internet Protocol". The numbers are somewhat similar to phone numbers - the first two sets of digits mark the system as being part of the Alameda County network system. (To test this on any Windows PC, open up a "command line" or "DOS prompt" and type "ping www.acgov.com" (their website) without quotes - you'll get 166.107.72.47 as their website host's IP addy. Those numbers can then be looked up to tell who owns them: "Alameda County Data Processing" at 1221 Oak Street, Oakland.)

So why did Diebold set up the Alameda County GEMS computer with numbers that would make it compatible to share the general Alameda County network system!? Which in turn is connected to the Internet?

Granted, hacking into GEMS this way from the Internet (outside of the Alameda County "firewall") would be difficult. Not so difficult from inside mind you, like at the County Supervisor's offices.

Still, if the danger is from Diebold itself, while this sort of security flaw is intolerable, it's not that useful. By entering in through the modem pool wired right to the GEMS box, Diebold could hack every single customer county, on an automated basis.

And you don't need a lot of "conspirators" to do this. Two or three programmers, one or two managers who are politically savvy and know which races to hack, one guy back in the "build room" setting GEMS boxes up, and one guy able to collect the data from the field regarding phone numbers, RAS passwords and the like.  A crew of as little as five people could pull it off, seven or eight a bit more likely. They would also have a "dialer war-room" with between 40 and 100 PCs each with a modem and scripts, to call out to GEMS boxes and mess with them.

NOTE: they may have set up some or all GEMS boxes to dial OUT to the precincts versus take calls in. It doesn't matter...if anything, that would make life easier on our theoretical "black hat crew", as there'd be no need to record the local dial-in numbers. Just program an extra dial-OUT number into the GEMS box as it's being built at Diebold. Diebold supplies the entire finished computer, with Windows and all applications loaded - they could supply an altered Windows COMM driver, hacked-up Digi or modem drivers, you name it - a small "extra dialer" could be hidden almost anywhere.

Can I prove that Diebold has done this?

No.

But why else leave GEMS so "tamper friendly", including the duplicated vote tallies designed to defeat individual precinct checks, if you're not going to use it? Remember, California Elections Code 19205(c) bans even theoretical security holes; to create one as gigantic as GEMS was a risky undertaking.

Nobody sane takes risks without payout potential.

First, let me explain that I fully "confess" that I am distributing Diebold copyrighted product on my website. And I was (and am) involved in the effort to strip the encryption from some of the ZIP archives downloaded from Diebold's FTP site.

So why am I not worried?

a) I believe all this falls under "fair use". I have a history of using the Public Records Act to expose government-related misconduct, corruption and general stupidity. See also:

http://www.ninehundred.net/~equalccw/commiemommies.html (the first time my reporting made Matt Drudge's site)

http://www.ninehundred.net/~equalccw/donperata.gif (the second time Drudge picked my stuff up - note that Perata is a well-known rabidly anti-gun politician)

http://www.ninehundred.net/~equalccw/oaklandzen.html

http://www.ninehundred.net/~equalccw/sactoletter.html

...and other examples.

b) Voting is a highly "public" function, and public scrutiny over the election process is a VERY well established area of law. There have been two lower court decisions in favor of the secrecy of electronic voting systems but first, I believe those decisions were wrong and second, in those cases no specific allegations of misconduct were presented - only theoretical issues.

c) In Diebold's case, misconduct is very, VERY well established. Good God, where do we start?

d) The elements of "c" above lead to an "unclean hands" problem on Diebold's. In court, the term "unclean hands" applies to somebody who tries to get "justice" when they themselves are law-breakers. This is why a crack dealer can't sue his customers over failure to pay.

e) I hope they do sue me in civil court. The discovery process will be an absolute blast. Depositions will be even more fun.

f) They might convince the Feds to prosecute me criminally. Riiight. Let's see - will they be able to convince a jury that hey, this whole "democracy" thing is over-rated? Basically, prosecuting me for copyright issues and/or hacking under the DCMA would be much the same as the guy who sees a robber in a ski mask and packin' a shotgun rush into a bank, so he slashes the crook's tires - and gets prosecuted for vandalism. There's such thing as a "necessity defense" in criminal law. It applies in this case, in spades.

g) Yo Diebold: before you take me on, you should know what you're up against. Go here:

http://www.keepandbeararms.com/information/Item.asp?ID=3601

Pay particular attention to the downloadable video linked in that article. That's what you'll be facing in court.

h) I have friends with law degrees. Lots of 'em. Scads. And they're gun-rights lawyers, which in California means "battle hardened sumbiches fighting behind enemy lines".

i) Special message to Diebold: you are cordially invited to bite me. Bring it on. Make my day.

As much information on each will be provided herein as we have. All of the step-by-step instructions that follow will work with ANY data file:

Filename: alameda ca primary election 0302 007.mdb

Original date: 1/26/02

Our best guess: this file was created by Diebold as a "template" for the March 5th 2002 primary race in Alameda County, California. It contains the complete layouts for the ballot, the entries for all the candidates and initiatives (local and state) but does NOT contain votes. The file itself is what you'd expect if Diebold was either helping Alameda County through their first election with the Diebold product, or possibly it was created as a "sales tool" prior to the contract being signed. Either way, it contains no votes - only the "places where the vote data would go".

This file was originally "packaged" with GEMS version 1.17.15 in a file called "pimaupgrade.zip". We have no idea why.

---------------------------------

Filename: cobb-corrected-100102-backup.mdb

Original date: 10/9/02

Data file from Cobb County, Georgia.

Seems to contain pre-election test data. It's probably some sort of logic & accuracy test run. The term "corrected" is puzzling but not necessarily damning.

---------------------------------

Filename: sloprimary2002ORIG.mdb

Original date/TIME: 3/5/02 at 3:31pm.

By all appearances, this is a set of live voting data STOLEN from San Luis Obispo County California literally right in the middle of the election. 3/5/02 is the date of the California primaries for the Governor's race and similar.

True, Diebold sets the date of the machine forward to the election date when running a Logic & Accuracy test - or at least, they've done so in some cases. (This would make sense, as "date sensitive code" is a well understood "hack technique".) But the data for the actual election results matches what you'd expect for the various races - more on that at the specific SLO County "step by step instructions".

The original ZIP file was password protected - we've left the password in on that ZIP (see also the "ORIGINAL ZIP FILES" folder on the CD) because it's a clue as to "whodunit" ("Sophia"). It was simple to crack that password using a "dictionary compare attack", wherein a program compares the ZIP archive password to complete English words found in a dictionary file.

"Sophia" is a Diebold employee who was on-site at the SLO County Registrar's office on the day of that election, according to SLO County Registrar Julie Rodewald in a conversation with the author of this document on 8/22/03. "Sophia Lee" is a known Diebold employee involved in on-site support, and most likely the "Sophia" involved.

As of Sept. 5th 2003, Ms. Rodewald has completely a preliminary examination of this file and determined it to be live data, but of the absentee ballot vote count which was completed with a bank of four optical scan systems in the central county offices. Therefore, it is her opinion that no communication with the precincts occurred at 3:31pm.

We are working to verify that ourselves. However, it would still be a breach of security for Diebold to get that file before the polls closed; we also don't know who put it on the Diebold website. Ms. Rodewald is quite clear that she didn't, her people didn't, and she didn't authorize it.

By making access to these data files basically public on an unprotected website, Diebold (inadvertently?) created a "toolkit and practice set" for vote tampering…and will allow us to actually test the security of the system.

Jim March - Email: jmarch@prodigy.net Website: http://www.ninehundred.net/~equalccw/voteprar.html