Not human readable. Software developer here. We have the ability to reverse de-compile compiled code to a very difficult but human readable version of the code. If we have a machine like I have heard we have. Then we can dump the executables and libraries of that system and show the algorithm. If we have a system that has the cheat settings we can KNOW. However the source code seized is likely already scrubbed of the cheating parts because if I was doing this. I would code the cheat and put it in. Compile then remove it immediately. So the source CODE BASE will not have the cheating part in it but the complied version could.
They can even be sneaky, put the cheat part in the compiler, and every program that is compiled with it has the cheat in it, but it is never shown in the source code.
There is a security practice called reproducible binaries that is meant to help ensure this doesn't happen, but it requires a known good compiler, so you have to trust something, and as we are learning to our sorrow, that isn't all that great an idea when dealing with these people.
This is why you don't trust source code in a matter like this. You disassemble and/or decompile the code on the machines themselves and reverse engineer it. Once you understand the system calls of the OS being used and are familiar with the fundamentals of the CPU architecture, it just takes a little time.
A way to check the source code is you take two machines, one suspect and another a control, compile the code they give you (assuming you can get it with a court Order) and put it on the control. Then you run several stacks of the same ballots through both machines and see if they give the same results. If not, they didn't give you the real source code.
Not human readable. Software developer here. We have the ability to reverse de-compile compiled code to a very difficult but human readable version of the code. If we have a machine like I have heard we have. Then we can dump the executables and libraries of that system and show the algorithm. If we have a system that has the cheat settings we can KNOW. However the source code seized is likely already scrubbed of the cheating parts because if I was doing this. I would code the cheat and put it in. Compile then remove it immediately. So the source CODE BASE will not have the cheating part in it but the complied version could.
They can even be sneaky, put the cheat part in the compiler, and every program that is compiled with it has the cheat in it, but it is never shown in the source code.
There is a security practice called reproducible binaries that is meant to help ensure this doesn't happen, but it requires a known good compiler, so you have to trust something, and as we are learning to our sorrow, that isn't all that great an idea when dealing with these people.
Yeah, I didn't think of that but your correct.
Its a little esoteric, most coders don't even think about these things.
He's correct. One method to do this is called dependency injection.
This is why you don't trust source code in a matter like this. You disassemble and/or decompile the code on the machines themselves and reverse engineer it. Once you understand the system calls of the OS being used and are familiar with the fundamentals of the CPU architecture, it just takes a little time.
A way to check the source code is you take two machines, one suspect and another a control, compile the code they give you (assuming you can get it with a court Order) and put it on the control. Then you run several stacks of the same ballots through both machines and see if they give the same results. If not, they didn't give you the real source code.