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."

Comments

Code shouldn't be important!

[hampton2600]

If these systems were really secure, then finding out the code shouldn't be important. Just because I know the RSA 128-bit algorithem, doesn't mean that I can break it in a second!

Also, why isn't the federal government coming out with a standard software framework for voting?

This seems obvious to me, at least.

Not that I trust my government to be the best coders, but heck... get the DOD on it. They are pretty good at these problem domains.

Maybe they'd run it off of source forge....

-hampton2600.

Embarrassing answer

[freeweed]

I'll probably embarrass myself even more by my answer, but here goes.

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? :) 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.

Short answer: variable names.

[slackergod]

To go from, say, a C language file to an exe,
the compiler first loads the C file (ending in .c),
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.

Bullshit. Libraries. F-15s. Interstate Highways.

[namespan]

Yeah, because if the federal government does it, it is efficient, reliable, and effective.

Blah blah -- the government boondoggle meme strikes again. Yes, it has its roots in some truths, and that's why it exists. But...

The problem is, there are in fact examples of government programs and agencies working and working well. Our, poor, terribly innefficient government programs are responsible for creating the world's best military. My locality might be an exception, but we've got incredible public library resources that I'm so happy with I'm *glad* when I get library fines. The Interstate Highway system makes cross country travel effecient and quick -- which keeps the cost of goods lower -- at least, those you buy that were shipped from somewhere else.

Yep -- I know, private firms were involved in the creation of each of those things. Doesn't change the fact that some branch of our poor, incapable, incompetent government commissioned and managed those projects.

And yes, I know -- the DMV is frustrating to deal with. But I can tell you that the service of the DMV and even the IRS looks positively stellar compared to any number of private entitities -- several health insurance companies, Sprint, Microsoft Customer support, and the hosting company I called last week (no, not some dinky provider either -- I'm talking freakin' Interland here). All of whom should have, in theory, been erased by the invisible hand or otherwise kicked in the pants by the market. But in fact, these beaurocracies are no better than most mediocre government beaurocracies.

So it's fun to repeat, but remember to look at the facts while you're thinking about it. Our beloved commercial driven-to-efficiency-by-the-market companies have produced an absolute steaming heap of bovine excrement when it comes to an e-voting product. And yes, it's still taxpayer subsidized, because our governments are paying for these products -- and not just the costs, but also the profits.