Jump to content
  • Revertendo Firmware - Conversando com o seu $device

       (0 reviews)

    barbieauglend

    No artigo anterior, discutimos como encontrar informações importantes para se comunicar com seu dispositivo. Neste, vamos falar sobre uma abordagem genérica antes de reverter o código do firmware de fato.

    Objetivos

    A coisa mais importante durante o processo a partir de agora  é saber quais perguntas você quer responder. Se você começa a querer entender tudo, sem focar, no final acaba perdido numa montanha de informações sem sentido.

    Dê uma de Jack, O Estripador clássico: entenda tudo, mas por partes. Eu normalmente começo procurando o protocolo de comunicação no caso dele não estar documentado. Após isso quero entender geralmente o algoritmo usado para autenticação ou o gerador de senhas ou algo que me dê acesso a dados interessantes que possam ser usados em outros $hardware iguais. Normalmente a segurança de sistemas embarcados não é muito boa nisso: todos os hardware precisam de alguma forma de identificação única presente no firmware. Como você solucionaria o problema pensando em larga escala?

    Conversando com o seu $sistema

    A melhor parte e o principal diferencial da análise de hardware é ter o bare metal (o equipamento físico) nas suas mãos. Ter acesso aos sinais eletrônicos, poder medir frequências e VER como o sistema trabalha (adicionar LEDs em todos os circuitos possíveis e adaptar a frequência por exemplo, sempre lindo!) são coisas que fazem o coração palpitar bem mais do que algumas linhas de código. Acredite 😉 Sem muita informação prévia e com alguns equipamentos baratos, é possível obter dados interessantes para a análise. Poderíamos começar a controlar o tráfego de dados usando o analisadores lógicos simples e ao mesmo tempo podemos usar equipamentos mais avançados para medir o consumo de energia no processo de inicialização do hardware com tanta precisão, que poderíamos deduzir possíveis valores de chaves privadas - é pura ciência, física 💚 - e claro que funciona em condições ideais, como aprendemos na escola.

    Fluxo de dados na PCB

    Não adianta muito ter dados se você não pode ler, escrever ou transferi-los de alguma maneira. Olhar a placa deve ser suficiente para entender como o fluxo de dados ocorre, simplesmente pensando na posição do CI (Circuito Integrado) e das marcas na PCB, ou seja, na placa. Outra coisa importante: quase todas as plaquinhas têm uma datasheet voando na !nternetz e acessível publicamente, contendo toda a informação técnica (da pinagem, voltagem e o PROTOCOLO DE COMUNICAÇÃO). Sempre vale a pena usar o DuckDuckGo antes de começar a ter dores de cabeça por algo que esta documentado, certo?

    Vamos começar sem gastar muito $$$:

    Procure a fonte!

    Quem esta começando agora pode não ter todas as ferramentas disponíveis ou não ter acesso a uma oficina / laboratório. Por isso, vamos dump o código direto do hardware e abrir mao do contexto - que teríamos no caso da leitura dos dados no hardware - mas economizaremos dinheiro e teremos acesso a toda informação possível do $device. 

    Acesso ao firmware e memória

    Dumpe o código do CI e o descomprima. Essa é a parte mais fácil e mais difícil de todo o processo, mas para isso você não precisa de nenhum equipamento e pode usar várias ferramentas de graça (algumas inclusive de código aberto).

    Como eu falei anteriormente, é possível achar na Internet os datasheets (documentação completa, normalmente em PDF) de quase todos os dispositivos. Ache a datasheet para o seu CI e assim não terá necessidade nem de identificar a pinagem nem de reverter o conjunto de instruções necessárias para a comunicação. Algo também importante é saber como parar a comunicação entre o seu CI e os outros pontos de comunicação da placa, pois isso pode interferir na leitura dos dados. Como interromper o fluxo de dados depende bastante do circuito que você esta analizando.

    Mas eu preciso desoldar?

    Esse seria o caminho mais óbvio certo? Não quer interferência, desconecte seu CI da placa e vai para o abraço. Esse método te dá controle total sobre o seu CI 🙂 O problema aqui é que esse processo requer experiencia e TEMPO.

    A ideia deste artigo é para ser algo mais simples e barato, então tente evitar essa situação e pense em ideias mais "criativas". Normalmente é possível conectar os dispositivos num osciloscópio ou voltímetro para monitorar e ter certeza que não há interferência dos sinais de cada pino do CI. Fique atento nos outros componentes, se algum tráfego de dados está ocorrendo (instale por exemplo um monitor na outra porta UART). Se algum tráfego ocorrer, daí não tem outro jeito a não ser desconectar o seu CI - use um fim de semana. 🙂

    Assim que o seu CI estiver isolado, conecte ele a qualquer aparelho que "fale" o mesmo protocolo e comece a ler a memória bloco por bloco. Isso pode demorar, por isso aconselho quando começar a leitura, vá a cozinha e faça um café! 🙂

    Dumping os dados

    Criar suas próprias ferramentas pode ser super divertido, mas custa tempo e é bem mais fácil quando você sabe o que está procurando. Por enquanto, podemos usar vários projetos de código aberto disponíveis:

    Para fazer o dumpflashrom é uma das ferramentas populares. É facil de usar, cheia de bugs mas tem suporte para várias arquiteturas diferentes. Funciona muito bem no Rasperry Pi. 🙂

    Normalmente vale a pena usar o comando file para ter uma ideia do tipo de arquivo que você esta lidando. Se ele não te ajudar em nada, tem o famoso binwalk.

    Os logs do binwalk the darão os endereços importantes. Então agora podemos usar o dd e dividir o seu binário em segmentos específicos. O comando dd precisa dos parâmetros bs (block size), do skip (offset) e o count (que aqui signifca quantos blocos você tem/quer copiar). Normalmente você terá pelo menos 3 blocos:

    1. O bootloader.bin: geralmente não esta criptografado pelo fato do microcontrolador não poder descriptografar.
    2. O mainkernel.bin: se você tiver sorte será algum kernel Linux. Esse é o firmware que controla o bare metal. 🙂 Geralmente o mais divertido de ler e várias vezes comprimido - use o file novamente para saber como descomprimir.
    3. O mainrootfs.bin: para quem entende um pouco de Linux e sistemas BSD, esse é o sistema de arquivos, contendo todos os arquivos com configurações, os binários do sistema, etc. Use novamente o file para verificar se está comprimido.

    No caso da imagem estar criptografada, é possível quebrá-la utilizando o fcrackzip

    No próximo artigo eu vou tentar entrar em detalhes desses três binários - vamos ver se eu acho algum hardware interessante. 🙂

    • Agradecer 2
    • Curtir 5


    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.

    Guest

  • Similar Content

    • By lucass
      Vou começar agradecendo ao @Fernando Mercês pela oportunidade e por ter sugerido este artigo, que também me motivou bastante a escrevê-lo!
      Introdução
      Não sou conhecido internet a dentro, apenas acompanho alguns canais no Discord (tal como o do Mente Binária). Meu nível de programação e engenharia reversa não é algo admirável ainda. Em um grupo especifico intitulado "Terra do 1337", que é um grupo fechado de amigos com finalidade de estudar engenharia reversa, programação e descontrair, eu surgi com uma idéia de escrever uma ferramenta que iria facilitar a vida de muitos nesta área de engenharia reversa e achei de API Inspector.
      A seguir um spoiler de como foi o início do projeto, para quem se interessar. 😉
      O que é o API Inspector
      É uma ferramenta de código-aberto voltada para área de engenharia reversa, que irá auxiliar na análise de funções correspondentes a certas API's do Windows, retornando informações obtidas dos argumentos caso a função seja chamada pela aplicação.
      O que ele faz
      Ele faz um hook (do Inglês "gancho"), que consiste num desvio na função original da API solicitada para nossa própria função e com isso podemos obter os dados (argumentos/parâmetros) que foram passados para tal função.
      Como ele funciona
      O princípio de um hook é simples: você insere no inicio da função um salto que irá levar para a sua função (que é uma cópia da função original) e depois de efetuar o que quiser, irá retornar para a função original prosseguir.
      Talvez mais fácil visualizar o que expliquei com código:
      //Aqui está a função //ZwWriteVirtualMemory | NtWriteVirtualMemory, originada do binário: ntdll.dll //créditos ao https://undocumented.ntinternals.net/ NTSYSAPI NTSTATUS NTAPI //WINAPI NtWriteVirtualMemory( IN HANDLE ProcessHandle, IN PVOID BaseAddress, IN PVOID Buffer, IN ULONG NumberOfBytesToWrite, OUT PULONG NumberOfBytesWritten OPTIONAL ); //Sua versão assembly 777F2110 mov eax,0x3A 777F2115 mov edx,ntdll.77808D30 777F211A call edx 777F211C ret 0x14 //O que nós vamos fazer é criar uma função similar á ela com o nome que decidirmos //Então vamos inserir um jmp no início da função original para nossa função, ficando assim: 777F2110 jmp api inspector.573523EC 777F2115 mov edx,ntdll.77808D30 777F211A call edx 777F211C ret 0x14 //Usei como exemplo minha próprio ferramenta! //Então quando ocorrer a chamada desta função ela será jogada em nossa função! Depois de nós fazermos que desejar vamos retorna-la, porém para uma região que aloquei onde contém //Um buffer dos bytes que foram sobrescritos da função original: 03610000 mov eax,0x3A 03610005 jmp ntdll.777F2115 //Ela irá retornar depois do jmp que existe na função original e continuar o código.... Vantagens de se utilizar o API Inspector ao invés de um debugger
      Imagine que você está visualizando as chamadas intermodulares (para bibliotecas externas, no caso) que um programa faz, utilizando um debugger (o x64dbg por exemplo) e notou que uma certa função que deseja inspecionar é chamada em diversos pontos do programa. Vejo duas opções neste caso: colocar vários breakpoints, um em cada chamada à função, no código do programa ou colocar um único breakpoint função em si, no código dela, na DLL.
      Em ambos os casos, você vai precisar analisar chamada por chamada, parâmetro por parâmetro. E se a função for chamada 20 vezes consecutivamente? O tempo que você levaria para visualizar apenas o primeiro parâmetro da chamada é o tempo que a ferramenta iria levar para exibir todas as 20 chamadas, com os argumentos formatados bonitinhos ao seu dispor. Entende a vantagem? 🙂
      E as desvantagens?
      Por hora, uma desvantagem é a quantidade de funções e API's suportadas. De fato, a primeira release não possui uma quantidade significativa que vá fazer você utilizar a ferramenta e nem uma quantidade de recursos interessantes na ferramenta. Mas é ai que vem o ponto chave, o fato de deixar ela pública remete ao próprio crescimento da mesma, no primeiro momento é necessário uma orientação da parte de vocês para me ajudar a melhorar o código visual. O segundo passo é eu e vocês começarem a fornecerem mais recursos para ela. Eu irei adicionar todo ou qualquer recurso que seja significativo para a mesma, e para isso eu já tenho mais funcionalidades para implementar na ferramenta que são excelentes.
      Interface gráfica
      Na imagem abaixo, utilizei o API Inspector para hookar a função MessageBoxW() da USER32.DLL. Depois disso, escrevi um texto num novo arquivo no Notepad++ e tentei fechar o programa. Ao fazer isso, o Notepad++ perguntou se eu queria salvar o arquivo e ele faz isso através de uma chamada à MessageBoxW(), que o API Inspector interceptou prontamente.

      Na imagem acima, a janela à esquerda mostra o que está atualmente passando pelas funções hookadas. Na janela a direita, temos um log.
      Como utilizar o API Inspector
      A única coisa que você precisa fazer é anexar a DLL do API Inspector ao processo desejado e para isso existem os softwares chamados "Injetores de DLL" que podem ser achados na internet.
      Você também pode criar o seu próprio injetor. Uma dica é pesquisar sobre injeção com a função LoadLibrary(), mas no exemplo a seguir eu vou mostrar como utilizar o Process Hacker para fazer a injeção.
      1 - Abra o Process Hacker e identifique no mesmo o processo no qual você quer injectar a DLL do API Inspector. No exemplo, usei o processo do Notepad++.

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

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

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

      Após isso você precisa selecionar a API desejada, a função desejada e clicar em GO Hook!
      O step call é uma funcionalidade que vai fazer a ferramenta aguardar o pressionamento da tecla ENTER para retornar para a função original. Pronto, o seu hook está feito e você já poderá inspecionar a função desejada.
      Download e código
      No repositório do API Inspector no Github você pode baixar a versão compilada e ter acesso ao código-fonte também. Contribuições são muito bem vindas!
      Bom, eu nunca tinha escrito um artigo. Se faltou informação ou coloquei informação demais me desculpe. Estou aberto pra ler os comentários. Ah, e participem deste projeto! Eu quero fazer ele crescer muito. Caso precise de referências de como cheguei a este projeto, tem tudo na página inicial do projeto no Github.
      Agradecimentos
      Obrigado novamente ao Fernando Mercês, ao pessoal do Terra 1337 que me incentiva cada vez mais e em especial para o iPower e Luan que são colaboradores do projeto.
      Referências
      Dear ImGui Programming reference for the Win32 API NTAPI Undocumented Functions C++ 3D DirectX Programming
    • By ncaio
      [- Primeiros passos com exemplo -]
      Este tópico tem como finalidade esclarecer alguns pontos sobre hardware hacking. Se você é um hobbyist como eu, muitas das vezes, pelo o fato da informalidade, não temos a preocupação de explorar uma vulnerabilidade, quebrar alguma proteção, fazer auditoria ou engenharia reversa. Geralmente alteramos um hardware para uma necessidade particular ou apenas por curiosidade. Mas isso não significar fazer de qualquer forma, sem controle e sem motivação. Vale também salientar que é comum não ter progresso por falta da ferramenta certa ou de conhecimento.
      Neste tópico iremos discutir sobre passos a serem seguidos, tanto por iniciantes, como por intermediários. Assim como profissionais e amadores. Claro, contribua e compartilhe o seu conhecimento, por favor.
      1 - Escolher;
      2 - Motivação!?;       
      3 - Catalogar;
      4 - Identificar pontos;    
      5 - Qual caminho devo seguir ?.
      Escolher
      A escolha é motivada por vários fatores, assim como mencionado anteriormente. E claro, em alguns casos não temos escolhas, o hardware chega a sua mão via propósitos profissional, pessoal ou aquele pedido amigo/familiar. Se você é iniciante e pode escolher por onde começar, inicie com o básico. Dê preferência a dispositivos que estão em seu campo de conhecimento, um access point, um controle remoto do portão, controle da TV e etc. 
      Motivação!?
      Se você escolheu um hardware aleatório para estudar/observar/explorar, provavelmente você não tem um objetivo especifico. Neste caso, a sua motivação é explorar e progredir. Se na escolha do hardware você já identificou pontos de mudança, como por exemplo: Mudar a cor do led que representa o power do seu access point que é vermelho para a cor azul. Essa será a sua motivação, pelo menos inicialmente. 
      Catalogar
      É muito importante conhecer o seu alvo. Neste ponto é onde identificamos os componentes eletrônicos, conectores e etc. Muitas vezes precisamos abrir, desmontar equipamentos e fotografar. Com relação a placas e componentes eletrônicos, tirar fotografias te permitirá identificar modelos e esquemas com bastante facilidade. E claro, é uma fonte de consulta rápida. Inicialmente, comece a catalogar as informações mais acessíveis e disponibilizadas pelo fabricante, quando possível.
      Identificar pontos
      Depois de coletar informações importantes do seu hardware, comece a identificar pontos promissores. Tais como: 
      Qual é o chip principal
      Conexões seriais
      Jtag
      I/O
      Memória
      E etc
      Procure se aprofundar em cada item, datasheet é a palavra principal neste passo. 
      Qual caminho devo seguir ?
      É hora de expandir a árvore. Você tá na base da raiz, e é aqui que as portas abrem, ou não. Se você não tinha uma motivação e chegou até aqui, é bem provável que encontrou um motivo. A dica é universal, comece pelo lado mais fácil, que você encontrou mais informações, que você tem as ferramentas corretas para seguir em frente. Geralmente, voltamos a passos anteriores para conseguir avançar por aqui.
      UM EXEMPLO PRÁTICO 1 - Escolher
      Vamos iniciar com algo bem aleatório. Simplesmente sai olhando o que tinha disponível e escolhi um console emulador que tenho guardado.
      2 - Motivação!?;
      Minha motivação é utilizar este dispositivo para exemplificar este tópico.
      3 - Catalogar
      Vamos dividir em sub tópicos.
      Informações básicos do equipamento
      Uma breve descrição: Dynavision CyberGame é um console que emula consoles, como: NES, SNES, MegaDrive e outras plataformas. É capaz de reproduzir vídeos e músicas. Tipo do dispositivo: Emulador Fabricante: Dynavision Modelo: CyberGame Versão: NA Destaques do Hardware
      CPU: PLACA MÃE: MEMÓRIA FLASH: SDRAM: NETWORK: ------------X-----------------X-------------X-------------X------------X--------------X------------- INTERFACE SERIAL: JTAG: FIRMWARE: BOOT: FOTOS: REFERÊNCIAS: Qual é a cara do device ?
      Fotografe o equipamento antes de desmontar. Alias, fotografar é um processo continuo. Para a sua organização, crie um diretório para guardá-las. Daqui para frente, irei adicionar imagens relevantes ao processo. O seu celular pode te auxiliar neste processo. 
      Visão externa
      Não apresenta acesso a parafusos de fixação. É necessário remover as abas laterais para ter acesso aos 2 parafusos de fixação.


      Visão interna geral
      Existem três partes. A placa principal e 2 periféricas. Uma periférica com RCA e alimentação, outra com o botão RESET POWER e o sensor do controle remoto.

      Visão da placa principal - Face Superior
      Já podemos identificar visualmente alguns componentes e conexões interessantes. Identificar  o  fabricante da placa é importante para pesquisar por modelo e ficha técnica, por exemplo. Não neste caso. Eu particularmente não obtive sucesso na minha busca. E para dificultar ainda mais, temos o CPU descaracterizado, sem identificação. 

      Visão da placa principal - Face Inferior
      Temos o modelo e fabricante da placa e um chip de memória da SAMSUNG.

       
      Postos de Destaque
      Como mencionado anteriormente, algumas informações foram "ofuscadas" e outras não. Vamos pegar cada um destes postos e discutir sobre eles.
      CPU - CHIP PRINCIPAL!?
      Temos um suposto chip principal, sem informações relevantes impressas nele. Até o momento,  não sabemos que chip é este e sua função. Mas deduzimos, pela justa posição na placa e o enorme  número de conexões/trilhas conectadas ao chip, que temos aqui um forte indicio para deduzir isso.

      Um chip de memória
      Instalado na face inferior da placa.

       
      Interface Serial !?
      Temos aqui um suposto UART serial. Para melhor entendimento, consulte o tópico: 

       
      Identificar esta interface UART fez toda a diferença no processo de identificação e catalogação. Foi possível acompanhar o processo de boot e salvar em um arquivo para visualização posterior. Segue em anexo o log.
      cutecom.log
      Vamos observar e tomar nota em alguns trechos do log. Iniciando pelas primeiras linhas. Temos informações relevantes a criação da ROM e informações sobre a memória NAND que conseguimos visualizar diretamente no chip.
      ü+++MMP RomCode ver 8000.4.0 2009/02/18 pwrc_cfg=a0000006 vic1_rawSts=00000020 keyscan4=00001980 iotraps=00000000 Read Id : ec-dc-c1-15-54-ec-dc-c1-15-54 NAND_TYPE: SAMSUNG u16PageNoPerBlk :64 u16PyldLen :2048 u16TotalBlkNo :4096 ecc_mode :0 Start to read DRAM_Init code from flash... Enter Load_PF u16PageNoPerBlk :64 u16PageSize :2112 u16PyldLen :2048 u16TotalBlkNo :4096 ecc_mode :0 Já entre as linhas  235-260, temos informações sobre o bootstrap: Red Hat Embedded Debug and Bootstrap (RedBoot),  podemos observar a possibilidade de interação com o RedBoot  == Executing boot script in 0.010 seconds - enter ^C to abort. E informações sobre a imagem de boot.
      RedBoot(tm) bootstrap and debug environment [ROM] ^MNon-certified release, version v2_0_28 - built 17:41:15, Apr 27 2010 ^MPlatform: SUNPLUS_MMP (ARM 9) ^MCopyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. ^MCopyright (C) 2003, 2004, eCosCentric Limited ^MCopyright (C) 2008, Sunplusmm v1.0.0.3 ^MRAM: 0x00000000-0x00f00000, [0x00200000-0x00f00000] available ^MLoad the kernel file: /Rom/image/8000_mmi.rap ^MLoad image from romfs! ^MFound the image entry point: 0x280040 ^Mg_Cfg_s.redbootCfg:0xc0000004 ^M== Executing boot script in 0.010 seconds - enter ^C to abort ^MRedBoot> go -c 0x280040 ^Mg_Cfg_s.redbootCfg:0xc0000004 ^M+do_go ^Mimage sel: 0, image_sel_set: 0 ^Mrmvb enable! ^MMask interrupts on all channels ^MID-CACHE sync and invalidate ^Mset up a temporary context. workspace_end=0x00f00000, entry=0x00280040 ^Mswitch context to trampoline. workspace_end=0x00efffb0 Informações como : Load the kernel file: /Rom/image/8000_mmi.rap, Platform: SUNPLUS_MMP (ARM 9) e o datasheet, chegamos a conclusão que estamos que estamos diante de um chip/ic SPMP8000. 
    • By ncaio
      ====== Bem-vindo a bordo ======

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

       
×
×
  • Create New...