No, You Cannot Hack an EVM With a Python Script

So, here we are.

It is June 2026, and somewhere in Delhi, a young man told at Jantar Mantar, I can hack EVM with three python scripts:

…and the crowd lost its mind. Within twelve hours, the clip was on every group chat in India, Saurav Das was being fanned by a personal aide for some reason, and the satirical Cockroach Janta Party born three weeks ago

YouTube parody accounts then put out videos joking that Google had offered the kid an “emergency job.” Some claimed Anthropic was hiring him. Microsoft sent a private jet. Vitalik Buterin reportedly asked him to audit Ethereum.

It was beautiful. Truly. As street theatre, as catharsis, as a vibe — 10/10. No notes.

But then I made the mistake of opening Twitter (or X, or whatever Elon wants us to call it this fiscal year), and I saw something deeply concerning: actual adults, with verified accounts, retweeting that clip with captions like “See? EVMs CAN be hacked!” and “Why is the ECI silent?”

So buckle up. We are going to do two things in this article.

The kid is just a meme protagonist now, immortal forever — but because the framing of that clip, the idea that a few lines of Python on a laptop touches an EVM in any way, is the kind of cybersecurity misinformation that does real damage.

Second, and more importantly, I will walk you through what an Indian EVM actually is. The real hardware. The real architecture. The real attack surface. Not the ECI’s marketing brochure version, but also not the WhatsApp uncle version. The actual engineering reality, with citations, because that is the only way to have this conversation honestly.

Let’s go.

Part 1: A Loving Roast of the Python EVM Hack

Let me paint a picture for you.

When you write a Python script and hit run, that script executes inside a Python interpreter (CPython, most likely), which is itself a program running on top of an operating system (Windows, macOS, Linux), which is running on hardware (your laptop) that is connected to peripherals like your screen, keyboard, and — critically for the meme — a network.

For your Python script to “hack” something, that something needs to be reachable from your script. Either:

1. It needs to be on the same network (and listening on a port your script can connect to), or
2. It needs to share memory or storage with your script (e.g. you’re writing to a file the target reads), or
3. There needs to be some kind of physical bridge — USB, serial port, Bluetooth, NFC, JTAG, something — between your laptop and the target.

Now here is the punchline.

An Indian EVM has none of those things. It has no network card. No Bluetooth chip. No Wi-Fi antenna. No NFC. No active USB port during polling. It does not even have a serial cable connecting it to anything other than its own ballot unit and (if applicable) VVPAT printer. It is literally just a sealed plastic box with buttons, a microcontroller, some EEPROM, a battery, and a 7-segment display.

So when our protagonist types votes += 1 into Python and the crowd cheers, the only thing his script has hacked is the Python interpreter on his own laptop. The EVM, sitting in a strongroom somewhere in a different state under armed CRPF guard, has no idea this happened. It cannot. There is no causal pathway between his keystrokes and that machine. They exist in different physical universes that have never made contact.

You could write the entire CPython implementation from scratch on stage, get a standing ovation from Linus Torvalds, win the Turing Award, and the EVM you are “hacking” would still not know you exist.

It would be like me yelling at my microwave to deliver a pizza. The microwave is right there. It can hear me. It can even beep at me. But the causal chain I am imagining — yelling → pizza arrival — does not exist in physics. The microwave is not connected to Domino’s. My yelling, no matter how loud or articulate, cannot summon a pizza.

This is the level we are operating at.

And yet, this clip was treated as a serious technical demonstration by hundreds of thousands of people. That is the part that should make every security person uncomfortable. Because the next time someone wants to undermine confidence in an election, they will use this exact playbook — fake demo, viral clip, screenshot-friendly drama — and a significant chunk of the population now believes “EVMs can be hacked with Python” is a true sentence.

Okay. Catharsis done. Let’s get serious.

Part 2: What an Indian EVM Actually Is

The three-piece setup: Ballot Unit (left), Control Unit (centre, with the polling officer), VVPAT printer (right). All connected by cables. None of them connected to anything else.

Before we talk about whether an EVM can be hacked, you need to know what it actually is. Most of the takes online — including, depressingly, some from people who should know better — describe a system that does not exist.

The hardware

The Indian EVM, in its current form, comes in three pieces:

1. Ballot Unit (BU) — the box with the buttons that the voter actually presses. Up to 16 candidates per unit, with multiple units cascadable (up to 24 BUs, supporting up to 384 candidates including NOTA, though no real-world contest comes close to that).
2. Control Unit (CU) — the smaller box that stays with the polling officer. It contains the main logic board, the vote-storage memory, and the result display.
3. VVPAT (Voter Verifiable Paper Audit Trail) — a separate printer unit, added after 2013, which prints a paper slip showing your vote for ~7 seconds behind a transparent window, then drops the slip into a sealed box.

These three units are connected to each other by physical cables. That is it. There is no wireless link. No Bluetooth. No Wi-Fi. No cellular modem. No Ethernet jack. The CU is battery-powered (7.5V battery pack), so it does not even need a wall socket, let alone a network.

The chip

The original first-generation EVMs (M1, manufactured up to 2006) used Hitachi 6305 microcontrollers with firmware in UV-erasable PROMs. The widely-cited 2010 Halderman/Prasad/Gonggrijp security analysis examined a second-generation ECIL machine and documented its centrepiece as a Renesas H8/3644-series microcontroller driven by an 8.8672 MHz crystal oscillator, with two redundant EEPROM chips for vote storage and a mask-ROM-burnt firmware image.

The current generation is M3, in production since 2013. According to RTI responses obtained over the years, the M3’s microcontrollers are imported — BEL has sourced them from NXP Semiconductors (Netherlands), and there has historically been a debate around whether the chip is “truly one-time-programmable” or whether it uses flash memory that could in principle be reprogrammed if you had physical access plus the right tooling plus a way to bypass tamper-detection circuitry.

I want to flag this honestly: the ECI’s marketing line that the chip is OTP (one-time programmable) has been contested by RTI activists who pointed to NXP datasheets showing flash memory in the relevant chip families. This is a real, legitimate debate and I am not going to gaslight you about it. But — and this is the crucial part — even if the chip is reprogrammable in theory, that reprogramming requires physical access to the chip itself, with specialized equipment, on each individual machine. We will get to why that matters in a minute.

The architecture, in one paragraph

Voter presses a button on the BU → BU sends a signal to the CU → CU records the vote in its EEPROM, increments the count for that candidate, and sends a command to the VVPAT → VVPAT prints a paper slip showing the candidate’s symbol → slip is visible for 7 seconds → slip drops into the sealed box → CU lights up a red LED on the BU and emits a beep.

End of cycle. No network call. No log shipped anywhere. No “cloud sync.” The machine does not know what year it is, does not know what constituency it is in until it is told seven days before polling, and does not know which candidate is on which button — that information is uploaded fresh to the VVPAT’s 4MB flash memory just before deployment, in the presence of candidates’ representatives.

This last point is worth dwelling on, because it is what defeats most of the “the EVM is pre-programmed to favour party X” theories. The Supreme Court was specifically told by the ECI in 2024 that the EVM’s burnt firmware is “agnostic” to political parties and candidates. The CU only knows: “button 1 pressed, button 2 pressed, button 3 pressed.” It has zero information about which party is button 1 vs button 2. That mapping lives only in the VVPAT’s slip images, uploaded a week before the vote. So for the firmware to “favour” a party, the manufacturer would need to know — months or years in advance — that, say, BJP would be assigned button 4 in every booth in the country in every future election. That is not how the randomization works. We’ll come to randomization shortly.

Part 3: Why a Python Script Specifically Does Nothing

Let me make this concrete with a threat-modeling exercise, because that is how my brain works after five years of doing this for a living.

If you want to “hack” something with a Python script, you need an interface. A socket. A pipe. A file descriptor. A USB endpoint. Bluetooth GATT. Something on the other side that is listening and willing to talk to your script.

Here is the EVM Control Unit’s complete list of external interfaces during polling:

1. A cable port for the Ballot Unit (proprietary connector, custom serial protocol).
2. A cable port for the VVPAT (same).
3. A physical power button.
4. A “Cand-Set” button to lock in the number of candidates (used during setup, not polling).
5. A “Ballot” button the polling officer presses to enable each individual vote.
6. A “Close” button to end polling.
7. A “Result” button (locked behind a tamper-evident seal) for displaying the result after polls close.
8. A 7-segment LED display.

That’s the entire I/O surface. There is no USB port. No SD card slot. No serial debug header exposed to the user. No JTAG pin you can reach without disassembling the unit (which triggers tamper-detection). No wireless transceiver. No bootloader you can talk to over a cable from a laptop.

A Python script, by definition, runs in an environment that has none of these things in common with the EVM. Your laptop’s Python interpreter has no shared memory with the EVM’s mask ROM. There is no network path between them — because the EVM is not on any network. There is not even a serial path, because the EVM does not have a generic serial port that accepts arbitrary commands from arbitrary devices.

To “hack” an EVM with code, you would need to first:

1. Physically obtain the EVM (defeats already-armed CRPF guards at the strongroom — good luck).
2. Defeat the tamper-detection circuitry that bricks the machine the moment the case is opened (this is the M3 generation’s flagship security feature, added in 2013).
3. Locate the microcontroller on the PCB and physically attach a programmer to it.
4. Successfully flash modified firmware that mimics the original well enough to pass the self-diagnostic checks at boot.
5. Reseal everything to look identical to a non-tampered unit.
6. Get the tampered unit back into the polling supply chain and have it specifically allocated to the constituency you care about, surviving two rounds of randomized allocation (more on this below).
7. Have it pass the on-site mock poll on election day, in front of polling agents.
8. Hope nobody asks for a VVPAT cross-verification at the counting stage.

None of those steps involve Python. None of them are remotely related to what was happening on that stage at Jantar Mantar. The Python script demonstration is to actual EVM tampering what a kid waving a foam sword in his garage is to amphibious warfare.

Part 4: The Procedural Security Almost Nobody Talks About

Here is the thing that frustrates me about the “EVM hacking” discourse: people argue endlessly about the chip, the firmware, the OTP-vs-flash question — and ignore that the actual security model of the Indian election is mostly procedural, not cryptographic.

The hardware is one layer. The much thicker layer is the chain of custody. Let me walk you through what an EVM actually goes through between leaving the factory and counting day. This is from publicly documented ECI procedures.

Step 1: Factory. Built at BEL (Bengaluru, under Ministry of Defence) or ECIL (Hyderabad, under Department of Atomic Energy). Each unit gets a unique serial number, recorded in the ECI’s EVM Tracking Software (ETPBMS). This is the only “network” that touches EVMs — and the network is on the tracking software, not on the machines themselves.

Step 2: First Level Checking (FLC). Before any election, every EVM allocated to a district undergoes FLC by BEL/ECIL engineers in the presence of representatives of recognized political parties. 5% of randomly chosen units undergo an extended mock poll of 1,200 votes; another 2% get 1,000 votes; another 2% get 500 votes. The vote results from the mock poll are tallied with VVPAT slips. Faulty machines are pulled out. A pink paper seal is affixed; if that seal is broken later, the machine is rejected from use.

Step 3: First Randomization. After elections are notified, EVMs are allotted to Assembly Constituencies (AC) through a software-based randomization run in the presence of the District Election Officer and recognized parties. A signed list is given to each party. This is the first time anyone knows which physical EVM serial number will go to which constituency.

Step 4: Second Randomization. After candidate nominations close, a second randomization happens, this time allocating each EVM to a specific polling booth within the constituency. Again, candidates’ representatives are present. Again, signed lists are distributed. This is also when the VVPAT gets the candidate symbols uploaded.

Step 5: Commissioning and Mock Poll #2. EVMs are loaded with the actual ballot configuration. A second mock poll is conducted, with results tallied against VVPAT.

Step 6: Strong Room Storage. EVMs are sealed and stored in strongrooms under 24/7 CRPF guard, with CCTV coverage and party representatives allowed to camp outside if they wish. The strongroom doors are sealed and re-sealed each time they are opened.

Step 7: Polling Day Mock Poll #3. One hour before polling begins, in the actual booth, in front of polling agents, the presiding officer runs a third mock poll with at least 50 votes. Results are matched against VVPAT slips. A “trial poll certificate” is signed. Mock poll votes are then deleted (and this step, when skipped due to human error, has historically been the source of real VVPAT-EVM mismatches reported in news cycles — not tampering, but a missed reset).

Step 8: Polling. People vote. Each vote is rate-limited to about 5 per minute by the hardware. The CU silently keeps a time-stamped log of each press.

Step 9: Close and Seal. Polling officer hits Close. EVMs are sealed again, signed by polling agents on the seal, and transported under armed escort to strongrooms.

Step 10: Counting and VVPAT Verification. On counting day, the CU’s electronic count is read. Then, in 5 randomly chosen polling booths per Assembly segment, the VVPAT slips are physically counted and tallied against the EVM count. This was mandated by the Supreme Court in N. Chandrababu Naidu v. Union of India (2019).

This last point is enormous and I want you to sit with it. Across all the elections in which this 5-VVPATs-per-segment verification has been done — the ECI’s submission to the Supreme Court in the 2024 ADR v. ECI case said 38,156 VVPATs have been physically counted to date, with not a single mismatch found between the electronic count and the paper slips. Updated figures in court showed over 41,000 instances and four crore (40 million) VVPAT slips matched. Zero mismatches that were not traceable to human procedural error (like the un-deleted mock poll votes mentioned above).

If the chip-level hack people fear were happening at scale, you would expect to see at least some statistical signal in the VVPAT cross-check. You don’t. That is real, falsifiable evidence, which is the only kind that counts in this kind of debate.

Part 5: The Hari Prasad Story — What Actually Happened in 2010

I want to spend some time here because this is the only serious technical research on Indian EVMs by an independent team, and it gets mythologized in both directions.

In August 2010, a Hyderabad-based engineer named Hari Prasad got hold of an actual Indian EVM through an anonymous source. He collaborated with J. Alex Halderman (then at the University of Michigan, one of the world’s foremost voting-system security researchers) and Rop Gonggrijp (the Dutch hacker who got NEDAP voting machines banned in the Netherlands). They published the paper “Security Analysis of India’s Electronic Voting Machines” at ACM CCS 2010.

What they actually demonstrated, on a real second-generation ECIL EVM:

1. Display replacement attack: Replace the 7-segment LED display board with a malicious one that shows fake totals. The CPU still has the real votes, but the polling officer reading the display sees whatever the attacker wants.
2. Memory manipulation attack: Use a small clip-on hardware device to read and modify the EEPROM vote storage. Required physical access to the inside of the CU.

Both attacks required physical access to a real machine, the tools to open it, and the ability to either replace components or attach hardware programmers. Neither attack could be done remotely. Neither attack could be done with a Python script from outside. Neither attack could be done without opening the case — which, on the M2 machines they tested, did not have the tamper-detection feature.

Prasad was arrested shortly after the demonstration on charges of stealing an EVM (a charge that was widely viewed as retaliatory, and which the EFF and others denounced). He was eventually released, the research was published, and the ECI’s response was — credit where credit is due — to introduce the M3 generation with tamper detection and self-diagnostics, which makes the case-opening attack from the 2010 paper much harder.

So the honest summary is this: in 2010, a determined attacker with physical access to a specific M2 machine could change votes on that machine. They could not do this remotely. They could not do it at scale without thousands of co-conspirators with physical access to thousands of machines. And the M3 generation specifically hardens against the case-opening attack vector.

Could a researcher in 2026 find new flaws in an M3 if given the same kind of access? Almost certainly. No machine is unhackable. Halderman himself routinely says this, and it is also stated explicitly in the India Forum analysis I read while researching this piece. The question is never “can a determined nation-state-level attacker with physical access break this single machine?” It is “can someone change the outcome of an election at scale?” — and that is a very different question with very different answers.

Part 6: The ECI’s 2017 Challenge — and Its Honest Limits

In 2017, after AAP’s Saurabh Bhardwaj demonstrated his own claimed “EVM hack” in the Delhi Assembly using a lookalike machine (which the ECI argued was not an actual EVM), the ECI threw an open challenge. Parties were invited to try to tamper with actual machines used in the 2017 elections.

Two parties — CPM and NCP — agreed to participate. The Congress and AAP boycotted, demanding access to the motherboard. The ECI refused, arguing — somewhat reasonably — that letting you replace internal components of a machine and then claim you’ve hacked it is “introducing your new EVM and calling it ours.”

The challenge ran. Nobody managed to alter results within the rules of the challenge.

Now, you can fairly argue — and the AAP did — that the rules were too restrictive to count as a real test. The rules forbade opening the machine, which is the only attack vector that the 2010 Halderman/Prasad research found to actually work. So the challenge was, in a real sense, asking attackers to hack a sealed black box with no physical access — which is a much harder problem than the actual threat model. That criticism has merit.

But the opposite framing also has merit: a real-world adversary trying to rig an election does not get unrestricted physical access to every machine in the country, in a clean lab, with months of preparation. They have to operate within the same chain-of-custody constraints that the challenge rules were trying to simulate. So both criticisms can be true at once. The 2017 challenge was a flawed test, but it was not a meaningless test either.

What it absolutely was, however, was not a test of Python-script remote hacking — because that is not a thing that can be tested, because that is not a thing that exists.

Part 7: What the Real Threat Model Looks Like

If I had to write a threat model for the Indian EVM system as an AppSec engineer — and ignore everything that is not actually a viable attack — here is what I would prioritize, roughly in order of plausibility:

1. Procedural failures and mock-poll-reset bugs. This is the most common cause of any real VVPAT-EVM mismatch that has surfaced in court. Polling officers occasionally fail to delete mock-poll votes before the actual poll begins. This is a known issue with known mitigations, not a tampering attack.
2. Insider supply-chain attack at BEL or ECIL. Theoretically, someone with privileged access at the factory could try to compromise units during manufacturing. This is hard because of the multi-stage testing and randomization that happens after — but it is the most defensible “real” attack path.
3. Physical tampering of specific units during the chain of custody. Possible in principle, hard in practice because of the seals, tamper-detection, FLC, two-stage randomization, and CRPF custody. Would require an enormous number of co-conspirators across multiple party-monitored steps to affect even a single constituency.
4. Strongroom break-in. Would require defeating armed federal guards and CCTV. Not a software problem.
5. VVPAT slip image manipulation. The 4MB VVPAT flash is uploaded with candidate symbols 7 days before polling. If someone manipulated that upload, the wrong symbol would print. But this would also show up as a mismatch with the EVM’s electronic count during the mandated 5-booth verification. The math of “how many booths would I need to compromise without ever getting caught in the random VVPAT audit?” works strongly against the attacker.
6. Display-board replacement (the 2010 attack). Mostly mitigated by M3 tamper detection, but not impossible if you can defeat the seals undetected.

Things that are not on this list because they are not actual attack paths:

• “Python script over Wi-Fi” — no Wi-Fi on the EVM.
• “Python script over the internet” — no internet on the EVM.
• “Python script over Bluetooth” — no Bluetooth on the EVM.
• “Hacking the EVM software remotely” — no remote interface to the software.
• “Mass remote vote-flipping” — not architecturally possible, full stop.

This is the boring truth that nobody wants to hear on either side. EVMs are not hack-proof — no system is. But the actual attack surface is physical, local, per-unit, and statistically auditable via VVPAT. The viral Python demos are not security research. They are political performance art that happens to use a laptop as a prop.

Part 8: So, Can I Hack an EVM?

If you got into the country’s most secured strongroom, defeated armed CRPF guards, opened the sealed case without triggering tamper-detection, hooked up a hardware programmer to a Renesas H8 series microcontroller (or its M3 successor) without bricking it, flashed custom firmware that passes self-diagnostics, resealed the unit to look factory-new, returned it to the supply chain, got it specifically allocated to the booth you care about via two rounds of randomization, passed the mock poll on election morning in front of opposing-party agents, and got lucky that your booth was not in the 5 booths randomly selected for VVPAT cross-verification at counting — then yes, you might have changed a few hundred votes in one polling booth.

If you want to do this at the scale that would actually change an election outcome, multiply the above effort by, conservatively, ten thousand. With ten thousand co-conspirators. None of whom snitch.

If you want to do this with a Python script on a laptop on a stage at Jantar Mantar, you can change exactly zero votes. You can, however, get 22 million Instagram followers and a meme named after you, so the ROI is honestly not bad — just be honest with yourself about what you’re actually doing.

Closing Thoughts

If you want to do real, honest, technical work on election security, there is plenty to do. RTI activists asking hard questions about chip provenance are doing real work. Researchers like Halderman doing peer-reviewed papers are doing real work. People demanding broader VVPAT verification, like the petitioners in ADR v. ECI, are doing real work. None of them are typing votes += 1 into Python on a stage.

If you want my advice, as a security person who has spent way too much of his career inside the guts of badly-built systems: be skeptical of authority, yes. Demand transparency, yes. Push for stronger audits, yes. But also — and I cannot stress this enough — learn what the system actually is before you “hack” it on stage. Because every cringe Python demo gives the people who should be reformed an excuse to dismiss every serious technical critique that follows.

The cockroach mascot is good. The energy is good. The Python votes += 1 was not.

Now if you’ll excuse me, I have a CLAUDE.md file to update for my actual pentest agent. Real targets. Real interfaces. Real attack surface. The boring stuff that actually matters.

If you found this useful, leave a few claps and follow for more long-form writeups on application security, AI-assisted offensive tooling, and the occasional viral-meme post-mortem. If you disagreed, the comments are open — but please come with citations, not Python scripts.

Disclaimer: I am an application security engineer based in Gujarat. I have no affiliation with the ECI, BEL, ECIL, the BJP, the Congress, the AAP, or the Cockroach Janta Party. I do, however, have a soft spot for cockroaches as a metaphor — they really don’t die, you have to give them that.