Jump to content
  • Hookando funções no Windows com o API Inspector

       (1 review)

    lucass
     Share

    Vou começar agradecendo ao @Fernando Mercês pela oportunidade e por ter sugerido este artigo, que também me motivou bastante a escrevê-lo!

    Introdução

    Não sou conhecido internet a dentro, apenas acompanho alguns canais no Discord (tal como o do Mente Binária). Meu nível de programação e engenharia reversa não é algo admirável ainda. Em um grupo especifico intitulado "Terra do 1337", que é um grupo fechado de amigos com finalidade de estudar engenharia reversa, programação e descontrair, eu surgi com uma idéia de escrever uma ferramenta que iria facilitar a vida de muitos nesta área de engenharia reversa e achei de API Inspector.

    A seguir um spoiler de como foi o início do projeto, para quem se interessar. ?

    Spoiler

    O início do projeto consistia em um console que se comunicava com uma DLL anexada ao processo (obrigado imensamente ao iPower por sugerir esse tipo de conexão, no caso por pipe. Mesmo o projeto depois deixando isto de lado e tomando outro rumo, essa conexão também encontra-se em meu Github), com isso eu poderia obter as informações internamente com a DLL e as enviar ao interpretador que era um executável.

    A primeira versão chamava-se HookInspector. Ignore o erro de formatação do data type LPWSTR na imagem a seguir. ?

    2011613001_unknown(1).png.21dadd6289bbb93bd4bc58753b2186e9.png

    Na imagem à direita, temos a DLL fazendo seu papel internamente no Notepad++ e do lado esquerdo o executável que recebia as informações da DLL.

    unknown.png.fb669f550c4c552b6f4ab953f231a97d.png

    O projeto também acabou mudando de nome. De HookInspector, passou a se chamar NTDLLInspector, já que iria visar somente funções da API ntdll.dll (x86).

    Porém eu vi a necessidade de fazer uma GUI porque em console (CLI) além de não ser tão bom visualmente dava muito trabalho (não que agora eu não tenha, mas é bem menor). Foi aí que o ImGui entrou em ação e passei a tratar o projeto como API Inspector, utilizando DirectX11.

    Enfrentei dois problemas nessa situação: o primeiro já foi corrigido (consumo extremo de CPU usando DirectX11, de 30% a 50%). A correção veio junto com um downgrade para DirectX9, o que também garantiu maior compatibilidade.

    O segundo problema ainda existe e já existia na primeira versão (de console), que é a dificuldade em obter as informações dos argumentos e encaminhá-las formatadas para o logger e para o ImGui renderizar. Justamente por ter essas dificuldades que eu pensei em abrir o código do projeto, para que este cresça. ?

    O que é o API Inspector

    É uma ferramenta de código-aberto voltada para área de engenharia reversa, que irá auxiliar na análise de funções correspondentes a certas API's do Windows, retornando informações obtidas dos argumentos caso a função seja chamada pela aplicação.

    O que ele faz

    Ele faz um hook (do Inglês "gancho"), que consiste num desvio na função original da API solicitada para nossa própria função e com isso podemos obter os dados (argumentos/parâmetros) que foram passados para tal função.

    Como ele funciona

    O princípio de um hook é simples: você insere no inicio da função um salto que irá levar para a sua função (que é uma cópia da função original) e depois de efetuar o que quiser, irá retornar para a função original prosseguir.

    Talvez mais fácil visualizar o que expliquei com código:

    //Aqui está a função //ZwWriteVirtualMemory | NtWriteVirtualMemory, originada do binário: ntdll.dll
    //créditos ao https://undocumented.ntinternals.net/
    NTSYSAPI 
    NTSTATUS
    NTAPI //WINAPI
    
    NtWriteVirtualMemory(
      IN HANDLE               ProcessHandle,
      IN PVOID                BaseAddress,
      IN PVOID                Buffer,
      IN ULONG                NumberOfBytesToWrite,
      OUT PULONG              NumberOfBytesWritten OPTIONAL );
    
    //Sua versão assembly
    
    777F2110          mov eax,0x3A
    777F2115          mov edx,ntdll.77808D30
    777F211A          call edx
    777F211C          ret 0x14
    
    //O que nós vamos fazer é criar uma função similar á ela com o nome que decidirmos
    //Então vamos inserir um jmp no início da função original para nossa função, ficando assim:
      
    777F2110          jmp api inspector.573523EC
    777F2115          mov edx,ntdll.77808D30
    777F211A          call edx
    777F211C          ret 0x14
    
    //Usei como exemplo minha próprio ferramenta!
    //Então quando ocorrer a chamada desta função ela será jogada em nossa função! Depois de nós fazermos que desejar vamos retorna-la, porém para uma região que aloquei onde contém
    //Um buffer dos bytes que foram sobrescritos da função original:
      
    03610000          mov eax,0x3A
    03610005          jmp ntdll.777F2115
    
    //Ela irá retornar depois do jmp que existe na função original e continuar o código....

    Vantagens de se utilizar o API Inspector ao invés de um debugger

    Imagine que você está visualizando as chamadas intermodulares (para bibliotecas externas, no caso) que um programa faz, utilizando um debugger (o x64dbg por exemplo) e notou que uma certa função que deseja inspecionar é chamada em diversos pontos do programa. Vejo duas opções neste caso: colocar vários breakpoints, um em cada chamada à função, no código do programa ou colocar um único breakpoint função em si, no código dela, na DLL.

    Em ambos os casos, você vai precisar analisar chamada por chamada, parâmetro por parâmetro. E se a função for chamada 20 vezes consecutivamente? O tempo que você levaria para visualizar apenas o primeiro parâmetro da chamada é o tempo que a ferramenta iria levar para exibir todas as 20 chamadas, com os argumentos formatados bonitinhos ao seu dispor. Entende a vantagem? ?

    E as desvantagens?

    Por hora, uma desvantagem é a quantidade de funções e API's suportadas. De fato, a primeira release não possui uma quantidade significativa que vá fazer você utilizar a ferramenta e nem uma quantidade de recursos interessantes na ferramenta. Mas é ai que vem o ponto chave, o fato de deixar ela pública remete ao próprio crescimento da mesma, no primeiro momento é necessário uma orientação da parte de vocês para me ajudar a melhorar o código visual. O segundo passo é eu e vocês começarem a fornecerem mais recursos para ela. Eu irei adicionar todo ou qualquer recurso que seja significativo para a mesma, e para isso eu já tenho mais funcionalidades para implementar na ferramenta que são excelentes.

    Interface gráfica

    Na imagem abaixo, utilizei o API Inspector para hookar a função MessageBoxW() da USER32.DLL. Depois disso, escrevi um texto num novo arquivo no Notepad++ e tentei fechar o programa. Ao fazer isso, o Notepad++ perguntou se eu queria salvar o arquivo e ele faz isso através de uma chamada à MessageBoxW(), que o API Inspector interceptou prontamente.

    Screenshot_1.thumb.png.8501231abce62d2f799122ed5a687f18.png

    Na imagem acima, a janela à esquerda mostra o que está atualmente passando pelas funções hookadas. Na janela a direita, temos um log.

    Como utilizar o API Inspector

    A única coisa que você precisa fazer é anexar a DLL do API Inspector ao processo desejado e para isso existem os softwares chamados "Injetores de DLL" que podem ser achados na internet.

    Você também pode criar o seu próprio injetor. Uma dica é pesquisar sobre injeção com a função LoadLibrary(), mas no exemplo a seguir eu vou mostrar como utilizar o Process Hacker para fazer a injeção.

    1 - Abra o Process Hacker e identifique no mesmo o processo no qual você quer injectar a DLL do API Inspector. No exemplo, usei o processo do Notepad++.

    Screenshot_2.png.a6db50cce5317153c5ed675a9ca98e95.png

    2 - Clique com o botão direito sobre o processo e escolha Miscellaneous > Inject DLL.

    Screenshot_3.png.be7aec2984c520ddfbe088ac69e8bd9f.png

    3 - Selecione a DLL API-Inspector.dll e clique em Abrir.

    Screenshot_4.png.deae66a97a357d33d213933a7654cb9e.png

    4 - Se o Process Hacker possuir privilégios suficientes a ferramenta irá ser carregada, caso contrário, não.

    Screenshot_5.thumb.png.574f17bc0fc93998d7ae358ccc494874.png

    Após isso você precisa selecionar a API desejada, a função desejada e clicar em GO Hook!

    O step call é uma funcionalidade que vai fazer a ferramenta aguardar o pressionamento da tecla ENTER para retornar para a função original. Pronto, o seu hook está feito e você já poderá inspecionar a função desejada.

    Download e código

    No repositório do API Inspector no Github você pode baixar a versão compilada e ter acesso ao código-fonte também. Contribuições são muito bem vindas!

    Bom, eu nunca tinha escrito um artigo. Se faltou informação ou coloquei informação demais me desculpe. Estou aberto pra ler os comentários. Ah, e participem deste projeto! Eu quero fazer ele crescer muito. Caso precise de referências de como cheguei a este projeto, tem tudo na página inicial do projeto no Github.

    Agradecimentos

    Obrigado novamente ao Fernando Mercês, ao pessoal do Terra 1337 que me incentiva cada vez mais e em especial para o iPower e Luan que são colaboradores do projeto.

    Referências


    Revisão: Fernando Mercês
    • Curtir 6
    • Haha 1
     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.



  • Similar Content

    • By Bruna Chieco
      O Siloscape é o primeiro malware que tem como alvo os contêineres do Windows – tecnologia para empacotamento e execução de aplicativos. Segundo o ThreatPost, o malware implanta backdoors e nós de invasão para obter credenciais de usuários.
      A campanha em andamento perfura os clusters do Kubernetes – sistema de orquestração de contêineres open-source – para a implantação de backdoors, permitindo que os invasores roubem dados e credenciais do usuário ou sequestrem bancos de dados inteiros hospedados em um cluster.
      Segundo a reportagem, o malware foi descoberto pelo pesquisador de segurança da Unidade 42, Daniel Prizmant, que o apelidou de Siloscape, ou "Fuga do Silo". O malware explora vulnerabilidades conhecidas em servidores da web e bancos de dados para comprometer os nós do Kubernetes e os clusters de backdoor. 
      Prizmant fez um trabalho de engenharia reversa para conseguir se conectar ao servidor de comando e controle (C2) do Siloscape, onde descobriu que estava hospedando um total de 313 usuários. Isso implica que o Siloscape é uma pequena parte de uma campanha mais ampla, observou ele. Prizmant destaca que o Siloscape é um malware fortemente ofuscado. 
      Os pesquisadores da Unidade 42 identificaram 23 vítimas do Siloscape e disseram que as evidências indicam que a campanha foi lançada há mais de um ano, podendo ter iniciado em janeiro de 2020. 
      A recomendação é que os usuários sigam o conselho da Microsoft para não usar contêineres do Windows como um recurso de segurança. Em vez disso, a Microsoft recomenda o uso estritamente de contêineres Hyper-V para qualquer coisa que dependa da conteinerização como limite de segurança. 
    • By Leandro Fróes
      Depois de muita espera a NSA anunciou oficialmente a inclusão de um debugger no Guidra na sua versão 10.0. Depois de muita discussão sobre esta possibilidade o time de desenvolvimento do framework lançou uma release beta da versão 10.0 ontem!
      Neste momento o debugger suporta analisar aplicações em userland e consegue debuggar tanto binários Windows quanto Linux (utilizando o gdb neste caso). Para quem quer começar logo de cara o Guidra disponibiliza um tutorial de início rápido em Help -> Guidra Functionality -> Debugger -> Getting Started:

      Existem várias formas de iniciar o debugger, desde clicando com o Botão direito -> Open With -> Debugger até direto da sua Project Window do Guidra clicando no ícone de "bug" debaixo de "Tool Chest", como mostrado abaixo:

      Uma vez que a ferramenta é inicializada você deve importar o arquivo a ser depurado para a ferramenta. Uma das formas de fazer isto é simplesmente o arrastando da Project Window. Uma fez carregado podemos ver a cara do mais novo debugger do Guidra:

      Algumas das funcionalidades são: debugging remoto utilizando GDB e windbg, rodar o debugger direto no programa do qual você está analizando estaticamente e tracing de memória.
      Além disso ele também conta com as funcionalidades básicas de um debugger como utilização de breakpoints, listagem de regiões de memória mapeadas, estados dos registradores e uma interface de linha de comando própria.
      Todas as funcionalidades listadas aqui possuem sua própria View, isto é, sua própria janela dentro da ferramenta:


      Vale lembrar que esta release está em sua versão beta e tem como objetivo principal coletar o feedback da comunidade. Caso queira dar uma testada e/ou dar um feedback pra galera do Guidra basta baixar a release clicando no botão abaixo 😉.

    • By Leandro Fróes
      E lá vai mais uma do horsicq! No dia de hoje horsicq, criador de inúmeras ferramentas de análise incluindo o incrível Detect It Easy (DIE), lançou a primeira release do seu novo projeto, um analisador de arquivos MachO chamado XMachOViewer.

      Para quem já utilizou o DIE vai notar uma grande semelhança no design e usabilidade. Já aquelas que não estão familiarizados com as ferramentas do horsicq (deveriam, sério!) fiquem tranquilos, todas são bem simples e intuitívas de se usar.
      Ao contrário do DIE o XMachOViewer tem foco exclusivo em binários MachO. Em relação à funcionalidades a ferramenta consegue fazer tudo que o Detect It Easy faz e ainda mais, tudo isso com uma console exclusiva e mais detalhada: 

      Dentre as funcionalidades novas temos a busca por padrões de criptografia (Base64, RSA, etc), muito útil para análise de malware, por exemplo:

      Name demangling (precisamos dizer o quanto isso é útil? 😄) :

      E também uma funcionalidade de hashing (por que não, né?):

      Além disso, devido à natureza interativa da ferramenta ela permite você editar o arquivo diretamente, bastando apenas selecionar o campo que deseja e começar a digitar:

      A versão 0.01 está pronta para download e com certeza vale uma conferida:

    • By Fernando Mercês
      A Hex-Rays surpreendeu todo mundo agora. Liberou a versão mais recente do IDA, a 7.6, no modelo freeware. Só isso já seria muito bom, mas eles foram além: O IDA 7.6 freeware inclui um descompilador online (cloud-based) gratuito! Pois é, pessoas... Parece que a concorrência exercida pelo Ghidra realmente está sendo saudável para a comunidade. Ao disparar o plugin de descompilação (F5), o programa deixa claro que este recurso na versão gratuita suporta somente binários de 64-bits, dentre outros avisos:

       
      Ao continuar, a descompilação é concluída e códiogo em pseudo-C é exibido ao lado. Veja o exemplo descompilando o notead.exe nativo do Windows:

      Os recursos de interação como renomear variáveis e funções no descompilador estão habilitados, uma notícia muito boa para a comunidade!
      Além do descompilador, a versão 7.6 do IDA freeware inclui:
      Modo escuro
      Tá na moda né? E o IDA não ficou de fora. Se você for em Options -> Colors e mudar o Theme para dark, vai ter um visual assim:

       
      Organização de dados em pastas
      Sendo um disassembler interativo, a versão 7.6 oferece a opção de organizar os dados em pastas. Isso vale para vários locais. Um deles é a janela de funções. É possível agora criar pastas e organizar as funções dentro delas. Para isso, basta clicar com o botão direito do mouse na janela de funções e escolher Show folders. Depois é só selecionar as funções desejadas e escolher Create folder with items.

      E mais:
      Suporte a binários compilados em Go. Suporte ao novo Apple M1. Rebasing mais rápido. Sincronização entre o descompilador online e o disassembly. Lembando que o disassembler em si suporta binários de 32-bits também (PE, ELF e Mach-O). Só o descompilador que não.
       

    • By Bruna Chieco
      Pesquisadores da Sayfer fizeram engenharia reversa no WhatsApp Web e acabaram encontrando "sem querer" um recurso desabilitado por padrão, ou seja, que ainda não está liberado. A função pre-released descoberta permite que a velocidade de um áudio seja acelerada. 
      Os pesquisadores, na verdade, estavam fazendo uma pesquisa sobre outro projeto quando descobriram acidentalmente que o WhatsApp tem um sinalizador para o recurso oculto que permite aos usuários alterar a taxa de reprodução de mensagens de voz.
      Uma das ferramentas de pesquisa utilizadas pelos pesquisadores permitiu essa alteração, sendo cada mensagem de voz é essencialmente uma marca de áudio com um blob de uma fonte de áudio. Para alterar a velocidade, contudo, foi necessário fazer engenharia reversa no código-fonte minimizado do WhatsApp para a web.
      Eles descobriram que o WhatsApp tem três velocidades pré-determinadas para os áudios, porém, desabilitadas. Em publicação, os pesquisadores explicam o passo a passo do que fizeram para conseguir alterar a taxa de reprodução dos áudios.
      E se você quiser saber mais sobre engenharia reversa, o Mente Binária tem um curso com 24 aulas que pode ser acessado por meio do nossos canal no YouTube:
       
×
×
  • Create New...