Imitação de digitação manual — o que está "sob o capô" dos antidetects populares?

Introdução

Hoje vamos falar sobre uma função que se tornou parte essencial do fluxo de trabalho de qualquer usuário de navegadores antidetect.

Paste Like Human Print (também conhecida como digitação semelhante à humana, ou PLHP) — é uma emulação da entrada de texto a partir da área de transferência, imitando o comportamento de um usuário real.

É uma ferramenta indispensável que economiza muito tempo e evita ações repetitivas ao trabalhar com múltiplas contas. Seu principal objetivo é minimizar o risco de restrições por parte de sistemas antifraude ao inserir texto em formulários em sites.

Cada produto chama essa funcionalidade de maneira diferente:

• Human Typing Simulation
• Paste as human typing
• Human typing emulation
• Smart Paste

O Linken Sphere foi o primeiro navegador antidetect a implementar a digitação semelhante à humana e oferecê-la ao mercado ainda no final de 2017. Na época, a maioria dos concorrentes não tinha pressa em adotar uma solução similar, alegando que essa funcionalidade não era demandada por um público amplo. No entanto, a prática mostrou o contrário: alguns anos depois, a tecnologia foi implementada em praticamente todos os produtos sérios deste segmento, tornando-se um padrão da indústria.

O impacto do método de entrada no sucesso do seu trabalho

Durante o trabalho, muitas vezes é necessário lidar com dados previamente preparados, por exemplo:

• Nomes, logins e endereços de e-mail ao registrar contas
• Dados de pagamento ao criar contas de publicidade
• Textos de apelação ao desbloquear contas de anúncios
• Comentários e mensagens em atividades de SMM
• E assim por diante

Não é segredo que os sistemas antifraude há muito monitoram e analisam o comportamento dos usuários. A digitação de texto em formulários não é exceção. Na grande maioria dos casos, o método de entrada realmente importa.

Se você simplesmente colar o texto usando o atalho padrão Ctrl+V / Cmd+V, isso pode parecer suspeito para o sistema em comparação com a digitação manual. Como resultado, sua conta pode receber mais atenção.

Por outro lado, embora a digitação manual pareça a mais natural possível, ela é praticamente inviável ao trabalhar com um grande número de contas. Primeiro, porque é cansativa. Segundo, porque o estilo único de digitação pode ser usado para vincular sessões entre si. Sim, a ligação entre contas pelo estilo de digitação não é paranoia — é a realidade em que vivemos. Um pouco mais adiante, mostraremos uma maneira visual de testar esse tipo de detecção.

Portanto, a solução ideal continua sendo o Paste Like Human Print, projetado para resolver todos os problemas descritos acima. O PLHP é uma solução milagrosa? Tudo depende da implementação técnica específica. Por isso realizamos nossa própria pesquisa sobre os navegadores antidetect mais populares do mercado.

Antes de apresentarmos os resultados, sugerimos que você se familiarize com os principais aspectos técnicos que ajudarão a entender melhor a lógica de funcionamento do mecanismo de entrada nos navegadores.

Quais são os tipos de eventos de teclado e em quais casos são usados?

Existem três eventos principais de teclado: keydown, keypress e keyup. Nos navegadores modernos (incluindo o Chrome), keydown e keyup são os relevantes, enquanto o evento keypress é considerado obsoleto (embora ainda seja disparado ao digitar).

• keydown – ocorre ao pressionar uma tecla e é disparado para qualquer tecla (incluindo teclas de controle como Alt, Shift etc.). É usado para reagir imediatamente ao pressionamento (por exemplo, para atalhos ou jogos). Se a tecla for mantida pressionada (por exemplo t), haverá repetição automática: um evento keydown inicial e repetidos keydown com event.repeat = true até a tecla ser liberada.
• keypress – (obsoleto) evento que ocorre ao pressionar uma tecla que insere um caractere. Historicamente era usado para capturar a digitação de caracteres imprimíveis (letras, números etc.), enquanto keydown/keyup monitoram o pressionamento físico das teclas. O evento keypress não é gerado para teclas que não inserem caracteres (por exemplo Shift ou setas), e nos padrões atuais seu uso é desaconselhado. Em vez disso, recomenda-se usar a propriedade event.key em combinação com o evento keydown ou eventos de entrada específicos (veja abaixo).
• keyup – ocorre ao soltar a tecla (após terminar de pressioná-la). É usado para lidar com ações depois que o usuário solta a tecla — por exemplo, para executar algo apenas após a digitação ou para saber que a tecla não está mais pressionada.

Atributos obsoletos do teclado: o que são charCode, keyCode, which e por que não devem ser usados?

charCode, keyCode e which são propriedades de eventos de teclado de versões antigas do DOM (legado). Elas representavam o código da tecla pressionada ou do caractere, mas atualmente são consideradas obsoletas e não são recomendadas. Os padrões modernos utilizam as propriedades event.key e event.code em seu lugar.

Aqui está um resumo de cada uma dessas propriedades legadas e os motivos para sua descontinuação:

Propriedade	Descrição (legado)	Status e substituição
event.keyCode	Código numérico da tecla (geralmente correspondente ao código ASCII do caractere sem modificadores). Usado em eventos keydown/keyup.	Obsoleto – descontinuado. Varia entre navegadores e layouts, especialmente com caracteres modificados por Shift/Alt. Use event.key ou event.code em vez disso.
event.charCode	Código Unicode numérico do caractere, gerado somente no evento keypress (para teclas que inserem texto).	Obsoleto – descontinuado. Era usado para obter o caractere via keypress; hoje, use event.key para capturar o caractere inserido.
event.which	Propriedade unificada que retorna o código da tecla ou caractere, dependendo do tipo de evento: replica keyCode em keydown/keyup e charCode em keypress. Também usada para o mouse.	Obsoleto – descontinuado. Não padronizado (diferentes navegadores retornam valores diferentes). Para teclado, use event.key e event.code; para mouse, use event.button.

Modificadores (Shift, Ctrl, Alt, Meta): como funcionam getModifierState() e propriedades relacionadas?

Eventos de teclado incluem propriedades que indicam o estado das teclas modificadoras, além de um método para verificá-las.

• Propriedades event.shiftKey, event.ctrlKey, event.altKey e event.metaKey são true se a respectiva tecla modificadora estava pressionada no momento do evento. Por exemplo, com a combinação Ctrl+X, o evento keydown da tecla "X" terá ctrlKey = true. A propriedade metaKey representa a tecla Meta (no Windows – tecla ⊞ Windows, no Mac – ⌘ Command). Essas propriedades booleanas permitem detectar se Shift, Ctrl, Alt ou Meta estavam pressionadas junto com outra tecla.
• Método event.getModifierState(key) retorna true ou false dependendo se o modificador indicado estava ativo no momento do evento. O parâmetro key é uma string com o nome da tecla modificadora, como "Shift", "Control", "Alt", "Meta" ou teclas de bloqueio como "CapsLock" e "NumLock". Retorna true se o modificador estiver pressionado ou ativado (por exemplo, CapsLock ligado). Isso permite verificar o estado de teclas como CapsLock, que não têm propriedade dedicada.

Atributos de eventos (UI Events): o que significam as propriedades key, code, location, repeat, isComposing, inputType, e data?

O objeto moderno KeyboardEvent fornece várias propriedades com informações sobre a tecla pressionada. Além disso, eventos InputEvent (gerados durante entrada de texto) oferecem propriedades extras.

Aqui estão os principais atributos e seus significados:

Propriedade	Valor (o que representa)
key	String representando o valor da tecla, com base no layout e modificadores. Para caracteres imprimíveis, é o caractere digitado (ex: "a" ou "A" dependendo do Shift); para teclas especiais — nomes predefinidos como "Enter", "Escape".
code	String que representa o código físico da tecla no teclado. Independe do layout atual — reflete a posição física da tecla. Por exemplo, pressionar a tecla na posição de "Q" resultará em event.code = "KeyQ" mesmo que o caractere digitado seja outro. (Nota: útil para jogos e atalhos, mas não para capturar o caractere digitado — use key para isso.)
location	Número que indica a posição da tecla no teclado. Ajuda a distinguir teclas idênticas em lados diferentes. Valores: 0 (padrão), 1 (LEFT), 2 (RIGHT), 3 (NUMPAD).
repeat	Booleano: true se o evento foi gerado repetidamente ao manter a tecla pressionada. No primeiro keydown, repeat = false; em repetições subsequentes, true. Em keyup, é sempre false.
isComposing	Booleano: true se o evento ocorreu durante uma composição de entrada (por exemplo, ao digitar ideogramas com IME entre compositionstart e compositionend).
inputType	(Propriedade de InputEvent) String que indica o tipo de alteração feita no conteúdo do campo ou área editável. Exemplos: "insertText" (digitação), "deleteContentBackward" (Backspace), "insertFromPaste" (colar texto). Isso ajuda a identificar se foi digitado, colado, apagado, etc.
data	(Propriedade de InputEvent) String com os dados textuais inseridos no campo como resultado do evento. Pode estar vazia (em exclusões) ou ser null (evento não ligado a texto).

Como eventos de teclado interagem com campos de entrada?

Quando o foco está em um campo de entrada (como <input> ou <textarea>), pressionar teclas gera tanto eventos de teclado quanto eventos de entrada de texto.

A sequência típica é a seguinte:

1. keydown – ocorre ao pressionar qualquer tecla. O evento é disparado no elemento focado (o próprio campo de entrada). Nesse momento, o caractere ainda não foi inserido. Pode-se usar event.preventDefault() aqui para bloquear a inserção do caractere.
2. beforeinput – em seguida, para teclas que inserem caracteres, o campo dispara o evento beforeinput, sinalizando a intenção de alterar o conteúdo. Imediatamente depois, ocorre o evento input, indicando que o conteúdo foi atualizado (por exemplo, uma letra foi inserida). Você pode inspecionar event.inputType e event.data nesses eventos para saber o que ocorreu exatamente (entrada de caractere, exclusão, colagem etc.). Nota: em alguns casos antigos, um evento keypress poderia ser disparado no lugar de beforeinput, mas nos navegadores modernos como o Chrome, usam-se beforeinput/input.
3. keyup – finalmente, quando a tecla é solta, ocorre o evento keyup no mesmo elemento.

Eventos keydown/keyup se propagam a partir do campo de entrada até o topo da árvore DOM (até document e window), então eles podem ser capturados tanto no próprio campo quanto em seus elementos-pai ou no escopo global.

Se o objetivo for reagir especificamente à entrada de texto (incluindo métodos não-teclado como colagem ou entrada por voz), o melhor é usar o evento input, que detecta qualquer alteração no valor do campo.

Já o KeyboardEvent é útil para lidar diretamente com interações de teclado — por exemplo, interceptar teclas como Escape, setas, teclas de função, combinações, etc. Para entrada de caracteres, ele é mais apropriado quando se deseja bloquear ou modificar o caractere digitado antes que ele apareça no campo.

Onde verificar a digitação manual e o Paste Like Human Print?

Para ter um panorama completo, os testes são realizados em várias etapas.

Keyboard Event Viewer

Este verificador fornece o máximo de informações sobre eventos de entrada, incluindo atributos Legacy, Modifiers e UI Events.

1. Verificação de digitação manual

Usando um navegador antidetect, digite manualmente os caracteres do conjunto de teste um por um. Em seguida, compare os eventos resultantes com aqueles da digitação manual no Chrome real, no mesmo computador.

2. Verificação do Paste Like Human Print

Usando o navegador antidetect, cole os mesmos caracteres usando a função Paste Like Human Print. Compare os resultados com a digitação manual no Chrome real no mesmo dispositivo.

Comportamento esperado: nos dois casos, os eventos de entrada devem coincidir ao máximo com os gerados pelo Chrome durante a digitação manual.

TypingDNA

Este serviço se concentra no reconhecimento de padrões de digitação, analisando os intervalos entre as teclas para identificar o estilo único de cada usuário.

1. Verificação de digitação manual

Usando um navegador antidetect, crie uma conta digitando manualmente dados únicos (e-mail, senha). Em seguida, faça login várias vezes usando os mesmos dados — também de forma manual.

2. Verificação do Paste Like Human Print

Crie uma conta colando os dados com a função Paste Like Human Print. Depois, realize múltiplos logins, sempre utilizando PLHP para entrada.

Comportamento esperado: registro e login bem-sucedidos, com aumento do contador de Enrollments a cada novo login. O aumento do contador indica que o padrão de digitação foi reconhecido como consistente entre sessões.

Detalhes adicionais

• Conjunto de teste de caracteres: tT@.
• Sistema operacional: Windows 11
• Paste Like Human Print foi sempre acionado via menu de contexto (clique direito), evitando interferência de atalhos de teclado

Resultados dos testes

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

O comportamento durante a digitação manual corresponde totalmente ao funcionamento do Chrome convencional.

Ao comparar o Paste Like Human Print com a digitação manual real no Chrome, observa-se uma correspondência completa dos eventos dentro do conjunto de teste. É exatamente assim que um PLHP corretamente implementado deve funcionar.

A comparação detalhada entre PLHP e entrada padrão no Chrome é mostrada no screenshot.

TypingDNA

A digitação manual funciona corretamente. Ao usar o PLHP, registro e login ocorrem com sucesso, e o contador de Enrollments aumenta — o que significa que o sistema detecta um padrão de digitação estável e repetitivo dentro da mesma sessão.

Octo Browser v2.5.5

Keyboard Event Viewer

O comportamento da digitação manual corresponde totalmente ao do Chrome comum.

O PLHP está melhor implementado do que em muitas outras soluções, mas ainda apresenta falhas.

Durante a comparação entre PLHP e digitação real no Chrome, foram observadas as seguintes particularidades:

• Ao digitar caracteres maiúsculos como T e símbolos especiais como @, a tecla Shift é usada
• Mas o estado de Shift não é refletido nos Modifiers (getModifierState, shift)

TypingDNA

A digitação manual funciona corretamente. Ao usar o PLHP, o contador de Enrollments não aumenta, ou ocorrem erros de login/registro. Isso sugere que um novo padrão de digitação é gerado a cada uso — o que pode ser negativamente interpretado por sistemas antifraude.

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

Digitação manual: ao pressionar teclas como Shift, Meta ou Control (por exemplo, para digitar T maiúsculo ou @), é registrado um evento keypress extra com valores nulos para charCode, keyCode e which.

Isso pode ser um gatilho para sistemas antifraude: mesmo em entrada manual, o comportamento do Dolphin Anty destoa do padrão, podendo denunciar o uso de navegador antidetect.

PLHP no Dolphin Anty é a pior implementação do mercado.

Durante a comparação com a digitação manual no Chrome real, foram identificados os seguintes problemas:

• Em vez de emular digitação real, é feita uma colagem caractere por caractere
• O valor de inputType nesse caso é "insertFromPaste", que revela imediatamente tratar-se de colagem a partir da área de transferência
• A própria colagem via PLHP diferencia-se da colagem comum pelo menu de contexto, pois não há eventos beforeinput

Apesar de visualmente parecer funcional, uma análise mais profunda revela falhas gritantes.

TypingDNA

A digitação manual funciona corretamente. Ao usar o PLHP, nenhuma entrada é detectada pelo site — como esperado, pois trata-se de colagem e não emulação de digitação real.

Undetectable v2.32.1

Keyboard Event Viewer

O comportamento durante a digitação manual corresponde totalmente ao do Chrome padrão.

Ao comparar o PLHP com a digitação real no Chrome, foram identificados os seguintes problemas:

• Nos eventos keydown e keyup, os valores dos atributos Legacy keyCode e which são sempre 0, o que é inaceitável — uma entrada correta deve conter os códigos reais das teclas
• O atributo code dos UI Events está ausente nos eventos keydown, keyup e keypress
• Ao digitar caracteres como T maiúsculo e @, a tecla Shift não é acionada — não há eventos keydown/keyup, e os Modifiers correspondentes não são ativados

A comparação visual detalhada entre o PLHP e a entrada padrão no Chrome confirma essas falhas.

TypingDNA

A digitação manual funciona corretamente. Ao usar o PLHP, o contador de Enrollments não aumenta ou há falhas de login/registro — o que indica que o padrão de digitação é inconsistente, prejudicando a confiança do sistema.

Adspower v6.12.6.0

Keyboard Event Viewer

O comportamento da digitação manual é idêntico ao do Chrome padrão.

Mas o PLHP apresenta múltiplas falhas graves:

• Em keydown, keyup e keypress, os atributos Legacy charCode, keyCode e which são sempre 0, em vez dos valores esperados
• Os atributos key e code dos UI Events estão ausentes nesses eventos
• Modificadores (Shift, Meta) têm um comportamento antinatural — ativam-se da mesma forma independente do conteúdo inserido
• No evento input, o atributo data é sempre 'null'
• O evento beforeinput não ocorre; em vez disso, o evento input é disparado duas vezes, e apenas o segundo contém inputType = insertText
• A ordem dos eventos está incorreta — não segue a sequência natural da digitação e permanece errada em qualquer contexto

Esses problemas demonstram uma simulação de entrada incompleta e artificial.

TypingDNA

A digitação manual funciona corretamente. Ao usar o PLHP, os dados não são inseridos no formulário e aparece o erro: "This input field does not support Paste It".

0detect browser (ex AQUM) v3.7.40

Keyboard Event Viewer

O comportamento da digitação manual corresponde totalmente ao do Chrome comum.

Entretanto, ao usar PLHP:

• Os atributos Legacy charCode, keyCode e which nos eventos keydown e keyup são sempre 0
• Os atributos key e code dos UI Events estão ausentes em keydown, keyup e keypress
• Ao digitar caracteres como T maiúsculo ou @, a tecla Shift não é acionada — não há keydown/keyup correspondentes, e os Modifiers não são ativados

TypingDNA

A digitação manual funciona corretamente. Com PLHP, os dados não são inseridos em certos campos — nada acontece. Em outros, como a barra de busca do Google, a entrada ocorre normalmente.

GoLogin v3.3.83.79

Keyboard Event Viewer

O comportamento da digitação manual corresponde totalmente ao do Chrome padrão.

Com o PLHP, os seguintes problemas foram observados:

• Nos eventos keydown e keyup, os valores de charCode, keyCode e which são sempre 0, quando deveriam refletir o código real da tecla
• Em keydown, keyup e keypress, os atributos key e code dos UI Events estão ausentes
• A tecla Shift não é acionada ao digitar T maiúsculo ou @ — os eventos keydown/keyup não são gerados, e os Modifiers não são ativados

Essas ausências prejudicam a emulação realista da digitação.

TypingDNA

A digitação manual funciona perfeitamente. Com PLHP, o contador de Enrollments não aumenta, ou há falhas no login/registro — sinal de que o padrão de digitação muda toda vez, o que quebra a continuidade para sistemas antifraude.

Vision v3.0.38

Keyboard Event Viewer

A digitação manual se comporta conforme o esperado, em total conformidade com o Chrome.

A implementação do PLHP, no entanto, é praticamente idêntica à do Dolphin Anty — com os mesmos defeitos críticos:

• Em vez de emular digitação real, é feita uma simples colagem caractere por caractere
• O valor de inputType é "insertFromPaste" — o que denuncia imediatamente que foi colado via área de transferência
• A colagem feita pelo PLHP não equivale nem à colagem comum pelo botão direito do mouse, já que os eventos beforeinput estão ausentes

TypingDNA

A digitação manual funciona normalmente. Com PLHP, o site não detecta nenhuma digitação — o que é esperado, já que não se trata de emulação real, mas de uma simples inserção via clipboard.

Bônus: Associação de contas com base no estilo único de digitação manual do usuário

Como mencionado na introdução, agora mostramos na prática que: vincular contas com base no padrão de digitação manual é não só possível, mas já é usado ativamente por sistemas antifraude.

E isso acontece independente da sessão, do perfil ou até do dispositivo. O principal identificador aqui é você mesmo — seu estilo de digitação único.

Algoritmo de verificação

1. Crie a primeira sessão/perfil em um navegador antidetect

2. Acesse TypingDNA

3. Crie um login e senha únicos, e anote-os (não é necessário e-mail de confirmação)

4. Faça o registro digitando manualmente

5. Faça login 4–5 vezes com os mesmos dados — para alimentar o contador de Enrollments

6. Crie uma nova sessão/perfil (até mesmo em outro dispositivo)

7. Acesse novamente o site de teste

8. Faça login com os mesmos dados — digitando tudo manualmente

Resultado da digitação manual

Ao fazer login de outro dispositivo, o contador de Enrollments aumenta. Isso confirma que o sistema reconheceu seu padrão de digitação e vinculou duas sessões ou dispositivos distintos.

Essa é justamente a ameaça que o Paste Like Human Print bem-implementado deve evitar.

Resultado do teste com PLHP no Linken Sphere

Ao aprimorar o PLHP no Linken Sphere, esse fator comportamental foi levado em conta: cada sessão no LS gera um padrão único de digitação.

Por isso, um teste semelhante com PLHP no Linken Sphere apresenta resultados diferentes:

Primeira sessão

• Registro e login com sucesso
• O contador de Enrollments aumenta

Segunda (ou qualquer outra) sessão

• Ou ocorre erro de login (padrão diferente)
• Ou o login é bem-sucedido, mas o sistema não aumenta o contador e pede nova digitação para capturar um novo padrão

Isso confirma que o Linken Sphere gera uma impressão digital de digitação única por sessão — como deve ser em uma boa implementação de PLHP.

Conclusão

Produto (versão)	Eventos – manual	Eventos – PLHP	TypingDNA – manual	TypingDNA – PLHP
Linken Sphere 2 v2.4.0 ⭐	Excelente	Excelente	Excelente	Excelente
Octo Browser v2.5.5	Excelente	Bom	Excelente	Ruim
Dolphin Anty v2025.152.125.0	Ruim	Terrível	Excelente	Terrível
Undetectable v2.32.1	Excelente	Ruim	Excelente	Ruim
Adspower v6.12.6.0	Excelente	Terrível	Excelente	Terrível
0detect browser (ex AQUM) v3.7.40	Excelente	Ruim	Excelente	Terrível
GoLogin v3.3.83.79	Excelente	Ruim	Excelente	Ruim
Vision v3.0.38	Excelente	Terrível	Excelente	Terrível

Com base nos resultados comparativos, podemos afirmar com segurança: Nem toda implementação de Paste Like Human Print é confiável ou eficaz.

Linken Sphere se destaca como líder absoluto, sendo o único produto que demonstrou comportamento correto tanto na entrada manual quanto usando o PLHP.

Seu comportamento a nível de eventos corresponde 100% ao do Chrome real, e os resultados no TypingDNA comprovam a geração de padrões de digitação independentes por sessão. Ou seja: o PLHP não apenas "funciona" — ele funciona da maneira certa.

Além de sermos pioneiros em inovações (muitas das quais trouxemos primeiro ao setor), mantemos e melhoramos ativamente os recursos existentes e reagimos rapidamente às ameaças emergentes dos sistemas antifraude.

E o mais importante: Não confie cegamente em um produto só porque ele "funcionou uma vez". O antifraude está sempre evoluindo — sua ferramenta de navegação também precisa estar um passo à frente.