Contratados pelo grupo que assessorou o candidato à presidência do Corinthians, Roque Citadini, os peritos Leandro Morales Baier Stefano, Marcelo Nagy, Leonardo Nery, Jayme Paiola e Joaquim Vidal elaboraram parecer técnico sobre “possíveis vulnerabilidades em sistema de votação” das eleições alvinegras.
Basicamente, constatou-se diversos erros de procedimentos (checagem de eleitores, etc) – reconhecidos pela Telemeeting (empresa responsável pelas urnas), porém, com pouca probabilidade de interferência no resultado final do pleito eleitoral.
Diz trecho do documento:
“A estrutura de tabelas registra todos os votos separados por urnas, mas não permite rastrear em qual chapa ou em qual presidente um determinado sócio votou, garantindo o voto secreto de cada sócio”
”Não há indícios de fraude ou alteração por meio técnico do sistema de urna”
”O confronto de ‘hash’ diferentes identificado foi um erro operacional do técnico da empresa Telemeeting, que no momento final da apuração de votos não pôde ser corrigido devido à confusão generalizada (tentativa de agressão a Andrés) ocorrida no local do pleito”
”Só não podemos dizer se votou só quem deveria votar. Não fizemos controle de associados porque nosso trabalho foi técnico, apenas na parte de informática”
“(por conta da transmissão de dados em wi-fi) é possível atacantes tentarem o acesso ao servidor de banco de dados”
Vale lembrar, não se trata da perícia judicial imposta em decisão do JECRIM, em ação promovida por outro candidato, Paulo Garcia, que ainda está em curso e deverá ter resultado, em breve, revelado.
O Blog do Paulinho selecionou os principais itens do parecer, até para que nossos leitores, principalmente os que possuem conhecimento técnico de informática, possam opinar.
Iniciaremos pela “conclusão”, para facilitar o entendimento de leigos e experts:
CONCLUSÃO:
Com base nos itens acima podemos concluir que:
1 – Não há indícios de fraude ou alteração por meio técnico do sistema de urna eleitoral.
2 – Não houve alterações de HASH, o que foi comprovado com procedimento pericial técnico de engenharia reversa que consta no item 7.0
3 – O confronto de hash diferentes identificado foi um erro operacional do técnico da empresa Telemeeting, que no momento final da apuração de votos, não pode ser corrigido devido a confusão generalizada ocorrida no local do pleito.
4 – Durante o processo eleitoral conforme combinado em reunião, “Dois Peritos Externos” acompanharam o processo de votação e acesso ao servidor de banco de dados, garantindo assim a lisura do processo constituído de votação.
5 – Existem alguns pontos do processo do sistema eleitoral que devem ser considerados abaixo:
a) O sistema de rede local é baseado em rede sem fio (Wifi).
Esse sistema é inseguro e está exposto a riscos de inundação de dados tornando a rede indisponível (Ataque do tipo JAMMER)
b) Através de um sistema “sem fio” Wifi é possível atacantes tentarem o acesso ao servidor de banco de dados através de tentativas de exploração de vulnerabilidades.
c) Não existem arquivo de log (Registro de ações) no banco de dados que aponta quais foram as alterações, consulta ou exclusões de dados.
Com esse arquivo teremos a garantia que durante o processo eleitoral não houve alterações propositais diretamente no console do servidor de banco de dados.
d) Os dados trafegados entre o tablet (APK) e o serviço que grava as informações coletadas no banco de dados (UrnaV2) deveriam ser criptografados ponta-a-ponta, a fim de garantir maior segurança nas comunicações, prevenindo o acesso indevido às informações, dificultando assim qualquer tipo de fraude a partir do tablet.
e) O local onde os servidores e equipe de TI da Telemeeting se encontravam para realizar o processamento dos votos não era adequado pois não havia segurança suficiente para garantir a integridade física dos colaboradores e dos auditores peritos. Um local mais restrito, assistido pelos fiscais de cada candidato/chapa seria mais apropriado para realizar a contagem dos votos,
emissão dos relatórios, batimento da lista de presença com o número de sócios votantes em relação ao número de votos acumulados na base de dados, cálculo de hash dos artefatos e backup para custodia de todas as máquinas utilizadas no pleito.
Testes e sistema de software
Foi demonstrado o sistema na data dos dias 01 e 02 do mês de fevereiro de 2018 pelo responsável pela Telemeeting Sr. Andrea Mosiici Sócio da empresa e o Sr. Enrico Del Pone responsável técnico pelo sistema de votação.
Em reunião do conselho deliberativo do clube, e os representantes dos candidatos à presidência, foram apresentadas todas as questões técnicas e respondidas as perguntas referentes ao sistema e ao processo eleitoral.
Funcionamento técnico do Sistema
O sistema foi desenvolvido na linguagem de programação C Sharp no Microsoft Visual Studio 17, e nos servidores JavaScript, utilizando um server local Microsoft Windows Server 2012 que armazena dados da votação em banco de dados SQL Server 2014.
Toda a comunicação é feita via rede Local (LAN) através de um dispositivo, roteador WIFI (Roteador Ruckus Zone Flex).
Não há conexões ativas de internet ou outras redes externas.
As urnas utilizadas são tablets da marca Samsung com a versão de Android 5.0.2 rodando um aplicativo (APK utilizando conector Web View) desenvolvido internamente que servirá como
conector ao banco de dados.
Nessas urnas (Tablet) não são possíveis a utilização dos botões, mas o acesso ao conector USB é possível sendo necessário a retirada do cabo de alimentação. Os Tablets estão condicionados em uma caixa de acrílico fechados com uma chave.
Como equipamentos foram utilizados 3 NOTEBOOKs da Telemeeting, sendo 1 Notebook a máquina do desenvolvedor e os outros 2 Notebooks com o software de virtualização VMWare instalado para abrigar o servidor virtual PRINCIPAL com o serviço UrnaV2 e um Banco de Dados SQL Principal e o Servidor virtual de BACKUP com uma cópia do serviço UrnaV2 e um Banco de Dados SQL Mirror, para que todos os dados gravados no servidor Principal fossem automaticamente replicados para o servidor de Backup, permitindo que o servidor de Backup fosse promovido como
Principal caso ocorresse algum problema com o servidor Principal.
Esses 3 computadores estavam ligados em rede com os tablets através de rede sem-fio Wifi. Ambos servidores virtuais estavam com o sistema operacional Windows Server 2012 R2 instalados.
Funcionamento operacional do Sistema e de Votação
Inicialmente, os eleitores vão até aos mesários onde são checados se estão aptos a votar conforme lista entregue a todos os candidatos. A lista de eleitores aptos à votação não foi auditada ou checadas pelos peritos.
Após aprovado o eleitor é encaminhado para a urna de votação. Nesse momento, um Fiscal da Telemeeting disponibiliza uma senha em papel única que foi gerada previamente no banco de dados
do sistema. O próprio fiscal digita a senha liberando a urna para votação (Urna Aberta).
Após a votação a urna soará um BIPE confirmando a votação, nesse momento será enviando um INSERT a uma tabela do banco de dados com os seguintes dados:
Número da Senha;
Voto;
Hora e data;
Urna.
Banco de Dados, scripts, Procedures, Triggers
O Banco de dados Microsoft SQL Server 2014, utilizado para que o serviço desenvolvido em C Sharp grave os votos, não possui nenhuma trigger instalada e conta com Stored Procedures para gravação dos dados.
Não há nenhuma trilha de auditoria habilitada no servidor SQL dificultando saber qual a origem de gravação dos dados, bem como se houve alteração ou exclusão das informações gravadas pelo sistema de votação através de interferência manual ou por outro aplicativo.
A estrutura de tabelas registra todos os votos separados por urnas, mas não permite rastrear em qual chapa ou em qual presidente um determinado sócio votou, garantindo o voto secreto de cada sócio.
Procedimento de auditoria pré-eleição
No dia 02 de fevereiro de 2018 foi realizada uma auditoria da criação de banco de dados e nas Urnas (Tablet) junto ao corpo técnico da empresa Telemeeting
Foi solicitado ao Sr. Enrico, técnico da Telemeeting, a apresentação do sistema gerando as zerézimas, após fazendo simulação de 4 votos, a apuração de resultado e a impressão de relatório com resultado final do pleito simulado.
Após a explicação a todos os auditores peritos e fiscais de chapa e candidatos presentes, foi solicitado que o Sr. Enrico apresentasse os códigos-fonte do aplicativo instalado nos tablets (APK) desenvolvido em JavaScript bem como o código-fonte do serviço que recebe os votos (URNAV2.DLL) desenvolvido em C Sharpe e a respectiva stored procedure que faz a gravação dos dados no SQL
Foram verificadas as assinaturas de arquivo (HASH) do arquivo APK:
Também foi solicitada a assinatura dos arquivos do servidor utilizados para o processo de votação nas eleições, coletada em 02/02/2018 às 17:12h com o seguinte comando:
FCIV -r urnaV2 -type *.dll
Como os dois servidores da Telemeeting eram máquinas virtuais executadas no VMWARE, o Sr. Enrico copiou tanto o APK quanto a pasta do aplicativo URNAV2.DLL para seu computador pessoal na pasta TEMP e gerou HASH em seu computador com o aplicativo FCIV da Microsoft.
Após os cálculos dos hashs e mais nenhuma dúvida apresentada pelos auditores peritos e fiscais, os tablets foram gravados com os APKs. Em seguida, os tablets foram inseridos no invólucro de plástico, onde foram parafusados e colocados em posições de votação.
Os servidores foram desligados e lacrados em sacos na presença de fiscais e auditores peritos, devidamente assinados, conforme visualizado abaixo:
Auditoria do processo eleitoral no dia 03/02/2018
Às 07:15h do dia 03/02/2018 foram abertos os malotes onde continham os servidores na presença do Sr Edmilson, Fiscal do candidato Paulo Garcia, primeiro a chegar ao local.
Os Servidores foram iniciados às 07:25h onde foram efetuados os testes de votação e funcionamento em algumas urnas.
Às 08:12h foi “resetado” o banco de dados eliminando qualquer tipo de voto gerando um relatório com “zero votos” entregue a cada fiscal dos respectivos candidatos e chapas na presença dos auditores peritos. Às 08:30h foram impressas as zerézimas e assinadas pelos representantes dos candidatos que estavam presentes.
A votação foi iniciada às 09h conforme planejamento da comissão eleitoral
Algumas urnas apresentaram problemas pontuais de falta de conexão ou erros, não sendo possível descobrir a causa. Essas urnas com problemas eram reiniciadas pelos integrantes da empresa
Telemeeting, voltando ao funcionamento logo após esse processo conforme registrado abaixo:
Apesar dos travamentos esporádicos, o pleito ocorreu normalmente até às 17:00h sem maiores complicações.
Nenhum técnico da Telemeeting teve acesso físico aos servidores durante o pleito. Apenas a máquina do desenvolvedor, notebook à direita da foto acima, foi acessado pelo Sr. Enrico da Telemeeting para consultar a quantidade de votos coletados durante o pleito, conforme pedido dos fiscais e da comissão eleitoral do Corinthians. Todo o processo de consulta foi assistido pelos auditores peritos presentes no local.
Finalização do processo eleitoral no dia 03/02/2018
Às 17:00h em ponto, a comissão eleitoral solicitou o encerramento do pleito, sendo aguardado somente o encerramento dos votos dos sócios que se encontravam na fila ou em processo de
votação.
Sendo assim, o Sr. Enrico da Telemeeting encerrou o pleito em seu sistema e gerou os relatórios de votação no servidor de banco de dados:
Neste momento, algumas pessoas presentes no clube tentaram o ingresso no ginásio onde ocorria a votação, com acesso não autorizado, gerando tumulto e uso da força por parte dos seguranças do Corinthians para evitar que essas pessoas adentrassem ao local, elevando a tensão dentro do ginásio.
Mesmo assim, o pessoal da Telemeeting continuou com o processo de geração de evidências para a perícia pós-pleito, copiando os artefatos dos servidores para a pasta C:\TEMP do Sr. Enrico, a fim de efetuar cálculo de HASH e batimento de assinaturas.
Também foi realizado um backup da base de dados com todos os votos computados.
Novamente foi gerado o hash do serviço UrnaV2 para que os peritos pudessem obter o resultado e confrontar com o hash coletado no dia anterior ao pleito. Foi utilizado o seguinte comando para
coleta do hash:
FCIV -r urnaV2 -type *.dll
Assinatura de arquivos do servidor utilizados para o processo de votação nas eleições realizadas no Corinthians – 2018, coletadas em 03/02/2018 às 17:14h.
Após a coleta dessa evidência por todos os auditores peritos e fiscais presentes, ocorreu uma confusão generalizada que refletiu no ginásio em uma tentativa de agressão aos que estavam presentes naquele local. Neste momento, o diretor Andréa da empresa Telemeeting resolveu recolher seus equipamentos e retirá-los juntamente com seus funcionários, a fim de manter a preservação de integridade, dado o risco de sofrimento iminente de agressões físicas, bem como a destruição dos equipamentos.
Com isto, não foi possível confrontar a integridade do APK, muito menos gerar uma cópia de segurança dos servidores virtuais para um PENDRIVE, conforme havia sido combinado no dia anterior do pleito, para que fosse lacrado e custodiado pela Telemeeting em caso de dúvidas sobre a idoneidade das eleições.
Problemas de integridade do HASH (DLLS)
Com os hashs coletados antes da confusão, foi possível detectar uma divergência no serviço de coleta de votos URNAV2, como demonstrado abaixo:
Com base em todos os problemas e divergências, a pedido dos Assistentes técnicos foram solicitados os quesitos à empresa Telemeeting através de e-mail.
Quesitos enviados para a empresa Telemeeting com as devidas respostas:
01) É sabido que o produto responsável em gravar no banco de dados SQL os votos coletados nas urnas (tablets) através de um aplicativo para o sistema operacional Android (APK) do fornecedor TeleMeeting do Brasil, é transmitido via wifi para a infraestrutura desenvolvida em C# chamada UrnaV2. O fornecedor confirma essa informação?
R. SIM
02) Em qual pasta do servidor estava instalado a infraestrutura de comunicação desenvolvida para receber os votos coletados tablets conhecido como UrnaV2 para o pleito realizado no Sport Clube Corinthians?
R. C:\Inetpub\wwwroot\UrnaV2
03) A última compilação do projeto UrnaV2 foi realizada em qual data?
R. 01/02/2018
04) Na sexta-feira, dia 02/02/2018, precisamente as 17:12:53 foi gerado uma assinatura de todos os arquivos do projeto UrnaV2, projeto esse que foi auditado pelos peritos auditores e fiscais presentes. Os artefatos cuja assinatura (HASH) foi gerado, tratam-se da última versão compilada, devidamente copiada para a pasta c:\temp do servidor do fornecedor, onde a o produto foi copiado para a pasta “urnav2srv”?
R. Na Sexta-Feira, dia 02/02/2018, precisamente as 17:12:53 foi gerado o hashcode da última versão compilada, mas houve uma falha técnica e essa versão NÃO foi copiada para o servidor
05) Todo acesso ao servidor foi realizado somente pelo pessoal autorizado do fornecedor, não havendo manipulação aos servidores por pessoal que não seja da TeleMeeting. Esta afirmação procede?
R. SIM
06) Ainda no dia 02/02/2018, após geração de assinaturas dos artefatos do programa UrnaV2, todos computadores foram lacrados na presença de fiscais e peritos designados pelos organizadores da eleição?
R. SIM
07) Após lacração dos servidores e tablets, alguém teve acesso aos servidores, seja de forma física ou remota?
R. Não ninguém teve acesso pois servidores e tablets lacrados ficaram no local de eleição sob o cuidado e a responsabilidade da organização do clube Corinthians
08) As 07:00H do dia 03/02/2018, os lacres foram violados para montagem dos equipamentos para realização do pleito, na presença dos peritos e fiscais designados pelos organizadores da eleição?
R. Sim
09) Na manhã do pleito, ao ligar os equipamentos, os servidores que estavam instalados em máquinas virtuais do produto VMWare, apresentou algum problema na inicialização. De qual forma esse problema foi resolvido pelos técnicos da TeleMeeting? Houve a necessidade de restaurar Snapshot, isto é, foi necessário voltar uma imagem do servidor anterior a imagem que teve os artefatos com as assinaturas coletadas no dia 02/02/2018 as 17:12:53?
R. Houve um problema no startup do servidor de backup, resolvido apagando manualmente um arquivo de lock que não tinha sido apagado automaticamente pelo processo de shutdown
da noite anterior.
10) Ocorreram travamentos de alguns tablets nas primeiras horas do pleito. Qual foi o procedimento adotado pela Telemeeting para corrigir o problema nas urnas que apresentaram o problema?
R. Os travamentos aconteceram na fase de abertura da sessão de votação. Os tablets eram reiniciados na presença de um ou mais fiscais e do eleitor. Uma vez reiniciado o aplicativo, a MESMA senha de desbloqueio era usada para abrir a sessão de votação. A aceitação da senha pelo sistema era prova que nenhum voto tinha sido gravado pela sessão anterior travada. A gravação dos 2 votos (Chapa e Presidente) acontecia só no final do processo e era comprovada pelo típico som de votação concluída emitido pelo tablet.
11) Após a apuração e divulgação do resultado do pleito, foi gerado pela Telemeeting uma assinatura do programa UrnaV2 com todos seus artefatos no dia 03/02/2018 as 17:14:01, artefatos esses copiados para pasta C:/TEMP, sub-pasta “urnav2”. O conteúdo copiado para esta sub-pasta, foi oriundo da mesma pasta respondida na questão 02, objeto de cálculo de assinatura (HASH) realizado no dia 02/02/2018 as 17:12:53?
R. Não, por causa de uma falha técnica a última versão do programa UrnaV2 não foi gravada corretamente no servidor, onde ficou uma versão anterior. O hashcode foi calculado sobre essa versão anterior e essa foi a motivação para que resultou diferente daquele calculado no dia 02/02/2018. Aplicando a engenharia reversa é possível verificar que não tem nenhuma diferença nas funções de gravação dos votos entre as duas versões diferentes.
12) Ainda no projeto UrnaV2, o artefato responsável em realizar a gravação dos dados em banco de dados, está escrito dentro do arquivo UrnaV2.dll. Este arquivo sofreu alteração entre o período do dia 02/02/2018 as 17:12:53 até o dia 03/02/2018 as 17:14:01 pela Telemeeting ou por algum colaborador designado pela empresa?
R.Não, os servidores ficaram travados para toda a duração do pleito e sob a constante vigilância de todos os assessores técnicos dos candidatos.
13) O processo de perícia não foi encerrado pela auditoria e fiscalização do clube, devido a confusão generalizada ocorrida após a apuração, devido a risco iminente em relação a integridade física das pessoas envolvidas e presentes no pleito. Sendo assim, as maquinas virtuais não foram gravadas e lacradas perante aos auditores peritos e fiscais do clube. O fornecedor da solução fez cópia de segurança desses servidores? Se sim, eles estarão disponíveis para realização de perícia caso seja formalmente solicitada pelo clube?
R. Sim para ambas as perguntas
14) As urnas utilizadas para votação (tablets) apesar de lacradas, deixavam um espaço para ser inserido um cabo de força para conexão do carregador de bateria. Ao retirar esse cabo, é gerado algum log de autoria informando que essa entrada foi desconectada? Se não há log, havia risco de um dispositivo ser inserido nesta entrada, dado que os tablets baseados em Android possuem uma única entrada tanto para carga de energia e leitura/gravação de dados?
R.Não tinha log de conexão, mas os votos nunca foram gravados localmente no tablet e a gravação no servidor precisava de uma senha unívoca de liberação, na posse exclusiva do pessoal da Telemeeting
15) Quando um sócio informava seus dados no dia da votação ao mesário, um ticket com uma senha era entregue a ele para que fosse digitada na urna, destravando assim o sistema para coleta dos votos para presidente e chapa. Ao pressionar CONFIRMA, os votos eram transferidos e a coleta encerrada para aquele sócio. O ticket com a senha era depositado numa urna para não mais ser utilizado. É correto dizer que essa senha era única para cada sócio? A Telemeeting está em poder dos tickets em papel depositados nas urnas? Se sim, é possível apresentar um relatório com todos os tickets utilizados, em quem foi votado e como contraprova todos os tickets em papel utilizados, para batimento do relatório?
R.Sim todas as senhas eram únicas para cada sócio e tinha um controle que impedia de utilizar a mesma senha para mais de um sócio. O sócio NUNCA deveria ter entrado em contato com o ticket em papel, que sempre estava na mão do pessoal da Telemeeting, até o momento de ser depositado nas urnas. É possível apresentar um relatório de todos os tickets utilizados junto com horário e urna de utilização, assim como todos os tickets de papel que foram achados nas urnas após a confusão generalizada ocorrida durante a apuração
A Telemeeting nos convidou para irmos às dependências da empresa e disponibilizou uma cópia de todos os servidores realizados (utilizados) no pleito, a fim de que pudéssemos averiguar o porquê da diferença ocorrida.
Perícia Técnica realizada na empresa Telemeeting no dia 09/02/2018
Após realizarmos os questionamentos presencialmente na Telemeeting conseguimos mapear o motivo da diferença das assinaturas (hash) do arquivo DLL em questão conforme as evidências abaixo:
Na sexta-feira 02/02/2018, o Sr. Enrico compilou a última versão da DLL UrnaV2 e gravou na pasta c:\TEMP de seu computador Pessoal. Dessa forma, ele gerou o hash nessa pasta, hash esse
apresentado aos auditores peritos e fiscais no dia 02/02/2018, entretanto não atualizou os servidores com essa versão. Significa que os auditores peritos e fiscais presentes no dia 02/02/2018
homologaram a versão que realmente foi utilizada no pleito.
O Erro foi acreditar que o hash apresentado no dia 02/02/2018 era oriundo do servidor. Na verdade, o hash era de uma versão que o Sr. Enrico compilou em seu computador, mas que não chegou a copiar para o servidor utilizado no pleito, causando dessa forma a confusão.
No dia do pleito foi calculado o hash novamente, mas dessa vez foi copiado para o c:\temp a DLL do servidor principal. A DLL que foi calculado o hash na sexta-feira (02/02/2018) era de 30 minutos depois da DLL utilizada no sábado.
Para nos certificarmos do ocorrido, fizemos uma cópia das duas VMs para um local seguro e abrimos essas duas VMs calculando o hash da DLL das máquinas em questão. Ambas geraram o hash com conteúdo igual ao hash apresentado no sábado (03/02/2018) pós-pleito.
Fizemos então a engenharia reversa dessa DLL e checamos a rotina que faz a gravação do voto. Para isto, utilizamos o software free JetBrains.dotPeek.2017.3.2.web.
O código apurado nos dois servidores no processo de engenharia reversa revelou que o código de gravação dos votos era idôneo, tal como estava no código fonte apresentado aos auditores na sexta-feira (02/02/2018).
Detalhes do Servidor Virtual analisado no dia 09/02/2018 nas dependências da Telemeeting:
Como ambos os servidores (principal e backup) estavam com o mesmo hash apresentado no dia 03/02/2018 pós-pleito, realizamos a engenharia reversa de uma das DLLs para constatar o conteúdo de seu código fonte.
Não observamos nenhum código que pudesse manipular os votos coletados antes da gravação em banco de dados.
Entretanto, restava a dúvida então do porquê o hash coletado do arquivo UrnaV2.DLL no dia 02/02/2018 não era o mesmo que coletamos no dia 03/02/2018. Vale observar que o hash obtido
no servidor Principal e no servidor de Backup coletados no dia 09/02/2018 são idênticos ao hash coletado no dia do pleito.
Solicitamos então uma cópia da última DLL compilada no Visual Studio .NET na máquina do desenvolvedor da Telemeeting. Obtivemos uma cópia da DLL compilada na estação de desenvolvimento do Sr. Enrico salva em um pendrive por ele.
A cópia da pasta C:\TEMP da máquina do Sr. Enrico (desenvolvedor) estava em um PENDRIVE e também em seu DROPBOX. Vale ressaltar que não havia DROPBOX no servidor Principal e servidor de Backup, somente no NOTEBOOK de desenvolvedor. Em posse dessa DLL copiada do pendrive do desenvolvedor, geramos o hash deste artefato.
O Resultado obtido coincidiu com o hash que coletamos na sexta-feira (02/02/2018) na homologação do produto.
Para tirar a prova, fizemos a engenharia reversa do código fonte dessa dll e vimos que a rotina de gravação dos votos é exatamente a mesma da DLL que estava em produção, tanto no servidor
Principal, como no servidor de Backup.
Concluímos que a não conformidade do hash deu-se por erro operacional ao copiar as DLLs do produto para a pasta C:\TEMP da estação do Desenvolvedor ao invés de ser copiada do servidor Principal e/ou servidor de Backup, entretanto graças à engenharia reversa foi possível atestar idoneidade no procedimento de gravação dos votos tanto na DLL dos servidores utilizado no
dia do pleito, como a DLL que estava na máquina do desenvolvedor e que nunca foi atualizada nos servidores, dado que não foi detectado nenhum código que poderia adulterar o voto coletado nessa funcionalidade.
Concluímos então que o problema foi apenas de erro operacional na apresentação dos artefatos para coleta de hash na sexta-feira (02/02/2018).
Abaixo, detalhes do código fonte extraído na engenharia reversa dos servidores de votação (DLL apresentada no dia 03/02/2018 pós-pleito):
Para confrontação, detalhes do código fonte extraído do pendrive do desenvolvedor (DLL apresentada no dia 02/02/2018):
Não observamos nenhuma alteração no código da DLL utilizada no pleito (03/02/2018) em relação a DLL apresentada equivocadamente pelo desenvolvedor no ato da homologação (02/02/2018)