Meu leitor de digital não tinha driver pro Linux. Então a IA fez um — na raça.

Como engenharia reversa e uma IA bem dirigida resolveram, num feriado, um problema que a internet dava como impossível.

Dia 4 de junho. Feriadão. A maioria das pessoas descansando, e eu ali, encarando um leitorzinho de impressão digital que eu tinha acabado de comprar no Mercado Livre por uns 80 reais.

A ideia era simples: parar de digitar senha e destravar o 1Password no dedo. Plugo no Windows, o Windows Hello reconhece na hora, cadastro, funciona. Reinicio no meu Zorin (Ubuntu por baixo) e… nada. O Linux via o aparelho e não fazia a menor ideia do que fazer com ele.

Antes de continuar, dois detalhes sobre mim que mudam tudo nessa história.

O primeiro: minha praia é arquitetura web. Eu não escrevo driver de Linux, nunca mexi com protocolo USB, não toco em C de baixo nível há um tempão. O que eu sei fazer mesmo é uma coisa só: pensar. Guarda isso.

O segundo: por que eu me importo tanto com o Linux funcionando direito? Porque eu vivo indo e voltando entre Linux e Windows, e esse vai e volta só aumentou com a IA. Várias ferramentas e MCPs que eu uso no dia a dia ainda penam horrores no WSL. Resultado: o Linux bare metal virou meu ambiente de trabalho de verdade. E ambiente principal sem login por digital me incomoda.

Então não, devolver o leitor não era uma opção.

O problema que a internet dava como morto

Fui pesquisar o bicho. Um MicroArray MAFP, USB 3274:8012.

Sem driver no kernel, em versão nenhuma. Sem suporte no libfprint (a biblioteca que cuida de digital no Linux). E o detalhe que me fez rir de nervoso: no linux-hardware.org tinha 53 máquinas com esse mesmo sensor. Status de todas? failed.

Cinquenta e três pessoas tentaram. Cinquenta e três desistiram. O protocolo era proprietário, fechado, sem uma linha de documentação em lugar nenhum.

Era a hora de devolver e comprar um compatível. Foi exatamente aí que eu resolvi não devolver.

E se a IA fizesse o driver?

Aqui mora o erro que quase todo mundo comete com IA: achar que é só pedir “faz um driver pra mim” e esperar a mágica cair do céu. Não funciona assim.

Eu chamei o Claude (rodando no Claude Code) não como gerador de código, mas como um engenheiro sênior que não cansa e não dorme. Alguém que lê hardware, escreve C e desmonta DLL sem reclamar. O trabalho pesado era dele. As decisões e as sacadas eram minhas.

Primeiro movimento dele: ler o driver do Windows que estava no meu disco, desmontar as DLLs e cravar três coisas que destravaram a parada. O canal USB era texto puro, sem criptografia. E o sensor fazia match-on-chip, ou seja, a digital nunca sai de dentro dele.

Difícil? Muito. Impossível? Não mais.

A sacada: e se a gente espionasse o Windows?

Pra escrever o driver, a gente precisava entender a conversa secreta entre o Windows e o sensor. E aí veio a ideia que virou a chave do projeto. Foi minha:

“E se a gente sobe uma VM com Windows, sob seu controle, e você fica espionando tudo lá de dentro?”

O Claude pegou a ideia e foi longe demais. Em poucos minutos ele tinha subido uma VM com Windows 11 inteira no QEMU/KVM, com UEFI, Secure Boot e TPM configurados do zero, e instalado o sistema sozinho, sem eu clicar em nada.

E aí veio a parte que me fez parar e olhar pra tela meio sem acreditar: como ele não enxerga monitor, ele tirava screenshot da VM e se guiava pelos prints. Clicava, digitava, instalava o driver de fábrica, tudo na base do “vê a imagem, decide o próximo passo”. Um Windows operado por uma IA enxergando por fotografia.

Com o driver original rodando lá dentro, a gente grampeou todo o tráfego USB pelo lado do Linux, usando o usbmon. Escuta telefônica, versão hardware.

O momento Sherlock

Essa foi a parte que me deixou de cara. Olhando os bytes capturados, o Claude reconheceu um padrão:

EF01 | FFFFFFFF | comando | tamanho | dados | checksum

Pra mim, que vivo de web, bateu uma familiaridade imediata. Aquilo era um contrato. Header, payload, checksum. Igualzinho a um endpoint bem desenhado, só que falando com silício em vez de JSON. E aquele 0xEF01 na frente entregou o jogo: era a família de protocolo R30x, a mesma de vários sensores de digital já documentados por aí.

Um protocolo “secreto” acabou de virar um sotaque de algo conhecido.

Daí foi decifrar comando por comando. Capturar imagem, extrair característica, comparar no chip, gravar template. Logo a gente tinha um protótipo em Python conversando com o sensor, e ele reconhecendo a digital que eu tinha cadastrado lá no Windows, agora pelo Linux. Primeiro MATCH na tela. Respirei.

Onde a IA quase se perdeu (e eu segurei a onda)

Agora a parte que ninguém te conta sobre usar IA pra valer.

IA é potente. Mas ela se empolga, e às vezes entra num looping cego, gastando recurso e teimando num caminho furado. É exatamente nessa hora que o humano tem que assumir o volante.

Teve um momento que resume tudo. O cadastro pelo sistema travava sem explicação, do nada, e o Claude já ia partir pra uma caçada gigante atrás de bug no código. Eu parei e perguntei uma bobagem:

“por acaso não é a VM?”

Era. Tinha sobrado um processo da máquina virtual rodando em segundo plano, roubando o sensor de volta no meio da operação. Cinco palavras minhas mataram uma hora de investigação que ia dar em nada.

Aconteceu de novo quando ele insistia em martelar o cadastro num loop frágil. Eu mandei parar e ir direto pro driver de verdade, onde aquele problema simplesmente não existia. E, de novo, a estratégia da VM monitorada que destravou tudo no começo: ideia minha, execução dele.

É essa a real da coisa. A IA é o motor. O volante é seu. Sem alguém dizendo a hora de acelerar, de frear e de apontar “ó, o problema tá ali”, ela vira uma ferramenta cara andando em círculo. Com direção, ela faz em horas o que levaria semanas.

A virada

No fim, foram 4 horas e 20 minutos. Num feriado.

Com o protocolo na mão, o Claude escreveu o driver de verdade. Um módulo libfprint em C, empacotado como TOD (o esquema de drivers do Ubuntu/Zorin) e instalado direto no sistema. Faltava um último nó, e foi um nó traiçoeiro: o reconhecimento só rolava "a quente". A solução foi uma única linha, um reset de USB na hora de abrir o dispositivo, que a gente só achou comparando friamente o que funcionava com o que não funcionava.

Coloquei a linha. Recompilei. Encostei o dedo.

Verify result: verify-match

A digital destravando o Linux. Login, tela de bloqueio, tudo via fprintd, com o nosso driver no meio do caminho. De "impossível, 53 máquinas falharam" pra funcionando nativamente, num feriado, com direito a repositório aberto pra próxima pessoa que comprar esse sensor não passar o que eu passei.

O que isso quer dizer pra você

Esse texto não é sobre um leitor de digital de 80 reais.

Reparou que “impossível” virou só “ainda não documentado”? Compatibilidade, interoperabilidade, hardware sem suporte, integração que “não dá”. Esse inferno todo virou território de caça. O que tomaria semanas de um especialista coube num feriado de quem nunca tinha escrito um driver na vida.

E essa é a sacada que importa: eu sou arquiteto web. Isso aqui estava a anos-luz da minha zona de conforto, e mesmo assim deu certo. Não porque eu sabia C, protocolo USB ou engenharia reversa. Eu não sabia nada disso. Deu certo porque eu sei pensar, e sei dirigir quem executa.

Não escrevi cada linha desse driver. Mas comandei cada decisão que fez ele existir. O conhecimento de domínio deixou de ser o gargalo. O gargalo agora é raciocínio, e coragem de não devolver o leitor.

O driver tá aberto no meu GitHub. Se você tem esse sensor, é clonar e rodar o install.sh. Deixa uma estrela lá, ajuda quem vier depois.

E se você tem um problema que todo mundo já disse que não tem jeito, daqueles de compatibilidade, hardware teimoso, integração que “não rola”, me chama no LinkedIn. Porque “impossível”, hoje, costuma ser só um problema que ninguém dirigiu a IA direito pra resolver.

Quem me acompanha sabe que isso aqui é meio a minha praia: já rodei até GitHub Actions na raça, sem push. Curtiu? Compartilha com aquele amigo que ainda acha que IA serve só pra escrever e-mail.