Este artigo explora o protetor ElecKey, um tipo de proteção de software incomum, e demonstra como contorná-lo para remover a proteção. O artigo detalha o processo de dump, análise e correção de um executável protegido, revelando as dificuldades e soluções encontradas.
MundiX News·21 de maio de 2026·10 min de leitura·👁 4 views
Hoje, vamos analisar o protetor incomum ElecKey e ver como a proteção de um aplicativo pode ser comprometida. Ao mesmo tempo, descobriremos por que as ferramentas de dump padrão não conseguem lidar com essa tarefa, encontraremos uma solução alternativa e escreveremos um pequeno script de demonstração.
Aviso: Este artigo é apenas para fins informativos e educacionais. O autor e a redação não se responsabilizam por quaisquer danos causados pelo uso das informações fornecidas. A disseminação de malware, a violação do funcionamento de sistemas e a violação do sigilo da correspondência são puníveis por lei.
Vamos continuar nossa excursão por vários protetores exóticos e seus mundos internos. Desta vez, encontramos um tipo de proteção bastante raro — ElecKey, então vamos tratá-lo com mais severidade do que o normal. Não nos limitaremos a patches, proxies e recomendações sobre como escrever nossos próprios decriptadores, mas simplesmente removeremos a proteção completamente.
Suponha que tenhamos um determinado aplicativo nativo, cujo código executável seja criptografado ou empacotado com alto grau de entropia. O Detect It Easy fornece as seguintes informações sobre o protetor:
PE64
Operation system: Windows(10)[AMD64, 64-bit, GUI]
Linker: Microsoft Linker(14.44.35221)
Compiler: Microsoft Visual C/C++ (19.44.35221)[C++]
Language: C++
Tool: Microsoft Visual Studio(2022, 17.14)
Sign tool: Windows Authenticode(2.0)[PKCS #7]
Protector: ElecKey(2.00.X) (Heur)
Protection: Generic[Stack-push address near EP Section #0 (".text") has RWX] (Heur)
Packer: Generic[Last section EP Sections like ElecKey Section #0 (".text") compressed High entropy]
É necessário remover o protetor do programa, obtendo um código funcional, transparente para engenharia reversa e patching. Como o programa é executado em nosso computador e funciona totalmente, temos todas as chances de que essa tarefa possa ser resolvida com um dump. O "Hacker" já publicou artigos sobre como fazer isso, e em meus artigos anteriores, fizemos dump de aplicativos repetidamente do depurador x64dbg usando o plugin Scylla. Vamos tentar seguir o mesmo caminho desta vez, pois o programa é executado sob o depurador e permite ser interrompido.
Infelizmente, este plano falha já no estágio de autodetecção do IAT.
Poderíamos procurar o IAT manualmente, mas parece que a raiz do problema reside no ponto de entrada incorreto OEP, então vamos começar a procurá-lo. Para começar, vamos tentar interromper o programa e rastrear a chamada superior dele na pilha de retorno.
Carregaremos a variante dumpada no IDA e veremos essa chamada no código descompilado.
Muito parecido com o código inicial do aplicativo em C. Vamos ver no IDA de onde esse procedimento é chamado.
Chamada de procedimento no IDA
Parece que o endereço no código dumpado EC596C (RVA=25596C) é o ponto de entrada do programa desejado. Este endereço poderia ser obtido por meio de um rastreamento ou definindo um ponto de interrupção na seção .text, contendo o código executável descriptografado, mas ambos os métodos têm certas nuances. Portanto, se for possível encontrar o ponto de entrada por meio de investigações teóricas no IDA, é mais fácil fazê-lo dessa maneira.
Bem, inserimos o OEP correto no campo apropriado da janela Scylla e vemos que agora a pesquisa automática do IAT também funciona, e as importações nele se parecem com as reais.
Removemos as últimas inválidas da lista de importações, fazemos o dump do programa e corrigimos o dump resultante. Infelizmente, o milagre não aconteceu: o programa dumpado não é executado (e nem carrega no depurador x64dbg), falhando com o erro C000007B STATUS_INVALID_IMAGE_FORMAT (FORMATO DE IMAGEM INVÁLIDO). Obviamente, Scylla fez algo errado durante o dump, e o problema é que a "Microsoft" não forneceu nenhuma dica sobre o que exatamente o formato da imagem não atende aos altos padrões de carregamento.
Um artigo mais ou menos decente sobre isso está no site DataDump, e, depois de lê-lo, tentaremos descobrir o que está errado no módulo dumpado.
Abriremos os programas originais e dumpados no CFF Explorer e compararemos os mapas de seção.
É visível que os tamanhos das seções mudaram, e Scylla adicionou sua própria seção, na qual colocou o IAT restaurado a seu critério. Parece que tudo se encaixa em tamanho, e parece que todos os dados estão em seus lugares. No entanto, a pequena seção vazia .ftable com apenas 0x200 bytes de tamanho inspira suspeitas. Durante o dump, Scylla, por algum motivo, a torna vazia e se sobrepõe à seção .rsrc que a segue, o que transforma a imagem em uma imagem definitivamente incorreta.
É verdade que, após a correção, esta seção é restaurada (o que é visível na captura de tela anterior), mas algumas alterações irreversíveis podem ocorrer. Normalmente, o sistema operacional olha para essas excentricidades de Scylla com favor, mas isso não elimina o problema em nosso caso — a imagem dumpada e corrigida se recusa teimosamente a carregar. E mesmo para entender o porquê, é preciso fazer muitos movimentos complexos, mergulhando nas entranhas do kernel, o que você realmente não quer fazer para remover um protetor relativamente simples.
Vamos pensar: precisamos reconstruir a importação em nosso caso? Talvez estejamos arrombando uma porta aberta? Na verdade, o IAT está localizado na seção .rdata, que não é criptografada nem empacotada. Se no cabeçalho do módulo dumpado, você alterar manualmente o ponteiro IAT do restaurado para o original e, em seguida, carregar o módulo no descompilador IDA, o código de chamada das funções importadas parece totalmente funcional à primeira vista. Além disso, a julgar por tudo, exceto a descriptografia da seção .text, após o dump, não há alterações nas outras seções, mesmo os tamanhos são aproximadamente preservados com a precisão do alinhamento.
O restante do artigo está disponível apenas para membros.
Materiais das edições mais recentes
tornam-se disponíveis separadamente apenas dois meses após a publicação. Para continuar lendo, você deve se tornar membro da comunidade "Xakep.ru".
Junte-se à comunidade "Xakep.ru"!
A associação à comunidade durante o período especificado lhe dará acesso a TODOS os materiais do "Hacker", permitirá que você baixe edições em PDF, desative a publicidade no site e aumente seu desconto acumulativo pessoal!
Mais detalhes
Eu já sou membro do "Xakep.ru"
← Anterior
Exploit PoC publicado para a vulnerabilidade DirtyDecrypt do Linux
Hoje, vamos analisar o protetor incomum ElecKey e ver como a proteção de um aplicativo pode ser comprometida. Ao mesmo tempo, descobriremos por que as ferramentas de dump padrão não conseguem lidar com essa tarefa, encontraremos uma solução alternativa e escreveremos um pequeno script de demonstração.
Aviso: Este artigo é apenas para fins informativos e educacionais. O autor e a redação não se responsabilizam por quaisquer danos causados pelo uso das informações fornecidas. A disseminação de malware, a violação do funcionamento de sistemas e a violação do sigilo da correspondência são puníveis por lei.
Vamos continuar nossa excursão por vários protetores exóticos e seus mundos internos. Desta vez, encontramos um tipo de proteção bastante raro — ElecKey, então vamos tratá-lo com mais severidade do que o normal. Não nos limitaremos a patches, proxies e recomendações sobre como escrever nossos próprios decriptadores, mas simplesmente removeremos a proteção completamente.
Suponha que tenhamos um determinado aplicativo nativo, cujo código executável seja criptografado ou empacotado com alto grau de entropia. O Detect It Easy fornece as seguintes informações sobre o protetor:
PE64
Operation system: Windows(10)[AMD64, 64-bit, GUI]
Linker: Microsoft Linker(14.44.35221)
Compiler: Microsoft Visual C/C++ (19.44.35221)[C++]
Language: C++
Tool: Microsoft Visual Studio(2022, 17.14)
Sign tool: Windows Authenticode(2.0)[PKCS #7]
Protector: ElecKey(2.00.X) (Heur)
Protection: Generic[Stack-push address near EP Section #0 (".text") has RWX] (Heur)
Packer: Generic[Last section EP Sections like ElecKey Section #0 (".text") compressed High entropy]
É necessário remover o protetor do programa, obtendo um código funcional, transparente para engenharia reversa e patching. Como o programa é executado em nosso computador e funciona totalmente, temos todas as chances de que essa tarefa possa ser resolvida com um dump. O "Hacker" já publicou artigos sobre como fazer isso, e em meus artigos anteriores, fizemos dump de aplicativos repetidamente do depurador x64dbg usando o plugin Scylla. Vamos tentar seguir o mesmo caminho desta vez, pois o programa é executado sob o depurador e permite ser interrompido.
Infelizmente, este plano falha já no estágio de autodetecção do IAT.
Poderíamos procurar o IAT manualmente, mas parece que a raiz do problema reside no ponto de entrada incorreto OEP, então vamos começar a procurá-lo. Para começar, vamos tentar interromper o programa e rastrear a chamada superior dele na pilha de retorno.
Carregaremos a variante dumpada no IDA e veremos essa chamada no código descompilado.
Muito parecido com o código inicial do aplicativo em C. Vamos ver no IDA de onde esse procedimento é chamado.
Chamada de procedimento no IDA
Parece que o endereço no código dumpado EC596C (RVA=25596C) é o ponto de entrada do programa desejado. Este endereço poderia ser obtido por meio de um rastreamento ou definindo um ponto de interrupção na seção .text, contendo o código executável descriptografado, mas ambos os métodos têm certas nuances. Portanto, se for possível encontrar o ponto de entrada por meio de investigações teóricas no IDA, é mais fácil fazê-lo dessa maneira.
Bem, inserimos o OEP correto no campo apropriado da janela Scylla e vemos que agora a pesquisa automática do IAT também funciona, e as importações nele se parecem com as reais.
Removemos as últimas inválidas da lista de importações, fazemos o dump do programa e corrigimos o dump resultante. Infelizmente, o milagre não aconteceu: o programa dumpado não é executado (e nem carrega no depurador x64dbg), falhando com o erro C000007B STATUS_INVALID_IMAGE_FORMAT (FORMATO DE IMAGEM INVÁLIDO). Obviamente, Scylla fez algo errado durante o dump, e o problema é que a "Microsoft" não forneceu nenhuma dica sobre o que exatamente o formato da imagem não atende aos altos padrões de carregamento.
Um artigo mais ou menos decente sobre isso está no site DataDump, e, depois de lê-lo, tentaremos descobrir o que está errado no módulo dumpado.
Abriremos os programas originais e dumpados no CFF Explorer e compararemos os mapas de seção.
É visível que os tamanhos das seções mudaram, e Scylla adicionou sua própria seção, na qual colocou o IAT restaurado a seu critério. Parece que tudo se encaixa em tamanho, e parece que todos os dados estão em seus lugares. No entanto, a pequena seção vazia .ftable com apenas 0x200 bytes de tamanho inspira suspeitas. Durante o dump, Scylla, por algum motivo, a torna vazia e se sobrepõe à seção .rsrc que a segue, o que transforma a imagem em uma imagem definitivamente incorreta.
É verdade que, após a correção, esta seção é restaurada (o que é visível na captura de tela anterior), mas algumas alterações irreversíveis podem ocorrer. Normalmente, o sistema operacional olha para essas excentricidades de Scylla com favor, mas isso não elimina o problema em nosso caso — a imagem dumpada e corrigida se recusa teimosamente a carregar. E mesmo para entender o porquê, é preciso fazer muitos movimentos complexos, mergulhando nas entranhas do kernel, o que você realmente não quer fazer para remover um protetor relativamente simples.
Vamos pensar: precisamos reconstruir a importação em nosso caso? Talvez estejamos arrombando uma porta aberta? Na verdade, o IAT está localizado na seção .rdata, que não é criptografada nem empacotada. Se no cabeçalho do módulo dumpado, você alterar manualmente o ponteiro IAT do restaurado para o original e, em seguida, carregar o módulo no descompilador IDA, o código de chamada das funções importadas parece totalmente funcional à primeira vista. Além disso, a julgar por tudo, exceto a descriptografia da seção .text, após o dump, não há alterações nas outras seções, mesmo os tamanhos são aproximadamente preservados com a precisão do alinhamento.
O restante do artigo está disponível apenas para membros.
Materiais das edições mais recentes
tornam-se disponíveis separadamente apenas dois meses após a publicação. Para continuar lendo, você deve se tornar membro da comunidade "Xakep.ru".
Junte-se à comunidade "Xakep.ru"!
A associação à comunidade durante o período especificado lhe dará acesso a TODOS os materiais do "Hacker", permitirá que você baixe edições em PDF, desative a publicidade no site e aumente seu desconto acumulativo pessoal!
Mais detalhes
Eu já sou membro do "Xakep.ru"
← Anterior
Exploit PoC publicado para a vulnerabilidade DirtyDecrypt do Linux
