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

       (0 reviews)

    lucass

    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

    • Curtir 4


    User Feedback

    Recommended Comments

    There are no comments to display.



    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Add a comment...

    ×   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 Fernando Mercês
      Comecei a estudar a linguagem Go há alguns dias e fiquei muito impressionado com seus recursos. A facilidade para programação paralela, o fato de ter ponteiros, funções que retornam mais de um valor, código enxuto (se você declarar uma variável e não usar, o programa nem compila!) e outros realmente me encantaram.
      Recentemente precisei disassemblar um trecho de código de um binário PE para um projeto que está escrito em Go. Vi que existem algumas bibliotecas prontas para serem usadas, como gapstone (bindings da Capstone) e go-zydis (bindings da Zydis) mas não encontrei uma nativa.
      No entanto, vi que existe uma ferramenta nativa no toolset da linguagem similar ao objdump do GNU binutils:
      $ go doc cmd/objdump Objdump disassembles executable files. Usage: go tool objdump [-s symregexp] binary Objdump prints a disassembly of all text symbols (code) in the binary. If the -s option is present, objdump only disassembles symbols with names matching the regular expression. Compilei um "hello, world" em Go só pra ver:
      ~/hello $ cat main.go package main import "fmt" func main() { fmt.Println("menteb.in") } ~/hello $ go build E de fato o objdump da Go funciona:
      ~/hello $ go tool objdump hello | head TEXT go.buildid(SB) :-134217728 0x1001000 ff20 JMP 0(AX) :-134217728 0x1001002 476f OUTSD DS:0(SI), DX :-134217728 0x1001004 206275 ANDB AH, 0x75(DX) :-134217728 0x1001007 696c642049443a20 IMULL $0x203a4449, 0x20(SP), BP :-1 0x100100f 226d35 ANDB 0x35(BP), CH :-1 0x1001012 4c6f OUTSD DS:0(SI), DX :-1 0x1001014 6a52 PUSHL $0x52 :-1 0x1001016 436e OUTSB DS:0(SI), DX :-1 0x1001018 4a31794f XORQ DI, 0x4f(CX) Mas ao tentar com o um PE compilado pra 64-bits, descobri que só funciona com binários feito em Go. 😩
      $ go tool objdump putty.exe objdump: disassemble putty.exe: no runtime.pclntab symbol found De qualquer forma, resolvi olhar o código-fonte deste objdump interno da linguagem pra ver qual é dessa mandinga.  Na linha 43 do main.go do objdump tem um import pra uma biblioteca chamada objfile. Pensei: Wow, deve ser uma biblioteca de disassembly, talvez eu possa alterar ! E na hora já criei um projeto tentando usá-la mas fui surpreendido com um errão! kkkk
      ~hello $ cat main.go package main import "fmt" import "cmd/internal/objfile" func main() { fmt.Println("menteb.in") } ~hello $ go build main.go:4:8: use of internal package cmd/internal/objfile not allowed Não pesquisei muito sobre essa história sobre eu não poder usar um pacote interno (por quê o objdump pode e eu não posso?!), mas fui olhar esta objfile e terminei encontrando seu fonte. Para minha alegria, neste arquivos disasm.go vi os seguintes imports:
      "golang.org/x/arch/arm/armasm" "golang.org/x/arch/arm64/arm64asm" "golang.org/x/arch/ppc64/ppc64asm" "golang.org/x/arch/x86/x86asm" Agora sim, carái! É tudo público e posso usar. Desculpe o desabafo.. hehe o artigo na verdade começa aqui mas quis contar como cheguei porque né. 😁
      Cada uma dessas bibliotecas possui uma função Decode() justamente pra decodificar uma instrução (tipo Inst). Testei com um NOP em 64-bits, só pra ver:
      package main import ( "fmt" "log" "golang.org/x/arch/x86/x86asm" ) func main() { dados := []byte{0x90} ins, err := x86asm.Decode(dados, 64) if err != nil { log.Fatalln(err) } fmt.Println(ins) } A saída foi exatamente a esperada:
      $ ./hello NOP Show. Agora é abrir um PE, ler de onde quero e daí disassemblar usado essa x86asm.Decode() num loop, mas vou deixar esse exercício aí pra quem quiser treinar Go. Ou se acharem útil posso postar um aqui mais tarde. Aqui já funcionou mas precisa de uma polida. 🙂
      Perceba também que há bibliotecas para ARM e PowerPC. Achei bem maneiro. Talvez em breve o time da Go adicione suporte a mais arquiteturas. Amém! 🙏 
    • By njrizzo
      VI BSDDAY
      Evento de software livre, realizado em Seropédica, levando tecnologia para o interior do estado do Rio de Janeiro
      O BSD DAY é um evento para entusiastas do software livre, em especial os sistemas operacionais  FreeBSD, NetBSD, OpenBSD, DragonFly e Linux, e suas aplicações como servidor ou desktop.
      A submissão de palestras está aberta e termina no dia 20/4/2020
      Compartilhando o conhecimento de profissionais na área para todos os interessados.
      Acesse o site: https://www.bsdday.com.br
      em breve com atualizações para o evento deste ano.
      Este dinheiro serve para bancar os dois coffe-breaks, transporte, confecções de material de divulgação e papelaria
      Brindes para doações: ( deverão ser retirados no dia do evento)

      R$ 30,00 até R$ 50,00   - Porta copos
      R$ 50,01 até R$ 100,00 - Caneca
      R$ 100,01 até R$ 300,00 - Porta copos + Caneca
      R$ 300,01 e acima -  2x Porta Copos + 2x Caneca

      Se quiser podemos enviar, mas o custo do envio deverá ser combinado e pago em separado
       

    • By ncaio
      ====== Bem-vindo a bordo ======

      Este é um repositório/espaço aberto/livre de conteúdo referente a hardware hacking em geral. Sinta-se a vontade para contribuir e retirar suas dúvidas. Assim como em outros espaços de conhecimento compartilhado na Internet, este Fórum tem regras. Algumas delas, são:
        * Seja educado(a) e respeitoso(a);
        * Pesquise antes;
        * Seja claro(a) e descritivo(a);
        * Esteja preparado(a) para compartilhar informações relevantes a sua dúvida;
        * Não fuja do foco;
        * Referencie autores;
        * E etc.
    • By Fabiano Furtado
      Pessoal...
      Ontem achei um artigo na Internet bem escrito, interessante e detalhado sobre Engenharia Reversa em ELF.
      É um reversing básico, mas não tããããão básico assim. Acho que vale a pena conferir.
      http://manoharvanga.com/hackme/
      Valeu!
    • By Ciro Moises Seixas Dornelles
      Olá a todos, existe alguma maneira de se extrair o conteúdo do livro de engenharia reversa para que eu posso lê-lo em um dispositivo kindle?

       
×
×
  • Create New...