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 dump, flashrom é 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: O bootloader.bin: geralmente não esta criptografado pelo fato do microcontrolador não poder descriptografar. 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. 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. 🙂

Trabalhei 100% remote quase 3 anos. 🙂 E agora eu tenho a opcao de home office 30% (que quase nao uso! Quando estou aqui, venho para o escritorio e tomo cafe com meus colegas 🙂 ) mas tenho q dizer q trabalhar remote te da muita liberdade e te ensina a trabalhar em qualquer lugar. Antes eu precisava sentar em um quarto sozinha para conseguir ler um artigo. Hoje em dia escrevo blog post e ate white paper sentada no chao do aeroporto esperando o boarding 😉 Reverteio malware durante o voo e quando chego ainda da tempo de escrever o report sentada em algum lugar esperando a janta chegar 🙂 A experiencia vale muito a pena!

barbie's hardware 101 Primeiro passo: Procure por portas de Debug Na verdade, esse deveria ser o passo zero, já que a primeira coisa que devemos fazer antes de começar qualquer outra coisa é dar uma boa olhada no hardware que você tem na mão. Nesse processo, faça uma lista das portas físicas que você tem acesso, conte os pinos que você vê, etc. O seu foco aqui é achar a porta de debug que geralmente é deixada na placa para reparos e suporte técnico. Essa porta está disponível em qualquer dispositivo (estamos falando de sistemas embarcados), ou seja, as queridas impressoras, câmeras de segurança, a torradeira no canto da cozinha, o roteador, etc. Outro fato importante: todo dispositivo mais complexo é um pouco mais fácil, pois estará provavelmente usando alguma versão do kernel Linux (que é open source :D). Se você não ver nenhuma porta de Debug diretamente, não desista. Muitas vezes elas estão um pouco escondidas e você terá que abrir o aparelho ou até romper algum lacre. 😉 As portas de debug são normalmente do tipo serial, UART, possuem de 4 a 6 pinos, e são literalmente desenhadas na placa. Sim, na PCB (placa) geralmente há uma marcação para a porta de debug, contornada, esperando para ser achada. 🙂 Como elas são feitas para o suporte técnico usar, elas não são cobertas, não tem um plug bonitinho esperando por você... Os conectores ou as ilhas (os buraquinhos na placa onde os fios ou terminais de componentes são soldados) vão estar soltos, sem proteção e não estarão conectados a lugar nenhum no dispositivo. Aqui o exemplo da placa do roteador FritzBox 4020: Localize as ilhas/conectores que não estão em uso e solde os pinos. Se a sua placa tem mais do que um CI (Circuito integrado), procure pelo principal e solde os pinos na porta que esta conectada a ele (geralmente a parte mais interessante está rodando lá de qualquer maneira!). Eu prefiro sempre soldar pinos para que fique mais fácil o acesso. Continuando É importante entender como o protocolo de transmissão da porta funciona. O protocolo de comunicação UART (Universal Asymchtonous Receiver / Transmitter) difere de outros protocolos de comunicação como o I2C, basicamente por ser um circuito físico do microcontrolador com a única função de transmitir e receber dados de forma serial. A parte boa é que por não ser de propósito geral como o USB, é possível transmitir dados usando apenas dois cabos entre dois dispositivos. Esse tipo de comunicação pode ser chamada de comunicação direta. Os dados são transmitidos do pino Tx (transmissor) da origem para o pino Rx (receptor) do destino. +-------+ +-------+ | | | | | Tx +-- --> Tx | | | ` . . ' | | | Rx +-- . ' ` . --> Rx | | | | | | GND +----------+ GND | | | | | +-------+ +-------+ Como o próprio nome diz, a transmissão de dados usando o protocolo UART é assíncrona, o que significa que não existe um relógio (sinal de clock) que sincronize os dados de saída do UART de origem com o os dados recebidos pelo UART de destino. Ao invés disso, o UART de origem adiciona bits de sinalização de "início" e "fim" em cada pacote de dados transmitido. Esses bits irão então definir o começo e o final de um pacote de dados de uma maneira que o UART de destino sabe onde começar e onde terminar a leitura. Quando o UART de destino recebe um "bit de início", ele começa a ler os dados recebidos na frequência chamada de baud rate (taxa de transferência). Essa frequência é a velocidade de transmissão de dados em bps (bits por segundo) e os dois UART devem estar operando na mesma frequência (ou com um erro de no máximo 10%) e a estrutura dos dados deve ser a mesma para que a comunicação ocorra sem problemas. Achando o output de cada pino: Até agora sabemos que as portas seriais possuem entre 4 e 6 pinos. Algo importante é saber que eles operam de acordo com a seguinte especificação ou "pinagem": Tx ou Transmitting: esse pino será conectado com o Rx do nosso leitor. Rx ou Receiving: esse pino será conectado com o Tx do nosso leitor. Vcc: POWER \o/ NÃO CONECTE! Geralmente 3.3V ou 5V. GND ou Ground (terra): esse será conectado com o GND do nosso leitor. (DTR e CTS) são dois pinos que não são obrigatórios e normalmente não são necessários. Talvez escreva mais sobre eles na próxima série! 🙂 Tx e Rx possuem o valor 1 / verdadeiro / ligado (por padrão). Proximo passo: Multímetro! Claro que você pode simplesmente olhar as conexões desenhadas na sua PCB e usar a técnica da "tentativa & erro", mas dependendo do dispositivo que você está analisando, pode acabar ficando caro 😉 Então o melhor é analisar um pouco mais a sua PCB antes de mandar sinais aleatórios e por fogo em tudo - been there, done that! not fun! E não é tão dificil assim 🙂 Geralmente um multímetro simples é o suficiente para nos oferecer a maioria das informações necessárias para dizer quem é quem na nossa plaquinha! Mas é claro que eu nunca direi não a um osciloscópio! 🙂 O osciloscópio não só nos dá "informações suficientes para deduzir" quem é quem, mas nos mostra exatamente quem é quem, de acordo com as especificações esperadas: O pino com valor 0V constante é o GND. O pino com valores constantes 3.3V ou 5V deverá ser o Vcc. Um dos pinos com valor flutuante próximo de 0V deve ser o Rx (faz sentido? Não? Pensa assim, Rx esta "escutando" mas não está conectado a nada ainda!) Yay! Agora que sabemos qual pino é qual, só falta saber a nossa taxa de transferência (baud rate) para montar o nosso leitor. Para descobri-la, a maneira mais facil que conheço é usando um analisador lógico: Conecte seus pinos, ligue (acione) a opção "análise de protocolo" e vai na adivinhação, simplesmente mudando o baud rate até você ver texto na saída de dados serial. Tendo o layout dos pinos e a taxa de transferência, nós podemos começar a nos comunicar com o dispositivo. \o/