How Triad hacked
SUMMARY
This paper presents a simple formula that vote tabulation software can employ to steal an election undetected.
I will show that this algorithm is guaranteed to be immune from detection under all conceivable circumstances except one: a full hand recount in a precinct that was hacked. I will also show how the formula can be designed to significantly reduce this risk using publicly-available information. I will highlight some political and procedural ways that this risk factor can be further reduced.
This document is based on information regarding the tabulation software called ElecTab produced by Triad Government Systems, Incorporated. Triad software was used in many counties in Ohio that voted using punch card and optical scan ballots. This algorithm could be adapted to work with many others systems’ tabulation software.
REQUIREMENTS FOR CONCEALMENT
The software used to tabulate ballot counts from punch card readers or optical scan readers have two essential functions:
a) interpret the results from the card reader, e.g. to match up the hole punched on the card with a candidate’s name.
b) total the votes
A third function could be introduced to contain the logic that will alter the outcome based on a simple formula designed to reduce the risk of detection. This formula depends on the inclusion of the following pieces of information within the program code:
1) precinct number
2) expected turnout
3) Yes/No flag indicating whether the precinct is safe to hack
The precinct number is required information that must be present in order to interpret results from the card reader. Expected turnout is used to distinguish whether the current tabulation is a test run or an official vote count. Expected turnout could be predicted ahead of time based on information about past turnouts and current voter registration information.
Defining certain precincts as unsafe to hack will protect against the risk of a full hand recount exposing the discrepancy between the true ballot count and the results generated by the software. It can be shown that the lax enforcement of Ohio recount procedures in combination with an intelligent assessment of precincts likely to be chosen for a hand recount can eliminate the risks of detection.
This information can be inside the compiled code of the tabulation software which is unreadable to the human eye. Only a court can order the software vendor to de-compile the code so others can inspect the source code. Otherwise there will be no other physical evidence on the computer that fraud occurred.
The software must be able to protect itself against detection during an audit. Therefore it must be able to determine whether the current tabulation is a test or the real thing. The test hand counts must always match the machine count. Ohio recount provisions state that actual ballots can not be used to perform the test. Because of this provision, the software will never hack a test count because the precinct information used to interpret the results will never match a precinct on the previously defined “safe” precinct list.
To guard against the possibility that Board of Elections workers will use the ballots from a real precinct in the test, the software can reference the computer’s system date and/or an audit file containing the results of previous tabulations. By incorporating conditions based on previous counts and the system clock the program will succeed in detecting test counts even in the cases where a) the battery-powered system clock is inaccurate; and b) the file containing past tabulations is missing.
Please note that it would not be unexpected for the tabulating computer to have the results of previous tabulations written to a file on the computer’s hard disk. In fact, it may even be required in some places as an auditing mechanism.
THE ALGORITHM
Designing software is a simple logical process. The program receives input and processes it based on clearly defined conditions. The designer must identify which conditions to test and process the input based on the answers. The decision charts shown below can be used to meet all the requirements mentioned above.
The first test shown below can be used if it is found that the system clock is unreliable. The system clock on personal computers is powered by a small battery that lasts up to ten years. Since one of the two algorithms shown below relies on the current date, it is necessary to code for the contingency that the system clock is not set correctly.
The first algorithm therefore depends on the existence of a file containing the results from a previous tabulation. That information can then be combined with the expected turnout number and safe-to-hack precinct flag to determine the results.
Below are the decision charts designed for arriving at the decision to hack or not hack the count in the current run of ballots. The software program will test for the conditions shown in the first three columns. The decision whether to hack the precinct during this tabulation is shown in the fourth column.
PREVIOUS TABULATION
SAVED TO FILE
Is PREVIOUS count close to expected turnout? Is the CURRENT count close to expected turnout? Is this precinct hackable? Hack Decision
N N Y N
N N N N
N Y Y Y
N Y N N
Y N Y N
Y N N N
Y Y Y Y
Y Y N N
If the file containing the previous tabulation numbers is not present OR the hack decision is YES, the program would then proceed to check against the system date to make the final decision whether to alter the results in this tabulation.
CURRENT SYSTEM DATE
Current Date Is THIS count close to expected turnout? Is this precinct hackable? Hack Decision
< Nov 2 N/A N/A N
>= Nov 2 Y Y Y
>= Nov 2 Y N N
>= Nov 2 N Y N
>= Nov 2 N N N
These tests will determine conclusively whether the current tabulation is for a test or for an official count. It will alter the outcome of the individual precinct only if it is an official ballot count and the precinct was pre-identified as one that is “safe” to hack. Additional logic can be included in the program to scientifically determine how many votes to flip in a way that will also help it avoid detection.
CONCLUSION
The programming design illustrated in this document guarantees against detection except in the situation where a full hand recount occurs in one of the precincts that was expected to be “safe” to hack. This design produces tabulation software that a) leaves no physical evidence of fraud; b) can differentiate between test runs and official counts; c) always returns the same results; and d) never needs modifying after the candidate rotation is entered. It can also run on any MS-DOS or Windows operating system released in the past 15 years.
Thus the key to avoiding exposure is to ensure that none of the hacked precincts are chosen for a full hand recount. Lax enforcement of recount guidelines greatly reduces this risk. Risk is reduced even further because many precincts will be not be hacked.
To swing the election in favor of a candidate by 2% percent only requires changing the votes on 1% of the ballots. Due to the small number of voters per precinct, the change would be quite small even in a hacked precinct. The discrepancy can even be small enough to be explained away by under votes or by chads falling off after the first tabulation.
According to published reports, random selection of the precincts for the full hand recount occurred in only one county. Many other irregularities surrounding the recount process have also been reported. Many of the hand counts that were conducted produced results that were slightly different from the machine count.
The design presented here offers a fool-proof method for avoiding detection when the risk of hand counting a known hacked precinct is managed.
http://www.democraticunderground.com/discuss/duboard.php?az=show_mesg&forum=203&topic_id=337686&mesg_id=339752