
KeySweeper é um dispositivo furtivo baseado em Arduino, camuflado como um carregador de parede USB funcional, que espiona, descriptografa, registra e reporta (via GSM) sem fio e passivamente todas as teclas digitadas de qualquer teclado sem fio da Microsoft nas proximidades.
KEYSWEEPER // SIGINT // SAMY.PL // REL TO ALL // HACKING APLICADO
KeySweeper é um dispositivo discreto baseado em Arduino, camuflado como um carregador de parede USB funcional, que captura, descriptografa, registra e envia de volta (via GSM) sem fio e passivamente todas as teclas digitadas de qualquer teclado sem fio da Microsoft nas proximidades.
Todas as teclas digitadas são registradas online e localmente. Alertas por SMS são enviados ao digitar palavras-gatilho, nomes de usuário ou URLs, expondo senhas. Se desconectado, o KeySweeper continua operando usando sua bateria interna e recarrega automaticamente ao ser religado. Uma ferramenta baseada na web permite o monitoramento ao vivo das teclas digitadas.
Demonstração ao vivo e detalhes completos disponíveis no vídeo:
Ponto de contato: @SamyKamkar // [email protected] // http://samy.pl
Lançado: 12 de janeiro de 2015
Código-fonte / esquemático: https://github.com/samyk/keysweeper
Custo unitário: $10 - 80 dependendo da operação
Status: Operacional, código aberto, hardware aberto, desclassificado.
KeySweeper é um dispositivo discreto baseado em Arduino, camuflado como um carregador de parede USB funcional, que captura, descriptografa, registra e envia de volta sem fio e passivamente todas as teclas digitadas de qualquer teclado sem fio da Microsoft (que usa um protocolo RF proprietário de 2.4GHz) na área.
As teclas digitadas são enviadas de volta ao operador do KeySweeper pela Internet via um chip GSM opcional, ou podem ser armazenadas em um chip flash e entregues sem fio quando um dispositivo KeySweeper secundário entra no alcance sem fio do KeySweeper alvo. Uma ferramenta baseada na web permite o monitoramento ao vivo das teclas digitadas.
O KeySweeper tem a capacidade de enviar alertas por SMS quando certas teclas são digitadas, por exemplo, "www.bank.com". Se o KeySweeper for removido da energia CA, ele parece desligar, no entanto continua operando de forma encoberta usando uma bateria interna que é recarregada automaticamente ao ser reconectado à energia CA.
O KeySweeper estende o trabalho de Travis Goodspeed no projeto goodfet.nrf e de Thorsten Schröder e Max Moser do projeto KeyKeriki v2.0.
$3 - 30: Um microcontrolador Arduino ou Teensy pode ser usado. Na minha montagem, uso um Arduino Pro Mini de 3.3v devido ao seu perfil muito fino.
$1: Eu uso um chip RF nRF24L01+ de $1 que se comunica usando GFSK em 2.4GHz. Mais detalhes estão disponíveis abaixo, e esses chips podem ser comprados por apenas $1 no eBay. Esses chips só podem se comunicar usando protocolos proprietários e não foram feitos para captura de pacotes; no entanto, veremos abaixo que podem ser usados de maneiras inteligentes para capturar de forma promíscua.
$6: Eu uso um carregador USB CA barato (retificador) que converte energia CA em 5V CC, e este que linkei tem um parafuso que facilita a abertura (destruí alguns outros no processo de abertura). Se estiver usando a versão GSM do KeySweeper, na verdade uso dois carregadores USB — os componentes internos de um carregador pequeno (semelhante ao de um carregador de iPhone) e o invólucro externo de um carregador USB maior.
OPCIONAL ($2): Um chip Flash Serial SPI opcional pode ser usado para armazenar as teclas digitadas. Se você usar a placa GSM FONA abaixo, isso não é necessário, pois as teclas podem ser armazenadas pela internet ao vivo; porém, se desejar uma opção de menor custo, você pode armazenar as teclas neste chip dentro do KeySweeper e obtê-las mais tarde aproximando-se do alcance sem fio de 2.4GHz do dispositivo com um dispositivo secundário, que fará a extração das teclas dele.
A maioria dos microcontroladores tem memória ou EEPROM muito limitada para armazenar dados, daí a vantagem de ter um chip flash para armazenar essas teclas.
OPCIONAL ($45): A Adafruit criou uma placa chamada FONA que permite usar um cartão SIM 2G para enviar/receber SMS, chamadas telefônicas e usar a Internet diretamente do dispositivo.
Com isso, nenhum chip flash é necessário, pois as teclas são imediatamente enviadas a um servidor backend para a coleta adequada de dados. Além disso, se palavras-chave específicas forem digitadas pelos teclados alvo, uma mensagem SMS pode ser enviada para um número especificado para alertar o operador do fato.
OPCIONAL ($3, apenas se usar FONA): A FONA requer um cartão mini-SIM (não um micro-SIM). Eu uso um cartão SIM pré-pago da T-Mobile. Sugiro o uso da T-Mobile, pois eles suportam 2G, enquanto a maioria das outras operadoras já desativou ou está desativando sua rede 2G, e a FONA só suporta 2G para Internet. Certifique-se de obter o tamanho certo do cartão SIM — mais detalhes em requisitos de SIM da FONA aqui.
OPCIONAL ($5 ou mais, apenas se usar FONA): A FONA fornece recarga de bateria LiPo/LiOn integrada, e enquanto o KeySweeper estiver conectado à energia CA, a bateria será mantida carregada, mas ainda assim é necessária. Além disso, o KeySweeper continua operando de forma encoberta com energia da bateria quando é removido da energia CA e começa a recarregar ao ser reconectado à energia CA.
O código-fonte do KeySweeper pode ser obtido integralmente no meu github: https://github.com/samyk/keysweeper
O KeySweeper tem várias partes. O código principal é instalado no microcontrolador, enquanto um backend baseado na web usando jQuery e PHP registra todas as teclas digitadas e fornece uma interface web para monitoramento ao vivo dos teclados alvo.
O KeySweeper também precisa dos seguintes arquivos da biblioteca RF24 do maniacbug:
RF24.hnRF24L01.hRF24_config.hBasta copiar os arquivos para o diretório keysweeper_mcu_src. Você também precisa alterar a instrução #include no arquivo RF24.h de #include <RF24_config.h> para #include "RF24_config.h".
Você deve usar minha versão da biblioteca Adafruit FONA, pois incluo uma opção adicional que permite à FONA nos avisar quando há uma nova mensagem de texto. Na biblioteca original, você precisa fazer polling constantemente para ver se há mais mensagens de texto do que o esperado; porém, com minha versão, você pode habilitar uma opção fona.setSMSInterrupt(1), que faz o pino RI (Ring Interrupt) ir para nível baixo por um momento ao receber novas mensagens SMS.
Criei uma ferramenta backend que permite monitorar teclados ao vivo por meio de uma página web. O plugin jQuery Terminal faz com que pareça mais legal.
O jQuery UI Virtual Keyboard continua fazendo a ferramenta de interface de espionagem ao vivo do KeySweeper parecer legal, mostrando teclas no teclado virtual sendo pressionadas quando o usuário pressiona de fato as teclas.
Ao obter um teclado sem fio da Microsoft, se estiver em nossa posse, podemos olhar na parte traseira para inspecionar o ID FCC. No meu teclado, o ID FCC (que é obrigatório para todos os dispositivos que usam radiofrequência nos EUA) é C3K1455, que podemos pesquisar facilmente no site da FCC.
Imediatamente descobrimos que o teclado se comunica em 2403 - 2480MHz com base no relatório da FCC.
Agora que sei que este é um dispositivo de 2.4GHz, presumo que esteja operando com um protocolo comum de 2.4GHz, como wi-fi, bluetooth, zigbee ou outros, ou que esteja usando um protocolo proprietário. Devido ao fato de o dispositivo vir com seu próprio dongle USB (com seu próprio ID FCC, C3K1461), é muito provável que seja um sinal proprietário de 2.4GHz.
Como provavelmente é 2.4GHz proprietário, precisamos agora usar algum método de captura de 2.4GHz. Sniffers de wifi não ajudarão, pois isto não é 802.11 (como o que usamos no SkyJack), e o RTL-SDR sozinho também não ajudará, pois seu limite é em torno de 2.2GHz, a menos que usemos adicionalmente um conversor de RF (down converter) (usamos RTL-SDR no Digital Ding Dong Ditch), então imediatamente quero usar o HackRF, um rádio definido por software poderoso e barato; no entanto, embora seja extremamente poderoso pelo preço, talvez possamos nos safar com hardware mais barato.
Com base em experiências anteriores, minha suposição é que o teclado está usando algo como um Nordic nRF24L01+, um TI CC2500, ou Cypress CYRF6936, mas não saberemos com certeza sem uma inspeção adicional.
Depois de remover os parafusos do teclado e abri-lo, vemos um único chip responsável por tudo. Ele está etiquetado como NRF 24LE1H, o que parece muito com nRF24L01 (n=Nordic Semiconductor, RF=Rádio Frequência, 24=2.4GHz)! Rapidamente encontramos o chip nRF24LE1 com uma busca e vemos que ele de fato tem o chip RF nRF24L01+ integrado a uma CPU (System-on-Chip/SoC), e uma busca rápida no eBay mostra que o nRF24L01+ pode ser enviado para nós por menos de $1.
The nRF24LE1 integrates an nRF24L01+ 2.4GHz RF transceiver core, enhanced 16MHz 8-bit 8051 compatible CPU, 1kB + 256B RAM, 16kB embedded Flash, and a wide range of system peripherals
Olhando a folha de dados do nRF24L01+, vemos que este é um chip RF de 2.4GHz que opera a 250kbps/1Mbps/2Mbps, usa GFSK (modulação por chaveamento de frequência gaussiana é uma modulação digital de frequência/FM) e, infelizmente, não possui qualquer modo promíscuo ou direto legítimo para captura... ou será que possui?
Embora eu normalmente usasse algo como um HackRF ou RTL-SDR com conversor digital de frequência (para trazer 2.4GHz para a faixa do RTL-SDR), seria muito bom se pudéssemos capturar com hardware mais barato, pois, em última análise, quero embalar tudo em um dispositivo que possa ser deixado em campo.
Após uma busca básica, apareceu uma página incrível de Travis Goodspeed, onde ele não apenas captura um teclado semelhante (Microsoft Comfort Desktop 5000), mas também demonstra como transformar o nRF24L01+ em um sniffer de 2.4GHz usando seu dispositivo GoodFET e um computador host com o aplicativo python goodfet.nrf.
Travis descobriu que capturar com o dispositivo é tradicionalmente difícil porque você não precisa apenas especificar o canal (frequência) para escutar; é preciso especificar um endereço MAC para escutar. O chip nRF só entrega pacotes enviados para aquele endereço MAC específico. Além disso, o chip nRF não informa o endereço MAC, já que você mesmo o especificou (presume-se que ele esteja em um de nossos pipes RX_ADDR_P[0-5], encontrados na folha de dados).
No entanto, ao especificar o comprimento do MAC, Travis descobriu que há uma opção considerada "ilegal" na folha de dados (SETUP_AW, 0x03 set to 00), mas que na verdade define o MAC para 2 bytes! Além disso, ao definir o MAC para dados que normalmente seriam encontrados no preâmbulo (0x00AA or 0x0055, in binary 0000000010101010 or 0000000001010101), podemos enganar o dispositivo para nos entregar o pacote antecipadamente, fornecendo um endereço MAC completo na porção de dados! Leia seu excelente artigo para todos os detalhes.
Embora possamos usar um GoodFET, computador e nRF24L01+ para captura durante os testes, em última análise queremos que isso esteja em um dispositivo embarcado e barato. Podemos pegar parte do ótimo trabalho de Travis em Python e portá-lo para C embarcado, de modo que possamos carregá-lo em um microcontrolador em vez de exigir computador+GoodFET.
Além disso, implementamos algumas melhorias. O Goodfet.nrf fornece um método de varredura de dispositivos executando o seguinte:
Isso significa que, para varrer a faixa completa de frequências, leva cerca de 85 minutos, e pelo menos várias teclas precisam ser pressionadas enquanto estamos capturando dentro do período correto de 10 segundos. Depois de revisar a pesquisa e o teclado de Travis, a pesquisa e o teclado do KeyKeriki, e meu próprio teclado, podemos implementar algumas melhorias:
0xAA (10101010), porque o preâmbulo de 0xAA é sempre seguido por um bit 1 (0xCD is 11001101) para manter os bits alternados, reduzindo nossa busca pela metadeThorsten Schröder e Max Moser apresentaram um ótimo dispositivo, o KeyKeriki, capaz de capturar teclados da Microsoft e fizeram a engenharia reversa completa do processo de descriptografia, produzindo um dispositivo para isso. No entanto, Travis ressalta que o dispositivo deles exige dois rádios e um microcontrolador de alto desempenho para capturar e analisar pacotes na velocidade de 2Mbps com a qual os teclados se comunicam. O projeto de Travis também é ótimo, porém exige um computador host e será grande demais para nossa implementação encoberta. Nesse cenário, melhoramos esses designs exigindo apenas um rádio e um microcontrolador baratos, ambos de baixo consumo e muito pequenos, sem necessidade de computador ou rádios sofisticados.
Thorsten e Max descobriram que as teclas digitadas são simplesmente criptografadas (com XOR) com o endereço MAC no modo ECB, que somos capazes de capturar após usar o método de Travis de abusar do nRF24L01+ para capturar e revelar endereços MAC ao mesmo tempo. Essa "criptografia" equivale a pegar um baralho, cortá-lo uma vez e chamá-lo de embaralhado.
Após investigação adicional, descobri que, como agora sabemos que todos os teclados da Microsoft começam com 0xCD como endereço MAC, o pressionamento de tecla real (em laranja abaixo) acaba alinhado com o primeiro byte do endereço MAC (0xCD). Isso significa que mesmo que não saibamos o endereço MAC, podemos descriptografar o pressionamento de tecla, pois o alinhamento nunca mudará, e 0xCD é sempre o primeiro byte do MAC.
Uma descoberta adicional é que, como o comprimento da porção criptografada do pacote é de 11 bytes, o MAC tem 5 bytes e o CRC é cada byte com XOR com outro (antes da criptografia), algo interessante acontece. Como o MAC é submetido a XOR duas vezes, também podemos calcular o checksum sem conhecer o endereço MAC. Isso ocorre porque o endereço MAC está presente duas vezes por completo, e aplicar XOR a qualquer número com ele mesmo (ou aplicar XOR no MAC com o MAC) se anula. O 11º byte é novamente o primeiro byte do MAC, que sempre sabemos ser 0xCD. Isso nos permite realizar outros ataques, como alterar o pressionamento de tecla e o CRC, novamente sem conhecer o endereço MAC. Apresentarei isso e algumas outras demonstrações divertidas em um projeto futuro.
Uma página da apresentação do KeyKeriki demonstra o processo de descriptografia:
Nosso método de descriptografia, implementado no código-fonte do KeySweeper:``` // decrypt those keyboard packets! void decrypt(uint8_t* pkt) { // our encryption key is the 5-byte MAC address and // starts 4 bytes in (4-byte header is unencrypted) for (int i = 4; i < 15; i++) pkt[i] ^= mac >> (((i - 4) % 5) * 8) & 0xFF; }
# (U) Construindo / Usurpando um Carregador USB
**AVISO: Dispositivos conectados à rede elétrica CA usam alta tensão, e o dispositivo que estamos criando, que se conecta à CA, não é seguro, nem atende aos padrões típicos de segurança elétrica. Este é um dispositivo perigoso e, se usado ou construído incorretamente, pode matar, causar incêndio ou outros danos graves. Não construa um dispositivo alimentado por CA a menos que você saiba o que está fazendo. Se quiser continuar construindo este dispositivo, mas sem energia CA, basta usar uma bateria ou alimentar o dispositivo diretamente via USB para acompanhar com segurança.**
O KeySweeper usa hardware de perfil baixo e consumo de energia extremamente baixo para permanecer o mais encoberto possível. O KeySweeper pode ser operado por bateria ou por alimentação CC de ~3-20V. Como desejamos manter o KeySweeper sempre alimentado, nós o instalamos furtivamente dentro de um inocente carregador USB de parede que esperamos que esteja sempre plugado.
Caso o carregador USB seja desconectado, o KeySweeper continua furtivamente suas operações usando sua bateria interna (opcional). No momento em que o KeySweeper é plugado novamente, ele volta a usar a energia CA e, simultaneamente, recarrega a bateria.
Se você está construindo o KeySweeper apenas **sem** a placa GSM, pode caber tudo em um carregador USB de parede CA típico. Sugiro procurar um que tenha um parafuso prendendo as partes, pois a maioria dos outros vem selado e exige a destruição de alguma parte do dispositivo para abri-lo.
[](http://samy.pl/keysweeper/usbopen.jpg)
Se você decidir usar a placa GSM, descobri que ela não caberia nesse tipo de carregador USB junto com o restante da eletrônica. No entanto, descobri que, ao abrir um carregador USB menor (semelhante aos carregadores USB do iPhone), encontramos um retificador (CA->CC) e um conversor abaixador de tensão (alta tensão->5V) muito menores, o que permite que **toda** a nossa eletrônica caiba no carregador USB maior.
[](http://samy.pl/keysweeper/usbcharger1.jpg)
[](http://samy.pl/keysweeper/usbcharger2.jpg)
Minha amiga Dana me emprestou seu ferro de soldar de bonecas. Não entendo bem para que ela o usa, mas é um ferro de soldar com uma lâmina acoplável. É ótimo para cortar plástico e, presumo, bonecas. Ela pegou o ferro de volta assim que expliquei o que o dispositivo faria. Aparentemente ela não aprova isso, embora eu não saiba por quê. Tenho certeza de que descobrirei depois de capturar mais teclas do teclado dela.
[](http://samy.pl/keysweeper/usbcharger3.jpg)
[](http://samy.pl/keysweeper/usbchargeropen.jpg)
**AVISO: Novamente, como estamos lidando com energia CA, isso é muito perigoso. Não abra/religue um dispositivo alimentado por CA a menos que você saiba o que está fazendo.** Você ainda pode construir o KeySweeper simplesmente alimentando tudo a partir de um carregador USB, porta ou bateria, sem modificar um dispositivo baseado em CA.
Também é importante conectar nosso Arduino pelo pino RAW à alimentação USB de 5v com a polaridade correta (negativo no GND, positivo no RAW). Neste caso, estou usando um Arduino Pro Mini de 3.3v. O pino RAW aceita tensão não regulada entre 3.35-12v e usa um regulador de tensão integrado para reduzi-la a 3.3v. Observe que o chip nRF24L01+ requer 1.9-3.6v, portanto fornecer 5v é **demais!** Além disso, se você estiver usando um chip SPI como o [SST25VF016B](http://ww1.microchip.com/downloads/en/DeviceDoc/S71271_04.pdf), ele requer 2.7-3.6v, então novamente usar 5v é **demais!** Certifique-se de usar os 3.3v regulados do Arduino (a partir do pino VCC em um Arduino de 3.3v, ou do pino 3V3 em um Arduino de 5v).
[](http://samy.pl/keysweeper/multimeter.jpg)
*nota: a placa USB mostrada ao lado do multímetro é a original antes de eu decidir trocá-la por uma menor para também caber a placa GSM*
Depois de reunir todo o nosso hardware, podemos ver que cabe tudo com folga no nosso carregador (antes da fiação):
[](http://samy.pl/keysweeper/testingsize.jpg)
Por diversão, conectei o LED do carregador ao pino 6 do Arduino e, embora o LED pareça se comportar da mesma forma, na verdade faço ele piscar ao capturar teclas digitadas. Isso provavelmente vai queimar seu disfarce, mas é muito divertido de assistir. Também garanto que o LED apague quando a energia CA for perdida, mesmo que o restante do dispositivo continue operando com a bateria interna.
Também queremos garantir que o restante do carregador USB continue operacional para que outros dispositivos possam continuar obtendo energia dele.

-----
# (U) KeySweeper Secundário Opcional
Se você quiser dispensar a placa GSM para reduzir custos, pode criar um dispositivo KeySweeper secundário contendo simplesmente um Arduino e um nRF24L01+. Ao compilar o secundário, descomente o `#define BACKTRACER 1`.
O funcionamento é o seguinte: se o KeySweeper secundário (BACKTRACER) alguma vez entrar no alcance sem fio (usando o nRF24L01+ de 2.4GHz) do primeiro, ele detecta automaticamente a existência do primeiro e o dispositivo KeySweeper inicial despejará seus logs no BACKTRACER. A autodetecção está embutida em ambos os KeySweepers para que eles possam se encontrar rapidamente, graças à capacidade do nRF24L01+ de ter múltiplos pipes de RX.
Se você tiver o BACKTRACER conectado a um computador, os keylogs serão despejados na porta serial, e você pode enviar um comando 'E' pela serial para apagar o conteúdo do chip de memória SPI Flash do KeySweeper original, agora que você obteve o conteúdo dele. Você pode ir embora permitindo que o KeySweeper original continue registrando teclas digitadas.
-----
# (U) Esquemático
Clique para ver a versão maior (esquemático baseado em FONA), ou [clique aqui](http://samy.pl/keysweeper/keysweeper.fzz) para o arquivo Fritzing.
[](http://samy.pl/keysweeper/keysweeper2_schem.png)
-----
# (U) Contato
**Ponto de Contato:** [@SamyKamkar](https://twitter.com/samykamkar)
Você pode ver mais dos meus projetos em <http://samy.pl> ou entrar em contato comigo em <[email protected]>.