Ir para conteúdo
  • Cadastre-se
  • Entre para seguir isso  
    Seguidores 0

    Artigos

    AndreAlves
    Um pouco depois das revelaçōes de Edward Snowden sobre monitoração generalizada da internet por entidades governamentais, a IETF (Internet Engineering Taskforce - uma comunidade de gente interessada na engenharia da internet) criou um grupo de trabalho para rever a privacidade do DNS e o nomeou "DPRIVE" - abreviação para DNS Privacy.
    Pensar em jeitos de tornar as resoluçōes deste protocolo tão fundamental menos manipuláveis e mais secretas sem perder muita velocidade é o abacaxi que foi dado a esse grupo, que tem trabalhado bastante e gerado alguns frutos.
    Mais recentemente um deles ficou mais conhecido entre nós quando a Cloudflare lançou um serviço de DNS focado em privacidade e rapidez e anunciou suporte a uma das propostas do IETF para DNS seguro-privado-rápido , o DOH (DNS over HTTPS), que dá nome à este artigo.
    A sacada do DOH é possibilitar queries (consultas) DNS criptografadas (tchau entidades governamentais tentando espionar 👻) que são difíceis de diferenciar de outros tráfegos criptofragados (tchau provedores tentando fazer bandwith throttling ou traffic shaping).
    Mas afinal, como isto funciona?
    Basicamente as queries DNS se tornam um request HTTP do tipo POST ou GET para uma URL definida pelo serviço de DNS. Essas requests são trafegadas dentro de uma sessão TLS e formatadas como JSONs codificados em base64. No JSON temos os campos definindo o tipo do registro a ser consultado (A, CNAME, AAA, etc).
    Para visualizar aqui vai um exemplo de solicitação de uma query para resolver o nome www.exemplo.com usando o método POST, tirado direto do rascunho da RFC:
    :method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-udpwireformat content-type = application/dns-udpwireformat content-length = 33 E o conteúdo de 33 bytes da query:
    00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 Não é lindo? Sim é. Mas se você quiser usar por enquanto terá que se aventurar. Um dos poucos (único?) navegadores que suporta este recurso é o Firefox em sua versão Nightly (sai um novo release toda noite!). Para configurar, os passos são:
    Digite about:config na barra de endereços e pressione [ENTER]. Altere o valor dos seguintes parâmetros de acordo: netowrk.trr.bootstrapAddress: 1.1.1.1 network.trr.uri: https://mozilla.cloudflare-dns.com/dns-query network.trr.mode: 2 (usa DOH primariamente, mas faz fallback pro DNS atual) Outros projetos utilizando DOH estão surgindo no Github. O DNS-over-HTTPS proxy, por exemplo, cria um proxy de modo que as consultas DNS sejam redirecionadas para o serviço do Google que suporta DOH.
    O mais legal é que a preocupação com privacidade e liberdade individual continuará a resultar em mais projetos como este para salvar nossa internet de quem se acha dono dela. 🙂
    Se você ficou interessado, dá uma pesquisada nos outros candidatos a DNS seguro:
    DNS over TLS (RFC 7858) DNS over DTLS (RFC 8094) DNS over QUIC (ID-draft) DNS over DNSCrypt (independente) DNS over TOR (independente)
    gzn
    Caro leitor, você gosta de desafios? Neste artigo vou contar como resolvi um desafio de engenharia reversa do Shellterlabs, mas sem usar um disassembly!
    Para quem não é acostumado com o termo, de acordo com o grupo CTF-BR!, um CTF (Capture The Flag) nada mais é do que uma competição que envolve diversas áreas mas principalmente as áreas ligadas à segurança da informação. No Papo Binário também há um vídeo sobre o assunto.
    O desafio em questão é o Shellter Hacking Express Acidentalmente. Em sua descrição, há a seguinte frase: Acidentalmente codificamos a chave.
    Isso não diz muita coisa mas ao baixar o binário, percebemos que há dois arquivos:
    tar tf ~/Downloads/e74a74b5-86cf-4cb3-a5bb-18a36ef067cf.tgz RevEng400/ RevEng400/encoder RevEng400/key.enc Usando o comando file, verifiquei de que tipo são os arquivos extraídos:
    cd RevEng400/ $ file * encoder: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, stripped key.enc: data Ao ver que o encoder é um binário ELF, fui direto analisar seu código num disassembler usando objdump e gdb, mas percebi que o binário não continha os símbolos, o que torna sua análise um pouco mais difícil.
    Sendo iniciante em engenharia reversa e depois de horas analisando a função de cifragem, confesso que fiquei sem saber para onde ir (já viu algum apressadinho tentando aprender a tocar guitarra? Pois é, já quer ir lá tocar aquele solo, e na velocidade Steve Vai, aí não dá né? rs) e desisti, mas não por muito tempo (ei crianças, nunca desistam dos seus sonhos viu! rs), e procurei o nosso querido prof. @Fernando Mercês lá no servidor do Discord, que me deu umas dicas. Segue trecho da conversa:
    > @fernandom @gzn sei que vc ta treinando ER, mas nem precisa disassemblar esse binario pra esse desafio nego > se vc olhar bem, vai ver que a saída do encoder tem o tamanho da string de entrada + o byte 0x03 no final > olhando a chave encodada (key.enc), é razoável admitir que ela tenha 16 caracteres então > você só precisa encontrar qual deles é o 0xef .. um loop com bash mata > supondo que seja o 'A'... então 'A' -> 0xef, aí você vai precisar da letra que gera o 0xf9 e assim sucessivamente, até chegar em 16 Já ouviu a expressão "pensar fora da caixa"? Pois é! Por que eu fui direto disassemblar? Esse é um dos problemas quando nós estamos começando: às vezes a gente acha que o método mais difícil deve ser o único ou o melhor para se resolver problemas, mas nem sempre é assim. Daí pensei: se o Mercês falou que não é muito difícil, vamos ao menos tentar não é?
    Bem, a primeira coisa que fiz foi ver uma maneira de imprimir o conteúdo do binário em hexadecimal. Para isso criei um pequeno script que usa o hexdump para me dar uma saída somente com os bytes em hexadecimal do parâmetro que receber. Chamei o script de hexdump.sh e depois dei permissão de execução nele (chmod +x). Seu conteúdo é o seguinte:
    #!/bin/sh hexdump -v -e '/1 "%02X "' $1 Então comecei os testes:
    for letra in 0 A a; do echo -n "$letra "; ./encoder $letra | ./hexdump.sh; echo; done 0 7F 01 A F7 02 a F7 03 Parece que nem sempre o final é 0x03... Bem, fui verificar o conteúdo do arquivo key.enc e encontrei isso:
    ./hexdump.sh < key.enc EF F9 42 09 A3 1A 43 F7 8C 8B BB 22 2A C2 A3 14 03  Pela lógica, já que essa é a chave codificada, se eu passar a chave correta original em texto como parâmetro para o binário encode ele terá que gerar a sequência acima. Seguindo a dica do Mercês, usei o próprio bash para tentar quebrar o desafio, primeiro mostrando o conteúdo em hexadecimal da chave codificada, depois iterando pelos caracteres possíveis e filtrando pelo primeiro byte dela:
    hexdump.sh < key.enc; echo for ((i=32;i<=126;i++)); do > l=$(printf "\x$(printf "%x" $i)") > echo -n "$l " > ./encoder "$l" | ./hexdump.sh > echo done | grep 'EF' Este código basicamente faz:
    Mostra os bytes em hexadecimal da chave a cada vez que executarmos esse comando (só pra saber qual byte é o próximo). Itera por todos caracteres imprimíveis da tabela ASCII (faixa de 32 à 126 em decimal). Imprime o caractere na tela sem a quebra de linha. Passa essa letra para como argumento para o binário encode e imprime a saída dele em hexadecimal. Por fim, usa o grep para encontrar uma combinação que tenha o próximo byte da chave. Partindo para um exemplo prático, fui tentar encontrar a primeira letra dessa chave, sabendo que sua versão codificada deve resultar no byte 0xEF:
    ./hexdump.sh < key.enc; echo EF F9 42 09 A3 1A 43 F7 8C 8B BB 22 2A C2 A3 14 03  for ((i=32;i<=126;i++)); do > caractere=$(printf "\x$(printf "%x" $i)") > echo -n "$caractere ";./encoder "$l" | ./hexdump > echo done | grep 'EF' " EF 01  B EF 02  b EF 03 Conforme pode ver acima, encontrei três caracteres diferentes que, quando encodados pelo encoder, geram o byte 0xEF: ", B, e b. Escolhi seguir com o B, prefixando-o na chave para dar sequência ao script e ver se encontramos o caractere que resulta no próximo byte da chave codificada (0xF9):
    ./hexdump.sh < key.enc; echo EF F9 42 09 A3 1A 43 F7 8C 8B BB 22 2A C2 A3 14 03  for ((i=32;i<=126;i++)); do > caractere=$(printf "\x$(printf "%x" $i)") > echo -n "B${caractere} " > ./encoder "B$l" | ./hexdump > echo done | grep 'EF F9' % EF F9 01  E EF F9 02  e EF F9 03  Mais uma vez encontrei três opções. Foi só continuar este processo até encontrar a chave que gera os exatos 16 bytes do arquivo key.enc.
    Aproveitei e automatizei um brute forcer com Python:
    #!/usr/bin/env python3 # -*- coding: utf-8 -*- import subprocess def encode(arg): result = subprocess.run(['./encoder', arg], stdout=subprocess.PIPE) return result.stdout def loadKey(): key_enc = [] with open('./key.enc', 'rb') as file: while True: byte = file.read(1) if byte: # a ordem dos bytes aqui não importa (porque trata-se apenas de 1 byte), mas é necessário especificar key_enc.append(int.from_bytes(byte, byteorder='little')) else: break return key_enc def permutations(key='', key_enc=loadKey(), key_i=0): if key_i == len(key_enc) - 1: print(key) return for char in (chr(i) for i in range(32, 127)): result = encode(key + char) if result[key_i] == key_enc[key_i] and key_i < len(key_enc): permutations(key=key + char, key_enc=key_enc, key_i=key_i + 1) def main(): permutations() if __name__ == "__main__": main() Saída codificada em base64 (pra não estragar a brincadeira de quem vai tentar resolver o desafio por conta própria):
    QmV3aXRjaGluZyBTZXh0LwpCZXdpdGNoaW5nIFNleHRPCkJld2l0Y2hpbmcgU2V4dG8K Segue vídeo do canal com a explicação do algortimo de encoding desse desafio: 
     
    Fernando Mercês
    Você gosta de software de código aberto? Gosta quando encontra um programa bem feito, que atende a sua necessidade, sem custo, é atualizado, os desenvolvedores colocam novos recursos, você pode até opinar, sugerir mudanças e várias são aceitas? Saiba que por trás destes milhares de programas livres há um mundo de pessoas que dedicam seu tempo (muitas vezes seu tempo livre) para entregar software de qualidade pra você sem nem te conhecer. Isso é muito louvável. Agora mesmo estou usando o WordPress para escrever este artigo, um software de código aberto. Não paguei nada por ele e ainda modifico da maneira que eu quiser, respeitando sua licença. Não é fantástico isso? Para este artigo motivei-me dos vários programas de código aberto que já vi nascerem e morrerem por falta de apoio, então resolvi escrever um manual de como ajudar a manter os programas que você gosta no ar. Preparado?
    O primeiro passo é entender o que é de código aberto (ou open source). Eu poderia tentar explicar com minhas palavras, mas há um vídeo que literalmente desenhou e explicou com LEGO. Incrível, não? E com legendas em Português do Brasil. Por favor assista, mesmo que você pense que já saiba o que é:

    Se você usa algum software de código aberto (e eu tenho certeza que sim), você pode ajudar com:
    Tradução - Nem todo mundo fala inglês no mundo. É importante que um software socialmente viável seja acessível e você pode contribuir com isso ajudando a traduzir as novas versões para sua língua nativa.
    Divulgação
    - Publicar no seu site, seu Twitter, Facebook ou qualquer outra rede social sobre sua experiência com o software, estimulando outras pessoas a o utilizarem.
    Reconhecimento
    - Enviar um e-mail de agradecimento aos desenvolvedores.
    - Publicar na sua rede social, ou na dos desenvolvedores (se houver) um depoimento sobre sua experiência com o software.
    - Se o software está no Github e você tem uma conta de usuário lá, é só ir na página dele e começar a segui-lo (follow) e dar uma estrelinha (star) também.
    - Se o software está no SourceForge você pode dar uma estrelinha (star), avaliar o software (rating) e também dar seu comentário (user reviews).
    Preferência
    - Mesmo que haja um software proprietário equivalente, estimular o uso de software de código aberto é muito importante. Ele é socialmente mais justo e depois de ver o vídeo do item 1 você já deve saber o motivo.
    Documentação
    - Se você já domina algum recurso do software, é legal escrever algo no seu blog ou gravar um vídeo no YouTube ensinando outras pessoas a fazê-lo. Isso faz com que mais e mais usuários sejam beneficiados e aumenta as chances de adesão do software em questão.
    - Ajudar a escrever a documentação oficial do software, coisa que te faz aprender muito e toma muito tempo dos desenvolvedores. Tempo este que eles poderiam dedicar a corrigir problemas e adicionar novos recursos. Só depende de você.
    Suporte
    - Se cadastrar nos fórums e listas de discussão sobre o software para ajudar outros usuários te faz estudar muito, ajudar muito e contribuir muito com o ecossistema que mantém o software vivo!
    Código
    - Claro que se você conhecer a linguagem de programação utilizada no software você pode – e deve – contribuir via código. Só tome cuidado com o egocentrismo aqui. Não é porque você fez um patch que ele tem que ser aceito. O software de código aberto é democrático e não serve pra você tentar provar pra ninguém que é bom. Basta querer ajudar e atender ao pedido de todos, não do seu ego.
    - Se você é programador e costuma desenvolver software freeware por exemplo, considera transformar em código aberto. Ele vai crescer muito mais e ter muito mais adeptos. Você pode se espantar com o tamanho que o projeto pode assumir quando se tem a colaboração da comunidade open source.
    Reportar problemas
    - Se você acreditar que encontrou um problema no software (bug), avise aos desenvolvedores. Normalmente isso é feito por um sistema de bug tracking ou issue tracking. Com certeza no site do desenvolvedor você terá mais informações sobre como fazê-lo. Pode ser que te peçam logs e outras informações para que eles possam reproduzir o erro e corrigir, mas vale a pena continuar e ir até o fim. Você vai ajudar muita gente no final.
    Doações
    - Muitas equipes que desenvolvem software de código aberto precisam de dinheiro para comprarem hardware, aluguel de  infraestrutura ou mesmo para promoverem eventos entre os desenvolvedores para alinharem o futuro do software. Doando você pode ajudar nisso. Se você tiver condições, apoie.
    Se informar
    - Empresas como Microsoft, Apple, Red Hat, dentre outras são grandes contribuidoras com projetos de código aberto, inclusive com o Linux.
    - Software livre e software de código aberto são diferentes. O primeiro movimento é criado pelo Richard Stallman, que explica as diferenças aqui.
    Essa lista não é definitiva e naturalmente deve haver várias outras formas de ajudar, mas escolhi escrever sobre as mais simples, que estão somente há alguns cliques de distância de você.
    Nos anos que venho dedicando a apoiar os projetos de código aberto, inclusive criando alguns, fiquei muito surpreso com as colaborações que meus projetos receberam e também tive a oportunidade de contribuir com muitos outros. Isso significa ajuda efetiva para pessoas e projetos. De verdade. As empresas também gostam disso (afinal são pessoas que trabalham nelas né!?) e várias propostas de emprego já surgiram através do Github. Não fica de fora dessa. O mundo open source precisa de você. E as pessoas também.
    Fernando Mercês
    É raro termos um artigo não técnico aqui no Mente Binária, mas este tema merece, creio. A proposta aqui é criarmos uma lista de filmes, séries e documentários que envolvam especificamente o tema informática (não vale tecnologia em geral, pois do contrário a lista ficaria gigante!) organizados por ano de lançamento. Preparado? Então pega a pipoca!
    2017
    Ghost in the Shell (A Vigilante do Amanhã: Ghost in the Shell) 2016
    Hackers Hacker (Anonymous) Cyberwar ZeroDays 2015
    Terminal F/Chasing Edward Snowden (Snowdens store flugt) Mr. Robot Hacker's Game Deep Web Blackhat (Hacker) 2014
    Who Am I - Invasores: Nenhum Sistema Está Salvo The Internet's Own Boy: The Story of Aaron Swartz (O Menino da Internet: A História de Aaron Swartz) The Hackers Wars Citizenfour Algorithm Sillicon Valley Halt and Catch Fire 2013
    We Steal Secrets: The Story of WikiLeaks Terms and Conditions May Apply TPB AFK: The Pirate Bay Away from Keyboard Her (Ela) Downloaded DEFCON 2012
    We Are Legion: The Story of the Hacktivists 2011
    Black Mirror 2010
    Tron: Legacy (Tron: O Legado) 2008
    Hackers Are People Too 2007
    Live Free or Die Hard (Duro de Matar 4.0) 2006
    Steal This Film 2005
    Hard Candy (Menina Má.Com) 2001
    The Code Revolution OS Antitrust (Ameaça Virtual) Artificial Intelligence: AI (A.I.: Inteligência Artificial) 2000
    Takedown (Caçada Virtual) 1999
    The Matrix (Matrix) Pirates of Silicon Valley (Piratas da Informática: Piratas do Vale do Silício) 1996
    Lawnmower Man 2: Beyond Cyberspace (O Passageiro do Futuro 2) 1995
    Ghost in the Shell (O Fantasma do Futuro) The Net (A Rede) Johnny Mnemonic (Johnny Mnemonic: O Cyborg do Futuro) Hackers - Piratas de Computador 1992
    The Lawnmower Man (O Passageiro do Futuro) 1984
    Triumph of The Nerds Hackers: Wizards of the Electronic Age 1983
    Wargames 1982
    Tron (Tron: Uma Odisséia Eletrônica) Esqueci de algum? Sugere aí nos comentários que adiciono! No canal Papo Binário já falei sobre algum destes títulos também. 🙂
    Fernando Mercês
    Desde 2013 que estamos trabalhando duro numa nova versão do pev, nosso toolkit para análise de binários PE (Portable Executable), o formato utilizado pelos executáveis (EXE, DLL, OCX, etc) do Windows.
    O pev é um projeto em que me sinto muito feliz de fazer parte e o principal motivo é que existe algo de muito forte e especial nele: colaboração.  Quase 30 pessoas contribuíram com o projeto de alguma forma (código, testes, empacotamento, etc) e hoje ele está presente nos repositórios das principais distribuições Linux, inclusive as focadas em segurança de alguma forma.
    Outro ponto importante é que ele começou como um projeto de faculdade lá em 2010, junto com outros alunos. Como a faculdade nem laboratório de pesquisa tinha, fizemos o nosso próprio grupo, batizado de Coding 40°, em homenagem ao calor da nossa cidade.
    O projeto atraiu muitos colaboradores, incluindo um que já commitou mais que eu no repositório e redefiniu, de forma muito profissional, toda a infraestrutura por trás do pev e da libpe. Foi o Jardel Weyrich. Sério, dá pra detectar que um projeto teve sucesso quando aparece alguém que já contribuiu com mais código para ele do que você!
    Por último, mas não menos importante: o pev é livre. E na boa, até agradeço as centenas de programadores que fizeram analisadores de PE proprietários, porque me motivaram a iniciar o pev. Era preciso um analisador de binários PE de código aberto, que permitisse estudantes e curiosos entender como um PE é parseado, que campos são importantes, por que a análise estática é tão poderosa, etc. Hoje, mesmo com todos os bugs que ainda hão de surgir (fora os que já surgiram e ainda não conseguimos corrigir!).
    Quero agradecer, de forma permanente, a todos que se envolvem ou se envolveram de alguma forma com o pev: usando, avisando-nos sobre bugs, contribuindo com código, ideias, testes, tudo importa! Obrigado, de coração.
    Emoções à parte, vamos partir para a análise de binários e falar das novidades do pev 0.80, lançado hoje!
    Acontece que um binário PE pode esconder muitas informações importantes antes mesmo de ser executado. Por exemplo, com a ferramenta readpe, do pev, você vai descobrir que um executável PE é dividido em cabeçalhos e seções e eles armazenam várias informações interessantes, por exemplo:
    $ readpe arquivo.exe DOS Header Magic number: 0x5a4d (MZ) Bytes in last page: 144 Pages in file: 3 Relocations: 0 Size of header in paragraphs: 4 Minimum extra paragraphs: 0 Maximum extra paragraphs: 65535 Initial (relative) SS value: 0 Initial SP value: 0xb8 Initial IP value: 0 Initial (relative) CS value: 0 Address of relocation table: 0x40 Overlay number: 0 OEM identifier: 0 OEM information: 0 PE header offset: 0x80 COFF/File header Machine: 0x14c IMAGE_FILE_MACHINE_I386 Number of sections: 3 Date/time stamp: 1425562907 (Thu, 05 Mar 2015 13:41:47 UTC) Symbol Table offset: 0 Number of symbols: 0 Size of optional header: 0xe0 Characteristics: 0x102 Characteristics names IMAGE_FILE_EXECUTABLE_IMAGE IMAGE_FILE_32BIT_MACHINE Optional/Image header Magic number: 0x10b (PE32) Linker major version: 11 Linker minor version: 0 Size of .text section: 0x2a800 Size of .data section: 0x3400 Size of .bss section: 0 Entrypoint: 0x2c78e Address of .text section: 0x2000 Address of .data section: 0x2e000 ImageBase: 0x400000 Alignment of sections: 0x2000 Alignment factor: 0x200 Major version of required OS: 4 Minor version of required OS: 0 Major version of image: 0 Minor version of image: 0 Major version of subsystem: 4 Minor version of subsystem: 0 Size of image: 0x34000 Size of headers: 0x200 Checksum: 0 Subsystem required: 0x2 (IMAGE_SUBSYSTEM_WINDOWS_GUI) DLL characteristics: 0x8540 DLL characteristics names IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE IMAGE_DLLCHARACTERISTICS_NX_COMPAT IMAGE_DLLCHARACTERISTICS_NO_SEH IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE Size of stack to reserve: 0x100000 Size of stack to commit: 0x1000 Size of heap space to reserve: 0x100000 Size of heap space to commit: 0x1000 Data directories Directory IMAGE_DIRECTORY_ENTRY_IMPORT: 0x2c738 (83 bytes) Directory IMAGE_DIRECTORY_ENTRY_RESOURCE: 0x2e000 (12728 bytes) Directory IMAGE_DIRECTORY_ENTRY_BASERELOC: 0x32000 (12 bytes) Directory IMAGE_DIRECTORY_ENTRY_IAT: 0x2000 (8 bytes) Directory IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR: 0x2008 (72 bytes) Imported functions Library Name: mscoree.dll Functions Function Name: _CorExeMain export directory not found Sections Section Name: .text Virtual Address: 0x2000 Physical Address: 0x2a794 Size: 0x2a800 (174080 bytes) Pointer To Data: 0x200 Relocations: 0 Characteristics: 0x60000020 Characteristic Names IMAGE_SCN_CNT_CODE IMAGE_SCN_MEM_EXECUTE IMAGE_SCN_MEM_READ Section Name: .rsrc Virtual Address: 0x2e000 Physical Address: 0x31b8 Size: 0x3200 (12800 bytes) Pointer To Data: 0x2aa00 Relocations: 0 Characteristics: 0x40000040 Characteristic Names IMAGE_SCN_CNT_INITIALIZED_DATA IMAGE_SCN_MEM_READ Section Name: .reloc Virtual Address: 0x32000 Physical Address: 0xc Size: 0x200 (512 bytes) Pointer To Data: 0x2dc00 Relocations: 0 Characteristics: 0x42000040 Characteristic Names IMAGE_SCN_CNT_INITIALIZED_DATA IMAGE_SCN_MEM_DISCARDABLE IMAGE_SCN_MEM_READ Só olhando para este cabeçalho, já dá pra dizer muita coisa sobre esse binário. Por exemplo, é possível inferir que ele foi compilado em 5 de março de 2015, é um executável de janelas (GUI – Graphical User Interface) e na Import Table dele tem apenas uma entrada, uma função chamada _CorExeMain importada da biblioteca mscoree.dll. Isso já dá a dica que esse é binário foi compilado em .NET. Como eu sei disso? É que eu já vi vários binários em .NET e todos eles importam somente essa função. Não se preocupe, com o tempo você também pega os macetes!
    Claro que, para estudar os binários de forma eficiente é legal ler também outros tutoriais sobre o assunto. O que mais gosto em Português é O formato PE, da Vovó Vicky, isso mesmo, uma simpática senhora, médica, do Sul do país que adora arquivos PE. ❤️
    Voltando ao nosso binário, vamos dar uma olhada nas strings presentes nele com o pestr:
    $ pestr -so arquivo.exe 0x2d81e .rsrc FileDescription 0x2d840 .rsrc Gynx 0x2d852 .rsrc FileVersion 0x2d86c .rsrc 1.0.0.0 0x2d882 .rsrc InternalName 0x2d89c .rsrc Gynx.exe 0x2d8b6 .rsrc LegalCopyright 0x2d8d4 .rsrc Copyright 0x2d8ea .rsrc 2015 0x2d8fe .rsrc OriginalFilename A lista de strings completa é bem maior, mas eu cortei só para mostrar algumas.
    Primeira pergunta que pode surgir aqui é: por que fizemos um programa pestr se já existe o programa strings? Bem, você pode notar pela saída que dizemos muito mais que a string (texto) em si. Sabemos em que seção ela está e o offset (posição) no arquivo. Além disso, o pestr imprime strings ASCII e Unicode.
    No meio das strings tem outra informação de data, que reforça o ano da data de compilação. Tem também o nome original do arquivo (quando o programador compilou). Se você pesquisar no Google pelo nome do arquivo, já vai encontrar muita coisa!
    Continuando nossa análise, vamos ver com o pescan se tem algo estranho neste arquivo:
    $ pescan -v ~/dotnet file entropy: 5.252392 (normal) fpu anti-disassembly: no imagebase: normal - 0x400000 entrypoint: normal - va: 0x2c78e - raw: 0x2a98e DOS stub: normal TLS directory: not found timestamp: normal - Thu, 05 Mar 2015 13:41:47 UTC section count: 3 sections section .text: normal section .rsrc: normal section .reloc: small length A baixa entropia sugere que o binário não está comprimido (packed) e tudo parece estar normal. Isso significa que o binário não está protegido, não que seu código não seja malicioso.
    Agora, já entrando nos novos recursos, que tal saber os hashes deste arquivo? Buscando por eles no Google também é possível encontrar algumas informações. Ao invés de calcular um por um, utilizando vários programas, o pev conta com o pehash, que faz tudo pra você:
    $ pehash -a arquivo.exe file filepath: /home/user/arquivo.exe md5: 1f4c40ff46297bdc5a595cd574e0db64 sha1: 2bc6fa6558988d628dd4b95d0741405685c1c232 sha256: b823a04f49463e410c9f823baade182eb283ba073b40c6d8cc443a570a9a1df6 ssdeep: 3072:yLYmWbfXGKJy7DFR9KwHS+MASjB5jL0S9Q0VwuUcu:AYmWbfX3y7DFR9KwHS+MAS/js0VhU imphash: f34d5f2d4577ed6d9ceec516c1f5a744 headers header header_name: IMAGE_DOS_HEADER md5: 919f1c12cf0d1cd93d7f1077f13ac374 sha1: 3d43712e5606b4640b85f5f0e25e9db8ed552074 sha256: c46a3fc444808f3b86a7e757e5202d16f8ea9bf1c6aff2cabc593e7d0f2c9ad2 ssdeep: 3:WlWUqt/vllnln:idqP header header_name: IMAGE_COFF_HEADER md5: 15174f39bbe557d104f169053af5c7a2 sha1: 21f9311fa5e1a7c8724c657db39ef2fbb1b896ce sha256: 7430166bd1b2d5c400f2f5fb60c90393b50388b97e877aa7cf0c3057a413a85f ssdeep: 3:HHJl/fkn:HHJlkn header header_name: IMAGE_OPTIONAL_HEADER md5: 3b079fa2a88b6901db907bc47dee2d67 sha1: 21c1c517743170c94d1ade608ff7d2746fd7e3ea sha256: 0fec7657e9361e8262af5872bf3784a7647b6978f3d0e35a419d2f410c8654a0 ssdeep: 3:6FZ//llAlFlllXNB//llrllel/dglPt1l9tllH:pfGwlN sections section section_name: .text md5: 973d11759194c14071aa6963de8f55c7 sha1: 1934e0085c8776e3243bf658e95b8943d4f91bc9 sha256: e68349bfcb04b20c11973ce27770570ebb22c8c7750133d073f15f7ec9eeda38 ssdeep: 3072:XLYmWbfXGKJy7DFR9KwHS+MASjB5jL0S9Q0VwuUc:bYmWbfX3y7DFR9KwHS+MAS/js0VhU section section_name: .rsrc md5: 9d498bee08b1cf075d8aca022f1e16e9 sha1: f938a8c23185b023bb5dd12082013c2a628bc0d3 sha256: eb7454309df90fea2d01c887b0040e8237353919efc06a7081a7abb15091283a ssdeep: 24:3A5t/ug9GXBEiViKZWIDDOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO:weg90VWIDZ6Kp+l4BhDqFWSfbNtm section section_name: .reloc md5: 37ab911460a0b274ffa9f4e388ec933b sha1: 7c9eac3b843c9a7ab8ef08aac5c14e4c51b2c703 sha256: fb50df3b064d126999295b35f1a151f8fbe7e3593e306a9255a534999843f5b2 ssdeep: 3:LlQl:S Achou que teria os hashes do arquivo somente? Pois é, o pev surpreende mesmo! O pehash calcula MD5, SHA1, SHA-256 e ssdeep (uma técnica de fuzzy hash que vale a pena pesquisar sobre!) para cada cabeçalho e seção. Além disso, a partir das funções importadas do binário o pehash calcula o imphash, que já expliquei no artigo Entendendo o imphash.
    Tanto o imphash quanto o ssdeep podem ser utilizados, de maneiras diferentes, para saber se um arquivo é parecido com outro, se são variantes do mesmo código-fonte, mas neste caso o imphash não ajuda por ser um binário .NET (todos eles importam aquela mesma função única que comentei acima).
    Também é possível, com o peres (criação do Marcelo Fleury),  extrair os recursos e checar, por exemplo, o manifesto em XML dos arquivo:
    $ peres -x arquivo.exe Save On: resources/icons/2.ico Save On: resources/icons/3.ico Save On: resources/icons/4.ico Save On: resources/icons/5.ico Save On: resources/icons/6.ico Save On: resources/icons/7.ico Save On: resources/icons/8.ico Save On: resources/groupicons/32512.ico Save On: resources/versions/1.rc Save On: resources/manifests/1.xml $ cat resources/manifests/1.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3"> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly> O ícone utilizado também é extraído (groupicons) mas ele é quebrado em várias imagens (icons) e precisam ser reconstruídos se você precisar do ícone original do arquivo. De qualquer forma, você pode calcular o hash deles e comparar com os dos ícones de outros arquivos, se for essa a intenção.
    Uma outra novidade é o programa cpload, para analisar arquivos .cpl (Control Panel Applets). Ele é presente somente na versão do pev para Windows, pois serve para analisar binários dinamicamente. Este formato é um pouco diferente do EXE convencional (na verdade um CPL é uma “DLL que executa com dois cliques”). Na época o formato desses arquivos era muito pouco conhecido e até escrevi um artigo para a Wikipédia em Português sobre. Com o cpload, é possível enviar para a função presente no arquivo .cpl todas as mensagens que ela deve reconhecer. Assim o analista pode ver qual delas dispara o código. No exemplo abaixo, a mensagem CPL_DBLCLK (clique duplo) foi enviada para um .cpl presente no Windows chamado joy.cpl. Veja que o programa executa e mostra uma janela:

    Adicionalmente, se você fizer isso no contexto de um debugger, passando os argumentos como na imagem abaixo:

    O cpload força um software breakpoint antes do carregamento do arquivo .cpl pela função LoadLibrary() e antes da entrada na CPLApplet(), que é a função principal de um arquivo .cpl, o que permite ao analista enxergar o trecho exato de código dele, sem precisar debugar processos do sistema como o rundll32.exe.

    E ainda sobre o pev, os plugins de formato de saída estão dando um show (ideia do Jan Seidl e portada para plugins pelo Jardel). Olha só como fica a saída se você pedir ao pedis, nosso disassembler, para disassemblar o entrypoint  de um binário PE em JSON:
    $ pedis --format json --entrypoint PUTTY.EXE { "54eb0": "6a 60 push 0x60", "54eb2": "68 70 7b 47 00 push 0x477b70", "54eb7": "e8 08 21 00 00 call 0x456fc4", "54ebc": "bf 94 00 00 00 mov edi, 0x94", "54ec1": "8b c7 mov eax, edi", "54ec3": "e8 b8 fa ff ff call 0x454980", "54ec8": "89 65 e8 mov [ebp-0x18], esp", "54ecb": "8b f4 mov esi, esp", "54ecd": "89 3e mov [esi], edi", "54ecf": "56 push esi", "54ed0": "ff 15 e0 d2 45 00 call dword [0x45d2e0]", "54ed6": "8b 4e 10 mov ecx, [esi+0x10]", "54ed9": "89 0d 48 e1 47 00 mov [0x47e148], ecx", "54edf": "8b 46 04 mov eax, [esi+0x4]", "54ee2": "a3 54 e1 47 00 mov [0x47e154], eax", "54ee7": "8b 56 08 mov edx, [esi+0x8]", "54eea": "89 15 58 e1 47 00 mov [0x47e158], edx", "54ef0": "8b 76 0c mov esi, [esi+0xc]", "54ef3": "81 e6 ff 7f 00 00 and esi, 0x7fff", "54ef9": "89 35 4c e1 47 00 mov [0x47e14c], esi", "54eff": "83 f9 02 cmp ecx, 0x2", "54f02": "74 0c jz 0x454f10", "54f04": "81 ce 00 80 00 00 or esi, 0x8000", "54f0a": "89 35 4c e1 47 00 mov [0x47e14c], esi", "54f10": "c1 e0 08 shl eax, 0x8", "54f13": "03 c2 add eax, edx", "54f15": "a3 50 e1 47 00 mov [0x47e150], eax", "54f1a": "33 f6 xor esi, esi", "54f1c": "56 push esi", "54f1d": "8b 3d d8 d2 45 00 mov edi, [0x45d2d8]", "54f23": "ff d7 call edi0x454f25", "54f25": "66 81 38 4d 5a cmp word [eax], 0x5a4d", "54f2a": "75 1f jnz 0x454f4b", "54f2c": "8b 48 3c mov ecx, [eax+0x3c]", "54f2f": "03 c8 add ecx, eax", "54f31": "81 39 50 45 00 00 cmp dword [ecx], 0x4550", "54f37": "75 12 jnz 0x454f4b", "54f39": "0f b7 41 18 movzx eax, word [ecx+0x18]", "54f3d": "3d 0b 01 00 00 cmp eax, 0x10b", "54f42": "74 1f jz 0x454f63", "54f44": "3d 0b 02 00 00 cmp eax, 0x20b", "54f49": "74 05 jz 0x454f50", "54f4b": "89 75 e4 mov [ebp-0x1c], esi", "54f4e": "eb 27 jmp 0x454f77", "54f50": "83 b9 84 00 00 00 0e cmp dword [ecx+0x84], 0xe", "54f57": "76 f2 jbe 0x45504b", "54f59": "33 c0 xor eax, eax", "54f5b": "39 b1 f8 00 00 00 cmp [ecx+0xf8], esi", "54f61": "eb 0e jmp 0x454f71", "54f63": "83 79 74 0e cmp dword [ecx+0x74], 0xe", "54f67": "76 e2 jbe 0x45504b", "54f69": "33 c0 xor eax, eax", "54f6b": "39 b1 e8 00 00 00 cmp [ecx+0xe8], esi", "54f71": "0f 95 c0 setnz al", "54f74": "89 45 e4 mov [ebp-0x1c], eax", "54f77": "56 push esi", "54f78": "e8 b4 28 00 00 call 0x457831", "54f7d": "59 pop ecx", "54f7e": "85 c0 test eax, eax", "54f80": "75 21 jnz 0x454fa3", "54f82": "83 3d 94 e1 47 00 01 cmp dword [0x47e194], 0x1", "54f89": "75 05 jnz 0x454f90", "54f8b": "e8 56 44 00 00 call 0x4593e6", "54f90": "6a 1c push 0x1c", "54f92": "e8 d8 42 00 00 call 0x45926f", "54f97": "68 ff 00 00 00 push 0xff", "54f9c": "e8 be fb ff ff call 0x454b5f", "54fa1": "59 pop ecx", "54fa2": "59 pop ecx", "54fa3": "e8 65 47 00 00 call 0x45970d", "54fa8": "89 75 fc mov [ebp-0x4], esi", "54fab": "e8 e9 25 00 00 call 0x457599", "54fb0": "85 c0 test eax, eax", "54fb2": "7d 08 jge 0x454fbc", "54fb4": "6a 1b push 0x1b", "54fb6": "e8 d0 fe ff ff call 0x454e8b", "54fbb": "59 pop ecx", "54fbc": "ff 15 a8 d1 45 00 call dword [0x45d1a8]", "54fc2": "a3 00 e9 47 00 mov [0x47e900], eax", "54fc7": "e8 af 4d 00 00 call 0x459d7b", "54fcc": "a3 8c e1 47 00 mov [0x47e18c], eax", "54fd1": "e8 03 4d 00 00 call 0x459cd9", "54fd6": "85 c0 test eax, eax", "54fd8": "7d 08 jge 0x454fe2", "54fda": "6a 08 push 0x8", "54fdc": "e8 aa fe ff ff call 0x454e8b", "54fe1": "59 pop ecx", "54fe2": "e8 bf 4a 00 00 call 0x459aa6", "54fe7": "85 c0 test eax, eax", "54fe9": "7d 08 jge 0x454ff3", "54feb": "6a 09 push 0x9", "54fed": "e8 99 fe ff ff call 0x454e8b", "54ff2": "59 pop ecx", "54ff3": "6a 01 push 0x1", "54ff5": "e8 95 fb ff ff call 0x454b8f", "54ffa": "59 pop ecx", "54ffb": "89 45 d8 mov [ebp-0x28], eax", "54ffe": "3b c6 cmp eax, esi", "55000": "74 07 jz 0x455009", "55002": "50 push eax", "55003": "e8 83 fe ff ff call 0x454e8b", "55008": "59 pop ecx", "55009": "89 75 bc mov [ebp-0x44], esi", "5500c": "8d 45 90 lea eax, [ebp-0x70]", "5500f": "50 push eax", "55010": "ff 15 ac d1 45 00 call dword [0x45d1ac]", "55016": "e8 2e 4a 00 00 call 0x459a49", "5501b": "89 45 e0 mov [ebp-0x20], eax", "5501e": "f6 45 bc 01 test byte [ebp-0x44], 0x1", "55022": "74 06 jz 0x45502a", "55024": "0f b7 45 c0 movzx eax, word [ebp-0x40]", "55028": "eb 03 jmp 0x45502d", "5502a": "6a 0a push 0xa", "5502c": "58 pop eax", "5502d": "50 push eax", "5502e": "ff 75 e0 push dword [ebp-0x20]", "55031": "56 push esi", "55032": "56 push esi", "55033": "ff d7 call edi0x455035", "55035": "50 push eax", "55036": "e8 93 3b ff ff call 0x448bce", "5503b": "8b f8 mov edi, eax", "5503d": "89 7d d4 mov [ebp-0x2c], edi", "55040": "39 75 e4 cmp [ebp-0x1c], esi", "55043": "75 06 jnz 0x45504b", "55045": "57 push edi", "55046": "e8 6f fc ff ff call 0x454cba", "5504b": "e8 8c fc ff ff call 0x454cdc", "55050": "eb 2b jmp 0x45507d", "55052": "8b 45 ec mov eax, [ebp-0x14]", "55055": "8b 08 mov ecx, [eax]", "55057": "8b 09 mov ecx, [ecx]", "55059": "89 4d dc mov [ebp-0x24], ecx", "5505c": "50 push eax", "5505d": "51 push ecx", "5505e": "e8 75 48 00 00 call 0x4598d8", "55063": "59 pop ecx", "55064": "59 pop ecx", "55065": "c3 ret" Os formatos de saída suportados por todos os programas do toolkit incluem JSON, XML, CSV e o padrão, texto. Assim o pev se faz útil para quem quer automatizar o processo de análise estática de binários PE, para salvar em um banco de dados para consulta posterior, por exemplo.
    A documentação para a versão 0.80 está pronta e recomendo fortemente que você a leia se quiser aproveitar o máximo do toolkit. O changelog completo também está disponível. Despeço-me com a certeza de que fizemos um bom trabalho e de que o software livre é viável, funciona e é, principalmente, algo prazeroso de se manter, que pode ajudar pessoas e empresas a atingirem seus objetivos, sem custo.
    Confere lá: https://github.com/merces/pev
    Fernando Mercês

    eXaminando dados

    Por Fernando Mercês, em Artigos,

    No dia-a-dia da programação, análise de binários e outras áreas relacionadas à segurança da informação é comum profissionais precisarem de conversões rápidas de dados, normalmente números e strings. Muitas vezes recorremos a sites, scripts, programas gráficos, calculadores e outros, mas como nos sentimos mais confortáveis na linha de comando, foi lá que decidi fazer algo.
    Há alguns anos iniciei um projeto que chamei de bashacks, que é um conjunto de funções em bash para as mais variadas tarefas, mas percebi que muitas vezes não sei que tipo de informação estou tratando e gostaria de ver rapidamente diversas conversões para um certo tipo de dado (um número por exemplo), para ver qual deles faz mais sentido. Foi aí que pensei em criar o eXamine, cujo nome veio do comando homônimo do gdb (GNU Debugger). Trata-se de um software de linha de comando para o que chamo de conversão indiscriminada e irresponsável de dados.
    Para ficar ainda mais enxuto, e também roubando a ideia do gdb, eu o chamo de x. Então supondo que você na sua análise você tenha encontrado um número hexadecimal, por exemplo, 0x585ca92c e deseja ver as conversões possíveis para ele. É só mandar pro x:
    $ echo 0x585ca92c | x Hex string: 30783538356361393263 Byte array: \x30\x78\x35\x38\x35\x63\x61\x39\x32\x63 URL encoding: %30%78%35%38%35%63%61%39%32%63 ROT13: 0k585pn92p Signed int: 1482467628 Unsigned int: 1482467628 Float: 9.70477e+14 Hexadecimal: 0x585ca92c Octal: 013027124454 Binary: 0b1011000010111001010100100101100 IPv4: 88.92.169.44 Timestamp: Fri, 23 Dec 2016 04:33:48 UTC/GMT-0 O jeito correto de interpretar a saída do eXamine é: se a entrada for tratada como x, então é y, ou seja, no exemplo, se o número for tratado como string (texto), então os bytes em hexadecimal equivalente são 30 78 35 38 35 63 61 39 32 e 63. Já se for tratado como número, então a conversão para inteiro fica 1482467628. Ainda tratando como número, pode ser o endereço IPv4 88.92.169.44 ou a data/hora de hoje. Qual é o certo? A resposta é: depende de como você quer tratar. Vê o que faz mais sentido pra sua análise e vai na fé.
    Sabemos que bytes são bytes e como serão usados depende da interpretação dada. 0x41 pode ser utilizado num programa como um inteiro de 8 bits, ou como parte de um inteiro de 16, 32 ou 64-bits, ou mesmo como o caractere ‘A’ (depende de como o programa usa essa informação). O eXamine não te ajuda nisso, mas imprime como saída algumas conversões possíveis e deixa você decidir.
    Por exemplo, você pode passar uma string para ele:
    $ echo 'feliz natal' | x Hex string: 66656c697a206e6174616c Byte array: \x66\x65\x6c\x69\x7a\x20\x6e\x61\x74\x61\x6c URL encoding: %66%65%6C%69%7A%20%6E%61%74%61%6C ROT13: sryvm angny Signed int: 0 Unsigned int: 0 Float: 0 Hexadecimal: 00 Octal: 0 Binary: 0b ASCII char: NUL RGB: (0, 0, 0) IPv4: 0.0.0.0 Timestamp: Thu, 01 Jan 1970 00:00:00 UTC/GMT-0 As saídas numéricas neste caso ficam zeradas e cabe a você saber que isso faz sentido, afinal, não passei um número como entrada.
    É possível também utilizá-lo no modo interativo. Neste caso, primeiro comandei x, depois digitei o número 65:
    $ x 65 Hex string: 3635 Byte array: \x36\x35 URL encoding: %36%35 ROT13: 65 Signed int: 65 Unsigned int: 65 Float: 0 Hexadecimal: 0x41 Octal: 0101 Binary: 0b1000001 ASCII char: A RGB: (0, 0, 65) IPv4: 0.0.0.65 Timestamp: Thu, 01 Jan 1970 00:01:05 UTC/GMT-0 Ainda há muito o que fazer no eXamine. Há várias conversões possíveis com strings, inteiros de outros tamanhos, hashes, etc. Se você tiver alguma sugestão de conversão, basta abrir uma issue na página do projeto no Github e a discutimos lá. Se souber programar em C, ficarei feliz em receber seu pull request após a discussão.
    Fernando Mercês
    O preloading é um recurso suportado pelo runtime loader  de binários ELF implementado na glibc (GNU C Library), mais especificamente no arquivo rtld.c. Ele consiste em carregar uma biblioteca antes de todas as outras durante o carregamento de um programa executável. Assim é possível injetar funções em programas, inspecionar as funções existentes, etc. Por exemplo, considere o programa ola.c abaixo:
    #include <stdio.h> void main() { printf("ola, mundo do bem!"); } Ao compilar e rodar, a saída é conforme o esperado:
    $ gcc -o ola ola.c $ ./ola ola, mundo do bem! A função printf() foi utilizada com sucesso pois este binário foi implicitamente linkado com a glibc graças ao gcc. Veja:
    $ ldd ola linux-vdso.so.1 (0x00007ffe4892b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a3a2dd000) /lib64/ld-linux-x86-64.so.2 (0x00007f8a3a692000) E portanto a função printf() é resolvida. Até aí nenhuma novidade. Agora, para usar o recurso do preloading, temos que criar uma biblioteca, que será carregada antes da glibc (libc6). A ideia é fazer com o que o binário chame a nossa printf() e não a da glibc. Isso pode ser chamado de usermode hook (incompleto, porém, já que eu repassei o argumento para a função puts() ao invés da printf() original da glibc). Considere o código em hook.c:
    #include <stdio.h> int printf(const char *format, ...) {     puts("hahaha sua printf tah hookada!");     return puts(format); } O protótipo da printf() é o mesmo do original (confira no manual). Eu não reimplementei tudo o que precisaria para ela aqui, somente o básico para ajudar na construção do artigo. E como expliquei antes, o hook não está completo uma vez que eu passo o que recebo na minha printf() para a função puts() da glibc. O ideal seria passar para a printf() original mas para isso eu precisaria buscar o símbolo, declarar um ponteiro de função, etc. E o assunto desde artigo não é hooking de funções.
    Por hora vamos compilar a biblioteca:
    $ gcc -shared -fPIC -o hook.so hook.c $ ldd hook.so linux-vdso.so.1 (0x00007ffffadb8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f011dfbc000) /lib64/ld-linux-x86-64.so.2 (0x00007f011e572000) E agora precisamos instruir o loader a carregá-la antes de todas as outras quando formos executar o nosso programa (ola). Há pelo menos duas formas de acordo com a documentação oficial:
    Definir uma variável de ambiente LD_PRELOAD contendo o endereço de uma ou mais bibliotecas para serem carregadas. Colocar o path de uma ou mais bibliotecas num arquivo /etc/ld.so.preload (caminho e nome são fixos aqui). Então vamos testar. Primeiro uma execução normal, depois com a variável LD_PRELOAD setada e finalmente com o recurso do arquivo /etc/ld.so.preload:
    ## Execução normal $ ./ola ola, mundo do bem! ## Com caminho em variável de ambiente $ export LD_PRELOAD=$PWD/hook.so $ ./ola hahaha sua printf tah hookada! ola, mundo do bem! ## Com caminho em arquivo $ unset LD_PRELOAD # echo $PWD/hook.so > /etc/ld.so.preload $ ./oi hahaha sua printf tah hookada! hello world Percebe o perigo? Não é à toa que existem vários malware para Linux utilizando este recurso. Alguns exemplos são os rootkits Jynx, Azazel e Umbreon. Além disso, algumas vulnerabilidades como a recente CVE-2016-6662 do MySQL dependem deste recurso para serem exploradas com sucesso. É razoável então um administrador que não utilize este recurso num servidor em produção querer desabilitá-lo, certo?
    Desabilitando o preloading
    Não há mecanismo no código em questão da glibc que permita desabilitar este recurso. Pelo menos eu não achei. Uma saída é alterar os fontes e recompilar, mas a glibc demora tanto pra ser compilada que eu desisti e optei por fazer engenheira reversa no trecho necessário e verificar quão difícil seria um patch. Analisando o fonte do rtld.c fica fácil ver que a função do_preload() retorna o número de bibliotecas a serem carregadas no preloading. Primeiro a checagem é feita na variável de ambiente LD_PRELOAD:

    O número de bibliotecas é armazenado na variável npreloads., que mais tarde alimenta uma repetição para de fato carregar as bibliotecas.
    Mais abaixo, o vemos que o trecho de código que busca o arquivo /etc/ld.so.preload também usa a do_preload():

    Sendo assim veio a ideia de encontrar essa função no loader (no meu caso /lib64/ld-linux-x86-64.so.2 – mas pode estar em /lib para sistemas x86 também) e patchear lá diretamente.
    PS.: Apesar de o código ser parte da glibc, a biblioteca do loader é compilada separadamente e tem um nome tipo ld-linux-$ARCH.so.2, onde $ARCH é a arquitetura da máquina. No meu caso, x86-64.
    Fiz uma cópia do arquivo /lib64/ld-linux-x86-64.so.2 para o diretório $HOME para começar a trabalhar.  Pelo visto ela é compilada sem os símbolos, o que elimina a hipótese de achar a função por nome de forma fácil:
    $ nm ld-linux-x86-64.so.2 nm: ld-linux-x86-64.so.2: no symbols Sem problemas. Com o HT Editor, um editor de binários com suporte a disassembly, abri o arquivo e busquei pela string “/etc/ld.so.preload” já que ela é fixa na função, que deve referenciá-la. A ideia foi chegar no trecho de código que chama a função do_preload(). Os passos são:
    Abrir a biblioteca no hte: $ hte ld-linux-x86-64.so.2 No hte, facilita se mudarmos o modo de visualização para elf/image com a tecla [F6]. Depois é só usar [F7] para buscar pela string ASCII /etc/ld.so.preload:

    Após achar a string percebemos que ela é referenciada (; xref) em 4 lugares diferentes. Um desses trechos de código também deve chamar a função do_preload() que é a que queremos encontrar.

    Depois de analisar cada um deles, percebemos que tanto na r4294 quando na r4302 logo depois da referência à string tem uma CALL para uma função em 0xae0 que ao seguir com o hte (apertando [ENTER] no nome dela) é mostrada abaixo:

    Se comparamos com o código da função do_preload() vemos que se trata dela:

    A ideia é forçar que ela retorne 0, assim quando ela for chamada seja pelo trecho de código que carrega as bibliotecas a partir da variável LD_PRELOAD ou pelo trecho responsável por ler o arquivo /etc/ld.so.preload, ela vai sempre retornar 0 e vai fazer com que o loader não carregue as bibliotecas. Para isso, desça até o trecho de código do salto em 0xb37. Perceba que ele salta para 0xb56 onde o registrador EAX é zerado com um XOR, e depois o registrador AL (parte baixa de AX, que por sua vez é a parte baixa de EAX) é setado para 1 pela instrução SETNZ caso a condição em 0x58 não seja atendida (linha 675 no código-fonte). Só precisamos fazer com que esta instrução SETNZ em 0xb5e não seja executada para controlar o retorno da função.

    Ao pressionar [F4], entramos no modo de edição. Há várias maneiras de fazer com que esta instrução em 0xb5e não execute, mas vou fazer a mais clássica: NOPar seus 3 bytes. No modo de edição, substitua os bytes da instrução SETNZ AL (0f 95 c0) por 3 NOP’s (90 90 90), ficando assim:

    Dessa forma, o EAX é zerado em 0xb56, a comparação ocorre em 0xb58 mas ele não é mais alterado, tendo seu conteúdo zerado até o retorno da função. [F2] para salvar.
    Agora para testar vou usar duas técnicas combinadas. A primeira é de declarar uma variável de ambiente só para o contexto de um processo. A outra é de usar o loader como se fosse um executável (sim, ele pode receber o caminho de um binário ELF por parâmetro!). Veja:
    $ LD_PRELOAD=$PWD/hook.so ./ld-linux-x86-64.so.2 ./ola Inconsistency detected by ld.so: rtld.c: 1732: dl_main: Assertion `i == npreloads' failed! Para nosso azar, o loader checa o número de funções a serem carregadas dentro de uma repetição, fora da função do_preload(). Precisamos achar essa confirmação (assertion) para patchear também. Usando a mesma técnica de buscar pela string primeiro (nesse caso busquei pela string “npreloads” exibida no erro) você chega na referência r3148:

    Que te leva diretamente para a repetição da assert():

    Comparando com o fonte:

    Para o salto em 0x3134 sempre acontecer e a CALL de erro em 0x3154 não executar, resolvi patchear a instrução JZ para que sempre pule para 0x2d60. No modo de edição dá pra ver que há um JMP negativo (salto para trás) em 0x315f de 5 bytes, conforme a figura:

    Podemos usá-lo só para copiar o opcode. 
    Como em 0x3134 temos 6 bytes, NOPamos o primeiro e copiamos o opcode do JMP negativo (que é 0xe9), ficando assim:

    Após salvar e testar, voilà:
    ## Com variável de ambiente $ LD_PRELOAD=$PWD/hook.so ./ld-linux-x86-64.so.2 ./ola ola, mundo do bem! ## Com arquivo # echo $PWD/hook.so > /etc/ld.so.preload $ ./ld-linux-x86-64.so.2 ./ola ola, mundo do bem! Agora se você for bravo o suficiente é só substituir o loader original para desativar completamente o recurso de preloading e ficar livre de ameaças que abusam dele.
    Fica também o desafio para quem quiser automatizar este processo de alguma maneira e/ou trabalhar na versão de 32-bits do loader.  O Matheus Medeiros fez um script maneiro para automatizar o patch! Valeu, Matheus!
    Patches de código e recompilação seriam melhores opções, de fato, mas quis mostrar uma maneira usando engenharia reversa por três motivos:
    Se automatizada, pode ser mais fácil de ser colocada em prática em um ambiente em produção. Recompilar a glibc demora muito. Se alguém souber de uma maneira de recompilar somente o loader, por favor, me avise! Engenharia Reversa é divertido.
    Fernando Mercês
    No início de 2014, a Mandiant publicou que estava calculando o hash MD5 das funções importadas por binários PE para buscar variantes de malware [1]. Eles também fizeram um patch na biblioteca pefile [2] para suportar o novo cálculo. A ideia colou e até o Virus Total passou a utilizar [3]. Eu mesmo utilizei um tempo sem entender direito até que um dia decidi estudá-lo para implementar no pev [4] (que ainda não fiz) e hoje decidi escrever sobre.
    Todo binário PE que se preze usa funções de bibliotecas. Assim sendo, desde os primórdios da especificação PE, há o que é conhecido por IT – Import Table, que é uma tabela contendo uma lista de cada módulo (DLL) que o binário utiliza (importa) com suas respectivas funções. Por exemplo, vamos analisar o programa no estilo “Hello, world” abaixo:
    #include <stdio.h> int main(void) { puts("Quem avisa chato eh!"); return 0; } Ao compilar usando o Dev-Cpp [5] no Windows 7, podemos checar quais funções são importadas por ele:
    C:\> readpe --imports hello.exe Imported functions Library Name: KERNEL32.dll Functions Function Name: DeleteCriticalSection Function Name: EnterCriticalSection Function Name: GetCurrentProcess Function Name: GetCurrentProcessId Function Name: GetCurrentThreadId Function Name: GetLastError Function Name: GetStartupInfoA Function Name: GetSystemTimeAsFileTime Function Name: GetTickCount Function Name: InitializeCriticalSection Function Name: LeaveCriticalSection Function Name: QueryPerformanceCounter Function Name: RtlAddFunctionTable Function Name: RtlCaptureContext Function Name: RtlLookupFunctionEntry Function Name: RtlVirtualUnwind Function Name: SetUnhandledExceptionFilter Function Name: Sleep Function Name: TerminateProcess Function Name: TlsGetValue Function Name: UnhandledExceptionFilter Function Name: VirtualProtect Function Name: VirtualQuery Library Name: msvcrt.dll Functions Function Name: __C_specific_handler Function Name: __dllonexit Function Name: __getmainargs Function Name: __initenv Function Name: __iob_func Function Name: __lconv_init Function Name: __set_app_type Function Name: __setusermatherr Function Name: _acmdln Function Name: _amsg_exit Function Name: _cexit Function Name: _fmode Function Name: _initterm Function Name: _lock Function Name: _onexit Function Name: _unlock Function Name: abort Function Name: calloc Function Name: exit Function Name: fprintf Function Name: free Function Name: fwrite Function Name: malloc Function Name: memcpy Function Name: puts Function Name: signal Function Name: strlen Function Name: strncmp Function Name: vfprintf Pois é, apesar de eu ter chamado apenas a função puts(), o binário precisa de muito mais para funcionar.
    Agora um segundo exemplo, com um recurso a mais, mas sem chamar nenhuma outra função da mesma biblioteca:
    #include <stdio.h> char *superfuncaonova(int n) { if (n >= 666) return "arre, porra!"; else return "eu quero eh rock, diabo!"; } int main(void) { puts("Quem avisa chato eh!"); puts(superfuncaonova(1)); return 0; } Após compilar e listar os imports deste hello2.exe, você vai confirmar que é exatamente a mesma lista do primeiro hello.exe. Isto porque, apesar de ter uma função interna nova, não utiliza outra função de biblioteca nova, o que não altera a IAT. Isso é comum em variantes de uma mesma família de malware já que as funcionalidades estão prontas e o que difere de uma variante para outra normalmente são informações como servidor de comando e controle, algumas strings, etc. Sendo assim, é inteligente utilizar essa lista para buscar famílias. Parabéns para quem pensou nisso.
    E como o imphash foi implementado?
    Comparar cada item da lista não seria prático então alguém teve a ideia de tirar o hash MD5 da lista, obedecendo o seguinte padrão:
    Varrendo a import table (IT), na ordem em que aparecem os imports:
    Prefixar cada função com o nome do módulo sem extensão (mas mantendo o ponto) da qual ela é importada. Por exemplo, se o binário importa DeleteCriticalSection() da KERNEL32.DLL, esse import reescrito ficaria KERNEL32.EnterCriticalSection. Caso não haja nome da função, tentar resolver e, caso não consiga, utilizar seu número ordinal. Converter tudo para minúsculo. Criar uma string com os imports no padrão acima, separados por vírgula. Calcular o hash MD5 da string acima. Eu salvei a saída do readpe para um arquivo de texto e, usando expressões regulares, o editei até que ficasse no padrão definido acima:
    $ cat hello.imports kernel32.deletecriticalsection,kernel32.entercriticalsection,kernel32.getcurrentprocess,kernel32.getcurrentprocessid,kernel32.getcurrentthreadid,kernel32.getlasterror,kernel32.getstartupinfoa,kernel32.getsystemtimeasfiletime,kernel32.gettickcount,kernel32.initializecriticalsection,kernel32.leavecriticalsection,kernel32.queryperformancecounter,kernel32.rtladdfunctiontable,kernel32.rtlcapturecontext,kernel32.rtllookupfunctionentry,kernel32.rtlvirtualunwind,kernel32.setunhandledexceptionfilter,kernel32.sleep,kernel32.terminateprocess,kernel32.tlsgetvalue,kernel32.unhandledexceptionfilter,kernel32.virtualprotect,kernel32.virtualquery,msvcrt.__c_specific_handler,msvcrt.__dllonexit,msvcrt.__getmainargs,msvcrt.__initenv,msvcrt.__iob_func,msvcrt.__lconv_init,msvcrt.__set_app_type,msvcrt.__setusermatherr,msvcrt._acmdln,msvcrt._amsg_exit,msvcrt._cexit,msvcrt._fmode,msvcrt._initterm,msvcrt._lock,msvcrt._onexit,msvcrt._unlock,msvcrt.abort,msvcrt.calloc,msvcrt.exit,msvcrt.fprintf,msvcrt.free,msvcrt.fwrite,msvcrt.malloc,msvcrt.memcpy,msvcrt.puts, msvcrt.signal,msvcrt.strlen,msvcrt.strncmp,msvcrt.vfprintf NOTA: O arquivo tem somente uma linha, sendo que não há um caractere de nova linha (\n ) no final dela, veja:
    $ hdump hello.imports | tail 000003c0 74 2e 65 78 69 74 2c 6d 73 76 63 72 74 2e 66 70 |t.exit,msvcrt.fp| 000003d0 72 69 6e 74 66 2c 6d 73 76 63 72 74 2e 66 72 65 |rintf,msvcrt.fre| 000003e0 65 2c 6d 73 76 63 72 74 2e 66 77 72 69 74 65 2c |e,msvcrt.fwrite,| 000003f0 6d 73 76 63 72 74 2e 6d 61 6c 6c 6f 63 2c 6d 73 |msvcrt.malloc,ms| 00000400 76 63 72 74 2e 6d 65 6d 63 70 79 2c 6d 73 76 63 |vcrt.memcpy,msvc| 00000410 72 74 2e 70 75 74 73 2c 6d 73 76 63 72 74 2e 73 |rt.puts,msvcrt.s| 00000420 69 67 6e 61 6c 2c 6d 73 76 63 72 74 2e 73 74 72 |ignal,msvcrt.str| 00000430 6c 65 6e 2c 6d 73 76 63 72 74 2e 73 74 72 6e 63 |len,msvcrt.strnc| 00000440 6d 70 2c 6d 73 76 63 72 74 2e 76 66 70 72 69 6e |mp,msvcrt.vfprin| 00000450 74 66 |tf| O imphash deste arquivo então deve ser o hash MD5 do conteúdo de hello.imports. Vamos ver?
    $ python imphash.py hello.exe # usando a pefile 3856e6eb1020e4f12c9b8f75c966a09c $ md5 hello.imports MD5 (hello.imports) = 3856e6eb1020e4f12c9b8f75c966a09c Legal! Agora que sabemos como calcular o imphash de binários PE, podemos implementar em qualquer software, certo? Mais ou menos. Você percebeu que ignoramos o passo 2? Pois é, no próximo artigo sobre o assunto vou explicar o motivo pelo qual o imphash está quebrado. Até lá. o/
     
    Referências
    [1] https://www.fireeye.com/blog/threat-research/2014/01/tracking-malware-import-hashing.html
    [2] https://github.com/erocarrera/pefile
    [3] http://blog.virustotal.com/2014/02/virustotal-imphash.html
    [4] https://github.com/merces/pev
    [5] https://sourceforge.net/projects/orwelldevcpp/
    Fernando Mercês
    Recebo com alguma frequência e-mails de pessoas perguntando algo sobre carreira em segurança da informação. Naturalmente não tenho todas as respostas, até porque sou novo na área, mas tento ajudar tanto quanto possível. Sendo assim, vou colocar aqui o que normalmente respondo, assim pode ser criticado e melhorado por outros pesquisadores, de modo que nos ajudemos mais e a partir de diferentes pontos de vista.
    Eu baseio uma carreira profissional em 4C, de prática diária:
    Comportamento
    Ética e disponibilidade para ajudar. Sempre.
    Crítica
    Infelizmente (ou felizmente, porque assim você as conhece), pessoas mentem pra você o tempo todo. Nas empresas, mais ainda. Leitura obrigatória aqui são os artigos da série “Profissão: escovador de bit” do Rodrigo Strauss.
    Conhecimento
    Sem o real conhecimento da sua área de atuação, todo o resto vai por água abaixo. De posse dele, você se torna necessário.
    Coexistência
    Ou “engolimento de sapo”. Nem sempre faremos o que achamos que gostaríamos de fazer, nem lidaremos com pessoas legais o tempo todo. São só testes, relaxe. Em tudo tem algo a ser aprendido, mesmo que você ache a tarefa chata ou ruim. É importante que você faça e, se caiu pra você, tem que ser você. Agradeça por isso e só faça.
    Se o objetivo é atuar na área técnica segurança da informação, eu penso que há 5 domínios de conhecimento, ou “blocos”, que precisam ser preenchidos ao máximo, que formam a base da atuação técnica em SI: Hardware, SO, Redes, Software Livre e Programação.
    O quanto você vai avançar em cada item (você pode nivelar em básico, intermediário e avançado) vai depender de qual sub-área de SI você deseja. Eu enxergo as macro: Teste de intrusão, hardening, computação forense, análise de malware e pesquisa de vulnerabilidades. Esqueci algo?
    O estudo nessas áreas é constante e sempre com foco na (in)segurança e geração de certezas mediante provas de conceito, testes e mais testes. Por exemplo, se ao estudar hardware alguém disser pra você que desconectar um teclado PS/2 da placa-mãe com o PC ligado “queima a saída da placa”, teste, mesmo que isso custe sua placa. Você vai aprender o certo e isso não tem preço.
    Voltando aos blocos, vou colocar umas dicas do que fazer neste caminho, baseadas na minha experiência e na de amigos. Definitivamente não é o “caminho para o sucesso”, mas só mais uma sugestão de jornada que pode – e deve – ser adaptada, alterada ou até mesmo completamente ignorada, de acordo com suas opiniões, necessidades e condições. Ou você pode seguir à risca e ver no que dá. Sua conta em risco.
    Hardware
    Acho que desmontar e montar um PC por completo é obrigação de qualquer profissional de TI. Soa um pouco ilógico um programador web, por exemplo, que “chama um técnico” para trocar o HD ou reinstalar o sistema operacional. Adicionalmente estudar eletrônica é muito interessante e é essencial para o que é conhecido por hardware hacking. As dicas são:
    Ser usuário ativo (perguntar e responder) no Fórum do Clube do Hardware. É uma comunidade gigante de técnicos de hardware e até encontros regionais (muito bons por sinal) são promovidos pelos membros. Recomendo muito. Estudar o terceiro volume (Física 3) da série Ramalho, Nicolau e Toledo. Prepare-se para gastar pois este livro é caro. Ah, estudar é diferente de ler. Os primeiros capítulos do livro Sistemas Digitais (Tocci/Widmer). Quando você chegar num capítulo que foge muito da computação, você saberá que pode parar de estudá-lo. O livro CompTIA A+ Complete Study Guide Authorized Coursewar (Quentin Docter, Emmett Dulaney, Toby Skandier) foi o que mais me deu base sobre hardware, mas ele é antigo. Recomendo buscar literatura autorizada pela CompTIA para a certificação A+, além de fazer esta prova e passar! Essa certificação não é lá muito valorizada no Brasil mas o estudo para ela dá uma base incrível sobre computadores. Eu achava que entendia alguma coisa de hardware até ler este livro. Sistemas operacionais
    No estudo de hardware você já deve lidar com os SOs no sentido de instalá-los e configurá-los por demais, no entanto, este item diz respeito a entendê-los.
    Aqui o estudo dos livros dos Tanembaum não podem faltar. Buscar o Minix (SO desenvolvido por ele) e seguir junto com seus livros pode ser um exercício e tanto. A wiki OSDev tem tudo o que é preciso para entender (e até criar) um SO deste o bootloader. O Linux From Scratch também é um excelente recurso e te ensina, dentre outras coisas, a criar sua própria distribuição Linux. Não é que você precise manter uma distribuição Linux, mas criar uma sem dúvida vai te dar uma base de Linux sem igual. A coleção do Windows Internals é o que há de mais profundo, oficialmente, de material para o SO Windows. Redes
    Sem TCP/IP você está perdido. Não conheço literatura específica além do excelente TCP/IP Illustrated (W. Richard Stevens), mas deve haver umas legais em português. O importante é estudar e por em prática os conceitos! Recomendo tirar uma certificação mínima na área como a Network+ ou CCNA, da Cisco e procurar empregos onde você possa trabalhar junto a administradores de rede, ou até se tornar um. Montar um laboratório em casa com alguns PCs também é essencial. Ao conectar este bloco com programação, também é legal programar para redes e, num futuro próximo, conectando também com servidores web e programação, chegar na web entendendo o HTTP com base de quem entende a pilha TCP/IP, os handshakes, os sockets, etc. Outro nível.
    Software livre
    Socialmente justo. Esta “modalidade” de desenvolvimento de software tem seus pilares nas comunidades. Estas, por sua vez, obrigam você a estudar e aprender, sempre ajudando. Você aprende muito mais numa comunidade de software livre, acredite. Aprende sobre todos os outros blocos que citei aqui. Muito. Muito mesmo.
    Fazer parte de um grupo de usuários de Linux da sua região e participar ativamente das suas atividades é obrigatório. Frequentar os eventos de software livre, tanto os regionais quanto os maiores, como o Latinoware constrói uma rede de networking profissional e aprendizado fantástica. Considere submeter propostas de palestras se você tem algo inédito a dizer. E eu acho que você tem. Ficar informado: BR-Linux e VivaOLinux. 4Linux. Essa empresa tem sempre uma equipe excelente de Linux. Fazer um curso lá, além de te dar conhecimento, pode te levar a monitor do curso, o que te ajuda a aprender ainda mais e até mesmo a ser contratado por eles. Livros: Descobrindo o Linux (Eriberto Mota), Servidores Linux (Morimoto), Programação em shell (Julio Neves). Seja qual for o sabor de Linux que você gostar, é essencial procurar se inteirar na comunidade oficial dele. Tem que ter uma conta no GitHub e mostrar o que você sabe fazer em software livre. Pode ser o script mais feio do mundo, mostra sem vergonha! A carreira de certificações LPI é obrigatória. Da LPIC-1 até a última. Programação
    Um dos, senão o mais importante bloco dessa base. Quem não sabe programar por certo não sabe como um computador funciona.
    Pra lógica de programação tem uma coisa chamada “portugol”. Funciona com algumas pessoas. Boa sorte! Estudar Assembly, por mais inútil que possa parecer, mesmo que o básico. Fazer uma calculadora em Assembly é necessário. Recomendo o nasm. Naturalmente, depois de Assembly, C. O livro C Completo e Total (Herbert Schildt) é excelente se você ignorar o último capítulo. Reimplementar programas existentes como ping, dir/ls etc é muito bom. Programar na web é essencial (PHP, Python, Ruby…). Entender o protocolo HTTP também. Mais livros: C++/Java (Deitel), Programação Avançada em Linux (Gleicon da Silveira Moraes) . Programar pra Linux é ótimo! Fazer seu código funcionar em OS X e também Windows (mesmo que via Cygwin) é muito legal/trabalhoso também! Noção de programação orientação a objeto é uma boa. O grupo C/C++ Brasil do Google é fantástico, mas se você pedir a resposta de um trabalho/exercício da escola/universidade lá, irá para o inferno sem escalas. Programar um Arduino é muito louco! Algumas dicas gerais, mas não menos importantes:
    Você só é útil se ajudar os outros. É só por isso que está aqui. Repasse todo o conhecimento que adquiriu, sem exceção. Do contrário ele morre. Você é ajudado. Escolha amigos para ajudar. Faça algum trabalho social envolvendo tecnologia em ONGs e afins. Prefira usar software livre sempre, mesmo no Windows e OS X. Quando gostar de um software livre, compartilhe isso nas suas redes sociais e mande um e-mail ao desenvolvedor (ou grupo de desenvolvedores) agradecendo e explicando porque o software te ajudou. Tenha ativo pelo menos 1 software livre seu. Não importa se é inovador ou não. Frequente eventos, conferências, palestras, workshops… Tire no mínimo uma certificação por ano. Faça coisas na empresa que só você sabe fazer, mas que ajude todo mundo. Faça um “hello, world” e uma função soma() em todas as linguagens que você sentir vontade de saber o básico sobre como ela funciona. Saiba fazer um site HTML/CSS/JavaScript, mesmo que feio. Não tenha medo de mandar currículo para empresas como Google, Microsoft, Oracle, Red Hat etc. Tem um monte de gente que não sabe o que você sabe e está ĺá. Tenha um site/blog onde você posta suas experiências, estudos e avanços. Após ler algo, faça o teste e aí sim, acredite. Se quer uma certificação, agenda a prova (e paga) pra daqui há alguns meses e aí sim começa a estudar. Não trapaceie em certificações (TestKing, Pass4Sure etc). O único idiota nesse ato é você. Agradeça publicamente! Admita erros publicamente! Se você não viver este vídeo, então seu objetivo é dinheiro. Está errado. Se você ainda pensa que é melhor que alguém, por favor assista este outro. Não fique obeso fazendo tudo isso.
    Fernando Mercês
    Este foi um problema que tive há bastante tempo, quando precisei fazer com que o módulo de kernel do antivírus Trend Micro ServerProtect funcionasse em versões de 64-bit do Linux. Acontece que este módulo utiliza o LSM (Linux Security Module) framework. Até aí tudo bem, foi como o jeito que programadores do módulo usaram para hookar a execve() nesta arquitetura, essencial para um antivírus por motivos óbvios: toda vez que um arquivo fosse executado no sistema, este seria escaneado por vírus.
    Apesar de um pouco defasado, decidi escrever agora pois me animei quando fui ao 11º Encontro da comunidade C/C++ Brasil [3]. De fato, atualmente um LSM não pode mais ser carregado num kernel rodando, como um LKM (Loadable Kernel Module) e isso tira toda a praticidade deste patch em específico, mas a técnica utilizada pode ser útil em outras ocasiões. Ou não.
    Indo direto ao ponto, a estrutura default_security_ops não era mais acessível diretamente na versão do kernel que trabalhei e por isso o seguinte trecho de código não funcionava num contexto LSM:
    unsigned long addr = kallsyms_lookup_name("default_security_ops"); Minha intenção não era reescrever todo o módulo, então tive que dar um jeito rápido. A ideia foi buscar uma função exportada que manipulasse a estrutura default_security_ops, assim eu teria acesso ao endereço dela. Várias funções o fazem, mas buscando pela mais simples/menor encontrei a reset_security_ops(), presente em security/linux.c:
    void reset_security_ops(void) { security_ops = &default_security_ops; } Essa função só faz uma coisa: coloca o endereço da estrutura que quero em outra. Sendo assim, é uma perfeita candidata para minha gambiarra.
    Pelo tamanho daria para tentar advinhar quão distante está o endereço da estrutura default_security_ops do endereço da função reset_security_ops(), mas vamos disassemblar só pra garantir:
    1. Extraindo a imagem do kernel
    O kernel fica comprimido em /boot e no próprio fonte existe um script para descomprimi-lo chamado extract-vmlinux. Usei da seguinte maneira:
    $ sudo cp /boot/vmlinuz-$(uname -r)-generic vmlinuz # trabalhar com um backup, só pra garantir ;) $ sudo chown $(whoami): vmlinuz $ /usr/src/linux-headers-$(uname -r)/scripts/extract-vmlinux vmlinuz > vmlinux O arquivo vmlinux (com “x” ao invés de “z”) criado é a imagem descomprimida do kernel, que precisamos disassemblar.
    2. Disassemblando a imagem
    Por padrão a imagem do kernel não contém símbolos, então minha tentativa com o gdb foi frustrada:
    $ gdb -q ./vmlinux Reading symbols from ./vmlinux...(no debugging symbols found)...done. (gdb) disassemble reset_security_ops No symbol table is loaded. Use the "file" command. Mas nem tudo está perdido. No kernel rodando, dá pra ver o endereço das funções no arquivo System.map:
    # grep reset_security_ops /boot/System.map-$(uname -r) ffffffff812d6be0 T reset_security_ops Sabendo o endereço, voltei ao gdb e pedi pra printar 8 intruções começando neste endereço, mas não antes de setar a sintaxe para Intel.
    (gdb) set disassembly-flavor intel (gdb) x/8i 0xffffffff812d6be0 0xffffffff812d6be0: call 0xffffffff81731480 0xffffffff812d6be5: push rbp 0xffffffff812d6be6: mov QWORD PTR [rip+0xcdd14f],0xffffffff81c80100 # 0xffffffff81fb3d40 0xffffffff812d6bf1: mov rbp,rsp 0xffffffff812d6bf4: pop rbp 0xffffffff812d6bf5: ret 0xffffffff812d6bf6: nop WORD PTR cs:[rax+rax*1+0x0] 0xffffffff812d6c00: call 0xffffffff81731480 (gdb) Essa call no início apontar para um ret e honestamente eu não sei por que ela existe:
      (gdb) x/i 0xffffffff81731480 0xffffffff81731480: ret    3. Contando os bytes
    Lembrando que esta função simplesmente implementa a atribuição do endereço que queremos (default_security_ops) para uma variável, fica fácil perceber que a varíavel (security_ops) é RIP+0xcdd14f e o endereço da estrutura que queremos é 0xffffffff81c80100. Mas claro, a ideia aqui é fazer de forma genérica, então não posso trabalhar com esse endereço fixo. Bem, admitindo que essa função não mude, é razoável dizer que o endereço é um número de 64-bits que tem seu primeiro byte em uma posição fixa a partir do endereço da função reset_security_ops(). Isto está longe de ser uma solução profissional, mas resolveu meu problema na época. Ao invés do x/i (examine as instruction), vou usar o disassemble pra poder contar melhor os bytes:
    (gdb) disassemble /r 0xffffffff812d6be0, 0xffffffff812d6bff Dump of assembler code from 0xffffffff812d6be0 to 0xffffffff812d6bf4: 0xffffffff812d6be0: e8 9b a8 45 00 call 0xffffffff81731480 0xffffffff812d6be5: 55 push rbp 0xffffffff812d6be6: 48 c7 05 4f d1 cd 00 00 01 c8 81 mov QWORD PTR [rip+0xcdd14f],0xffffffff81c80100 0xffffffff812d6bf1: 48 89 e5 mov rbp,rsp 0xffffffff812d6bf5: c3 ret End of assembler dump. Para disassemblar sem símbolo você precisa dizer ao gdb até onde ir, por isso fui até 0xffffffff812d6bff, mas cortei o que veio depois do ret no dump. Se contarmos, vamos perceber que o número começa em (endereço da função) + 13 e tem 4 bytes. Só pra confirmar:
    (gdb) x/x 0xffffffff812d6be0 + 13 0xffffffff812d6bed: 0x81c80100 Agora vamos seguir (#medo)!
    4. Implementação
    Ficou deste jeito:
    unsigned long default_security_ops = 0xffffffff00000000; unsigned long _reset_security_ops = 0; _reset_security_ops = kallsyms_lookup_name("reset_security_ops"); memcpy(&default_security_ops, (void *) (_reset_security_ops + 13), 4); A variável default_security_ops já é inicializada com sua parte alta toda setada, pois só a parte baixa do endereço está no assembly. A kallsyms_lookup_name() me dá o endereço da função reset_security_ops(). A memcpy() então copia os 4 bytes que compõem o segundo operando da instrução mov, que é o nosso endereço. O resultado abaixo foi obtido com este código implementado em um módulo:
    # grep default_security_ops /boot/System.map-3.13.0-44-generic ffffffff81c80100 d default_security_ops # rmmod teste; make >/dev/null && insmod teste.ko && dmesg | tail -1 [15999.471619] default_security_ops address: 0xffffffff81c80100 Os endereços batem, no entanto, essa coisa não foi para produção (graças ao Divino) e não recomendo que utilizem nada parecido em nenhum sistema crítico, mas será que dá pra aplicar essa técnica de “contagem de bytes” para outras coisas?
×