Should we discontinue EVMs?

[Raju]

Instead of blindly arguinging and disputing with the Mehta it would be a wiser idea to see what all are the ways and means to rig an EVM or totalizer or the system as a whole. And after all the details are clear then the opposite camp can place their views. But not before all the details are placed on the table and discussed in detail.

the missing details until now are as follows:

1. Proper audit of later EVM chips, esp those after 2007 by an independent authority.

2. totalizers usage details in various constituencies esp if they were used in Chidambaram's constituency Sivaganga and Sawai Madhopur.

3. why were the EVM maintenance outsourced ?

4. what constitutes maintenance of these machines ? And why were the details of such hidden from public

5. how are the contractors for this job selected. why wasn't due diligence done to ensure non-partisan contractors.

6. how come there is a claim that the EVM machines cannot be connected in/to a network yet their output is connected by a cable to a totalizer.

7. what make are the EVM chips ?

8. what are the maintenance schedules for the EVM machines ? Were any changes made to these recently.

9. Why do BEL and ECIL not maintain these machines by themselves or develop adequate capacity to do so ?

10. why is totalizer usage being hidden from the country ?

[Tanaji]

Instead of blindly arguinging and disputing with the Mehta it would be a wiser idea to see what all are the ways and means to rig an EVM or totalizer or the system as a whole. And after all the details are clear then the opposite camp can place their views. But not before all the details are placed on the table and discussed in detail.

Raju, I submit that this is exactly what has been happening. Rahul Mehta has been proposing fantastic theories that defy time, space and physical laws about cache hardwiring, 30387 micro code hacking, EVM replacements that have been shot down since they were either technically implausible or having too high an associated risk of discovery

1. Proper audit of later EVM chips, esp those after 2007 by an independent authority.

No one is debating this. In fact, Dileep, Sanku and myself have agreed that an audit is required. The EC did constitute a technical committee whose report is on the web, but a more thorough audit with full disclosure is required.

BTW, I am under the impression that the 2007 machines had a firmware upgrade rather than a hardware change to ensure that time stamps are captured. Also this was done in accordance with the explicit recommendations of the technical committee mentioned earlier.

2. totalizers usage details in various constituencies esp if they were used in Chidambaram's constituency Sivaganga and Sawai Madhopur.

We need a statement to see how prevalent was totalizer usage in these elections. Note that in your example Rawle complained of EVM fraud, but he has booth level details. So there was no totalizer. How many constituencies had this? EC is on record saying that if used, it will be only in problem constituencies or even parts of the constituency.

#3, 4, 5,8, 9 , well I am not too worried about them.

#6: Both myself and Sanku clarified this one. Network means different things in different contexts. You cant expect the EC to be pedantic on IT matters.

#7: The controller is supposed to be something from Japan that "is sealed" on delivery. Don't know what it means

#10 Perhaps its because it wasn't really used apart from the one test ? Has any other report about its usage come out?

EC has statistics on its site, I wonder if they have booth level details?

[RayC]

I am not a techinical peson.

All I know is that if I am to cast a vote, it should not be manipulated!

Do what you want, but let my vote be genuine!

[Rahul Mehta]

Rahul Mehta: EVM has 16 keys. Say EVM uses 8057. So lets say BEL ordered some 8057 for example. Then it is possible for intel to make chips that looks like 8057 and behave like 8057 with one extra feature : when a human punches KeyN followed by keys 8, 10, 14 and 12 in that order, it will give 60% votes to Candidate no. N and 40% to the rest AFTER over 400 votes are entered. The mock use just a few votes. And so mock poll will not show this manipulation, while real poll will show it.

Dileep:

1. How would the trojan knows which IO lines are used with which key, and which RAM location is used to store the vote count of each row?

2. How does it know the entry points of the "good program" so that it can call the other functions when needed?

3. How would you call the trojan code from the main program, without modifying the main program itself?

Dileep,

1. If the chip-manufacturer knows the full code inside the ROM of the EVM, he can know which RAM locations are used to store the counts of each row. eg say counts of Row1 are stored in word number 80. Say count of Row2 are stored in word number 81 and so forth.

2. Now code in ROM will make predictable changes in CPU registers when a key is pressed. eg say row-1 is pressed, then ROM will write 01 in CPU register-D. Say row-2 is pressed, then ROM will write 02 in register-D and so forth. So if ROM code is known, one can state the predictable changes ROM will make in CPU register when a key is pressed. So the microcode can know which key was pressed.

3. So the microcode inside controller can know which keys were pressed from (2). So when a key combination comes, microcode will increase the contents of the RAM location corresponding to Row #k. (The k will be part of activation key sequence).

---

Can one write such code in microcode? People have implemented far far more complex routines in microcode. The only issue is chip manufacture must know EVM code inside out. I dont see that difficult at all. For a bribe, CEC will handover EVM to who-so-ever who wants along with source code.

So yes, one can surely write a microcode which can rig voting output, if one fully knows the EVM ROM code.

[Raju]

Note that in your example Rawle complained of EVM fraud, but he has booth level details. So there was no totalizer.

yes, I had already mentioned in my opening post citing Rawle that since he had mentioned a booth level detail, totalizers were not at work in Maharashtra.

IMHO if indeed the devil lay in the totalizer, they were not needed in MH at all, since the MNS had already done its job. IB & State level Intelligence would have collated the data and presented it to their political bosses anyways.

whereas there is more or less concrete proof that totalizers were used in Chandigarh & Haryana. Now in Haryana there was a lot of infighting among Congress and all the candidates proposed by Hooda was disposed by Sonia and she had forwarded her own group of candidates. I figure UPA got a majority in Haryana, ordinarily one could not fathom why that happened.

Also it is 1 of the six suspect states. Andhra, TN, Delhi, UP, Haryana, Raj.

[Rahul Mehta]

Rahul Mehta has been proposing fantastic theories that defy time, space and physical laws about cache hardwiring, 30387 micro code hacking, EVM replacements that have been shot down since they were either technically implausible or having too high an associated risk of discovery

Tanaji,

EVM replacement has not been shot down yet. Dileep has merely "stated" that EVMs are NOT stored in 1-5 locations but stored over 100-200 locations in India. He is merely claiming, no one forum here knows for sure whether EVMs are stored in 4-5 locations or 100-200 locations.

My claim is that EVMs stored in locations under CEC can be replaced by CIA with different ones. This is physically possible.

The microcode argument has technical value. If the chip manufacturer (most likely some US company) knew EVM ROM code in advance, then the chip manufacturer *can*put a trojan inside the chip's microcode. Activating that trojan would require some human inputs at some point after candidate number is given on EVMs.

And I am still waiting for YOU to show how much money EVMs saved compared to paper ballots. No numbers, eh? But your claim that EVMs saved a lot of paper cost is something we should accept, right?

[negi]

^ RM ji

I do not wish to go into 'whether the EVM's can be rigged'...hell of course anything with human inputs can be rigged ...but question is is the process as susceptible and vulnerable to malpractices as 'ballot paper' ? I would say in India's context yes ...why ? Because we have seen and read ballot boxes being stolen,misplaced,and even read stories about folks in Bihar pouring ink or even urinating inside one.

EVM's can be bugged but then so can laloo or likes easily manage to print fake copies of ballot paper have them stamped on 'LALTAIN' and shove them into the box after booth capturing...big deal eh.

This thread was started with rumours of EVM's being rigged and we only wish to verify that possibility ...going back to Ballot paper is not an option if we can fix the issue with EVM's ...IF any exist.

The most salient feature of EVM system is the amount of time saved in the whole process , this directly translates to money being spent on arranging polls amidst tight security measures.
If it is about EVM's being scrutinised before and after each election in a practical and verifiable manner then I am all for it but going back to Ballot paper is not an option imho.

[Rahul Mehta]

1. Proper audit of later EVM chips, esp those after 2007 by an independent authority.

Would you accept audit from PwC?

Or say 2 years ago, would you have accepted an audit from PwC?

We have seen audits from Arthur Anderson, PwC and 10s of reputed auditors. More the reputation of being impartial, more the sell out price. So audits are useless.

And if the microcode on the chip has trojan, which equipment exists to know the microcode INSIDE the chip after the chip is made? How much do those equipment cost and how much time do they take? I will wait for Dileep to answer that.

I would opt for something that is LEAST riggable option. And paper ballots are far far less riggable than EVMs. But EVM-lovers keep saying that paper is far far more expensive that EVMs. None of them gives an iota of estimate on how much money in paper is saved. A ballot with 20 names would cost no more than Rs 0.50 paise with printing. So total paper and printing cost is Rs 35 cr. Now 1,400,000 EVMs cost Rs 5500 per piece of Rs 770 cr. So 22 elections would be needed to recover the cost of paper ballots, not counting interest. And if EVMs cost Rs 10000 a piece, then 44 elections would needed to recover the cost. And storage, repair and maintainence of EVMs is not free. If you add that, then many more elections would be needed before costs equal to paper ballots. So what savings are we talking about?

Except jholavalas, not even 1% population minds raising deposit amount from Rs 10,000 to Rs 50,000. That would bring down number of candidates from 20 per seat to mere 5-8, and bring down printing costs to Rs 20 cr. And counting costs and time would also reduce. I myself was a counting agent in Gandhinagar 1996 election. The counting with paper ballots was over within 8 hours. How long can it take with some 30% increase in population today? 12 hours?

Pls ask EVM lovers to give some idea on costs the paper ballots. I bet insults is only thing you will get.

[Raju]

Would you accept audit from PwC?

No

Or say 2 years ago, would you have accepted an audit from PwC?

No

by independent audit I mean a parliamentary Standing Committee with all parties free to nominate their chosen people as experts and also MPs representing cross-sections of political spectrum. Let this group vet the EVMs.

Also let EVMs be used in Bihar and other remote localities (not North-East) in Chattisgarh and West bengal where booth capturing is commonplace. And in cities and towns and secure locations, ballot boxes can be used. It is preferable to go for a hybrid system so that it is more complicated to manipulate the final results.

[Samay]

Should we discontinue EVMs?

Look like people are really worried about EVM's , imagining that their votes are really drained , and brf is the only place on the web where so much discussion is going about Indian evms ,.

Looks like other than brfites ,no body cares what happened in the elections so ,
I can still dream of selling my own evms to EC

[Dileep]

I appreciate this RM. You have a technical proposal here, which could be rationally analyzed and answered. Thanks.

1. If the chip-manufacturer knows the full code inside the ROM of the EVM, he can know which RAM locations are used to store the counts of each row. eg say counts of Row1 are stored in word number 80. Say count of Row2 are stored in word number 81 and so forth.

The RAM locations are decided by the compiler at the time the source is compiled. So, it would be different from version to version. There is no guarantee that the "Stolen" version of the software is going to be ultimately used in the EVM where the chips are getting soldered.

2. Now code in ROM will make predictable changes in CPU registers when a key is pressed. eg say row-1 is pressed, then ROM will write 01 in CPU register-D. Say row-2 is pressed, then ROM will write 02 in register-D and so forth. So if ROM code is known, one can state the predictable changes ROM will make in CPU register when a key is pressed. So the microcode can know which key was pressed.

The registers are GENERAL PURPOSE, and will be used for all calculations. If you look at them, their values go on changing. No one can detect a key press by looking at the registers.

3. So the microcode inside controller can know which keys were pressed from (2). So when a key combination comes, microcode will increase the contents of the RAM location corresponding to Row #k. (The k will be part of activation key sequence).

Since 1 and 2 can't be done, and those are necessary conditions for 3, it can't be done.

Can one write such code in microcode? People have implemented far far more complex routines in microcode. The only issue is chip manufacture must know EVM code inside out. I dont see that difficult at all. For a bribe, CEC will handover EVM to who-so-ever who wants along with source code.

So yes, one can surely write a microcode which can rig voting output, if one fully knows the EVM ROM code.

I will tell you HOW can the chip be rigged. It can't be done by microcode.

Add another microprocessor core to the chip, which duplicates the original one. Program it to disable the original core and enable itself at a key sequence. Then, whenever a new lot is ordered, obtain the latest binary and create a corresponding rigged binary. Burn this rigged binary into the second core and ship the chips.

When enabled, the second core should check the binary in the first core. If it happens to be the same as its parent, it can safely take over and do the rigging. If it is different, it can do nothing, so it should re-enable the original core back.

Here, you get a fair chance of matching the binaries. Since it is OTP, either you hit it or miss it, but if you hit it, it will work till the end of life of the machine.

Then, you should make sure that you always ship that "dual core" version onlee. Otherwise a simple x-ray inspection will reveal it.

I, the 1/500 million voters of this country, am willing to take THAT risk, as a necessary one for the advantages.

[vera_k]

TDP opposes use of EVMs in muncipal polls

As the government is all set to issue the notification for the Greater Hyderabad Municipal Corporation polls in a week's time, the TDP on Thursday urged the state election commission to reintroduce the ballot box system in the coming elections.

[Pranav]

Can you post your CS degree certificate RMji?

How would the trojan knows which IO lines are used with which key, and which RAM location is used to store the vote count of each row? How does it know the entry points of the "good program" so that it can call the other functions when needed? How would you call the trojan code from the main program, without modifying the main program itself?

This idea has fallen deep below being absurd, it insults my intelligence!!

Dileep, is it possible for you to make a post without your repetitive comments about your own and others' intelligence?

The trojan writer would need to know about how the good program works, and they would not need to "steal" the code. They would have access via trusted individuals in the companies that the PSUs are sourcing the software from.

As regards how to call the trojan, you need logic on the processor through which the key-presses are filtered. When the unusual key presses which constitute the trigger mechanism are encountered, control is transferred to the known location of the trojan code. (RMji - the key in favour of which the rigging is to be done would be the first key to be pressed once control is transferred to the trojan.)

The RAM locations are decided by the compiler at the time the source is compiled. So, it would be different from version to version. There is no guarantee that the "Stolen" version of the software is going to be ultimately used in the EVM where the chips are getting soldered.

Answered above.

He don't even know what a CACHE is. Do you? RM? Please google for that. Anyone with any exposure to microprocessor would be ROFL with that claim. More hilarious than the "audit the millions of transistors and interconnects".

Dileep, please stop the rolling on the floor and other intemperate public displays of extreme emotion. Are you claiming that code cannot be hardwired onto a processor chip?

RMji, as has come out in this thread, the totalisers are just as critical as EVMs. Unfortunately, not too much is publicly known about them. One cannot concentrate one's attention on EVMs alone.

[Dileep]

Dileep, is it possible for you to make a post without your repetitive comments about your own and others' intelligence?

When someone claims things that are technically ridiculous, and they refuse to admit that, what else one could do?

I know no amount of explanation is going to get to you, so I am not wasting my time on that. I have explained how you can achieve what you want above. That uses a parallel core.

[Tanaji]

One another way of doing it (theoretically similar to another core) would be to completely replace the electronics of CU with your own somehow, just keeping the original box the same. With that, you have bit more flexibility on how the system responds and are not constrained by original design except for the BU interface and how you want fraudulent code activation.

Of course the possibility of this happening is equally remote. You also would have to ensure that no one opens the box up. But since CIA is involved and BEL is penetrated in Rahul Mehta universe, all this is possible onlee.

[Dileep]

To think about it, I am more concerned about our own politicians, who don't have any backing from the almighty CIA, or even the aliens living in LaLeLa land, rigging the polls the old fashioned way. The ballots are known to be prone to that. The EVMs are definitely better secure against that attack.

I support EVMs because it defeats the petty politicians antics to rig the election. If the CIA has spent billions and done the impossible, and all they did achieve was to install congress in power and MMS as PM, I for one have no problem with that.

Politicians try to derail it because of the same reason I like it. Their antics are no longer working. It would be a black day if EC or the SC forces its withdrawal, based on the cock-a-mamie schemes like the ones outlined here. The real corruption would have won.

[Tanaji]

^^^
But thats probably what the powers-that-be want. Putting my conspiracy hat on, the politicians know that EVMs make rigging difficult, so they make use of naive do-gooders like Rahul Mehta to further their agenda.

Mehtaji is only too willing by making use of fantastic theories to achieve this goal.

I think the above is a more probable theory than replacing EVMs by CIA. The corollary to this then is:

OMG! Rahul Mehta is part of NBJPRIE!!!!



Run for the hills!

[rkirankr]

To think about it, I am more concerned about our own politicians, who don't have any backing from the almighty CIA, or even the aliens living in LaLeLa land, rigging the polls the old fashioned way. The ballots are known to be prone to that. The EVMs are definitely better secure against that attack.

I support EVMs because it defeats the petty politicians antics to rig the election. If the CIA has spent billions and done the impossible, and all they did achieve was to install congress in power and MMS as PM, I for one have no problem with that.

Politicians try to derail it because of the same reason I like it. Their antics are no longer working. It would be a black day if EC or the SC forces its withdrawal, based on the cock-a-mamie schemes like the ones outlined here. The real corruption would have won.

Dileep,
I also for one have no problem with a stable govt whether it belongs to hand or lotus. I do not give a d##n sh#t. But I do have a problem if the govt is set up not by the will of the people through elections but by some external power which might have ulterior motives . Please note it is still one of the Indian parties but it might not be the actual choice of the people. I do not see how you can have no problem with that

[Dileep]

rk,

If there was believable indication that the vote was rigged, I would have been unhappy. I don't see that at all. I haven't seen even one scenario that is even remotely plausible being discussed. Can someone believe that some agency manufactured and replaced the EVMS, or manufactured custom ICs to swap at source?

I repeat my promise. Let anyone prove that the EVMs are corrupted in a widespread fashion, I will eat the print out of these forum pages on video.

[Dileep]

x post from nukkad.

Dileep saar, I actually took the liberty to fwd the thread to some illiterate dehati folks from Intel SeCoE, TI and the best embedded systems hacker I know (who BTW is a she not a he ). Universal reaction was esp. due to one poster's fundas. They all agree it is doable (so is flying a man to Mars) but it is not practical given current tools. Moreover all the bandying about of numbers ignores a fundamental reality called Murphy's Law.

[Muppalla]

The trojan writer would need to know about how the good program works, and they would not need to "steal" the code. They would have access via trusted individuals in the companies that the PSUs are sourcing the software from.

Is there any evidence for this statement? The only software I see in Indian EVMs is software inside EEPROM. This is burnt on to the chips and electrically erasable.

I believe(needs verification), the EVMs are not manufactured with chips from Intel or any other company. The chips are manufactured by BEL and ECIL and I am 100% sure they are capable of manufacturing these chips.

Trojan introduction at usage time, trojan living in "ROM cashe" and then getting triggered by some key stokes are all not possible. This is all hot air drivel written by propagandists over the cyber space. I request to not fall for it.

The two long shot possibilities (and probabilites) I see are:

1) Though all the hardware and software is supposed to be inhouse (BEL and ECIL), the Government is hiding the purchase of EEPROMS from other vendors. ECIL and BEL assembled These other vendors have created the EEPROMS with a software that is biased. Since there is a lot of randomization in the EC process they cannot write the software biased towards Congress. However, the following scenario may be probable:
a) Write the algorthim is such a way the votes from top 5 buttons will have no impact.
b) The votes from all the bottom buttons can be shifted to all other buttons with a formula like for every 5 votes shift them to one of the top 5 equally.
c) At a practical level create as many candidates/independents and parties.
d) The candidates of congress party at each constituency ensure at the time of randomization to get their button in the top 5.
e) Even if Congress does not get the button in the top-5 - it is a gamble that they can live with. After the assignements of all the constitencies they may have calculated the victory possibilities and annonced the opinion polls thru their channels.
f) To keep the plausible deniability they did not send these types of EVM to where they are definite to lose. However, in those states they sent some to few constituencies to "salami slice" the main opposition.

2) Election officials being able to replace the hardware units at the booths - RM thinks it is easy and others think it is not easy without a scandal - I tend to agree with others.

Note: (1) is only possible if the EEPROMS are bought from other vendors. If we really need to get to the bottom of this we need to use RTI etc and get the actual information from EC, ECIL and BEL regarding what elements are outsources.

[Dileep]

Mupalla, the chips are OTP, one time programmable, not EEPROM. The code is stored within the controller chip itself. The EEPROM chip is used only for data storage. That can't be 'biased'. The executable program is burned into the controller itself, and it can never be changed again. Those are verified facts. As long as you control the binary file that goes in, and verify the result of programming, you should be fine.

The controller chips are "imported". Not sure if they are ASICs developed at BEL, or COTS product.

[Muppalla]

Dileep,
added later: How do you know controller chips are imported? I thought they are all manufactured by BEL. BEL has the capability.

Replace EEPROMS with OTP in my theory above. BEL and ECIL are pretty good PSUs and they have capabilites of higest order. I know for sure that many computers ( with no imported/MNC components) that are used in defense establishments are manufactured here. Both these orgs are capable of manufacturing everything. However, in the name of meeting targets/deadlines someone at the top with the approval from "the powerful" and EC might have pulled a fastone by outsorcing the OTP manufacturing to some korean and/or other vendors. These vendors might have used a compromised program when manufacturing the OTPs.

One more probability, the randomization of buttons, officials etc. are also done using a radomization program on a PC. This code also needs to be verified.

Bottomline - The trust of EVMs was built with a clean fact that they all will be manufactured 100% in desh within the compounds of BEL and ECIL. I have a problem if there is any outsourced/bought components in the process. This is what is vague in the entire topic.

[Sanku]

Mupalla;
BEL may use external components if they meet their specifications. I dont see per se how that can cause an issue.

If the Randomization is well random, it will be impossible to do a rigging to ensure that votes preferentially go to a single bucket even if you had total control on software ab initio. It is simply not possible.

Even if all the votes were divided into top 5 equally, Congress will have to ensure that its nearest competitor is also not within top five. A very tough call. (and as I know in most cases Congress and BJP were buttons 1 and 2 in most places)

[Tanaji]

added later: How do you know controller chips are imported? I thought they are all manufactured by BEL. BEL has the capability.

The EC itself has clarified this

Q21. Is it possible to program the EVMs in such a way that initially, say upto 100 votes, votes will be recorded exactly in the same way as the `blue buttons’ are pressed, but thereafter, votes will be recorded only in favor of one particular candidate irrespective of whether the `blue button’ against that candidate or any other candidate is pressed?

Ans. The microchip used in EVMs is sealed at the time of import. It cannot be opened and any rewriting of program can be done by anyone without damaging the chip. There is, therefore, absolutely no chance of programming the EVMs in a particular way to select any particular candidate or political party.

http://eci.nic.in/faq/evm.asp
Somewhere else on the EC site, it mentions that they import it from "Japan".

So BEL is not manufacturing the micro controller.

[Muppalla]

Mupalla;
BEL may use external components if they meet their specifications. I dont see per se how that can cause an issue.

If the Randomization is well random, it will be impossible to do a rigging to ensure that votes preferentially go to a single bucket even if you had total control on software ab initio. It is simply not possible.

Even if all the votes were divided into top 5 equally, Congress will have to ensure that its nearest competitor is also not within top five. A very tough call. (and as I know in most cases Congress and BJP were buttons 1 and 2 in most places)

Elections in a country of billion population is a challenge and high stakes one.

Regarding external components and outsourced software - EC and BEL/ECIL should tell the public regarding what is that and how the quality was ensured. This will bring the credibility and what is the problem in doing that? Even if they do random validation, they should publish the code.

In my personal opinion and based on the capabilites of these institutions, there is absolutely no need for external components especially in the areas like OTP/EEPROM chips. They can do that for manufacturing commercial/other applications. Let me try to tell you, how capable these folks are:
Though my education is in CS, my expertise is in the in the area of biz app development and growing decently in the consulting area and hence I do not have more than conceptual/"little more than novice" knowledge on the computer hardware. I did my aprenticeship at BARC as part of my college curriculum. Even during 90s they have their own (100% shudh desi maal including the everything that is inside the boxes) computers. The OS is some-Windows not X-Windows or anything that you hear outside (don't know good or bad hence deliberately not writing out) is used in that particular department of BARC. They did not even tell me for what application etc except giving me inputs and expected outputs. This OS is completely written inside BARC and a fantastic one( excellent graphics and user friendliness) that I have worked. Those days, in the commercial world we have Windows 3.1 (16 bit) and X-Windows in unix world.

By the way, I also did a two month project at ECIL during the second year of my graduation.

Hence my belief of that there is no need to shop outside whatever the case may be especially for these stupid and simple EVMs.

Randomization software - Who wrote it? They should seriously publish the code and they should compile infornt of the candidates when they are randomizing.

Regarding BJP and INC next to each other - that is not enough. The loss of BJP is not that much as compared to gain of INC. The top 5 buttons is a scenario I gave and the actual scenario can be some other combination.

I am just putting a scenario out so that it can be shredded to peices by experts here.

Here is summary of my scenario:
1) Probability of sabotage of EVM is high if the OTPs are manufactured outside inspite of the quality checks. There is no need for many people to know and can be done quitely.
2) Software manupulation of randomization in conjunction with the software manupulation of outsourced components is a probable scenario.
3) The sofistication of the hack-based-rigging does not need to be foolproof towards INC. It can just give a leg-up as rest can be handled by creating more vote sharable candidates and parties.

Here is what happened and quote from my post in the election thread

There is a reason for so much of mourning and jumping to EVM fraud type conclusions. The way the election results look like is a perfect orchestration of "removal of all troubles and ills of INC" in one shot from the past. Though INC did win only 206 and not win 543 they blanked out their enemies 543-0.

It seems like that in their calculations, BJP was never in the contention for them and hence no worries there. Here is how it looks like and it is amazing to achieve all in one shot. Even though it is election but it looks like a programmed thing for me to get me out of all troubles. For telugu folks it is like ayurveda medicine "sakala roga nivarini" aushadha working.

1) Salami slice BJP in its area of influence so that it does not rise it head. Guj, MP, Uttarakhand
2) Let us not do anything with Karnataka as we think we will look suspicious. But Dev Gowda - the damn guy should be put in is place and how dare he cheats us.
3) AP - We got to win here but I don't think YSR whould have a large majority. Chiru should not grow. Ok fine- let us give huge LS majority and but 10 seater to YSR. Damn guy let him live there. CBN can sulk in the opposition for a while. Again this damn TRS how dare he crossed my line. Let us finish him.
4) Left - These jokers tried to convert Nuke deal as Muslim Vs. Non-Muslim. These folks needs rape and murder and hence let us order the robots to do exactly the same
5) Laloo, Paswan - Let us flush them like a lavatory-tissues
6) Naveen and Nitish - let us leave them in good humor and may be useful in future.
7) AGP - Let BJP win here but not AGP. AUDF - the two bit party that sole depends on BDs is good thing for future. Ok done deal so let us add them
8 ) ADMK -PMK - MDMK - big nuisance and how dare they talk of Elam etc. Let us see if we can do such a way so that we don't have to work with toooo many *MKs but just with one who is anyway. Jaya is looking like BJP-B anyway. Let us do only salami slicing here so that we don't look suspicious.
9) Delhi and Rajasthan - forget about voting percentages etc. - let us just sweep because we won the assembly recently.
10) JMM is a huge pain and hence lets dump it.
11) By the way for all these parties, let us give one seat each so that we do not look like we did something
12) SP - BSP: Damn black mailers - Let us make them as irrelevant and dependent on us from tommorow but be cautious. We should not go from zero to 80.
13) Over all we don't win 300 seats on our own but we have 300 with about 100 of them has no option but us.
14) pawar- bloody fellow wants PM ship. Show him his place while we win.

Make Singh the King!!! It is infinite number of master strokes and a beautifullest victory that anyone can dream/cherish

[Tanaji]

These vendors might have used a compromised program when manufacturing the OTPs.

IF that is the case, then the whole conspiracy theory is easily verified by dumping the firmware from a randomly selected or a particular constituency EVM and comparing it with the authentic firmware bit-by-bit.

But the above flies against the claim being made by the two gentlemen that if a fraud/hack is done it is undetectable impossible to find out.

[Muppalla]

These vendors might have used a compromised program when manufacturing the OTPs.

IF that is the case, then the whole conspiracy theory is easily verified by dumping the firmware from a randomly selected or a particular constituency EVM and comparing it with the authentic firmware bit-by-bit.

But the above flies against the claim being made by the two gentlemen that if a fraud/hack is done it is undetectable impossible to find out.

It is detectable (they can investigate using RTI and courts) and folks ( many others and these two gentlemen ) are not trying to detect/investigate it and instead they are publishing reams and reams of blogs that has all the same again and again. Every article starts with "many sensible countires banned them" and hence India should ban them. I am afraid that even in case there is fraud, due to this high amount of trash theories, the actual fraud investigation will miss all these folks.

They need to first collect the information like:
1) who manufactured the controllers
2) What are all the vendors
3) Get the programs
4) Randomly select the suspected constituencies and verify the binaries ( or whatever is possible)
5) Verify all the randomization code

[Tanaji]

^^^^

I agree that a random sampling of firmware comparison should be done. But the issue is that no amount of auditing is enough to satisfy the likes of Mehtaji that spin fantastic theories to establish a conspiracy.

[Raju]

IF that is the case, then the whole conspiracy theory is easily verified by dumping the firmware from a randomly selected or a particular constituency EVM and comparing it with the authentic firmware bit-by-bit.

who will bell the cat ?

^^^^

I agree that a random sampling of firmware comparison should be done. But the issue is that no amount of auditing is enough to satisfy the likes of Mehtaji that spin fantastic theories to establish a conspiracy.

Tanaji, I wouldn't blame Mehtaji so much. Of what i am sure of is that there was mischief, the only question is how it was done. Mehtaji is trying to come up with various explanations for the said mischief, but his mileage may vary but that alone isn't proof of absence of mischief and manipulation of verdict.

[Dileep]

Mupalla, let me explain, before you go too far and others jump in.

The processor, ROM and RAM are all self contained in a single silicon chip, called the "controller". The ROM is all blank when manufactured and shipped to BEL. At BEL, the binary image of the software is "burned" into the ROM area. This can only be done once. This image that is permanently programmed into the ROM can be read, and compared with a master copy, any time. The unused ROM areas are all programmed with unblanks, so that you can't do anything anywhere.

It is technically impossible to embed ( at the time of silicon fabrication) another piece of program within the same controller without easy detection. Anyone familiar with microprocessor design can verify that fact. So, the ONLY way to corrupt the program is to do it at the time of the initial programming, and that will be detectable any time thereafter. In fact I would bet that there will be am explicit programming and verification process at BEL for this.

So, it doesn't matter who manufactures the chips. What matters a bit is who programs it (I guess BEL does it in a controlled fashion) and it gets diligently verified.

SCL used to have facility to fabricate processors. But I don't think they have the process for OTP ROMs.

[Raju]

Dileep, what Mupalla is pointing out is that there are various batches of EVMs with varying standards. The full extent of these varying standards are not exposed to public esp in absence of an independent audit by a multi-party parliamentary standing comittee.

What you speak of may well be true of the Gen 1 EVM, but need not be true of later Gen evm's. Infact no one knows what is going on.

[Tanaji]

Dileep, what Mupalla is pointing out is that there are various batches of EVMs with varying standards. The full extent of these varying standards are not exposed to public esp in absence of an independent audit by a multi-party parliamentary standing comittee.

What you speak of may well be true of the Gen 1 EVM, but need not be true of later Gen evm's. Infact no one knows what is going on.

I profess I dont know much about this, but has it been proved that between various generation(s?) of EVMs, there has been a hardware upgrade?

From what I have read, the only change has been that they are including time stamps now. This, does not require a hardware change as long as the original memory was sufficient. I could be wrong though... 10 years from design is a long time and the manufacturer may have stopped providing the original version.

[Dileep]

From what I read in the handbook, the randomization software can be manipulated to send a particular EVM unit to a particular assembly constituency. This is a trivial vulnerability, but it should be eliminated. The software must be audited for sure. Thought it is not mentioned, it seems to be a PC software. Instead of entering the serial numbers into a database and then randomizing it, I would recommend the following procedure:

1. Pull out an EVM from the lot, preferrably as pointed out by one of the party agents.
2. Use a simple random number generator that will generate a number corresponding to the assy constituency. If that number is "useable", ie it indicates a valid constituency id, and the need for machines there is not yet filled, assign that machine to that constituency. Else, hit the button for another number.

Simple, and I am sure even RMji can't find fault with it.

[Dileep]

Dileep, what Mupalla is pointing out is that there are various batches of EVMs with varying standards. The full extent of these varying standards are not exposed to public esp in absence of an independent audit by a multi-party parliamentary standing comittee.

What you speak of may well be true of the Gen 1 EVM, but need not be true of later Gen evm's. Infact no one knows what is going on.

No, Muppalla didn't say that. He mentioned the OTP as something external to the controller, and programmed by an external source. I wanted to refute that.

The audit report posted by KVRao is dated Sep 2006, and it was based on the current design then. I don't think there would be any change from then to the order in Jan 2007.

I don't think the basic things like the processor and system architecture would change between versions.

[Tanaji]

Why the need for software?

Get one of those rolling wheels that are used for lottery numbers. Put numbers of all constituencies in it. Roll the wheel and get a party representative to draw a number.

[Muppalla]

No, Muppalla didn't say that. He mentioned the OTP as something external to the controller, and programmed by an external source. I wanted to refute that.

The audit report posted by KVRao is dated Sep 2006, and it was based on the current design then. I don't think there would be any change from then to the order in Jan 2007.

I don't think the basic things like the processor and system architecture would change between versions.

Dileep is right. I was of the opinion that the OTP is a seperate peiece that is embeded into the controller. I was of the opinion that OTP cannot be programmed later (bought from Japan and programmed in BEL is a safe option) but has to be programmed at the time of OTP's manufacture.

[Muppalla]

Mupalla, let me explain, before you go too far and others jump in.

The processor, ROM and RAM are all self contained in a single silicon chip, called the "controller". The ROM is all blank when manufactured and shipped to BEL. At BEL, the binary image of the software is "burned" into the ROM area. This can only be done once. This image that is permanently programmed into the ROM can be read, and compared with a master copy, any time. The unused ROM areas are all programmed with unblanks, so that you can't do anything anywhere.

It is technically impossible to embed ( at the time of silicon fabrication) another piece of program within the same controller without easy detection. Anyone familiar with microprocessor design can verify that fact. So, the ONLY way to corrupt the program is to do it at the time of the initial programming, and that will be detectable any time thereafter. In fact I would bet that there will be am explicit programming and verification process at BEL for this.

So, it doesn't matter who manufactures the chips. What matters a bit is who programs it (I guess BEL does it in a controlled fashion) and it gets diligently verified.

SCL used to have facility to fabricate processors. But I don't think they have the process for OTP ROMs.

Are you sure about the highlighted portion. I am asking because I do not have related knowledge/expertise. I am interested to know if the ROM is programmed at BEL or outside.

[Sanku]

The question where the ROM was progarmmed is a germane one, however as a layman (to Election process and not electronics) I think I will assume that the programming was done at BEL.

However for a moment even if I assume (as an engineer) that the programming was done else where.

What we are saying is that some one (some supreme power) made sure that the program had a Trojan which could add votes to XYZ in light of randomization much before the distribution of EVMs happened (which means they knew the key map at the time of burning in software).

This is simply impossible and if there is such a power it gets my vote anyway. Since we are talking god here.

[Muppalla]

What we are saying is that some one (some supreme power) made sure that the program had a Trojan which could add votes to XYZ in light of randomization much before the distribution of EVMs happened (which means they knew the key map at the time of burning in software).

This is simply impossible and if there is such a power it gets my vote anyway. Since we are talking god here.

Agreed there are too many ifs and buts here. Trying to see the probable theory and hoping somebody who has expertize shred it to pieces. In that pursuit, if we assume that ROM is programmed somewhere and taking the my fictious theory of spread the votes polled thrrough certain buttons to some selected buttons is the program that is burnt into the vilayat ROMs. Okay let us say CIA did it in Japan.

Now the DOOs who wrote the PC based randomization program ensured that Congress will get one of the buttons from the above programmed certain buttons then the possibility of the magic is feasible.

When we say it "it all looks nah/far fetched" we have to accept the probabilities and expect/lobby for investigation to keep us and nation assured. But if they are programmed outside BEL/ECIL complexes then these needs to be binary verified/audited by competent authorities for assurance.