Diebold's Vote-Tally Software - Security Review
DIEBOLD'S VOTE-TALLY SOFTWARE- Security Review Instructions
SECURITY TEST PROCEDURES (step by step)
Analyzing The San Luis Obispo County Data File
Appendix A: Legalities (read: why Diebold isn't going to sue me)
This document is based on the prior reporting of Bev Harris, which can be found here:
This document describes the files archived at http://www.equalccw.com/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:
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:
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.
There are a series of 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 (suggesting that these systems can be dialed into and modified remotely). Download this at:
http://www.equalccw.com/pimaupgrade.zip (no password - otherwise, this is what the file looked like on the Diebold website.)
Filesize: 52.7 megabytes
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.
GEMS 1.17.17 - there appears to be few visible differences from 1.17.15. We have reason to believe this version was certified through NASED or with some NASED connection (http://www.nased.org). Download it at:
Filesize: 18.1 megabytes
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. As with 1.17.17, few changes. Download:
Filesize: 17 megabytes
GEMS 1.18.17 - Most of the files are dated 1/23/03, which is only days before the Diebold FTP site was "raided" by activists around 1/26/03 and for the next few days (hardly a serious "raid", as Diebold didn't put an FTP password up!). File formats in this version are slightly different; all the same security problems seem to exist but it does a "database conversion" from "1.17 to 1.18" when loading older data files such as the ones provided in these links. Special instructions for v.1.18.17 will be included below in italics. Download:
Filesize: 28 megabytes
Each GEMS version above has a file in it's directory (once unzipped) titled "README.HTM". Opening this file will reveal a detailed bug history report for the GEMS product, complete with the release date for each version. The file for GEMS 1.18.17 is of course the most useful. Diebold had a "bug-tracker database" online which has since been taken down, apparently at http://staff.dieboldes.com/bugzilla which contained reports on each bug - one upcoming project is to see if an "Internet history archive site" still has that stuff. Some of the one-line bug descriptions seem to indicate a potential for data loss. At least one refers to modem functionality in the very latest revision, among others.
The following data files are available for download, and 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
Download: it's part of the GEMS 1.17.15 package, at:
Filesize: 52.7 megabytes (mixed in with GEMS 1.17.15)
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.
Original date: 10/9/02
Data file from Cobb County, Georgia.
http://www.equalccw.com/cobb-corrected-100102-backup.zip (No ZIP password; there's a special instruction once unzipped: you must completely load a GEMS install (version number your choice) before using this file. Once taken out of it's ZIP file, it will produce a file ending in ".GBF" for "GEMS backup file". Double-click this, and GEMS will turn it into an MDB file located in the correct directory for dealing with GEMS data files: C:\PROGRAM FILES\GEMS\LOCALDB)
Filesize: 4.8 megabytes
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.
Original date/TIME: 3/5/02 at 3:31pm.
http://www.equalccw.com/sloprimary030502.zip (ZIP PASSWORD REQUIRED: "sophia", all lowercase, no quote marks. With most ZIP/UNZIP programs, you enter the password when you "extract" the files. There's a special instruction once unzipped: you must completely load a GEMS install (version number your choice) before using this file. Once taken out of it's ZIP file, it will produce a file ending in ".GBF" for "GEMS backup file". Double-click this, and GEMS will turn it into an MDB file located in the correct directory for dealing with GEMS data files: C:\PROGRAM FILES\GEMS\LOCALDB)
Filesize: 53.7 megabytes
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" on page 7.
The original ZIP file was password protected - we've left the password in 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.
If this is live data, and we'll step you through an examination of it starting here, then why was Diebold "scooping up" preliminary elections results from the field? To prove they could? To bet on the stock market!? WTF!?! (NOTE: this data could be used by the campaign staff of a particular candidate to determine where best to send resources on the day of the vote, esp. registered voter transport services. It's quite common for campaigns to bus people to the polls who are registered for their own party, and quite legal. But early returns data would be invaluable in letting a party assign a limited number of such transport vans across several counties, wherever they're needed most. Data of this sort AFTER the election is, in my opinion, public record - but not DURING THE VOTE.)
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.
There is also a file called "http://www.equalccw.com/ATL-TSRepair.zip" (small, only 66k), with a password we have NOT cracked yet. It is going to take a "brute force approach" to do so. We are highly interested in the contents of that file - it is a tiny database file (.MDB) dated several days AFTER the November 2002 elections. "ATL" probably means "Atlanta, Georgia". We believe the Georgia election of 2002 was stolen. That file may contain proof. Hint: open it in a ZIP reader such as WinZip. You can't extract it without a password, but you can view the file size, compression type and original file creation date/time.
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.
- EXACT STEPS:
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. IF YOU INTEND TO TEST GEMS 1.18.17, it will "convert" files to its newer format. That will screw them up for reading in 1.17.xx. No big deal, either test 1.18.17 last or if you switch to an earlier version, re-copy the data from the original ZIPs.
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" from the unzip directory directory to that particular folder on "C:" (what a techie would call "C:\program files\gems\localdb"). 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 ZIP files. If you've played with them in GEMS version 1.18.xx, you'll have to do this reload to be able to use 1.17.xx. No big deal, just keep it in mind. If the data file(s) are of the .GBF type, double-click the data file and GEMS will put the .MDB version of the file into "C:\program files\gems\localdb" automatically. Look, 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 - 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. (SPECIAL NOTE IF YOU'RE TESTING GEMS 1.18.xx series: when you open a datafile created with 1.17.xx, it will want to "update" the data files. It will ask permission to back them up first. Let it rip, with all default options…it'll add few minutes to do it's "backup" but otherwise there's no significant difference. It will also render the files useless for GEMS version 1.17.xx - if you run into this, reload the data out of the ZIP files per steps 3 and 4 above.)
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 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 the 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?
- MS-Access allows unlimited tampering with the elections data.
- There's also an easy way to defeat the GEMS Admin password.
- The audit trail has been left wide open to the point of uselessness. Even if it wasn't, alterations that are done in Access never make it to the GEMS audit log anyways - the log items are CREATED by GEMS, not by Access.
- Therefore, the only reason you'd need to tamper with the GEMS password by copying the password from a new datafile is if you wanted to check your dirty deeds in the GEMS program. Somebody who knows GEMS inside and out will never have to do that - they only need alter the data in MS-Access.
- There's one other issue we didn't get into, as it's more complex than I wanted to do for this article: the actual vote data is duplicated internally, and GEMS makes requests to each of the two tables for different purposes. In accounting terms, it's a "double set of books" problem (which is a hallmark of fraud). Basically, if you ask for countywide totals, that's pulled out of one data file, while precinct-by-precinct data comes out of another - and GEMS never checks to see if the two match, or informs the GEMS console user that this is happening. But in Access, you can alter the vote tallies in the one GEMS uses for countywide queries and so long as you take away the same number of votes for one candidate as you give another (to keep the total number of votes correct), there's no way to tell. Here's the critical part: if you're an honest elections officer and you "smell a rat", the first thing you do is spot-check some precincts. And you'll get honest numbers. Only by printing out the totals from each individual precinct one at a time, adding them on a hand calculator and comparing to the countywide total would you realize there's a problem - and you still wouldn't understand why, because nowhere in the GEMS program or documentation (see also the GEMS user manuals in PDF form included) does it say there's "two sets of books". (SEE ALSO Bev Harris's report on the "scoop" site, first URL at the very beginning of this document for more info.)
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:
- Chavez: 88 /
Boyd: 89 / Pineda: 90 / Davis: 91 / Jones: 93 / Simon: 99 /
(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!
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.equalccw.com/commiemommies.html (the first time my reporting made Matt Drudge's site)
http://www.equalccw.com/donperata.gif (the second time Drudge picked my stuff up - note that Perata is a well-known rabidly anti-gun politician)
...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?
- Diebold is supposed to be supplying security with their system - it's part of the contract for services, either implied, specific or in some cases, mandated by law. So they leave their FTP site totally wide open, only encrypt some files and the ones they do encrypt, they do so with ZIP encyption which is known to be flawed?
- Diebold grabbed elections data from 3:31pm on the DAY OF THE RACE in SLO County. If the data isn't public record, then what the hell were they doing with it?!
- California Penal Code 19205(c) says that the Secretary of State shall not approve voting systems that are "subject to tampering". GEMS doesn't even begin to qualify, once you know that MS-Access is a "hack tool". By withholding the info on grotesque security flaws via MS-Access, Diebold violated God only knows how many contracts plus that element of state law.
- I could go on, but you get the point.
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:
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.