AuthKeyDuplicatedError no Telegram: Recuperando um Parser Banido com Dump tdata e Spoofing de Sessão

A migração de um parser funcional para um novo servidor é uma tarefa rotineira. No entanto, um único erro descuidado pode custar uma conta valiosa. Ao executar acidentalmente o mesmo arquivo .session (usando Telethon) em dois servidores simultaneamente, o Telegram imediatamente invalidou a sessão com o erro AuthKeyDuplicatedError. Tentativas subsequentes de login resultaram em UPDATE_APP_TO_LOGIN, efetivamente colocando a conta em um shadow ban. Este artigo detalha o processo de recuperação de um parser (Python 3.11, Telethon) que foi colocado na lista cinza do Telegram. Exploraremos o reverse engineering do cliente desktop, o dump de memória tdata, a superação de conflitos PEP 604 e o spoofing de sessão agressivo para fazer com que o sistema antifraud do Telegram acredite que nosso servidor Ubuntu está operando como um cliente oficial no macOS. O resultado: o parser foi salvo, a conta está ativa e o negócio não perdeu nenhum lead.

Ponto A: O Gatilho do Antifraud e a Morte da Sessão No protocolo MTProto, a autorização está rigidamente ligada a uma chave criptográfica chamada AuthKey, gerada durante o login. Quando meu script foi executado em dois servidores ao mesmo tempo, o Telegram detectou uma condição de corrida clássica: requisições assinadas pela mesma chave foram enviadas de dois endereços IP diferentes em um curto intervalo de tempo. O sistema de segurança do Telegram interpretou isso como um roubo de chave. A chave foi instantaneamente invalidada e as sessões foram encerradas. Tentando me recompor, executei um script padrão para reautorização via client.send_code_request() para receber um SMS. Em vez disso, fui recebido com um RPCError 406: UPDATE_APP_TO_LOGIN. Por baixo dos panos, o problema reside no fato de que, para contas na lista cinza, o Telegram desabilita a capacidade de receber códigos via camadas de API mais antigas. A biblioteca Telethon utiliza a camada 167, enquanto os clientes oficiais operam em camadas 180+. O Telegram força o login através do aplicativo oficial, tornando o fluxo padrão do Telethon tecnicamente inviável para esta conta.

Solução de Engenharia: QR-Bypass e Dump de Memória Como não consigo solicitar um código via API, o plano é o seguinte: autenticar-me no cliente desktop oficial (usando um QR code para contornar a solicitação de SMS), descriptografar seu banco de dados local, extrair o AuthKey e empacotá-lo em um banco de dados SQLite no formato do Telethon. O primeiro obstáculo foi o "zoo" de clientes no macOS. Existem dois clientes oficiais no Mac, com arquiteturas drasticamente diferentes: o Telegram for macOS (Swift, da App Store), que armazena chaves em bancos de dados protegidos dentro de um sandbox em ~/Library/Group Containers/..., tornando o dump de chaves uma tarefa árdua; e o Telegram Desktop (C++/Qt, baixado do site), que armazena chaves em um formato binário proprietário na pasta tdata. Este último é o que eu precisava. Para garantir que eu não copiasse uma sessão vazia ou antiga, identifiquei o diretório ativo verificando o tempo de modificação dos arquivos logo após o login via QR code. O segundo obstáculo foi a "matryoshka Unix" ao copiar. Ao tentar copiar a pasta tdata para a área de trabalho com cp -r, encontrei um problema clássico. Como a pasta de destino já existia (de uma tentativa anterior malsucedida), a nova pasta foi copiada para dentro dela. O script de conversão esperava os arquivos na raiz e falhava. A correção envolveu a remoção explícita do snapshot anterior antes da cópia: rm -rf ~/Desktop/my_tdata seguido por cp -r "$HOME/Library/Application Support/Telegram Desktop/tdata" "$HOME/Desktop/my_tdata". Em seguida, naveguei para ~/Desktop e comprimi a pasta: cd ~/Desktop && zip -r my_tdata.zip my_tdata.

O Terceiro Obstáculo: Inferno de Dependências e PEP 604 Ao tentar descriptografar o tdata diretamente no Mac, a biblioteca antiga opentele falhou, pois as versões recentes do Telegram Desktop alteraram os algoritmos de criptografia local. Mudei para um fork mais moderno, opentele2, mas o script falhou com um TypeError: unsupported operand type(s) for |: 'type' and 'type'. A causa foi que a biblioteca foi escrita usando os padrões PEP 604 (sintaxe bytes | bytearray), que meu sistema Python 3.9 padrão do Mac não suportava (introduzido no Python 3.10). Em vez de criar ambientes virtuais complexos no Mac, simplesmente transferi o arquivo tdata.zip para o servidor Ubuntu de produção, que já possuía Python 3.10+ instalado de fábrica.

O Chefe Final: Conversão e Spoofing no Servidor É aqui que a parte mais crítica começa. Se simplesmente converter a sessão e executá-la, o Telethon enviará uma requisição InitConnection aos servidores do Telegram. Para uma conta na lista cinza, a entrada de um novo dispositivo não oficial a partir do IP de um data center resultaria em banimento permanente imediato. Precisava fazer com que o Telethon clonasse a AuthKey existente e se passasse pelo cliente oficial.

Passo 1. Conversão sem criar uma nova sessão Escrevi um script convert_server.py no Ubuntu:

python
import os
import asyncio
from opentele2.td import TDesktop
from opentele2.api import UseCurrentSession

async def main():
    tdata_path = "./my_tdata"
    session_path = "./reserve_session.session"
    
    print("[*"] Carregando tdata via opentele2...")
    try:
        tdesk = TDesktop(tdata_path)
    except Exception as e:
        print(f"[!] Erro ao ler pasta: {e}")
        return

    if not tdesk.isLoaded():
        print("[!] Erro: Pasta vazia ou não autenticada.")
        return
    
    try:
        # CRITICAMENTE IMPORTANTE: O flag UseCurrentSession impede o envio
        # da requisição InitConnection e protege contra banimento instantâneo.
        # Estamos clonando a chave, não criando um novo dispositivo.
        client = await tdesk.ToTelethon(session=session_path, flag=UseCurrentSession)
        
        await client.connect()
        if await client.is_user_authorized():
            me = await client.get_me()
            print(f"[+] SUCESSO! Sessão criada. Conta: @{me.username or 'Hidden'}")
        else:
            print("[!] Erro: Sessão não autenticada.")
            
        await client.disconnect()
        
    except Exception as e:
        print(f"[!] Erro de conversão: {e}")

if __name__ == "__main__":
    asyncio.run(main())

Passo 2. Spoofing agressivo na inicialização Para tornar a ilusão completa, ao iniciar o parser de produção, codifiquei agressivamente os parâmetros do Telegram Desktop oficial. Se os parâmetros padrão do Telethon fossem mantidos, o sistema antifraud detectaria que a chave foi emitida para um cliente Desktop, mas as requisições estariam vindo de um aplicativo desconhecido.

python
import asyncio
from telethon import TelegramClient

async def main():
    session_name = "reserve_session"
    
    # Chaves oficiais do Telegram Desktop (API ID 2040)
    # Usar chaves customizadas com uma sessão desktop levará ao ban!
    api_id = 2040
    api_hash = "b18441a1ff607e10a989891a5462e627"
    
    # Inicialização com spoofing agressivo dos parâmetros do dispositivo
    client = TelegramClient(
        session_name, 
        api_id, 
        api_hash,
        device_model="PC 64bit",
        system_version="Windows 10",
        app_version="4.8.1"
    )
    
    print("[*"] Conectando aos servidores do Telegram...")
    await client.connect()
    
    is_authorized = await client.is_user_authorized()
    if is_authorized:
        print(f"\n[+] TESTE BEM-SUCEDIDO! Telethon reconhece a sessão.")
    else:
        print("\n[!] ERRO CRÍTICO: Sessão inválida.")
        
    await client.disconnect()

if __name__ == "__main__":
    asyncio.run(main())

Ponto B: A Rede foi Penetrada Substituí o arquivo de sessão no parser de produção, reiniciei o serviço e verifiquei os logs:

text
# journalctl -u reserve_parser.service -n 20
Jun 29 12:05:58 server systemd[1]: Started reserve_parser.service - Telegram Reserve Parser.
Jun 29 12:05:59 server bash[94626]: INFO - Connecting to 149.154.167.51:443/TcpFull...
Jun 29 12:05:59 server bash[94626]: INFO - Connection to 149.154.167.51:443/TcpFull complete!
Jun 29 12:06:05 server bash[94626]: INFO - Config updated. Chats: 25, Keys: 63, Intents: 58
Jun 29 12:06:05 server bash[94626]: INFO - === STARTING ACTIVE PULL PARSER ===

A rede foi penetrada e o parser está funcionando. Uma limitação arquitetural importante: como a sessão do servidor e o cliente desktop no Mac agora compartilham a mesma chave criptográfica, clicar em "Sair" no Mac enviará uma requisição para destruir a chave. O parser do servidor será encerrado instantaneamente. O cliente no Mac só pode ser fechado (kill process), mas não deslogado.

P.S. Trabalhar com a API do Telegram em 2026 é uma batalha constante contra o antifraud. Um movimento em falso e seu negócio fica sem leads. Publico mais análises aprofundadas sobre automação e engenharia reversa em meu canal do Telegram. Se você precisa desenvolver um parser tolerante a falhas, extrair dados de fontes complexas ou configurar uma infraestrutura segura, entre em contato comigo via Telegram para discutir sua tarefa em termos de números e arquitetura.