Engenharia reversa e modificação de hardware: interceptação de sensores ópticos de mouse

Este documento apresenta uma visão técnica da arquitetura interna de mouses ópticos e das principais técnicas utilizadas em engenharia reversa para observar, analisar, emular ou modificar a comunicação entre o sensor óptico e o microcontrolador (MCU).

O objetivo é compreender o caminho percorrido pelos dados desde a captura óptica da superfície até a geração do relatório USB HID recebido pelo sistema operacional.

Escopo: estudo de hardware próprio, desenvolvimento de periféricos, pesquisa, reparo e engenharia reversa autorizada.

1. Arquitetura geral de um mouse óptico

O fluxo típico pode ser representado assim:

┌──────────────┐
│  Superfície  │
└──────┬───────┘
       │
       ▼
┌────────────────────┐
│ Sensor óptico      │
│ + iluminação       │
│ + processamento    │
└─────────┬──────────┘
          │
          │ SPI / interface específica
          ▼
┌────────────────────┐
│ Microcontrolador   │
│ (MCU)              │
└─────────┬──────────┘
          │
          │ USB HID
          ▼
┌────────────────────┐
│ Computador         │
│ Windows / Linux    │
└────────────────────┘

Em termos funcionais:

O sensor observa a superfície através de uma lente.
A iluminação cria contraste suficiente para o sensor identificar características da superfície.
O circuito interno compara quadros sucessivos e calcula deslocamentos.
O sensor disponibiliza informações como X, Y, movimento, qualidade da superfície e estado de lift-off.
O MCU consulta essas informações.
O MCU combina movimento com botões, roda e outros controles.
O MCU transforma tudo em um relatório USB HID.
O sistema operacional interpreta o relatório como entrada de mouse.

É importante perceber que o sensor óptico normalmente não conversa diretamente com o Windows. Existe uma camada intermediária formada pelo MCU.

2. O sensor óptico

2.1 O sensor é mais do que uma câmera

É comum descrever um sensor óptico de mouse como uma "microcâmera". A analogia é útil, mas incompleta.

Internamente existe uma combinação de:

matriz de aquisição de imagem;
sistema de iluminação;
lente;
processamento digital;
algoritmos de correlação;
registradores de configuração;
lógica de detecção de movimento;
interface serial com o MCU.

O sensor normalmente não envia continuamente uma imagem para o computador.

Em condições normais, ele processa internamente as imagens e fornece algo muito mais compacto:

Imagem anterior
       +
Imagem atual
       ↓
Processamento interno
       ↓
ΔX / ΔY

Por isso, o MCU geralmente precisa apenas consultar os resultados do processamento.

2.2 Sensores PixArt

Sensores da PixArt são extremamente comuns em mouses modernos.

Por exemplo, o PMW3389 utiliza uma interface SPI de quatro fios e possui registradores específicos para identificação, movimento, resolução, configuração e leitura de dados. A própria PixArt especifica o PMW3389 como um sensor de navegação óptica com interface 4-wire SPI.

Outros sensores da família também utilizam SPI. A documentação e drivers de projetos de firmware aberto, como QMK, mostram suporte para sensores como PMW3360 e PMW3389 através de SPI.

Entretanto:

Não se deve assumir que todo sensor óptico utiliza exatamente a mesma interface.

Existem sensores com diferentes variantes de SPI e outros dispositivos que utilizam interfaces diferentes.

Portanto, o primeiro passo de uma engenharia reversa real é identificar o código exato do sensor.

3. O barramento SPI

Um sensor SPI típico pode possuir sinais semelhantes a:

MCU                  SENSOR

SCK   ─────────────► Clock
MOSI  ─────────────► Dados MCU → Sensor
MISO  ◄───────────── Dados Sensor → MCU
CS/NCS─────────────► Seleção do sensor

Alguns projetos também possuem sinais adicionais, como:

RESET
MOTION / IRQ
POWER
GND

O significado exato depende do sensor.

3.1 O MCU normalmente atua como mestre

Em uma implementação típica:

MCU = SPI Master
Sensor = SPI Slave

O MCU controla:

clock;
seleção do sensor;
momento da leitura;
registradores acessados;
configuração;
frequência de comunicação.

O sensor responde aos comandos enviados pelo MCU.

Isso significa que, para "assumir" a comunicação do sensor, não basta simplesmente gerar alguns bytes.

É necessário reproduzir o comportamento esperado pelo MCU.

4. O que realmente é transmitido pelo sensor

Um sensor como o PMW3389 possui registradores para diferentes tipos de informação.

Entre eles podem existir:

Product ID
Revision ID
Motion
Delta X
Delta Y
SQUAL
Resolution
Configuration
Motion Burst
Raw Data

Drivers de firmware aberto mostram, por exemplo, a existência de registradores como Motion, Delta_X, Delta_Y, Motion_Burst e RawData_Burst em sensores PixArt compatíveis.

Assim, a comunicação pode conceitualmente se parecer com:

MCU:
    "Leia o registrador de movimento"

Sensor:
    "Há movimento"

MCU:
    "Leia Delta X"

Sensor:
    "X = +37"

MCU:
    "Leia Delta Y"

Sensor:
    "Y = -12"

Ou, em determinados modos, vários valores podem ser obtidos em uma única operação de burst.

5. Motion Burst

Uma das características importantes de determinados sensores PixArt é o chamado Motion Burst.

Em vez de realizar várias transações independentes:

ler Motion
ler X
ler Y
ler SQUAL
...

o MCU pode iniciar uma operação de burst e receber uma sequência de informações.

Conceitualmente:

MCU
 │
 │ comando Motion Burst
 ▼
Sensor
 │
 ├── Motion
 ├── estado
 ├── Delta X
 ├── Delta Y
 ├── qualidade
 └── outros dados

Isso reduz o número de transações e permite uma aquisição mais eficiente.

Drivers reais de PMW3389 implementam esse mecanismo e também precisam respeitar temporizações específicas do sensor.

6. Temporização é uma parte crítica

Um dos erros mais comuns em uma tentativa de emulação é pensar:

"Se eu enviar os bytes corretos, funcionará."

Não necessariamente.

Sensores ópticos possuem requisitos temporais específicos para:

seleção por CS;
início do clock;
leitura de registradores;
escrita;
mudança de estado;
operação de burst;
inicialização;
carregamento de firmware interno/SROM, quando aplicável.

Por exemplo, implementações públicas para PMW3389 precisam inserir atrasos entre determinadas operações SPI.

Portanto, uma emulação precisa reproduzir:

PROTOCOLO
   +
FORMATO DOS DADOS
   +
TEMPORIZAÇÃO
   +
ESTADOS INTERNOS

Não apenas os bytes.

7. Engenharia reversa passiva: observar primeiro

Antes de tentar modificar qualquer coisa, a abordagem mais segura é simplesmente observar o barramento.

7.1 Logic Analyzer

Um analisador lógico pode ser conectado às linhas:

SCK
MOSI
MISO
CS

O objetivo inicial não é interferir.

É descobrir:

Quem transmite?
Quando transmite?
Qual frequência?
Qual modo SPI?
Qual registrador?
Qual sequência de inicialização?
Qual intervalo entre leituras?

Um exemplo conceitual:

CS ↓

MOSI:
02

MISO:
80

CS ↑

Isso pode indicar uma leitura do registrador 0x02, dependendo do protocolo específico do sensor.

7.2 O que procurar durante a captura

Uma captura completa pode revelar:

Inicialização

RESET
↓
IDENTIFICAÇÃO
↓
CONFIGURAÇÃO
↓
CARREGAMENTO DE SROM/FIRMWARE
↓
CONFIGURAÇÃO DE CPI
↓
MODO NORMAL

Operação normal

CS
↓
Comando de leitura
↓
Resposta
↓
CS

ou:

CS
↓
Motion Burst
↓
Motion
↓
X
↓
Y
↓
outros dados
↓
CS

A partir dessas informações é possível começar a reconstruir a máquina de estados do sensor.

8. Interceptação ativa: hardware Man-in-the-Middle

Depois de entender o barramento, existe uma abordagem mais complexa: inserir um dispositivo entre o MCU e o sensor.

Conceitualmente:

             ┌─────────────────┐
             │ Interceptor     │
             │ / FPGA / MCU    │
             └───────┬─────────┘
                     │
                     │
MCU ─────────────────┼──────────────── SENSOR

O objetivo pode ser:

MCU → interceptor → sensor
MCU ← interceptor ← sensor

O interceptor pode:

observar transações;
registrar dados;
alterar respostas;
substituir determinados valores;
em uma implementação mais avançada, emular completamente o sensor.

8.1 O problema do MISO

SPI não deve ser tratado como uma simples conexão de três fios.

O MISO é normalmente dirigido pelo dispositivo escravo selecionado.

Se dois dispositivos tentarem dirigir a mesma linha simultaneamente:

Sensor ──────┐
             ├──── MISO ──── MCU
Emulador ────┘

pode ocorrer contenção elétrica.

Isso pode causar:

comunicação corrompida;
aquecimento;
comportamento imprevisível;
potencial dano aos componentes.

Por isso, um projeto de MITM precisa considerar cuidadosamente:

controle de CS;
estado de alta impedância;
buffers;
switches analógicos/digitais;
níveis lógicos;
alimentação;
direção dos sinais.

9. Emulação completa do sensor

Em vez de modificar o sensor original, outra possibilidade é construir um dispositivo que se comporte como ele do ponto de vista do MCU.

O conceito é:

          MOUSE ORIGINAL

             MCU
              │
              │ SPI
              ▼
       ┌─────────────┐
       │ EMULADOR    │
       │             │
       │ "Sensor"    │
       └─────────────┘

O MCU acredita que está falando com o sensor original.

O emulador precisa responder às operações esperadas.

Por exemplo:

Read Product ID
        ↓
    retorna ID

Read Motion
        ↓
    retorna estado

Read Delta X
        ↓
    retorna X

Read Delta Y
        ↓
    retorna Y

10. Por que um Arduino comum não é necessariamente suficiente

Um ponto importante é que não basta ligar um Arduino diretamente no chip.

Existem pelo menos quatro questões:

1. Nível lógico

Sensores PixArt de alto desempenho podem operar em torno de 1,8–2,1 V. O PMW3389, por exemplo, é especificado pela PixArt nessa faixa.

Um Arduino de 5 V conectado diretamente pode danificar o sensor.

É necessário verificar:

Tensão do sensor
Tensão do MCU
Tensão dos GPIOs

e utilizar conversão de nível quando necessária.

2. Frequência

O MCU pode consultar o sensor em alta frequência.

3. Temporização

O emulador precisa responder dentro das janelas esperadas.

4. Máquina de estados

O sensor pode possuir estados diferentes durante:

Reset
Inicialização
Configuração
Normal
Burst
Sleep
Wake
Firmware/SROM loading

Por isso, para uma emulação precisa, um MCU rápido, FPGA ou hardware dedicado pode ser mais apropriado do que um Arduino clássico.

11. Substituição completa do sensor

Existe uma abordagem ainda mais interessante para projetos DIY:

PCB original
      │
      ├── MCU original
      │
      ├── botões
      │
      └── alimentação
             │
             ▼
      sensor substituto

Nesse caso, é necessário descobrir:

pinagem;
alimentação;
SPI;
CS;
MOTION;
RESET;
clock;
configuração;
formato dos dados;
requisitos da lente;
posição física do sensor.

A parte óptica também é crítica.

Um sensor pode funcionar eletricamente e ainda apresentar rastreamento incorreto se:

lente ≠ sensor esperado
altura ≠ especificação
iluminação ≠ adequada
distância focal ≠ correta

12. Firmware do sensor

Alguns sensores possuem memória interna ou recebem um firmware/SROM durante a inicialização.

Isso adiciona outra camada à engenharia reversa.

Um fluxo pode ser:

MCU
 │
 ├── Reset
 │
 ├── Identificação
 │
 ├── Habilita carregamento
 │
 ├── Envia SROM
 │
 ├── Verifica identificação
 │
 └── Inicializa operação normal

Implementações abertas para PMW3360/PMW3389 mostram rotinas de inicialização e, em determinados modelos, carregamento de firmware/SROM pelo SPI.

Isso significa que substituir o sensor pode exigir reproduzir também sua etapa de inicialização.

13. Modificação do firmware do mouse

Uma segunda estratégia é modificar o próprio firmware do MCU.

Em vez de interferir fisicamente no SPI:

Sensor → MCU

o código do MCU pode ser alterado para:

Sensor
   ↓
MCU
   │
   ├── movimento real
   │
   └── movimento gerado

A lógica poderia conceitualmente possuir:

if (modo_normal):
    ler_sensor()
    enviar_movimento()

if (modo_teste):
    ignorar_movimento_sensor()
    gerar_movimento()

Essa abordagem depende fortemente do MCU utilizado.

13.1 O firmware pode não ser facilmente extraível

Não se deve assumir que:

"Existe firmware no MCU"

significa:

"Posso simplesmente ler o firmware."

Microcontroladores podem utilizar:

proteção de leitura;
bootloaders;
memória interna protegida;
mecanismos de debug desabilitados;
firmware criptografado ou assinado.

A possibilidade de extração depende do fabricante e do MCU.

14. A camada USB HID

Depois que o MCU obtém o movimento do sensor, ainda existe outra etapa:

Sensor
   ↓
SPI
   ↓
MCU
   ↓
processamento
   ↓
USB HID
   ↓
Windows

O USB HID define como o dispositivo descreve seus dados para o sistema operacional.

O USB-IF mantém a especificação HID e as tabelas de usos oficiais.

15. Relatório HID de mouse

Um relatório simples pode conceitualmente ser:

Byte 0 = Botões
Byte 1 = X
Byte 2 = Y

Por exemplo:

[BUTTONS] [DX] [DY]

O importante é que X e Y normalmente representam movimento relativo, e não uma coordenada absoluta da tela.

A especificação HID fornece inclusive um exemplo de relatório de mouse com três botões e dois eixos relativos X/Y.

Assim:

Sensor:

ΔX = +20
ΔY = -5

       ↓

MCU:

X = +20
Y = -5

       ↓

USB HID:

[botões] [14h] [FBh]

       ↓

Sistema operacional:

cursor desloca
+20 X
-5 Y

O formato real, porém, depende do Report Descriptor do mouse.

16. Sensor hack × HID injection

É importante separar duas camadas diferentes.

Técnica	Camada	O que é manipulado
Sensor reverse engineering	Hardware interno	Comunicação sensor ↔ MCU
SPI MITM	Hardware interno	Transações SPI
Sensor emulation	Hardware interno	Respostas do sensor
Firmware modification	MCU	Lógica interna
HID injection	USB	Relatórios enviados ao PC
Software automation	Sistema operacional	Eventos depois do driver

A diferença fundamental é:

HID injection

PC
↑
USB HID
↑
Dispositivo

enquanto:

Sensor interception

PC
↑
USB HID
↑
MCU
↑
SPI
↑
Sensor

No segundo caso, a intervenção ocorre antes da camada USB.

17. Transformar o sensor em uma câmera

Alguns sensores possuem modos de acesso a dados brutos.

Isso é diferente do funcionamento normal.

No modo normal:

Imagem
   ↓
processamento interno
   ↓
ΔX / ΔY

Em determinados sensores, recursos de captura de dados brutos podem permitir:

Imagem
   ↓
dados brutos
   ↓
SPI
   ↓
MCU
   ↓
PC

Isso permite utilizar o sensor como uma espécie de câmera microscópica de baixa resolução.

Entretanto, a possibilidade e o formato dos dados dependem do modelo específico. Não é correto assumir que qualquer sensor de mouse pode simplesmente transmitir sua imagem inteira.

O PMW3360, por exemplo, possui recursos e registradores relacionados a dados brutos, além da leitura convencional de movimento.

18. Arquitetura de um projeto experimental

Uma plataforma de pesquisa poderia ser organizada assim:

                 ┌───────────────────┐
                 │ Computador        │
                 │ análise / logging │
                 └─────────┬─────────┘
                           │
                         USB
                           │
                 ┌─────────▼─────────┐
                 │ MCU / FPGA        │
                 │ experimental      │
                 └─────────┬─────────┘
                           │
                         SPI
                           │
                 ┌─────────▼─────────┐
                 │ Sensor óptico     │
                 └───────────────────┘

O MCU experimental pode ter duas funções:

Modo observação

Sensor → MCU → computador

Apenas coleta dados.

Modo emulação

Computador
     ↓
MCU
     ↓
"Sensor virtual"
     ↓
SPI
     ↓
outro MCU

Isso permite estudar o comportamento do dispositivo sem modificar imediatamente o mouse comercial.

19. Roteiro recomendado de engenharia reversa

Uma abordagem organizada seria:

Fase 1 — Identificação

[ ] Abrir o mouse
[ ] Fotografar a PCB
[ ] Identificar o sensor
[ ] Identificar o MCU
[ ] Identificar reguladores
[ ] Identificar memória externa
[ ] Identificar conectores

Fase 2 — Documentação

[ ] Encontrar datasheet do sensor
[ ] Encontrar datasheet do MCU
[ ] Encontrar pinagem
[ ] Identificar alimentação
[ ] Identificar SPI
[ ] Identificar sinais auxiliares
[ ] Identificar frequência do clock

Fase 3 — Observação

[ ] Conectar analisador lógico
[ ] Capturar inicialização
[ ] Capturar operação normal
[ ] Identificar leituras
[ ] Identificar escritas
[ ] Identificar burst
[ ] Medir intervalos

Fase 4 — Reprodução

Primeiro reproduzir somente uma operação simples:

MCU → sensor
      ↓
    leitura
      ↓
resposta correta

Depois:

Inicialização
      ↓
Identificação
      ↓
Configuração
      ↓
Leitura de movimento
      ↓
Burst

Fase 5 — Emulação

Somente depois de compreender o protocolo:

MCU
 │
 │ SPI
 ▼
Emulador

O emulador começa respondendo apenas às operações necessárias.

Fase 6 — Integração

Finalmente:

Mouse original
       ↓
sensor removido
       ↓
emulador
       ↓
MCU original
       ↓
USB HID
       ↓
PC

O objetivo é verificar se o MCU continua funcionando como se estivesse conectado ao sensor original.

20. Equipamentos úteis

Para esse tipo de pesquisa, os equipamentos mais úteis são:

Básicos

multímetro;
fonte de bancada;
ferro de solda;
estação de ar;
fios finos;
microscópio ou câmera macro.

Análise

analisador lógico;
osciloscópio;
pontas de prova adequadas;
adaptadores/breakouts.

Desenvolvimento

MCU com SPI;
FPGA, para experimentos que exigem temporização muito precisa;
conversores de nível lógico;
protoboard ou PCB experimental.

21. Cuidados elétricos

Antes de conectar qualquer equipamento:

Tensão do sensor
        ≠
Tensão do Arduino

não deve ser ignorada.

É necessário verificar:

VCC
GND
VIH
VIL
VOH
VOL

Além disso:

não aplicar 5 V diretamente em um dispositivo de 1,8 V;
não unir duas saídas digitais sem verificar a arquitetura;
evitar conectar simultaneamente dois mestres SPI;
confirmar quem controla CS;
verificar se o dispositivo entra em alta impedância quando não selecionado;
limitar a alimentação durante os primeiros testes.

22. Pontos que não devem ser presumidos

Algumas simplificações comuns podem levar a uma conclusão errada.

❌ "Todo mouse usa SPI"

Não.

É necessário identificar o sensor e sua interface.

❌ "O sensor envia coordenadas diretamente"

Não exatamente.

O sensor normalmente processa imagens e disponibiliza resultados de movimento através de registradores ou bursts.

❌ "É só trocar o sensor por um Arduino"

Não.

É necessário reproduzir protocolo, temporização, estados, alimentação e comportamento esperado.

❌ "Qualquer Arduino pode trabalhar diretamente com o sensor"

Não.

O nível lógico e a frequência precisam ser compatíveis.

❌ "O firmware do mouse pode sempre ser extraído"

Não.

O MCU pode possuir mecanismos de proteção.

❌ "O sensor é simplesmente uma câmera"

Também não.

Ele contém processamento especializado para navegação óptica.

23. Comparação das abordagens

Abordagem	Dificuldade	Alteração física	Conhecimento necessário
Observar SPI	Baixa/Média	Pequena	SPI + eletrônica
Analisar firmware	Alta	Pode ser nenhuma	Arquitetura + reversing
MITM SPI	Alta	Sim	SPI + eletrônica digital
Emular sensor	Muito alta	Sim	SPI + firmware + timing
Substituir sensor	Alta	Sim	Hardware + óptica
Criar mouse próprio	Média/Alta	Total	Hardware + firmware
Modificar HID	Média	Depende	USB + firmware

24. Modelo mental completo

A maneira mais útil de pensar no sistema é dividir tudo em camadas:

┌─────────────────────────────┐
│          WINDOWS            │
│       Aplicação / OS        │
└──────────────┬──────────────┘
               │
               │ USB HID
               ▼
┌─────────────────────────────┐
│            MCU              │
│                             │
│  Botões                     │
│  Roda                       │
│  Sensor                     │
│  Processamento              │
│  Firmware                   │
└──────────────┬──────────────┘
               │
               │ SPI
               ▼
┌─────────────────────────────┐
│      SENSOR ÓPTICO          │
│                             │
│  Imagem                     │
│  Correlação                 │
│  ΔX / ΔY                    │
│  SQUAL                      │
│  Lift detection             │
│  Configuração               │
└──────────────┬──────────────┘
               │
               │ Óptica
               ▼
┌─────────────────────────────┐
│         SUPERFÍCIE          │
└─────────────────────────────┘

Consequentemente, existem três pontos principais de intervenção:

             ┌── Sensor
             │
Superfície → Sensor → SPI → MCU → USB HID → PC
                         │
                         └── Firmware

Quanto mais próximo do sensor se trabalha, mais baixo é o nível da intervenção.

25. Conclusão

Interceptar ou substituir um sensor óptico de mouse não significa simplesmente "mandar coordenadas para o mouse".

O processo envolve várias camadas:

Óptica
  ↓
Aquisição de imagem
  ↓
Processamento interno do sensor
  ↓
Registradores / Motion Burst
  ↓
SPI
  ↓
Firmware do MCU
  ↓
USB HID
  ↓
Sistema operacional

A abordagem mais sólida para estudar o sistema é começar pela observação passiva do barramento, identificar o protocolo e somente depois avançar para emulação ou modificação.

Em especial, a combinação:

Datasheet
+
Logic Analyzer
+
Firmware aberto
+
Osciloscópio
+
MCU/FPGA

permite reconstruir progressivamente o funcionamento do periférico sem precisar começar diretamente por uma modificação destrutiva.

O ponto central da engenharia reversa é transformar o dispositivo de uma "caixa-preta" em uma sequência observável de estados:

IDENTIFICAR
     ↓
OBSERVAR
     ↓
DECODIFICAR
     ↓
REPRODUZIR
     ↓
EMULAR
     ↓
MODIFICAR

Esse mesmo método pode ser aplicado não apenas a mouses, mas também a trackballs, sensores ópticos, teclados, controles, dispositivos USB e diversos outros sistemas embarcados.

Referências técnicas

USB-IF — HID Specifications and Tools: especificação da classe USB HID e Usage Tables.
USB-IF — HID 1.11: exemplo de Report Descriptor de mouse e definição de X/Y relativos.
PixArt — PMW3389DM-T3QU: características oficiais, alimentação e interface SPI do sensor.
PixArt — Optical Mouse Sensors: comparação de diferentes sensores ópticos, incluindo PMW3360 e PMW3389.
QMK — drivers PMW3360/PMW3389: implementação aberta de comunicação SPI, registradores, burst e inicialização.
SunjunKim/PMW3360: biblioteca Arduino para comunicação com PMW3360 e leitura de dados de movimento.