MTProxy Jumper: Criando um Comutador Automático de Servidores Proxy para Telegram
Este artigo explora o desenvolvimento de um software em Python que atua como um MTProxy para o Telegram, alternando automaticamente entre diferentes servidores proxy. O objetivo é contornar bloqueios e garantir uma conexão estável, utilizando o protocolo FakeTLS para mascarar o tráfego.
MundiX News·26 de maio de 2026·10 min de leitura·👁 27 views
No cenário atual, com as recentes notícias envolvendo o Telegram, foram realizados experimentos com o protocolo MTProxy. A ideia principal é desenvolver um software que se comporte como um servidor MTProxy para o cliente Telegram, facilitando a troca de dados com outros servidores MTProxy. Idealmente, esses servidores externos deveriam ser detectados automaticamente, e a troca entre eles também deveria ocorrer de forma automática.
O código é escrito em Python, servindo como uma solução experimental para uma implementação rápida. Caso o software demonstre ser útil, a possibilidade de reescrevê-lo em C é considerada. Do protocolo MTProxy, apenas a parte relacionada às conexões que imitam TLS (FakeTLS, com a chave do proxy começando com "ee") é implementada. Outros tipos de conexão parecem mais vulneráveis a interferências de DPI (Deep Packet Inspection), tornando-os menos vantajosos.
O software é projetado para ser executado em um computador. A verificação de funcionamento é realizada nos clientes Telegram Desktop e Unigram no Windows. Do ponto de vista do cliente, o software se apresenta como um servidor MTProxy comum, com a conexão sendo estabelecida da maneira padrão. Após aceitar a conexão do cliente, o software tenta estabelecer uma conexão com um servidor MTProxy externo. Se bem-sucedido, o software encaminha todos os dados recebidos do cliente para o servidor externo e vice-versa, realizando a transcodificação necessária devido à criptografia do protocolo. Caso a conexão com o servidor externo falhe ou seja interrompida, a conexão com o cliente é imediatamente fechada. Espera-se que, ao detectar isso, o cliente Telegram tente se reconectar ao nosso software, repetindo o processo.
O servidor MTProxy externo é selecionado a partir de uma lista, que pode ser definida previamente ou baixada de uma URL especificada. Para os experimentos, foi necessário um proxy funcional. A opção mais confiável foi configurar um na própria máquina, utilizando o mtg (disponível em https://github.com/9seconds/mtg) e executando-o através de mtg run config.toml. O arquivo de configuração config.toml foi baseado em example.config.toml, com pequenas modificações:
Nessa configuração, o mtg aceita conexões na porta 3128 via MTProxy e garante a troca com os servidores Telegram através de um proxy SOCKS5 na porta 9150. O Tor Browser, em execução, estabelece um proxy SOCKS5 na porta 9150, que pode ser utilizado por outros aplicativos. No nosso caso, ele é necessário para garantir uma comunicação confiável com os servidores Telegram em um ambiente com interferência de DPI.
As chaves de proxy podem ser "simples" (32 dígitos hexadecimais), "dd" (iniciando com "dd" seguido de 32 dígitos hexadecimais), "ee" (iniciando com "ee" seguido de 32 dígitos hexadecimais e um nome de domínio simulado) e "estranhas" (formato não correspondente a nenhum dos anteriores). Ao conectar, o cliente escolhe o protocolo a ser usado dependendo do tipo de chave. As chaves "ee" correspondem ao protocolo com FakeTLS, que é o foco principal. Os demais tipos de chave correspondem ao protocolo MTProxy "puro", sem encapsulamento em TLS. O formato "dd" envolve ofuscação, mas sua eficácia é questionável. Os formatos "estranhos" não foram analisados em detalhes, mas podem envolver algo semelhante a Base64 e também podem usar o protocolo "puro".
O protocolo MTProxy com FakeTLS imita HTTPS (HTTP/2 via TLS 1.2). O cliente envia um pacote Client Hello, onde os campos Random e server_name são importantes. Random é usado para armazenar um resumo calculado com base no conteúdo do pacote, na chave do proxy de 16 bytes e no tempo atual. server_name contém o nome de domínio simulado. O servidor proxy envia três pacotes TLS: Server Hello, Change Cipher Spec, Application Data. O campo Random é importante aqui também, sendo usado para armazenar um resumo calculado com base no conteúdo dos três pacotes e no resumo do pacote Client Hello. Os pacotes Application Data e Change Cipher Spec são trocados continuamente entre o cliente e o servidor. No primeiro, os dados do protocolo MTProxy "puro" são encapsulados, enquanto o segundo é geralmente ignorado. O conteúdo do primeiro pacote Application Data (que vem com Server Hello) é ignorado. No segundo pacote Application Data, os primeiros 64 bytes, juntamente com a chave do proxy de 16 bytes, são usados para gerar as chaves usadas para criptografar o restante do segundo pacote e o conteúdo de todos os pacotes Application Data subsequentes.
O software atua como intermediário entre o cliente Telegram e o servidor MTProxy externo. Para o cliente, ele se apresenta como um servidor MTProxy, e para o servidor externo, como um cliente. O software aguarda conexões de entrada do cliente. Para cada conexão aceita:
O pacote Client Hello é recebido do cliente e validado.
O campo de extensão server_name é substituído no pacote.
O campo Random é recalculado.
Uma conexão é estabelecida com o servidor proxy externo (veja abaixo o princípio de seleção da lista).
O pacote Client Hello modificado é enviado ao servidor.
O pacote Server Hello (mais dois - veja o parágrafo anterior) é recebido do servidor e validado.
O campo Random é recalculado no pacote.
O pacote Server Hello modificado (mais dois) é enviado ao cliente.
Em seguida, os pacotes Application Data e Change Cipher Spec são enviados em loop, nas direções do cliente para o servidor e do servidor para o cliente:
Change Cipher Spec diretamente.
Application Data após descriptografia e criptografia com a chave necessária.
Se a conexão com o servidor for interrompida ou dados inválidos forem recebidos, as conexões com o cliente e o servidor são interrompidas; presume-se que, nesse caso, o cliente tentará restabelecer a conexão.
O algoritmo mais simples para selecionar um servidor proxy da lista é escolher o próximo na lista e, quando a lista terminar, retornar ao início. Na prática, isso não funciona muito bem, pois apenas alguns proxies em listas públicas funcionam, e levará muito tempo para percorrer os servidores se a conexão for interrompida. Atualmente, o seguinte algoritmo é implementado. Ao receber um pacote Server Hello válido do servidor, um contador para esse servidor é incrementado em 1. Quando uma nova conexão é estabelecida com o cliente e é necessário selecionar um servidor proxy da lista, um dos servidores com um valor de contador positivo é selecionado, e o contador é decrementado em 1. Se não houver nenhum contador positivo, o servidor é selecionado pelo algoritmo mais simples.
Esse algoritmo permite que, em caso de interrupção aleatória da conexão, as tentativas de conexão sejam feitas em primeiro lugar com os servidores com os quais as conexões foram bem-sucedidas anteriormente. A questão do "fe02" foi abordada, com uma solução para corrigir o pacote. No entanto, nenhuma diferença foi notada. Os servidores que foram bloqueados por DPI (que no log aparece como uma interrupção de conexão após o envio do Client Hello ao servidor) continuaram a ser bloqueados. Possivelmente, no caso, o bloqueio é feito por IP, ou o DPI reage a outros sinais. Experimentos podem ser continuados aqui. Quase todos os campos podem ser alterados, pois, para o protocolo MTProxy no Client Hello, nada importa além do campo Random.
Possíveis problemas incluem a instabilidade e imprevisibilidade da conexão, baixa velocidade e vazamento de metadados para o proprietário do servidor externo, embora a criptografia seja prometida para as mensagens. Os servidores proxy podem adicionar um "canal patrocinado" à força, e com a troca automática de proxy, isso acontece repentinamente. As chamadas no Telegram ignoram o proxy, então, se estiverem quebradas, não serão corrigidas.
OUR_CONFIG_URL é o link que pode ser aberto no Telegram. Onde é possível alterar a porta, se não for satisfatório 13128, e o endereço para 0.0.0.0, para que o nosso proxy possa ser acessado de outros computadores na rede local. TARGET_CONFIG_URLS é a lista de links para servidores proxy. Se @ estiver no início, é um link para baixar a lista de proxies (na versão atual, a lista é baixada apenas uma vez na inicialização). Por padrão, os URLs do ambiente de teste e o URL de uma das listas de proxy são inseridos lá.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
No cenário atual, com as recentes notícias envolvendo o Telegram, foram realizados experimentos com o protocolo MTProxy. A ideia principal é desenvolver um software que se comporte como um servidor MTProxy para o cliente Telegram, facilitando a troca de dados com outros servidores MTProxy. Idealmente, esses servidores externos deveriam ser detectados automaticamente, e a troca entre eles também deveria ocorrer de forma automática.
O código é escrito em Python, servindo como uma solução experimental para uma implementação rápida. Caso o software demonstre ser útil, a possibilidade de reescrevê-lo em C é considerada. Do protocolo MTProxy, apenas a parte relacionada às conexões que imitam TLS (FakeTLS, com a chave do proxy começando com "ee") é implementada. Outros tipos de conexão parecem mais vulneráveis a interferências de DPI (Deep Packet Inspection), tornando-os menos vantajosos.
O software é projetado para ser executado em um computador. A verificação de funcionamento é realizada nos clientes Telegram Desktop e Unigram no Windows. Do ponto de vista do cliente, o software se apresenta como um servidor MTProxy comum, com a conexão sendo estabelecida da maneira padrão. Após aceitar a conexão do cliente, o software tenta estabelecer uma conexão com um servidor MTProxy externo. Se bem-sucedido, o software encaminha todos os dados recebidos do cliente para o servidor externo e vice-versa, realizando a transcodificação necessária devido à criptografia do protocolo. Caso a conexão com o servidor externo falhe ou seja interrompida, a conexão com o cliente é imediatamente fechada. Espera-se que, ao detectar isso, o cliente Telegram tente se reconectar ao nosso software, repetindo o processo.
O servidor MTProxy externo é selecionado a partir de uma lista, que pode ser definida previamente ou baixada de uma URL especificada. Para os experimentos, foi necessário um proxy funcional. A opção mais confiável foi configurar um na própria máquina, utilizando o mtg (disponível em https://github.com/9seconds/mtg) e executando-o através de mtg run config.toml. O arquivo de configuração config.toml foi baseado em example.config.toml, com pequenas modificações:
Nessa configuração, o mtg aceita conexões na porta 3128 via MTProxy e garante a troca com os servidores Telegram através de um proxy SOCKS5 na porta 9150. O Tor Browser, em execução, estabelece um proxy SOCKS5 na porta 9150, que pode ser utilizado por outros aplicativos. No nosso caso, ele é necessário para garantir uma comunicação confiável com os servidores Telegram em um ambiente com interferência de DPI.
As chaves de proxy podem ser "simples" (32 dígitos hexadecimais), "dd" (iniciando com "dd" seguido de 32 dígitos hexadecimais), "ee" (iniciando com "ee" seguido de 32 dígitos hexadecimais e um nome de domínio simulado) e "estranhas" (formato não correspondente a nenhum dos anteriores). Ao conectar, o cliente escolhe o protocolo a ser usado dependendo do tipo de chave. As chaves "ee" correspondem ao protocolo com FakeTLS, que é o foco principal. Os demais tipos de chave correspondem ao protocolo MTProxy "puro", sem encapsulamento em TLS. O formato "dd" envolve ofuscação, mas sua eficácia é questionável. Os formatos "estranhos" não foram analisados em detalhes, mas podem envolver algo semelhante a Base64 e também podem usar o protocolo "puro".
O protocolo MTProxy com FakeTLS imita HTTPS (HTTP/2 via TLS 1.2). O cliente envia um pacote Client Hello, onde os campos Random e server_name são importantes. Random é usado para armazenar um resumo calculado com base no conteúdo do pacote, na chave do proxy de 16 bytes e no tempo atual. server_name contém o nome de domínio simulado. O servidor proxy envia três pacotes TLS: Server Hello, Change Cipher Spec, Application Data. O campo Random é importante aqui também, sendo usado para armazenar um resumo calculado com base no conteúdo dos três pacotes e no resumo do pacote Client Hello. Os pacotes Application Data e Change Cipher Spec são trocados continuamente entre o cliente e o servidor. No primeiro, os dados do protocolo MTProxy "puro" são encapsulados, enquanto o segundo é geralmente ignorado. O conteúdo do primeiro pacote Application Data (que vem com Server Hello) é ignorado. No segundo pacote Application Data, os primeiros 64 bytes, juntamente com a chave do proxy de 16 bytes, são usados para gerar as chaves usadas para criptografar o restante do segundo pacote e o conteúdo de todos os pacotes Application Data subsequentes.
O software atua como intermediário entre o cliente Telegram e o servidor MTProxy externo. Para o cliente, ele se apresenta como um servidor MTProxy, e para o servidor externo, como um cliente. O software aguarda conexões de entrada do cliente. Para cada conexão aceita:
O pacote Client Hello é recebido do cliente e validado.
O campo de extensão server_name é substituído no pacote.
O campo Random é recalculado.
Uma conexão é estabelecida com o servidor proxy externo (veja abaixo o princípio de seleção da lista).
O pacote Client Hello modificado é enviado ao servidor.
O pacote Server Hello (mais dois - veja o parágrafo anterior) é recebido do servidor e validado.
O campo Random é recalculado no pacote.
O pacote Server Hello modificado (mais dois) é enviado ao cliente.
Em seguida, os pacotes Application Data e Change Cipher Spec são enviados em loop, nas direções do cliente para o servidor e do servidor para o cliente:
Change Cipher Spec diretamente.
Application Data após descriptografia e criptografia com a chave necessária.
Se a conexão com o servidor for interrompida ou dados inválidos forem recebidos, as conexões com o cliente e o servidor são interrompidas; presume-se que, nesse caso, o cliente tentará restabelecer a conexão.
O algoritmo mais simples para selecionar um servidor proxy da lista é escolher o próximo na lista e, quando a lista terminar, retornar ao início. Na prática, isso não funciona muito bem, pois apenas alguns proxies em listas públicas funcionam, e levará muito tempo para percorrer os servidores se a conexão for interrompida. Atualmente, o seguinte algoritmo é implementado. Ao receber um pacote Server Hello válido do servidor, um contador para esse servidor é incrementado em 1. Quando uma nova conexão é estabelecida com o cliente e é necessário selecionar um servidor proxy da lista, um dos servidores com um valor de contador positivo é selecionado, e o contador é decrementado em 1. Se não houver nenhum contador positivo, o servidor é selecionado pelo algoritmo mais simples.
Esse algoritmo permite que, em caso de interrupção aleatória da conexão, as tentativas de conexão sejam feitas em primeiro lugar com os servidores com os quais as conexões foram bem-sucedidas anteriormente. A questão do "fe02" foi abordada, com uma solução para corrigir o pacote. No entanto, nenhuma diferença foi notada. Os servidores que foram bloqueados por DPI (que no log aparece como uma interrupção de conexão após o envio do Client Hello ao servidor) continuaram a ser bloqueados. Possivelmente, no caso, o bloqueio é feito por IP, ou o DPI reage a outros sinais. Experimentos podem ser continuados aqui. Quase todos os campos podem ser alterados, pois, para o protocolo MTProxy no Client Hello, nada importa além do campo Random.
Possíveis problemas incluem a instabilidade e imprevisibilidade da conexão, baixa velocidade e vazamento de metadados para o proprietário do servidor externo, embora a criptografia seja prometida para as mensagens. Os servidores proxy podem adicionar um "canal patrocinado" à força, e com a troca automática de proxy, isso acontece repentinamente. As chamadas no Telegram ignoram o proxy, então, se estiverem quebradas, não serão corrigidas.
OUR_CONFIG_URL é o link que pode ser aberto no Telegram. Onde é possível alterar a porta, se não for satisfatório 13128, e o endereço para 0.0.0.0, para que o nosso proxy possa ser acessado de outros computadores na rede local. TARGET_CONFIG_URLS é a lista de links para servidores proxy. Se @ estiver no início, é um link para baixar a lista de proxies (na versão atual, a lista é baixada apenas uma vez na inicialização). Por padrão, os URLs do ambiente de teste e o URL de uma das listas de proxy são inseridos lá.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
