Supicious Signs of Hacking in the Pima County RTA Election

Jim March, a longtime associate and current boardmember of BlackBoxVoting.org, has been working pro bono with EDA investigator John Brakey for most of 2007, examining suspicious elections in Pima and Maricopa counties. The Pima trial is a direct result of their investigative findings.

The RTA Election Of 2006: Suspicions Outlined

1. The county ran the election and had a strong interest in the outcome, going so far as to pay consultant James Berry at least $75,000 in support of the bond measure. Berry also took money ($13,000) from the "official" pro-RTA bond people (basically developers).

Here's a link to the video of James Barry's court testimony, demonstrating that the Pima County government had a deep, vested, and motivated interest in the outcome of the RTA election.

http://video.google.com/videoplay?docid=1282511168148207359

2. The bond measure had failed four times previously and was losing in the pre-election polls. (There was no exit poll.)

3. On the evening of the election (5/16/06) Dr. Ted Downing (a legislator at the time) noted Bryan Crane reviewing an open MS-Access manual on the table next to the central tabulator station. John Brakey found op-scans breaking down at precincts and called Downing.

4. In the weeks that followed, in meetings with (among others) the Pima County Democratic Party chair (Donna Branch-Gilby), Brad Nelson refused to allow even basic oversight -- such as a visual inspection to make sure that additional PC stations weren't wired into the central tabulator via the network cable clearly visible snaking under a locked door. This refusal was interpreted at the time as Nelson's practical declaration that he had an unfettered right to manipulate elections, and nothing he's done since has alleviated that apparent stance. (It's true that since that event, John Moffatt has managed to push through some transparency measures -- but all the while Nelson and Crane have systematically sabotaged Moffatt's efforts.)

5. The actions of Bryan Crane on the morning of 5/11/06 have been rehashed ad nauseum. Yet the fact remains that the official story (at least the version in court on the witness stand) has Crane making two mistakes rapid-fire on the morning of the 11th: He over-writes the previous day's backup file (ignoring GEMS' warning about same) and then prints TWO copies of the summary report within 10 minutes of each other -- and again, for each summary report he has to confirm his selections manually. Either mistake would be remarkable. Both happening within minutes? It looks like hacking. Period. The appearance is that bad data from outside the shop was brought in, uploaded, then an over-write of the previous day's good data with the bad occurred. And then two summary reports were printed moments later -- to confirm a successful hack and/or in order to prove to parties unknown that the hack had occurred? In his court testimony, Crane lied about how he performs backups.

Testimony of Bryan Crane on the RTA and iBeta report (17 minutes): http://video.google.com/videoplay?docid=7304338799617243809

6. There is still a timestamp anomaly. Granted, the file "creation" and "last accessed" timestamps would have been re-written by the exchange of file servers in June of 2006 due to how Windows handles those timestamps. But our tests show that the "modified" time/date-stamp would not change due to a simple file copy operation. According to the iBeta report and associated E-mail traffic behind it (public records after the fact) the "early day 1" filename has a "last modified" date of 9:56 a.m. on the morning of May 11th, 2006. But according to E-mail traffic back and forth to John Moffatt, the timestamp was 10:56 a.m.

In December of 2006 the Democratic Party obtained a complete directory listing of both current servers. We show a timestamp for that file of 9:56 a.m. -- which in turn matches the time and date that the GEMS audit log says the "overwrite" of the morning of 5/11/06 happened.

We have confirmed that if a file is created and has a "last modified" date of, say, 3:00 p.m., and the file is shipped across time zones by ANY means, the timestamp doesn't "auto-correct" for the new time zone. Such functionality just isn't there -- the Windows file system has literally no place to record the timezone in which a file was created. So iBeta's Colorado location wouldn't have adjusted the file "last modified" time by an hour.

The implication is that somebody adjusted the file before it got to iBeta.

7. The "five files" situation. According to iBeta, they were unable to read any data off of the original pair of GEMS systems (the ones actually used on the RTA just before their retirement). From the other newer pair of systems they extracted five identical copies of the "early day 1" RTA file involved in the over-write of 5/11/06.

Our copy of the directory listings of Dec. '06 shows only two copies.

This bolsters the possibility that the RTA data files were modified prior to being shipped to iBeta. At a minimum, we can state that the files were being looked at and duplicated between Dec. '06 and their duplication for iBeta around June '07.

CONCLUSIONS:

The court has already been provided with a schedule of tests we believe should be performed on the complete data set for any given election -- most definitely including the RTA '06 Special Election. We feel that some of these tests would be particularly beneficial in this case, such as checking the internal timestamps on the MS-Access tables and looking at the "vote totals flow" throughout the mail-in vote processing.

ADDENDUM:

In April of 2007 the court wisely agreed to sequester copies of the MDB/GBF files at issue in this case in the court's vault. To that end the plaintiffs purchased a brand new external hard disk (Seagate FreeAgent 250gig) from Best Buy and brought it to county elections HQ in it's factory shrinkwrap. County staff unwrapped it, plugged it in, created two directories (one for each GEMS main and backup server) and copied all MDB and GBF files to it.

But they also grabbed something else.

At the plaintiffs' request, they created new copies of the file directory listings as .TXT files, similar to what was obtained in December of 2006 and already understood by the county elections office to be a public record. Those also went onto that Seagate disk and are in the court's vault right now.

We would dearly love to compare that directory listing to the Dec. '06 listing we have now. That alone may show a difference in the RTA-related files if somebody was doing "cleanup" after this situation began to publicly implode. We would then like to compare that listing to what iBeta received. We suspect the data sent to iBeta was already falsified, rendering their results null and void.

We don't know for sure if this directory listing analysis will flush out fraud. It might prove our theory that iBeta received the famous "garbage in" that led to "garbage out".

We would ask that our hard disk be plugged into a computer owned by the court, and the two .TXT directory listing files be copied to at least three CDs -- one for us, one for the court, one for the defense.

John Brakey is co-founder of AUDIT-AZ (Americans United for Democracy, Integrity, and Transparency in Elections, Arizona) and Co-Coordinator of Investigations for Election Defense Alliance

5947 S Placita Picacho El Diablo
Tucson, AZ 85706
Ph: 520-578-5678
Cell: 520-250-2360
AUDITAZ[at]cox[dot]net

The Mission of AUDIT-AZ and EDA: To restore public ownership and oversight of elections, work to ensure the fundamental right of every American citizen to vote, and to have each vote counted as intended in a secure, transparent, impartial, and independently audited election process.

"Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has." -- Margaret Mead