Jump to content

Leandro Fróes

Mente Binária
  • Content Count

    166
  • Joined

  • Last visited

Community Reputation

17 Good

Personal Information

Recent Profile Visitors

2,238 profile views
  1. Fala Helder, blz? Isso é definido pelo próprio formato do arquivo e é possível sim achar só olhando pro dump em hexa. Da certo "trabalho" ficar procurando os campos olhando direto pro hexa, mas tenho que dizer, é super divertido e se aprende muito 😁. Bom, olhando para o dump do arquivo em hexa a primeira coisa que vemos é o DOS Header, que representa os primeiros 64 bytes do arquivo e nele há um campo chamado e_lfanew, que define o offset para a assinatura PE. Esta assinatura é o primeiro campo de outro header chamado NT Header: typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; } IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS; Como podemos ver a assinatura PE tem o tamanho de uma DWORD, isto é, 4 bytes de acordo com a Microsoft e os campos seguintes são: um outro cabeçalho completo (os bytes dele em si) chamado File Header: typedef struct _IMAGE_FILE_HEADER { WORD Machine; WORD NumberOfSections; DWORD TimeDateStamp; DWORD PointerToSymbolTable; DWORD NumberOfSymbols; WORD SizeOfOptionalHeader; WORD Characteristics; } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER; E logo depois um cabeçalhado chamado Optional Header, que é um dos mais importantes do formato PE. Este cabeçalho possui dentro dele um campo chamado ImageBase, que é justamente o que você está procurando. Eu lembro que você parecia estar estudando pelo tutorial que eu fiz sobre o formato PE aqui, certo? No post de número 3 do tutorial eu falo sobre os campos do NT Header e do Optional Header. De qualquer forma, saiba que é sim possível, é só questão de ler o formato da struct na documentação e ir contando byte a byte até chegar lá!! Abs
  2. Opa, na verdade ele não mostra a quantidade de strings distintas não. Peguei um binário qualquer aqui como exemplo e rodei readelf -h arquivo pra pegar as informações do ELF Header: Cabeçalho ELF: Magia: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Classe: ELF64 Dados: complemento 2, little endian Versão: 1 (current) OS/ABI: UNIX - System V Versão ABI: 0 Tipo: EXEC (ficheiro executável) Máquina: Advanced Micro Devices X86-64 Versão: 0x1 Endereço do ponto de entrada: 0x453140 Início dos cabeçalhos do programa: 64 (bytes no ficheiro) Início dos cabeçalhos de secção: 456 (bytes no ficheiro) Bandeiras: 0x0 Tamanho deste cabeçalho: 64 (bytes) Tamanho dos cabeçalhos do programa:56 (bytes) Nº de cabeçalhos do programa: 7 Tamanho dos cabeçalhos de secção: 64 (bytes) Nº dos cabeçalhos de secção: 24 Índice de tabela de cadeias da secção: 3 Como podemos ver o valor do campo e_shstrndx ali é 3 (última linha). Agora para printar os Section Headers usei readelf -S arquivo: Há 24 cabeçalhos de secção, começando no desvio 0x1c8: Cabeçalhos de secção: [Nr] Nome Tipo Endereço Desvio Tam. Tam.Ent Bands Lig. Info Alinh [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000401000 00001000 00000000000b140b 0000000000000000 AX 0 0 16 [ 2] .rodata PROGBITS 00000000004b3000 000b3000 000000000004fa5d 0000000000000000 A 0 0 32 [ 3] .shstrtab STRTAB 0000000000000000 00102a60 0000000000000193 0000000000000000 0 0 1 [ 4] .typelink PROGBITS 0000000000502c00 00102c00 0000000000000d2c 0000000000000000 A 0 0 32 [ 5] .itablink PROGBITS 0000000000503930 00103930 0000000000000080 0000000000000000 A 0 0 8 [ 6] .gosymtab PROGBITS 00000000005039b0 001039b0 0000000000000000 0000000000000000 A 0 0 1 [ 7] .gopclntab PROGBITS 00000000005039c0 001039c0 0000000000086003 0000000000000000 A 0 0 32 [ 8] .noptrdata PROGBITS 000000000058a000 0018a000 ... Omiti a saída completa, mas já deu pra ver que tem mais de 3 seções, como estava dizendo no primeiro comando rodado. O que rola na verdade é que campo e_shstrndx possui o índice da Section Header Table de uma seção chamada .shstrtab (da pra ver ali na saída do segundo comando), que por sua vez possui dentro dela a Section String Table. Quanto ao sh_name, é simplesmente o índice (offset em hexa) da respectiva seção dentro da Section String Table. Pra ficar mais claro vou fazer igual você disse que estava fazendo, ver os bytes diretamente. Deu pra ver pela saída do comando que o array de Section Headers começa no offset 0x1c8. Cada Section Header possui 64 bytes de tamanho e podemos ver que o primeiro elemento deste array está todo zerado, então vou pular 0x1c8 + 0x40 (64 em hexa) com o comando hd -s 0x208 arquivo e ver no que da: 00000208 01 00 00 00 01 00 00 00 06 00 00 00 00 00 00 00 |................| 00000218 00 10 40 00 00 00 00 00 00 10 00 00 00 00 00 00 |..@.............| 00000228 0b 14 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000238 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ... Os primeiros 4 bytes (lembrando do endianess) representam o índice (isto é, o offset em hexa) do nome desta seção dentro da Section String Table. Se formos até esta suposta table (offset 0x102a60 segundo readelf -S), veremos o seguinte: 00102a60 00 2e 74 65 78 74 00 2e 6e 6f 70 74 72 64 61 74 |..text..noptrdat| 00102a70 61 00 2e 64 61 74 61 00 2e 62 73 73 00 2e 6e 6f |a..data..bss..no| 00102a80 70 74 72 62 73 73 00 2e 6e 6f 74 65 2e 67 6f 2e |ptrbss..note.go.| 00102a90 62 75 69 6c 64 69 64 00 2e 65 6c 66 64 61 74 61 |buildid..elfdata| ... De fato, no índice 00 00 00 01 (ou simplesmente 1, em hexa) está o nome da nossa seção .text na Section String Table. Abs.
  3. Me diz uma coisa, algum motivo pra você ter feito em Go? Ou foi só preferência msm? Vi que você tem bastante coisa com Go no seu git, vou dar uma olhada o/. Btw, quando comecei a estudar fiz isso aqui https://github.com/leandrofroes/gohunting , é uma toolzinha bem simples pra pegar algumas infos de processos em ambiente *nix com uma saída limpa . Se alguém tiver qualquer feedback vou adorar ouvir.
  4. Eu não lembro porque postei isso na época, mas deve ter sido pelo fato de um tempo atrás eu ter um preconceito muito grande quanto à certificações. Hoje eu posso dizer que continuo com o pensamento de que elas não podem provar seu conhecimento de fato, mas admito que elas ajudam um pouco dependendo do caso 😃 .
  5. Opa, vou reviver esse post aqui. De uns tempos pra cá as vezes ando brincando com Go e tenho que dizer, a linguagem é muito interessante. Eu curti muito essa pegada única dela de interagir com API e ao mesmo tempo ser robusta e bem estruturada. Vocês fizeram algo com Golang? Acho que até agora só fiz scripts pra interagir com API e uns programas pra agilizar meu trabalho 😅. Abs.
  6. Opa, vamos lá: Isso aqui de fato não temos, mas parece ser uma boa. Há um espaço no seu perfil onde você pode colocar o link do seu website, github, gitlab, linkedin, etc. Mesma coisa que o número 2. Abs!!
  7. Fala @HelderPereira. Os primeiros 64 bytes de um arquivo no formato PE pertencem ao DOS-Header. Os primeiros passos do loader são: Checar se os dois primeiros bytes do arquivo são iguais à "MZ". Ir até o campo e_lfanew do DOS-Header (offset 0x3c) e ler a DWORD dentro dele, isto é, os 4 bytes deste campo. Pular para o offset lido e ver se ele é igual à "PE\0\0", ou seja, a assinatura PE. Notou alguma coisa? O campo e_lfanew fica dentro do DOS-Header e ele possui o offset para a assinatura PE. Caso ela não exista, o arquivo é considerado um "não PE", do contrário, o loader continua seu trabalho analisando os outros cabelhos. Obrigado pela pergunta e qualquer coisa só mandar bala. Abs.
  8. Opa, achei esse do tanenbaum um pouco complicado na época que li (não li todo no caso) . Tem um que é a mesma pegada, mas um pouco mais leve do Mario A. Monteiro chamado Arquitetura e Organização de Computadores. Eu não sei de muitos livros sobre o assunto, e se você me perguntar a maior referência eu diria que é o próprio manual da intel, mas eu não sei se é uma boa começar por ele, principalmente se você não tem um background de computação (não sei qual é o caso). E ah, estudar assembly, por exemplo, ajuda a entender MUITO sobre a arquitetura do seu computador 😀.
  9. Leandro Fróes

    Import REC

    Opa, por acaso você apagou os prints? Lembro de ter batido o olho neles. Pode postar de novo? 😃
  10. Opa, você diz interpretar um valor em hexa utilzando a linguagem C? Ou literalmente pegar um arquivo binário e tentar transformar em C?
  11. Leandro Fróes

    Import REC

    Fala @SiriusB. Cara eu não consegui entender muito bem, você poderia postar um print? No caso, só pra confirmar, você tem ctz que esse é o OEP né? Sobre fazer Engenharia Reversa no software X ou Y, sim, da pra fazer Engenharia Reversa no que você quiser, só não esqueça que nem sempre é permitido. 😉
  12. Leandro Fróes

    Curso de Ghidra

    O que é o Ghidra? É um framework para engenharia reversa de software composto por várias ferramentas e plugins, cada um desempenhando uma tarefa específica dentro da plataforma. O Ghidra ficou famoso e chamou atenção pelo fato de ser o primeiro de código aberto com funcionalidades muito parecidas com o IDA Pro, além de ter sido disponibilizado pela NSA. Como funciona? Em computação não existe mágica, tudo tem um motivo de ser e com Engenharia Reversa podemos chegar neste motivo. Ferramentas como disassemblers, descompiladores e analisadores de binários permitem um melhor entendimento sobre o que de fato acontece quando executamos algo. Seja para exploração de software, análise de malware ou simplesmente para aprender melhor sobre computação, a Engenharia Reversa é composta por várias etapas e frameworks facilitam muito o nosso dia a dia. O instrutor @Leandro Fróes trabalha com segurança da informação e tem interesse em Threat Hunting e em simplesmente entender como as coisas funcionam. 😎 Pré-requisitos Para um melhor aproveitamento, recomendados assistir ao Curso de Engenharia Reversa e ao Curso de Programação em C antes. Estes cursos cobrem o básico da linguagem C e Assembly, além de como a Engenharia Reversa de Software funciona. O treinamento O curso busca dar uma introdução e explorar o framework em si: como ele funciona, recursos mais importantes e como ele pode ajudar a tornar a Engenharia Reversa mais prática. Segue a lista das aulas já publicadas: Aula 00 - Instalação e apresentação Aula 01 - Iniciando seu projeto Aula 02 - Vendo o código em assembly Aula 03 - Convertendo seu programa para C puro Aula 04 - Analisando blocos mapeados em memória Aula 05 - Resolvendo o AnalyseMe01 Aula 06 - Auto Analyzer Aula 07 - Um pouco sobre a tabela de funções Aula 08 - Tipos de dados com o Data Type Manager
  13. Fala @sayseven blz? Cara, eu não tenho uma cópia do site não, mas se eu não me engano alguém por aqui tem, já tentou perguntar no nosso canal do discord? Eu lembro que o máximo que eu fiz foi imprimir alguns artigos da vovó Vicki 🙁
  14. Engenharia reversa em jogos não está nada distante da Engenharia Reversa utilizada em Análise de Malware, correção de bugs, etc, até porque os conceitos que ela envolve são os mesmo, não importa o local onde é aplicada. Falando em jogos, você conhece o Mega Drive? Sim, aquele console da Sega de 16 bits, lançado em 88 e com sucesso nos anos 90. Foi lançado em um blog uma espécie de CTF para o SEGA Genesis (nome popular para o Mega drive) que se resume à "apenas" um desafio: reverter o jogo criado pelo autor e quebrá-lo utilizando um emulador. O autor disponibilizará o código fonte daqui um tempo, mas até lá você pode mandar um e-mail e/ou twitter com sua resolução!! Se pararmos para pensar este desafio parte de uma abordagem ofensiva, mas será que além de burlar há uma maneira de defender este ou outro jogo? 🤖
  15. Go é uma linguagem de programação criada pela Google e lançada em código livre em novembro de 2009. Ela é uma linguagem compilada estaticamente, isto é, não depende do carregamento de nenhuma biblioteca. Deixando de lado as vantagens e desvantagens da compilação estática, podemos notar vantagens muito interessantes ao se programar em Go, como por exemplo: portabilidade, sintaxe enxuta e parecida com C e o fato de atingir patamares dos quais linguagens como python atingem, mas com uma linguagem compilada. A visibilidade da linguagem vem se tornando bem grande devido à ferramentas gigantescas sendo escritas em Go (docker, por exemplo) e isto atrai a atenção de qualquer um, inclusive os criadores de malware. Justamente por Go estar entrando no dia a dia de um profissional de segurança foi lançado um artigo introdutório que visa dar uma noção de como analisar executáveis em Go de uma forma simples e direta. Como profissionais de segurança devemos estar sempre abertos para novas abortagens e como lidar com elas, seja na programação em si ou na anáise. 😄
×
×
  • Create New...