Democratic Underground Latest Greatest Lobby Journals Search Options Help Login
Google

Diebold Software and Impounding machines

Printer-friendly format Printer-friendly format
Printer-friendly format Email this thread to a friend
Printer-friendly format Bookmark this thread
This topic is archived.
Home » Discuss » Topic Forums » Election Reform Donate to DU
 
berni_mccoy Donating Member (1000+ posts) Send PM | Profile | Ignore Thu Dec-09-04 11:31 AM
Original message
Diebold Software and Impounding machines
I've heard on other posts that Diebold use the Windows platform and programmed it in .NET. If this is true, there is a good chance, if a machine is impounded, that we could 'de-compile' the binary images back into source code (if Diebold didn't take steps to perform source code obfuscation on the binaries).

.NET is very much like Java with respect to the ability to get source back out of the compiled image. I'd like to get my hands on the file-system of one of those machines...

Of course, I've also heard that Diebold machines use a central tabulator. These machines need to be impounded as well in order to get the server-side processing code off them.
Printer Friendly | Permalink |  | Top
flyingfysh Donating Member (1000+ posts) Send PM | Profile | Ignore Thu Dec-09-04 11:36 AM
Response to Original message
1. what .NET compiles down to
Any .NET language compiles down to something called "IL" (intermediate language), which looks like assembly language, but is oriented toward making things like various types of procedure calls and object manipulations easier. IL itself is compiled further by the runtime on each particular machine, so that quirks of the processors that happen to be present on particualar machines can be taken advantage of.

IL is actually easy to read. There are whole books on the topic, some of them published by Microsoft.
Printer Friendly | Permalink |  | Top
 
berni_mccoy Donating Member (1000+ posts) Send PM | Profile | Ignore Thu Dec-09-04 11:41 AM
Response to Reply #1
2. Exactly.
Unless the binaries are obfuscated, the names of variables, routines, and other symbols are preserved, making the re-compiled source represent the original source-code fairly accurately. Even better, the algorithms are preserved better than native code since many compiler optimizations occur on IL, not on the original source language.
Printer Friendly | Permalink |  | Top
 
thedutch Donating Member (37 posts) Send PM | Profile | Ignore Thu Dec-09-04 01:17 PM
Response to Reply #2
3. diebold, at least, has been very kind
not to obfuscate any of the code in GEMS. Ive been messing with it in Ollydebug and IDA( free edition, www.datarescue.com ). IDA in particular does a VERY good job at translating symbols, imports and routines.
Printer Friendly | Permalink |  | Top
 
mulethree Donating Member (1000+ posts) Send PM | Profile | Ignore Thu Dec-09-04 02:01 PM
Response to Reply #2
4. Is this like the symbol data stored in a debug compile in pre-NET?
I haven't used .net
Printer Friendly | Permalink |  | Top
 
berni_mccoy Donating Member (1000+ posts) Send PM | Profile | Ignore Thu Dec-09-04 04:28 PM
Response to Reply #4
5. Not exactly
A good deal of software relies on runtime-type inspection and late-binding to interfaces exposed in the code. This requires that more type information be embedded than has traditionally been done with native code. Furthermore, because the language is first converted into an intermediate language (IL), common optimizations that usually hide the original intent of the program are not done at the conversion to IL. Instead they are done to the converted IL. But the IL is considered the binary (so it can be optimized on any platform it is run on). As a result, it is much easier to reconstruct the original source from the binary.


Traditionally the process went like this:

High-level language (C/C++/VB) ----optimizing compile----> native machine code binary


Now it's like this:

High-level language (C++/C#/VB) ---- IL conversion ---> IL binary (machine independant)


When the binary is run, it is dynamically compiled (and optimized) by the .NET runtime and the native machine code binary is only temporarily cached.

There is much more information available in the IL binary than the traditional machine code binary.

There do exist code obfuscators that take the original IL binary and change it into a new IL binary that produces functionally equivalent native machine binary code but is much more difficult to reconstruct the original source code from. You can usually tell just by looking at the IL if its been obfuscated.

Printer Friendly | Permalink |  | Top
 
thedutch Donating Member (37 posts) Send PM | Profile | Ignore Thu Dec-09-04 04:40 PM
Response to Reply #5
6. "functionally equivalent native machine binary code"...
similar to what they called polymorphism back in the day? there could be heuristic analysis techniques that can reconstruct the source, like what the virus-scan progs use.
Printer Friendly | Permalink |  | Top
 
mulethree Donating Member (1000+ posts) Send PM | Profile | Ignore Fri Dec-10-04 02:10 AM
Response to Reply #5
7. so munged variable names?
If I read that right, you said it's PCode with late binding :) (flashback 25 years to UCSD Pascal and smalltalk-80 on my very first home machine - a screamer with 3.5mhz and 64KB!)

So it wouldn't need to store the human readable names for symbols like a debug symbol table. But I'd bet $5 that they release the debug symbol table with it.

Printer Friendly | Permalink |  | Top
 
DU AdBot (1000+ posts) Click to send private message to this author Click to view 
this author's profile Click to add 
this author to your buddy list Click to add 
this author to your Ignore list Thu Apr 25th 2024, 06:30 AM
Response to Original message
Advertisements [?]
 Top

Home » Discuss » Topic Forums » Election Reform Donate to DU

Powered by DCForum+ Version 1.1 Copyright 1997-2002 DCScripts.com
Software has been extensively modified by the DU administrators


Important Notices: By participating on this discussion board, visitors agree to abide by the rules outlined on our Rules page. Messages posted on the Democratic Underground Discussion Forums are the opinions of the individuals who post them, and do not necessarily represent the opinions of Democratic Underground, LLC.

Home  |  Discussion Forums  |  Journals |  Store  |  Donate

About DU  |  Contact Us  |  Privacy Policy

Got a message for Democratic Underground? Click here to send us a message.

© 2001 - 2011 Democratic Underground, LLC