[–] 26556494? ago (edited ago)
Decompiling the code (or even analyzing the machine code) certainly could produce conclusive evidence, however only so if the actually used code is still available (hasn’t been replaced nor tampered with).
However, even without that, we know the software (or firmware) stores each vote as a decimal value, and the documentation touts that an adjustment ratio (multiplication factor) can be set, which would weight votes for one candidate — which both Rudy and Sidney have already alluded to being used.
There is no legitimate reason for having this “feature” at all, except to rig an election.
[–] 26556841? 1 point -1 points 0 points (+0|-1) ago (edited ago)
OP please stop talking out of your ass you're obviously a novice
For one, compiled code is harder to read but its still code. A sufficiently knowledgeable person can read it just fine.
For another, the much bigger issue is determining what actual binary was deployed to the machines.
Voting machines are heavily regulated so there are a lot of checks against stuff like this but obviously no system is perfect.
[–] 26556987? ago
there are excellent open source compiler frameworks like the excellent llvm/clang stack which, for instance, Apple bases its language compilers off of
so one could get a great deal of leverage by just starting with such an existing compiler and the going to the code generation module (a distinct module in llvm) and work on that to obfuscate - even the higher degrees of optimization alone can tend to make the actual machine instruction sequence rather non-obvious relative to the original source code, but with actual intent, a higher degree of obfuscation could be acheived.
Or one could transform ordinary binary instruction code into an encrypted form that has to be decrypted before it can execute on the target CPU. The decryption could be built into a custom page loader - the decryption key could be provided at program execution time and the key might be kept on something like a removable usb stick or smart card