"The Howard Dean Demo"
In Still Images

By Jim March, based on research by Bev Harris.

(1024x768 screen recommended, but 800x600 will basically work)

In early August, Bev Harris demonstrated to Howard Dean on CNBC how MS-Access can be used as a "hack tool" to alter votes in a way that precinct spot checking such as the California mandated 1% manual recount won't catch, even if there's optical ballots and a proper paper trail.

The implication is that even with a "Voter Verified Paper Trail", election tampering is possible with dishonest software such as the Diebold GEMS product - the central vote tabulator software in any Diebold voting system configuration (touchscreen or optical scan).

This series of still images walks you through what Dean saw, via screenshots.

IMPORTANT!: everything you see here as done in MS-Access can also be accomplished via SMALL Visual Basic script files.  The ability to have such scripts run can't be removed as it's built into Windows as long as the MS-Access runtime is present - and that's needed to make GEMS work.  Many counties have been removing MS-Access from the one computer in the county that runs GEMS; that is NOT a fix for what you see here!



http://www.ninehundred.net/~equalccw/BGFD.gif - basic opening screen of GEMS once you're past the login.  I can't show it to you, but under the "GEMS" pulldown menu are two commands that are used to extract data.  "Election Summary Report" is supplied by the "SumCandidateCounter" table (countywide summary) and "Statement Of Votes Cast" comes from the "Candidate Counter" table.



http://www.ninehundred.net/~equalccw/BMBD.gif - this is what the first screen looks like when you open the same data file in MS-Access (ver. 2000 or better).  Other items to note: "operator" allows you to alter GEMS system passwords - no password is needed to get into the data with MS-Access!  You can also see the GEMS "audit log" - THAT is fully editable.  In MS-Access, there's a feature that assigns permanent line numbers to audit logs in MS-Access databases.  Diebold turns it off...so you can edit "middle entries" without leaving a noticable gap in the log entries.  The security was bad to start with, and then Diebold flat-out raped it.



http://www.ninehundred.net/~equalccw/BDCVT.gif - In MS-Access again, with the table "SumCandidateCounter" open.  This is the table that generates "countywide" summary figures.  We've stripped it down to just one precinct with data; note the numbers.



http://www.ninehundred.net/~equalccw/BDPBPVT.gif - MS-Access view of the table that GEMS pulls it's precinct-by-precinct queries from ("CandidateCounter").  We've got different numbers going on than SumCandidateCounter - we entered those manually in MS-Access.



http://www.ninehundred.net/~equalccw/FDGPBPVT.gif - the results of a "Statement Of Votes Cast" command in GEMS (precinct by precinct data from "CandidateCounter").  Note the totals.



http://www.ninehundred.net/~equalccw/FDGC.gif - results of a GEMS "Election Summary Report" command (data from "SumCandidateCounter").  Note how different numbers are being reported.

It's easy to see the problem here because we've created a very artificial vote database so that it has data in ONE precinct only.  But if there were hundreds of precincts, this would be impossible to spot by eye; thousands of precincts is a more common situation!  (We altered a test data file from Cobb County GA.)

Now let's check out how we did this:


http://www.ninehundred.net/~equalccw/BDMAATDF.gif - this is the "SumVCenterStats" table, where the item in the "Dirty" column determines whether or not each precinct is "coupled" - crosslinking "SumCandidateCounter" and "CandidateCounter".  In this version of GEMS (1.17.15) a "zero" indicated "decoupled".  Change to a "-1" and the system will "block hacking" of the sort we've just seen by making sure the vote totals match across the two sets of books.  Under a number of circumstances, GEMS will re-link individual precincts using this table...basically any time they suspect somebody might personally inspect matters, such as just after some manual entries.  It's human nature to check your work - enter some paper votes that wouldn't scan (written in crayon or whatever) and you might check to see that first they were entered into the right precinct, and then that the countywide total incremented.  If this didn't happen, an honest election worker unaware of the back door might smell a rat.  We don't know all the circumstances but we have IDed manual entry as something that re-links those precincts in which data was manually entered.  NOTE: there is NO "manual control" for this field's data in GEMS!  It is controlled "automatically" or manually via the "back door".

We don't claim to know everything about this hack.  But Diebold damned well does.  They have the access to the GEMS machine necessary to exploit it, via at least four channels that we know of and probably more that we don't.

GEMS must die.  Period.


The problems are present on all versions of GEMS now in use.  This is GEMS 1.17.15 but it's been examined all the way through 1.18.19 (the latter thanks to an honest elections official in Arizona).  Only the exact "cheat codes" in the "dirty" field change significantly.

Back to Jim's "Diebold page"