Jump to content
  • Construindo seu debugger - Parte 4 (final): Implementação

       (1 review)

    Já faz um bom tempo (quase 1 ano!) desde o último artigo da série de desenvolvimento de debuggers. Este é o último artigo da série e iremos finalmente criar nosso primeiro prototipo de debugger.

    A ideia aqui, é compilar tudo que foi ensinado nos artigos anteriores sobre Sinais, Forks e ptrace . Com isso, criaremos um simples tracer em C que irá receber um endereço como argumento e colocar um breakpoint no mesmo.

    Diagrama

    Antes vamos definir um pouco o escopo do nosso software:

     

    image.png.dfff5b52f31853b9445fff07335e5284.png

    O nosso tracer irá criar um fork e nesse fork será feita a chamada para a execv, que por sua vez irá trocar a imagem do atual processo (seu conteúdo) pela de outro processo, fazendo com que de fato vire outro processo. Já o nosso debugger, dentro de um loop, irá se comunicar via sinais com o processo filho.

    Breakpoints

    Existem dois tipos de breakpoints: software breakpoints e hardware breakpoints. Ambos servem para interromper a execução do nosso software em determinada instrução. Para que isso seja possível é necessário que a execução do processo seja interrompida na nossa CPU.

    Interrupções

    Quando ocorre algum evento no computador que precisa de um tratamento imediato, a CPU invoca uma interrupção. Cada evento desse contém uma ação especifica que nosso kernel irá lidar de alguma maneira e a estrutura responsável por salvar os valores e significados das mesmas é a Interrupt Descriptor Table.

     

    image.thumb.png.e98d3bb41f9a61d7ce737625572a41a1.png

    A imagem acima representa visualmente uma implementação desse vetor, onde cada posição (offset) contém uma struct associada e nela os valores necessários para lidar com isso. Você pode ter uma explicação mais detalhada aqui.

    Mas por que eu estou falando de tudo isso? Porque breakpoints nada mais são do que uma interrupção em um dado endereço que faz com que o processador pare a execução do seu programa.

    O valor que interrompe a CPU para um breakpoint é o 0x03. Vamos testar isto nesse pequeno bloco de código:

    main() {
        int x = 4; // Iniciando qualquer coisa
        __asm__(
            "int $0x03"
        );
    }

    A macro __asm__ permite que seja colocado o código direto em assembly, nesse caso, foi colocado o mnémonico INT, que cuida das interrupções com o valor 3 (offset comentado acima na IDT). Se você compilar e executar esse programa:

    ~ ./code                                                                  
    zsh: trace trap (core dumped)  ./code

    Nesse momento o trabalho de fazer o handle dessa interrupção é do nosso software. O que fizemos aqui foi implementar um software breakpoint. Agora vamos executar esse programa no gdb e não por breakpoint algum (dentro do gdb) e só executar:

    (gdb) r
    Starting program: /home/zlad/code
    
    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x000055555555515f in main ()
    (gdb) disas
    Dump of assembler code for function main:
       0x0000555555555139 <+0>: push   %rbp
       0x000055555555513a <+1>: mov    %rsp,%rbp
       0x000055555555513d <+4>: sub    $0x10,%rsp
       0x0000555555555141 <+8>: movl   $0x2,-0x4(%rbp)
       0x0000555555555148 <+15>:    mov    -0x4(%rbp),%eax
       0x000055555555514b <+18>:    mov    %eax,%esi
       0x000055555555514d <+20>:    lea    0xeb0(%rip),%rdi
       0x0000555555555154 <+27>:    mov    $0x0,%eax
       0x0000555555555159 <+32>:    callq  0x555555555030 <printf@plt>
       0x000055555555515e <+37>:    int3  
    => 0x000055555555515f <+38>:    mov    $0x0,%eax
       0x0000555555555164 <+43>:    leaveq
       0x0000555555555165 <+44>:    retq  
    End of assembler dump.
    (gdb) 

    Veja que a nossa interrupção foi capturada pelo GDB, pois ele detectou um breakpoint trap e é exatamente isso que iremos fazer. Nosso tracer será capaz de detectar quando irá ocorrer um SIGTRAP, ou seja, um sinal que deve ser tratado por nosso sistema operacional.

    Finalmente implementando

    Vamos finalmente começar o nosso pequeno tracer, que será capaz colocar breakpoints, executar instrução por instrução e imprimir os registradores na tela!

    Para inserir a interrupção de breakpoint (int 3) não precisamos de muito, pois já existe um mnemónico para isso que é o int3 e que tem como valor 0xCC. Para inserir breakpoints precisamos de um endereço (que vá ser executado) e uma maneira de escrever nesse local na memória virtual do nosso processo.

    Já vimos anteriormente o ptracer e nele sabemos que temos alguns enums que podem ser passados como seu primeiro argumento. São eles o PEEK_DATA e o POKE_DATA, que servem para buscar algo na memória de um processo e escrever algo na memória de um processo, respectivamente. Segue a função que vamos usar para adicionar breakpoints no nosso tracer:

    uint64_t add_breakpoint(pid_t pid, uint64_t address)
    {
        uint64_t break_opcode = 0xCC;
        uint64_t code_at = ptrace(PTRACE_PEEKDATA, pid, address, NULL);
        uint64_t breakpoint_code = (code_at & ~0xFF) | break_opcode;
           
        ptrace(PTRACE_POKEDATA, pid, address, breakpoint_code);
       
        return code_at;
    }

    Respire fundo e vamos em partes, a ideia aqui é a seguinte:

    Dado o pid do nosso processo filho e um endereço de memória, vamos buscar o código que estava naquele local (code_at), salvar esse código (não só queremos adicionar um novo opcode, mas podemos futuramente querer executá-lo) e então vamos adicionar nossa instrução nos bytes menos significativos, ou seja, vamos executar ela primeiro.

    Usamos aqui uma variável de 64 bits por conta da arquitetura do meu sistema. Se você quiser tornar isto portável, é possível criar uma variável genérica baseada na arquitetura:

    #ifdef __i386__
    #define myvar uint32_t
    #else
    #define myvar uint64_t
    #endif

    Isso é opcional, mas caso você queira criar algo mais genérico, esse é o caminho.

    A operação bitwise que fizemos aqui também pode ser “nebulosa” para alguns, mas segue o equivalente de maneira mais “verbosa” e em python:

    >>> hex(0xdeadbeef & ~0xFF) # Mascarando byte menos significativo
    '0xdeadbe00'
    >>> hex(0xdeadbeef & ~0xFF | 0xCC) # Mascarando byte e adicionado opcode int3(0xCC)
    '0xdeadbecc'

    O que é feito aqui é uma jogada lógica. Vamos quebrar isso em passos:

    • Fazemos um AND com algo negado (0xFFFFFF00);
    • Fazemos um OR com o resultado que irá "preencher" o espaço vazio, visto que um valor OR 0 será sempre o valor com conteúdo;
    • No final mascaramos o último byte e colocamos nosso opcode;

    O nosso loop precisa executar enquanto nosso processo filho estiver sendo debugado. Em termos de estrutura de códigos vamos usar um laço que irá receber uma flag para sua execução:

    while (!WIFEXITED(status)) {
        // Our code
    }

    Caso você esteja perdido nessa função WIFEXITED, vale a pena dar uma olhada no artigo desta série sobre Forks. Agora é puramente uma questão de jogar com sinais e estruturar nosso código da maneira mais coesa possível, resumindo, pura programação ?

    Após nosso breakpoint ser definido em memória precisamos fazer o handling disso. Para isso usamos a função WSTOPSIG, que irá receber o status do nosso processo (que é atribuído na função wait) e irá nos dizer qual tipo de interrupção ocorreu:

    while (!WIFEXITED(status)) {
        wait(&status);
        signal = WSTPOPSIG(status);
    
        switch(signal) {
            case SIGTRAP:
                puts("We just hit a breakpoint!\n");
                display_process_info(pid);
                break;
        }
    }

    No momento que uma sigtrap for enviada para a gente podemos considerar que caímos no nosso breakpoint. Nesse momento, nosso processo filho está block (pois sofreu uma interrupção), esperando algum tipo de ação para continuar.

    A função display_process_info(pid) irá mostrar o atual estado dos nossos registrados, usando o enum PTRACE_GETREGS que recebe a struct regs (também já visto no artigo passado):

    void display_process_info(pid_t pid)
    {
        struct user_regs_struct regs;
        ptrace(PTRACE_GETREGS, pid, NULL, &regs);
       
        printf("Child %d Registers:\n", pid);
        printf("R15: 0x%x\n", regs.r15);
        printf("R14: 0x%x\n", regs.r14);
        printf("R12: 0x%x\n", regs.r12);
        printf("R11: 0x%x\n", regs.r11);
        printf("R10: 0x%x\n", regs.r10);
        printf("RBP: 0x%x\n", regs.rbp);
        printf("RAX: 0x%x\n", regs.rax);
        printf("RCX: 0x%x\n", regs.rcx);
        printf("RDX: 0x%x\n", regs.rdx);
        printf("RSI: 0x%x\n", regs.rsi);
        printf("RDI: 0x%x\n", regs.rdi);
        printf("RIP: 0x%x\n", regs.rip);
        printf("CS:  0x%x\n", regs.cs);
        printf("EFGLAS: 0x%x\n", regs.eflags);
    }

    O código do nosso loop final fica da seguinte forma:

    while (!WIFEXITED(status)) {
        signal = WSTOPSIG(status);
    
        switch(signal) {
            case SIGTRAP:
                puts("We just hit a breakpoint!\n");
                break;
        }
       
        printf("> ");
        fgets(input, 100, stdin);
        if (!strcmp(input, "infor\n")) {
            display_process_info(pid);
        } else if (!strcmp(input, "continue\n")) {
            ptrace(PTRACE_CONT, pid, NULL, NULL);
            wait(&status);
        }
    
    }
    
    printf("Child %d finished...\n", pid);
    return 0;
    }

    Não iremos focar em implementação pela parte da interação do úsuario pois não é o foco dessa série de artigos. Tentei ser o mais “verboso” possível no quesito UX ?. No projeto original usei a lib linenoise para criar uma shell interativa, mas isso fica para sua imaginação.

    Vamos executar:

    ~/.../mentebinaria/artigos >>> ./tracer hello 0x401122 #<== Endereco da main                  [130]
    Forking...
    
    Adding breakpoint on 0x401122
    We just hit a breakpoint!
    
    > infor
    Child 705594 Registers:
    R15: 0x0
    R14: 0x0
    R12: 0x401050
    R11: 0x2
    R10: 0x7
    RBP: 0x0
    RAX: 0x401122
    RCX: 0x225d7578
    RDX: 0x19a402c8
    RSI: 0x19a402b8
    RDI: 0x1
    RIP: 0x401123
    CS:  0x33
    EFGLAS: 0x246
    We just hit a breakpoint!
    
    > continue
    Hello world
    Child 705594 finished...

    A ideia aqui não é criar tudo para você. A partir de agora, com o conhecimento básico dessa série de artigos, é possível criar o seu próprio debugger ou ferramenta semelhante. Deixo aqui o meu projeto, sdebugger, que foi fruto do meu estudo sobre este tema. Todo conhecimento base que eu passei aqui foi o necessário para criar este projetinho.

    Agradeço a toda turma do Mente Binária pelo apoio e desculpa à todos pela demora para finalizar essa série de artigos. Tenho várias ideias para artigos futuros, então vamos nos ver em breve!

    Links úteis:

    Qualquer problema/erro por favor me chame ?


    User Feedback

    Join the conversation

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

    Guest

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

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

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

      ×   Your previous content has been restored.   Clear editor

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



  • Similar Content

    • By Bruna Chieco
      O Cisco Talos, grupo global de inteligência de ameaças de cibersegurança da Cisco, descobriu uma vulnerabilidade de divulgação de informações no kernel do Linux.
      A vulnerabilidade, rastreada como CVE-2020-28588, pode permitir que um invasor visualize a pilha de memória do kernel, o que significa que dados ou informações que não deveriam ser vistas possam ser acessadas. O problema foi visto pela primeira vez pelo Cisco Talos em um dispositivo Azure Sphere (versão 20.10), um dispositivo ARM de 32 bits que executa um kernel do Linux corrigido.
      O kernel do Linux é o núcleo livre e de código aberto dos sistemas operacionais do tipo Unix. A vulnerabilidade existe especificamente na funcionalidade /proc/pid/syscall de dispositivos ARM de 32 bits executando Linux.
      Um invasor pode explorá-la lendo /proc/<pid>/syscall, um arquivo legítimo do sistema operacional Linux, podendo aproveitar esse vazamento de informações para explorar com êxito vulnerabilidades adicionais não corrigidas.
      O Cisco Talos trabalhou com o Linux para garantir que esse problema seja resolvido e uma atualização já está disponível para os clientes afetados. Os usuários são incentivados a atualizar esses produtos afetados o mais rápido possível para o Kernel Linux versões 5.10-rc4, 5.4.66 e 5.9.8.
    • By Bruna Chieco
      Pesquisadores da Sayfer fizeram engenharia reversa no WhatsApp Web e acabaram encontrando "sem querer" um recurso desabilitado por padrão, ou seja, que ainda não está liberado. A função pre-released descoberta permite que a velocidade de um áudio seja acelerada. 
      Os pesquisadores, na verdade, estavam fazendo uma pesquisa sobre outro projeto quando descobriram acidentalmente que o WhatsApp tem um sinalizador para o recurso oculto que permite aos usuários alterar a taxa de reprodução de mensagens de voz.
      Uma das ferramentas de pesquisa utilizadas pelos pesquisadores permitiu essa alteração, sendo cada mensagem de voz é essencialmente uma marca de áudio com um blob de uma fonte de áudio. Para alterar a velocidade, contudo, foi necessário fazer engenharia reversa no código-fonte minimizado do WhatsApp para a web.
      Eles descobriram que o WhatsApp tem três velocidades pré-determinadas para os áudios, porém, desabilitadas. Em publicação, os pesquisadores explicam o passo a passo do que fizeram para conseguir alterar a taxa de reprodução dos áudios.
      E se você quiser saber mais sobre engenharia reversa, o Mente Binária tem um curso com 24 aulas que pode ser acessado por meio do nossos canal no YouTube:
       
    • By Felipe.Silva
      Injeção de código é uma técnica que consiste em adicionar instruções extras em um executável. Essas instruções podem ser adicionadas em vários lugares do programa, inclusive executar antes do entry point original.
      O uso mais comum para injeção de código é para fins maliciosos, onde um shellcode poderia ser inserido no executável e dar acesso remoto para um atacante. Mas um exemplo de uso "justo" para essa técnica é para fins de patching no executável quando você quer que algo seja alterado em tempo de execução no binário.
      Se você já tentou injetar código em um executável manualmente deve saber que não é uma tarefa tão divertida. Pensando neste tipo de impasse, imaginei que seria interessante ter uma ferramenta para automatizar esse tipo de manipulação de um executável. Por esse motivo criei o pei, uma ferramenta para automatizar injeção de código e outros tipos de manipulações em executáveis PE de 32-bit e 64-bit.
      O pei foi programado pensando na automação e por isso é fácil usar a ferramenta a partir de um script. Com ela você pode obter e modificar valores no executável, e é claro, injetar código.
      Antes de qualquer coisa você pode instalar o pei em seu Linux rodando os comandos abaixo:
      git clone https://github.com/Silva97/pei cd pei make sudo make install Nota: Caso use Windows e não esteja usando WSL ou um MSYS2 da vida, você pode compilar o projeto instalando o make e o MinGW (recomendo usar o Chocolatey). No entanto, o “sudo make install” não vai funcionar no Windows, você vai ter que adicionar o executável ao PATH manualmente.
      Se você não estiver a fim de compilar o executável, fiz o favor de adicionar o binário da ferramenta compilado para Windows nos releases dela. Você pode baixá-lo no link https://github.com/Silva97/pei/releases/latest.
      O uso básico da ferramenta segue o seguinte formato:
      pei [opções] <operação> <executável> [argumento] Se você quiser ver mais detalhes de como usar a ferramenta você pode rodar “pei -h”.
      Operações
      As operações são o que determinam o que a ferramenta irá fazer com o executável, indo desde exibir informações sobre ele até modificar campos dos cabeçalhos.
      show
      A operação show serve para exibir informações sobre o executável e campos dos cabeçalhos. Se você não passar argumentos para a operação por padrão ela irá exibir informações básicas do executável:

      Você também pode especificar uma combinação de letras para escolher quais campos serão exibidos, dentre elas: c (COFF header), o (optional header), d (data directories) e s (section). Exemplo:
      $ pei show test.exe co Esse comando, por exemplo, exibe o COFF header e optional header do executável.
      get
      A operação get pega o valor de um campo individual de um dos cabeçalhos (coff, optional ou section) do executável.
      Seguindo uma notação com pontos, semelhante à acessar campos de estruturas em C, você pode especificar o cabeçalho e o nome do campo para ser obtido. Por exemplo, para obter o entry point do executável o comando ficaria:
      $ pei get executavel.exe optional.entry_point '%x' 14f0 Dica: Veja o nome dos campos dos cabeçalhos usando a operação show.
      O argumento após o nome do campo é uma string de formatação idêntica a da função printf() da libc, que aceita quaisquer flags de formatação disponíveis para a função.
      Para acessar os campos de uma seção é necessário especificar o número da seção também, como demonstrado no print abaixo:

      edit
      A operação edit serve para modificar o valor de campos, onde o nome do campo é especificado de maneira idêntica à operação get.
      Você pode utilizar os operadores `=`, `|=` e `&=` que fazem exatamente a mesma coisa que na linguagem C. Exemplos:
      $ pei edit executavel.exe section.0.name = .code $ pei edit executavel.exe optional.entry_point = 0xabcd1234 Esta operação aceita números em decimal, hexadecimal ou octal na hora de definir o valor de campos numéricos.
      zeros
      Esta operação simplesmente exibe uma lista das maiores sequências de bytes nulo em cada seção do executável. É este espaço que é utilizado para injetar o código, tornando a operação útil para você poder escolher em qual seção injetar o código.
      $ pei zeros executavel.exe Section #0 '.text': 0x00000000000022fb of 13 bytes Section #1 '.data': 0x000000000000242c of 1012 bytes Section #2 '.rdata': 0x0000000000002a5b of 37 bytes Section #6 '.idata': 0x0000000000003a26 of 22 bytes Section #7 '.CRT': 0x000000000000420b of 21 bytes Section #9 '/4': 0x0000000000004649 of 23 bytes Section #10 '/19': 0x0000000000004cbe of 10 bytes Section #12 '/45': 0x000000000003e2fc of 5 bytes Section #13 '/57': 0x0000000000041019 of 8 bytes Section #15 '/81': 0x0000000000043c33 of 44 bytes Section #16 '/92': 0x0000000000045509 of 23 bytes inject - A cereja do bolo 🙂
      Esta é a operação que injeta o código. Você pode usar a opção -f para especificar o arquivo contendo o código a ser injetado, que seria um raw binary. Onde esse arquivo deve conter apenas as instruções de código de máquina a ser injetado, como um shellcode por exemplo.
      Opcionalmente, você pode usar a opção -s para especificar o número da seção que você quer injetar o código. Se a opção não for especificada, por padrão o pei vai injetar onde houver mais espaço disponível.
      $ pei -f my_code.bin inject executavel.exe Writed code of 12 bytes on offset 0x0000000000043924 of section #15 '/81' Após o código injetado, o pei insere um jump absoluto para o entry point original do executável, fazendo com que após o código injetado ser executado o fluxo de execução do programa continue normalmente.
      Outra modificação que o pei faz é desabilitar o dynamic base do executável, para evitar que o jump aponte para o endereço errado.
      Dica: Injetando Código Muito Grande
      Se você precisar injetar um código maior do que o espaço disponível apontado pela operação zeros, você pode dividir o código a ser injetado em várias partes e injetar cada parte por vez, seguindo a ordem da última até a primeira parte. Isso funciona porque o pei irá adicionar um jump no final do código para o endereço que está sendo indicado como entry point. Se você já injetou código antes, esse endereço é o endereço do código anteriormente injetado. 🙂
      Dessa forma você pode fazer um chain de saltos da primeira parte até a última e então saltar para o entry point original. Exemplo:
      $ pei inject -f parte-3.bin executavel.exe Writed code of 87 bytes on offset 0x0000000000043833 of section #15 '/81' $ pei inject -f parte-2.bin executavel.exe Writed code of 80 bytes on offset 0x0000000000044924 of section #11 '/23' $ pei inject -f parte-1.bin executavel.exe Writed code of 32 bytes on offset 0x0000000000401a15 of section #1 '.text' Isso irá criar a seguinte ordem de execução: parte-1.bin -> parte-2.bin -> parte-3.bin -> entry point. Onde as setas “->” representam os saltos.
      diff
      Esta operação exibe diferenças entre dois executáveis. Ela compara cada campo dos cabeçalhos do executável e o conteúdo das seções, e depois exibe estas diferenças no terminal. Você pode usar a opção -c (ou --color) para que a saída da operação seja colorida:

      Em vermelho são os valores no executável original que foram modificados e em verde são os valores novos no executável modificado.
      patch
      Essa operação lê um texto de entrada no mesmo formato que a saída da operação diff e replica as mesmas modificações no executável. Exemplo:
      $ pei patch executavel2.exe diff-output.txt Caso você não especifique um patch file, o pei irá ler de stdin. Assim, é possível que você faça um pipe entre uma operação de diff e patch:
      $ pei diff original.exe mod.exe | pei patch outro.exe A diferença de fazer isto e simplesmente fazer uma cópia do executável modificado, é que a ideia é replicar somente as diferenças entre os executáveis. Quaisquer outros campos não são tocados pela operação patch, o que te permite salvar alterações e replicá-las por meio de um script. 🙂
      Se você quiser, também é possível escrever um patch file manualmente, bastando imitar a saída de diff. Uma dica é que os valores dos campos originais (em vermelho) não são necessários para a operação patch, então você pode inserir somente os valores novos. Seguindo o print da saída do diff que utilizamos agora pouco como exemplo:
      optional.entry_point xxx 0x4ca33 section.0.name xxx .code section.15.characteristics xxx 0x62100040 // @O texto não faz diferença, só importa o @ no início da linha // Daqui para baixo qualquer linha que não inicie com + será ignorada. +0x43830 00 30 9f 61 62 63 0a b8 f0 14 40 00 ff e0 00 00 // O formato é: +0xoffset bytes em hexadecimal Nota: Onde há o “xxx” seriam os campos dos valores originais (em vermelho) que não são lidos pelo pei porém são necessários para imitar a saída da operação diff. Você pode colocar qualquer valor aí que não dará erro já que são ignorados.
      Você pode usar a operação patch em scripts para automatizar várias modificações em um executável ao mesmo tempo, inclusive em bytes de um determinado offset.
    • By Bruna Chieco
      Três vulnerabilidades foram encontradas no subsistema iSCSI do kernel do Linux, permitindo que invasores locais com privilégios básicos de usuário obtenham privilégios de root em sistemas Linux sem patch. Segundo o BleepingComputer, os bugs de segurança só podem ser explorados localmente, o que significa que invasores em potencial terão que obter acesso a dispositivos vulneráveis explorando outra vulnerabilidade ou usando um vetor de ataque alternativo.
      O mais impressionante é que essas vulnerabilidades já existem há 15 anos. A descoberta foi feita por pesquisadores do GRIMM. "Ao contrário da maioria das coisas que encontramos acumulando poeira, esses bugs revelaram-se ainda bons, e um acabou sendo utilizável como um escalonamento de privilégio local (LPE) em vários ambientes Linux", diz publicação feita no blog do GRIMM.
      De acordo com o pesquisador de segurança do GRIMM, Adam Nichols, as falhas afetam todas as distribuições Linux, mas felizmente o módulo de kernel scsi_transport_iscsi vulnerável não é carregado por padrão. No entanto, dependendo da distribuição do Linux que os atacantes estejam focando, o módulo pode ser carregado e explorado para escalonamento de privilégios.
      Saiba mais sobre as vulnerabilidades: 
      CVE-2021-27363: vazamento do ponteiro do kernel (vazamento de informações) CVE-2021-27364: leitura fora dos limites (vazamento de informações, negação de serviço) CVE-2021-27365: estouro de buffer de heap (escalonamento de privilégio local, vazamento de informações, negação de serviço)
    • By Fernando Mercês
      Batizado com nome herdado da estrela binária VV Cephei, o Linux.Cephei é provavelmente o primeiro file infector para executáveis ELF (utilizados nos sistemas baseados em Linux, entre outros) escrito na linguagem Nim. Isso mesmo, o autor é um tanto excêntrico e disse em seu blog que o Linux.Cephei é inofensivo (por enquanto) e fez somente para participar de um concurso de programação.
      O vírus é do tipo que chamamos de prepender, ou seja, ele adiciona algo "antes" da execução de um programa saudável, no caso, de um binário ELF. A técnica para isso é a alteração de seu entrypoint. 
      Nos testes que fizemos aqui, o Linux.Cephei só funcionou com binários compilados estaticamente: 
      $ uname -a Linux malinux 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux $ cat /etc/debian_version 9.2 $ cat h.c #include <stdio.h> int main(void) { printf("ola mundo do bem!\n"); return 0; } $ gcc -static -o hello h.c $ ./hello ola mundo do bem! $ chmod +x linux.cephei $ ./linux.cephei $ ./hello Did you know that VV Cephei, also known as HD 208816, is an eclipsing binary star system located in the constellation Cepheus, approximately 5,000 light years from Earth? It is both a B[e] star and shell star. Awesome! https://en.wikipedia.org/wiki/VV_Cephei The more you know... :) ola mundo do bem! $ gcc -o hello h.c $ ./linux.cephei $ ./hello ola mundo do bem!  Perceba que ele injetou seu código com sucesso no binário hello, mas somente quando foi compilado estaticamente.  
      Além da linguagem exótica, ultimamente não se vê muitos file infectors já que a moda de infectar executáveis passou. De qualquer forma, é bom ficar de olho. Com códigos como o do Linux.Ceiphei, vírus podem permanecer ocultos num sistema por muito tempo. E pouca gente usa antivírus no Linux, mesmo tendo uma alternativa livre como o ClamAV.
×
×
  • Create New...