here's one for the geeks - GEMS: A few dirty hacks

http://www.legjoints.com/DirtyHacks/

if you're not a geek, here's the conclusion:

I really thought it would be more difficult than this. As I said above, this is reverse engineering 101 stuff; the guys who cracked that copy of Doom 3 you were just playing can do this in their sleep. Furthermore, this method leaves a far smaller footprint on a system than the installation of MS Access( see http://www.chuckherrin.com/hackthevote.htm ), a program which takes quite a few megs of diskspace and makes numerous changes to the registry and system files. Ollydebug will run from and fit comfortably on a 3.5" disk, and will only leave a trace of its use if the changes to Gems.exe are saved.

It should also be noted that there are much more powerful debuggers out there. The commercially available Softice, for instance, is made to run invisibly in the background, and contains features allowing the debugging of a system from a remote machine. And, of course, if there were to be no filesystem integrity checks on the machine in question, a small patch could be written to make the changes to the program very quickly.

if you have any questions about it, Im glad to answer them

Is that after you install those patches the system is obviously hacked. A better approach is to detour the SQL invocation stuff and then (by manipulating the SQL gems is trying to pass to the database) add a login that doesn’t exist in the database, remove actions associated with that login from the audit log, and do whatever manipulation your hack is intended to do.

For those not familiar with this stuff, the suggested approach (as well as my modification to it) exists only in memory. Meaning that once the target program is reloaded or the machine is rebooted all evidence that it was ever hacked is gone.

I just placed the vulnerabilities in the paper in the order I found them. and for shock value.

i just read it.
its interesting. nice work..

question: it is possible to install a "runtime programm" that runs in background an modifies the values of votes of an candidate while those are in memory or on disk (harddisk)?

i guess that possible.

also a question about gems itself. where exactly is it running?

every county has one program where they recieve all datas from the Precincts?

or do all Precinct have one GEMS runing and recieve the datas from the "wards" (right word?i am german:).. and forward the final total to the county?

greets

in regards to the first question; yes, it is possible. GEMS is like any other unprotected program ( think notepad ), and any program that uses debugging routines can "attach" itself to GEMS by either loading the .exe from disk or hooking it during runtime. And since all of the database access in the program that Ive seen is done using SQL strings, its quite easy to manipulate what comes up on the screen. Ive successfully patched it to display the votes for one candidate as the others and vice verse.
for the second question, I would assume the number of tabulators would be up to the discretion of state or local legislators. to tell the truth, Im not really sure; but in the sample database it seems to be one tabulator, one county.

info could have the patch above and do the adjusting of the votes as it read them -

with the audit log off - hmmmm - didn't Bev find no entries for a rather larger period of time - the change can be made, a wipe clean and restore orginal program done - all in a few seconds.

Simple audit controls would make the result "reasonable" and a simple wipe coded at the end of the instruction of the "read" portable memory device done as it is being used leaves us with voting machine totals matching portable memory device totals and no patch program visible.

Without CIA/FBI level readers, there would no trail - ANYWHERE

THE ONLY PROOF WOULD BE THE EXIT POLLS!

but theres always the possibility of carelessness. if there WAS hacking of the GEMS tabulators, and if thre is a clear idea of HOW it was done, auditors will have a better idea of what to look for.