Incident Report on PKR E-Voting App


The report’s objective is to understand the technicalities of the vote submission failure. Initial finding concludes that the voters’ data are available but the votes are missing for a period of time.


Limited to understanding the failure during the election in Melaka and Negeri Sembilan identifying if the missing votes are recoverable.

Brief on the technical flow

The voting system built to cater to Internet disruptions. Voters’ data and votes stored locally before syncing to the server.


  1. Technical team rebuild a new package for each election.
  2. Publish and update all the devices.
  3. The app identifies the user based on the QR code.
  4. Fetch the user data from the server.
  5. Store the user data locally in the device.
  6. User submits their votes.
  7. Votes store locally in the device database.
  8. Votes push to the server.


  1. Voters data successfully verified and stored locally.
  2. Votes stored successfully for some of the users.
  3. Once votes failed to store locally, the rest of the votes failed too.
  4. When the failed votes pushed to the servers, they are stored as empty (not voting).

Root cause

Unable to identify the reason why votes failed to store.

We know the votes does not appear in the server and result dashboard because of failure to send to the server, but we don’t know the reason why it happened in the first place.

Root cause assumptions

We have a few working assumptions, but unable to clearly replicate and validate.

  1. Data corrupted because of Internet connectivity slow or unavailable when the systemfetch users data from the server.
  2. Data corrupted when stored in the local database. Reason unknown.


The app built in a way that it would silently ignore any exceptions or errors in the system. This is the main reason why while we understand the symptoms, we still unable to find the root cause. Initial findings confirmed that the votes are missing from the local devices. Hence the votes not stored in the server and do not reflect the actual voting results.


The votes are irrecoverable. We concluded that the election results are null and void.
While the symptoms show that potential reason behind the failure is technical incompetencies, we are unable to determine if it was an act of sabotage or hacking. Further independent audit required.

Short-Term Recommendation

While there are many ways we can build a more fault tolerant and reliable system, it is not feasible to rebuild the system due to time constraints and public perception. Hence we are only recommending short-term solutions to mitigate the situation and avoid a similar incident.

Our recommendation covers two parts, technical and processes.

Processes Improvement
1. Appoint another party to review the rebuilt app for each election. In an ideal scenario, the

app only built once and use the same app for all elections to ensure consistencies. But since it’s not feasible to do that, having an independent party to review the changes for each build allow us to monitor if there are any unwanted changes or possibilities of new bugs.

Technical Improvement

  1. Use third-party services to capture errors and exception. This way we can quicklyidentify any issues before it’s too later.
  2. Store raw data of the votes and the original source of truth for audit purposes.
  3. Do not silently ignore the errors, it is okay to show error notification to the users so thatthey know something is wrong with their vote and we can quickly take action on it.
  4. Replicate the server in the local environment. We can do away with using Celcom sim card when all the devices will only submit to the local server. The local server then willsync to the cloud server.

Potential Sabotage Scenario

This scenario is based on the assumption that the failure caused by sabotage or hacking. Step 1: Source code aquisition

The attacker needs to get the source code or steal the device to reverse engineer the code. From the code, the attacker would know that any errors will be silently ignored by the system.

For remote attacker – Hard
For employees, internal team, or friendly parties – Easy

Step 2: Internet failure

The attacker would need to ensure failure on the devices Internet connectivity. This could be done with a commercial jammer or in unlikely situation, with help from the Internet providers.

Jammer – Medium Internet providers – Hard

Step 3: Submit the votes directly to the server

There’s no authentication on the server site for vote submission. The server only relies on Hashing of the voters IC number as verification, not authentication. It means the attacker can submit the votes directly from anywhere.

However, the attacker would need to require the IC number of the voters in order to get the IC Hash.

Difficulties (to retrieve IC numbers):
For remote attacker – Hard
For employees, internal team, or friendly parties – Easy

Difficulties (to submit votes):


Difficulties level is Hard for remote attackers, except when there’s an internal accomplice.

[sc name=”47comm”]Laporan pakar IT yang menyebutkan sistem e-voting boleh dimanipulasi & boleh mengantar undi melalui back door dengan hanya memerlukan no kad pengenalan seseorang anggota.