More E-Voting Software Leaks Surface
Christopher Soghoian writes "Sound like something you've seen before? Wired News reports that the software which runs Sequoia's AVC Edge voting machines has been accidentally placed on another company's publicly available FTP server, although this time it's the binary, rather than the source that's been leaked. Machines running this software were used in California's Riverside County for the 2000 presidential election and for last month's California gubernatorial recall election. The system also has been used in counties in Florida and Washington state."
Let's see, the software is written on a Microsoft base, is closed source and... shudder... appears to be prone to tampering. Just like Diebold and I would imagine every other vendor's software.
We need to get the source in the open, and more importantly, we need to have these machines give paper ballot reciepts as well as an internal audit tape like those found on ATMs...
There is a bill in the House (H.R. 2239) that already has a lot of support and addresses a lot of these issues. Please urge your representative to support it as well.
The /. community didn't produce the binary in question nor did open source. The point is that a source code leak shouldn't imply a security risk and a binary leak *really* shouldn't imply a problem.
I'll probably embarrass myself even more by my answer, but here goes.
:) I'm sure 50 other Slashdotters will expand/correct/make fun of me, but I figure since no one else is answering, I'll take a stab at it.
You can often get a fair bit of source from a binary, but it all depends on what language the source was originally from, what platform it was written for, etc.
More importantly (as I understand it) is how it was compiled, etc. Source code isn't just translated line by line into machine code. Especially with today's optimizing compilers, there's a lot of automagic going on.
Now, you usually can get the assembler directives out of a binary (ahh, disassemblers are fun), but even this is dicey. I know from playing around with Atari 2600 roms that often you can't know precisely what parts of the code do what, iirc because code and data were often intermixed in irregular ways. Even if you get the full assembly code, have fun reading it if it's more than a few thousand lines.
Having said that, there's a lot of incredible stuff a skilled person can do with disassemblers, but it all comes down to the source->machine code translation. There's a lot of factors that come into play here, and it's not just a simple inversion of some always used process.
There, can I be less specific?
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
To go from, say, a C language file to an exe, .c),
the compiler first loads the C file (ending in
and all the files it refers to,
and then parses all of it into an internal
structure.
this structure is then optimized:
loops are unrolled, functions are inlined,
and info that is mention but isn't needed
is stripped out.
the resulting structure is then
written out as a series of assembly
instructions, which are then
converted to the numeric codes
the processor understands.
this is the exe.
to go backwards, it's (generally)
trivial to take an exe and get a
plaintext file containing the assembly
instructions (this file usually ends in '.a')
it's the optimization step that causes
issues: one of the main things the computer
doesn't need which is stripped out is
variable names, comments, etc.
without them, there's no context.
you can figure out the algorithm from the assembly,
but you can't easily figure out what
it's operating on.
to make things worse, other optimizations
may alter the code for faster execution,
making it even harder to figure out.
Occasionally, mistakes are made...
Microsoft slipped up a while back,
and released a windows patch which had
the 'debugging info' left in it.
All this really amounts to is the variable
names, function names, etc...
which is bloody useful.
Making this process even worse is that
some (rare) executeables are self modifying,
which makes them MUCH harder to predict.
in summary, it's not that hard to get
back to C code, assuming the program
was even written in C. You'd just have
variable names like 'var0001', 'var0002'
'func0001', etc.
It's basically the difference between
having a nice nested tree structure
which you can compartmentalize and analyze,
versus one long list of instructions,
which the computer may start and stop
execution of at any point.. sorta like DNA.
Here in Brazil, were we have had last year the largest elections using proprietary-software-equiped-polls, it seens that there have been more than a
couple of frauds last year.
The latest news are these ones (In Portuguese. Use
the fish to read in English).
There have surfaced accuatins of votings being sold at R$10,00 (~U$3.30) each one, and of a candidate that had more than 1000 votes while they were being counted ending up with zero votes.
I just hope they get to the only one true: these eletronic polls, as they are, are nothing but election-buying machinnes.
-><- no
This is from Lynn Landes ecotalk.org... I am sure she won't mind.
SEQUOIA VOTING SYSTEMS INC. http://www.sequoiavote.com
Article - August 4, 2003 - Sequoia Voting Systems, a pioneer in direct recording electronic voting systems and a leading provider of voting equipment and services in the United States, will partner with VoteHere, Inc. of Bellevue, Washington, a leading supplier of secure electronic voting technology, to provide a new level of electronic ballot verification to customers of the AVC Edge touch screen voting system. http://www.votehere.net/news/archive03/080403.htm
? % of U.S. vote count: According to its website, Sequoia technicians "managed thousands of electronic elections for 14 years in 16 states." http://www.sequoiavote.com/aboutSequoia.php
Company description: Full service. "Through its nationwide network of offices, Sequoia has equipped and supported elections in thousands of jurisdictions - with populations ranging from a few hundred voters to over three million." http://www.sequoiavote.com/aboutSequoia.php
Ownership: 85% De La Rue www.delarue.com 15% Jefferson Smurfit Group http://www.smurfit.ie/ / source: http://moneyextra.uk-wire.com/cgi-bin/articles/200 205290701145655W.html
"De La Rue (London, UK) is the world 's largest commercial security printer and papermaker, involved in the production of over 150 national currencies and a wide range of security documents such as travellers cheques and vouchers. Employing almost 7,000 people across 31 countries, the company is also a leading provider of cash handling equipment and software solutions to banks and retailers worldwide helping them to reduce the cost of handling cash. We are also pioneering new technologies including tailored solutions to protect the world 's brands through to government identity solutions in secure passports, identity cards and driver 's licences. De La Rue has a 20% shareholding in Camelot - the operator of the UK National Lottery." source: http://www.delarue.com/about/ http://moneyextra.uk-wire.com/cgi-bin/articles/200 205290701145655W.html
"The Jefferson Smurfit Group... (Ireland) is one of the largest European-based manufacturers of containerboard, corrugated containers and other paper-based packaging products. In addition to wholly owned operations, the Group has interests in several associated companies, the principal of which is Smurfit-Stone Container Corporation (SSCC). Spanning 4 continents and 30 countries, JSG and its associates employ some 68,000 people and are significant players in Europe, Latin America and North America." source: http://www.smurfit.ie/ (see below for Madison Dearborn Partners buy out information)
Chicago-based Madison Dearborn Partners has received antitrust approval from the Federal Trade Commission for its proposed acquisition of Jefferson Smurfit Group PLC..http://stlouis.bizjournals.com/stlouis/storie s/2002/07/15/daily68.html Madison Dearborn Partners ("one of the largest and most experienced private equity investment firms, lots of communication stuff - http://www.mdcp.com/portfolio.asp ) has ownership stakes in Milnot Holding Corp. http://www.milnot.com/ and Outsourcing Solutions Inc. http://stlouis.bizjournals.com/stlouis/stories/200 1/05/07/daily28.html in St. Louis. Jefferson Smurfit Corp., the American division of Ireland-based Jefferson Smurfit Group PLC holding company, was based in St. Louis prior to its 1998 merger with Stone Container Corp. The merged company became Smurfit-Stone Container Corp. based in Chicago. Jefferson Smurfit holds about 29.5 percent of Smurfit-Stone. Jefferson Smurfit (NYSE: JS) is one of the largest manufacturers of container board and corrugated containers and recycles wastepaper in about 600 facilities worldwide.
Madison Dearborn Partners: Council Tree Hispanic Investors II, LLC Longmont, Colorado CTHI indirectly owns approximately 18% of Telemundo, one of two Spanish-language broadcasting
You would think these guys would disable it after a slashdot posting... They must be busy playing pirated half life 2 demos.
His response: We talked about it but this would make full internet voting possible. The API and protocol would be documented. We would not have a captive product! We will never move in this direction.
Shows what they care about the quality of the actual voting.
I found a pretty interesting list of the available voting software . At least I thought it was interesting.
*Very informative* articles by Votescam.com
http://votescam.com/chap1.html (1 of 5 chapters)
Technological excerpts:
"Nothing was said in the press about the secretly programmed computer chips inside the "Shouptronic" Direct Recording Electronic (DRE) voting machines in Manchester, the state's largest city.
These 200-pound systems were so easily tampered with that the integrity of the results they gave -- and George Bush was the beneficiary of their tallies -- will forever be in doubt. Consider these points:
1. The "Shouptronic" was purchased directly from a company whose owner, Ransom Shoup, had been twice convicted of vote fraud in Philadelphia.
2. It bristled with telephone lines that made it possible for instructions from the outside to be telephoned into the machine without anyone's dear knowledge.
3. It completely lacked an "audit trail," an independent record that could be checked in case the machine "broke down" or its results were challenged.
4. Roy G. Saltman, of the federal Institute for Computer Sciences and Technology, called the Shouptronic "much more risky" than any other computerized tabulation system because "You are fundamentally required to accept the logical operation of the machine, there is no way to do an independent check."
A year later, in June of 1989, Robert J. Naegele, who had investigated all computerized voting systems for New York State, warned: "The DRE (which the Shouptronic was) is still at least a year and possibly two away from what I would consider a marketable product. The hardware problems are relatively minor, but the software problems are conceptual and really major".
A source close to Gov. Sununu insists that Sununu knew from his perspective as a politician, and his expertise as a computer engineer, that the Shouptronic was prime for tampering."