Como subir um servidor próprio de MSN Messenger (Windows Live Messenger 2009) no Ubuntu

-

 Nos últimos dias montei, do zero, um servidor próprio do protocolo MSN/WLM usando o projeto open-source Escargot. O objetivo era simples: ter um ambiente de testes na rede local, com contas próprias, sem depender do serviço público.

O caminho não foi linear. Python 3.12, bibliotecas antigas, autenticação SSO do WLM 2009 e certificado TLS geraram vários obstáculos. Abaixo está o passo a passo real — incluindo os ajustes que quase ninguém documenta.

O que é o Escargot?

O Escargot é um projeto que recria a infraestrutura do antigo MSN Messenger e Windows Live Messenger. O servidor é open-source (GitLab) e fala MSNP até a versão 18, o suficiente para o WLM 2009 (build 14.0.8117.0416), o cliente mais recente ainda suportado de forma estável.

Não é um “clone visual”: é o protocolo de verdade, com clientes originais da Microsoft patchados para apontar para o seu servidor.

Ambiente usado

  • Ubuntu Server 24.04 LTS (teste em LAN)
  • Python 3.12 + venv
  • SQLite (padrão do projeto)
  • Cliente: Windows Live Messenger 2009 (patchado)
  • IP de exemplo: 192.168.1.106

Servidor

Instalação base

Atualização do sistema e instalação de pacotes necessários.

sudo apt update && sudo apt upgrade -y
sudo apt install -y git python3 python3-pip python3-venv python3-dev build-essential libssl-dev libffi-dev

Clonagem do projeto

mkdir /msn && cd /msn
git clone https://gitlab.com/escargot-chat/server.git 
cd server

Ativação do ambiente virtual e instalação de dependencias

python3 -m venv venv 
source venv/bin/activate 
pip install --upgrade pip

Obs.: O requirements.txt original puxa, entre outras coisas, sqlalchemy sem pin e um sqlaltery antigo via Git. Isso já anuncia problemas com Python moderno. Eu precisei fazer alguns ajustes nas dependências necessárias para rodar esse projeto, pois os pacotes originais, não tinham a versão necessária para o correto funcionamento e eu encontrei algumas incompatibilidades nas versões mais atuais. A seguir seguem todas as dependências e suas versões que estão rodando no meu servidor:

aiohappyeyeballs==2.7.1
aiohttp==3.14.3
aiosignal==1.4.0
alembic==1.4.3
ast_serialize==0.8.0
astroid==4.0.4
attrs==26.1.0
cffi==2.1.1
cryptography==50.0.0
devtls @ git+https://gitlab.com/valtron/devtls.git@777de1111839b64353c20c8045ec99139a5204f3
dill==0.4.1
docstring_parser==0.18.0
frozenlist==1.8.0
funcli==0.8.1
greenlet==3.5.5
HLL==1.3.1
idna==3.18
iniconfig==2.3.0
isort==8.0.1
Jinja2==3.1.6
librt==0.15.0
lxml==6.1.1
Mako==1.4.1
MarkupSafe==3.0.3
mccabe==0.7.0
multidict==6.7.1
mypy==2.3.0
mypy_extensions==1.1.0
packaging==26.3
pathspec==1.1.1
pillow==12.3.0
platformdirs==4.11.3
pluggy==1.6.0
propcache==0.5.2
pycparser==3.0
Pygments==2.20.0
pylint==4.0.7
pytest==9.1.1
python-dateutil==2.9.0.post0
python-editor==1.0.4
pytz==2026.3.post1
six==1.17.0
SQLAlchemy==1.3.24
sqlaltery @ git+https://gitlab.com/valtron/sqlaltery.git@f2b0a593bc313bba5725b582964c99a224d4a9c0
tomlkit==0.15.1
typing_extensions==4.16.0
yarl==1.24.5

Após editar o arquivo requiriments.txt com as dependências acima, basta instala-las com:

pip install -r requirements.txt

Configuração local

Crie settings_local.py na raiz do projeto:

DEBUG = True
DEBUG_MSNP = True
DEBUG_HTTP_REQUEST = True
DEBUG_HTTP_REQUEST_FULL = True
TARGET_HOST = "m1.escargot.log1p.xyz"
LOGIN_HOST = "m1.escargot.log1p.xyz"
STORAGE_HOST = "m1.escargot.log1p.xyz"
ENABLE_FRONT_MSN = True

O nome m1.escargot.log1p.xyz não precisa existir na internet. Ele será resolvido via arquivo hosts no Windows do cliente. Usar só o IP costuma quebrar o TLS (SNI / domain is None no devtls).

Banco de dados — o primeiro obstáculo real

No Python 3.12 + SQLAlchemy 2.x isso quebra de várias formas:

  • ValueError: can't find Table 't_user' no sqlaltery
  • conflitos com Alembic
  • incompatibilidades de API

Workaround que funcionou: deixar o create_all() criar o schema final e marcar as migrations como aplicadas manualmente, sem rodar o motor antigo de reverse do sqlaltery.

Em resumo, o dbcreate.py foi adaptado para:

  1. Criar as tabelas com db.Base.metadata.create_all
  2. Inserir registro fake em sqlaltery_migration (revision 9)
  3. Criar também o banco de stats

O script adaptado ficou da seguinte forma:

from core import db, stats
from core.conn import Conn
import settings

def main() -> None:
    create_dbs()

def create_dbs() -> None:
    conn_db = Conn(settings.DB)
    db.Base.metadata.create_all(conn_db.engine)

    # Workaround para o bug do sqlaltery no Python 3.12
    with conn_db.engine.begin() as conn:
        conn.execute("""
            CREATE TABLE IF NOT EXISTS sqlaltery_migration (
                "order" INTEGER NOT NULL,
                revision INTEGER NOT NULL,
                date_applied DATETIME NOT NULL
            )
        """)
        conn.execute("""
            INSERT INTO sqlaltery_migration ("order", revision, date_applied)
            VALUES (0, 9, CURRENT_TIMESTAMP)
        """)

    conn_stats = Conn(settings.STATS_DB)
    stats.Base.metadata.create_all(conn_stats.engine)

if __name__ == '__main__':
    main()

Depois disso, crie o banco e as contas de teste com senha 123456

export PYTHONPATH=".:$PYTHONPATH"
python script/dbcreate.py
python script/dummydata.py

Contas de teste

Email	                Username	Nome de exibição
tle@example.com	        t1e	        T1e
t2e@example.com	        t2e	        T2e
t3e@example.com	        t3e	        T3e
t4e@example.com	        t4e	        T4e
t5e@example.com	        t5e	        T5e
tly@yahoo.com	        tly	        T1y
t2y@yahoo.com	        t2y	        T2y
t3y@yahoo.com	        t3y	        T3y
t4y@yahoo.com	        t4y	        T4y
t5y@yahoo.com	        t5y	        T5y
t1h@hotmail.com	        t1h	        T1h
t2h@hotmail.com	        t2h	        T2h
t3h@hotmail.com	        t3h	        T3h
t4h@hotmail.com	        t4h	        T4h
t5h@hotmail.com	        t5h	        T5h
t1l@live.com	        t1	        T1l
t2l@live.com	        t2l	        T2l
t3l@live.com	        t3l	        T3l
t4l@live.com	        t4l	        T4l
t5l@live.com	        t5	        T5l

Contas de bot

 Email		        Username		Nome de exibição
bot0@bot.log1p.xyz	bot0		        Bot0
bot1@bot.log1p.xyz	bot1		        Bot1
bot2@bot.log1p.xyz	bot2		        Bot2
bot3@bot.log1p.xyz	bot3		        Bot3
bot4@bot.log1p.xyz	bot4		        Bot4

Subir o servidor (modo dev)

export PYTHONPATH=".:$PYTHONPATH"
python dev

Na primeira execução o devtls gera:

./.devtls_cache/DO_NOT_TRUST_DevTLS_Escargot.crt

Esse certificado precisa ser instalado no Windows do cliente como Autoridade de Certificação Raiz Confiáveis (máquina local). Só no servidor Ubuntu não basta.

Instale o certificado

# Copia o certificado para o local de confiança do sistema
cp .devtls_cache/DO_NOT_TRUST_DevTLS_Escargot.crt /usr/local/share/ca-certificates/DO_NOT_TRUST_DevTLS_Escargot.crt
# Atualiza a lista de certificados
sudo update-ca-certificates

Portas que sobem:

  • 80 (HTTP/HTTPS dos serviços web)
  • 1863 / 1864 (MSNP)
  • 4308

Para teste, o firewall pode ficar desligado:

sudo ufw disable

Inicie o servidor novamente

export PYTHONPATH=".:$PYTHONPATH"
python dev

Observações:

  • Os SyntaxWarning que apareceram são só avisos (código antigo usando is em vez de ==). Não impedem o funcionamento.
  • O certificado expira em 30 dias. Depois desse prazo o devtls vai gerar outro e você terá que instalar de novo.

Veja as linhas importantes no final:

Serving on 0.0.0.0:80
Serving on 0.0.0.0:1863
Serving on 0.0.0.0:1864
Serving on 0.0.0.0:4308

Isso significa que ele está escutando nas portas principais do MSN Messenger.

Serviço em segundo plano (systemd)

Para não depender de terminal aberto:

Cria o arquivo /etc/systemd/system/escargot.service e adicione o seguinte

[Unit]
Description=Escargot Chat Server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/msn/server
Environment=PYTHONPATH=/msn/server
ExecStart=/msn/server/venv/bin/python -m dev
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Reiniciar o daemon, habilitar o inicio do serviço junto com o sistema, verificar status do serviço e acompanhar logs em tempo real

systemctl daemon-reload
systemctl enable --now escargot
systemctl status escargot
journalctl -u escargot -f

Cliente: WLM 2009

  1. Baixe a versão patchada no site do Escargot
  2. Instale (desinstale Windows Essentials mais novos, se houver conflito)
  3. Ajuste os .ini:

C:\Program Files (x86)\Windows Live\Messenger\msnmsgr.exe-escargot.ini
C:\Program Files (x86)\Windows Live\Contacts\wlcomm.exe-escargot.ini

Substitua pelo seguinte conteúdo

[options]
type=msn
server=m1.escargot.log1p.xyz

O segundo arquivo (wlcomm) é crítico: o Address Book do 2009 passa por ele. Sem isso, o login pode autenticar e ainda assim falhar ao carregar contatos (erro do tipo 84cc0020).

Hosts no Windows

No cliente, abra o arquivo "C:\Windows\System32\drivers\etc\hosts" com o bloco de notas como administrador e cole as seguintes linhas no final do arquivo. Não esqueça de substituir pelo IP do seu servidor.

192.168.1.106   m1.escargot.log1p.xyz
192.168.1.106   msnmsgr.escargot.chat
192.168.1.106   conf.escargot.chat
192.168.1.106   login.live.com
192.168.1.106   login.microsoft.com
192.168.1.106   login.passport.com
192.168.1.106   nexus.passport.com
192.168.1.106   messenger.hotmail.com
192.168.1.106   gateway.messenger.hotmail.com
192.168.1.106   byrdr.omega.contacts.msn.com
192.168.1.106   config.messenger.msn.com
192.168.1.106   tkrdr.storage.msn.com
192.168.1.106   ows.messenger.msn.com
192.168.1.106   rsi.hotmail.com
192.168.1.106   muser.messenger.hotmail.com

Sem isso, o fluxo SSO do WLM 2009 não completa (erros como 80048820).

Instalar o certificado no Windows do cliente (muito importante)

O certificado que o servidor gerou precisa estar confiado no PC que está rodando o WLM, não só no Ubuntu.

No servidor Ubuntu, copie o certificado para o Windows (pode usar pendrive, SCP, etc.):

# No servidor
ls -l .devtls_cache/DO_NOT_TRUST_DevTLS_Escargot.crt

No Windows:

  • Clique duas vezes no arquivo .crt
  • Clique em Instalar Certificado...
  • Escolha Máquina Local (Local Machine)
  • Selecione Colocar todos os certificados no repositório a seguir
  • Clique em Procurar → escolha Autoridades de Certificação Raiz Confiáveis
  • Finalize

Instale o Flash Player

Para poder reproduzir os winks (figurinhas animadas parecidas com gifs) é necessário o Flash Player 10


Fluxo de login que realmente importa

No log do servidor, o caminho saudável parece com:

  1. VER / CVR (negociação de protocolo)
  2. USR 3 SSO I → desafio MBI_KEY_OLD
  3. USR 4 SSO S ... → USR 4 OK
  4. Requisições SOAP em /abservice/... (lista de contatos)

Se parar no passo 2 (dis logo após o desafio), o problema é quase sempre certificado ou hosts. Se passar do USR 4 OK e cair depois, o foco é Address Book (wlcomm + abservice).

Observação útil: MSN 7.5 é bem mais tolerante e serve como diagnóstico. Se o 7.5 entra e o 2009 não, o core do servidor está ok — o gargalo é o SSO/AB do 2009.

Lições práticas

  1. Python 3.12 + código de 2017–2020 exige gambiarra. Pin de dependências e patches pontuais são regra, não exceção.
  2. WLM 2009 não é “só apontar o IP”. SSO, certificado e Address Book são partes separadas do problema.
  3. Certificado no cliente Windows é obrigatório no modo devtls.
  4. Nome de host estável > IP puro para TLS/SNI.
  5. Teste com cliente mais antigo antes de culpar o servidor inteiro.
  6. Em produção de verdade: usuário não-root, HTTPS real, backup do SQLite e revisão de exposição de portas.

Conclusão

Subir o Escargot em Ubuntu é viável e didático: você revê MSNP, autenticação legada, SOAP de Address Book e os efeitos colaterais de rodar software antigo em stack moderna.

Para uso casual, o serviço público do Escargot continua sendo o caminho mais simples. Para laboratório, nostalgia controlada ou estudo de protocolos, montar o próprio servidor ainda vale o esforço — desde que se documente os pontos que quebram no caminho.

Se alguém estiver tentando o mesmo setup e travar em t_user, 80048820, 84cc0020 ou HLL/stats, os sintomas acima costumam apontar a região certa do problema.

Projeto: gitlab.com/escargot-chat/server · Cliente recomendado: WLM 2009 patchado · Ambiente de teste: Ubuntu + LAN


Comentários

Postar um comentário

Postagens mais visitadas deste blog

-
Imagem
 Hoje finalizei um projeto bem interessante envolvendo monitoramento de infraestrutura com automação 🚀 Implementei uma integração entre um ambiente de climatização (CPD) e ferramentas de monitoramento, permitindo acompanhar em tempo real o estado dos equipamentos e a temperatura do ambiente. 🔧 O que foi feito: Integração de ar-condicionados via API Coleta automática de dados (temperatura, status, operação) Monitoramento centralizado Alertas em tempo real via Telegram 📊 Com isso, agora é possível: Identificar rapidamente aumento de temperatura Detectar falhas nos equipamentos (ex: ar ligado mas não refrigerando) Receber alertas instantâneos antes que vire um problema crítico Esse tipo de solução mostra como dá pra unir automação, IoT e monitoramento para aumentar a confiabilidade de ambientes críticos como CPD.
Leia mais

Monitor de Estatísticas de Performance de Servidor 🚀

-
Imagem
 O monitoramento contínuo de servidores é essencial para garantir a estabilidade e o bom funcionamento das operações. No entanto, nem sempre uma solução complexa faz sentido para todas as infraestruturas. Em ambientes menores, simplicidade também é uma estratégia . Ter uma ferramenta leve, funcional e direta muitas vezes é melhor do que não ter dado algum — ou depender de stacks grandes que exigem mais manutenção do que retorno. Pensando nisso, desenvolvi um script simples em Shell que exibe informações básicas de um servidor Linux, como: uso de CPU memória disco além de alguns dados adicionais do sistema A proposta é ser prático: em vez de executar vários comandos para obter essas informações, um único comando centraliza tudo de forma clara e rápida . Esse projeto faz parte de uma série de estudos voltados para o desenvolvimento de habilidades em DevOps , onde o foco é entender o problema e aplicar a solução mais adequada ao contexto — não necessariamente a ma...
Leia mais

Zammad - Sistema de chamados

-
Imagem
 🎯 Organização não é exclusividade da TI! Muita gente associa sistemas de chamados apenas ao time de TI, mas a verdade é que qualquer área que receba solicitações recorrentes pode (e deve!) se beneficiar desse tipo de ferramenta.  📩 E-mails e chats internos funcionam... até certo ponto. Mas quando as demandas aumentam, é fácil perder o controle — prazos se confundem, pedidos se repetem e o acompanhamento vira um desafio. Hoje finalizei a implementação do Zammad, um sistema de chamados (tickets) no setor de Engenharia — e posso dizer: 💡 foi um grande passo para a eficiência interna! Com o Zammad, tudo fica centralizado: cada solicitação gera um ticket, é priorizada e acompanhada até a resolução.  O resultado? 👇  ✅ Mais transparência nas demandas   ✅ Melhor comunicação entre as equipes  ✅ E, principalmente, organização e rastreabilidade de cada atividade A implementação foi feita utilizando 🐋Docker e 📃Docker Compose, o que tornou todo o p...
Leia mais