Arpchat - una app de chat para enviar mensajes a amigos en la misma red usando solo ARP

• arpchat es una herramienta convertida en app de chat que usa ARP, el protocolo que las computadoras usan para encontrar la dirección MAC de otras computadoras en la misma red
• El proyecto surge de la idea de querer chatear con amigos en una red con aislamiento entre clientes
• Implementa un protocolo de transporte genérico y simple sobre ARP, con el que puede enviar mensajes de decenas de miles de caracteres, y también usa algo de compresión
• Incluye un sistema de presence discovery y heartbeats para actualizar la lista de usuarios en línea, junto con notificaciones de entrada y salida
• Los binarios para instalación se pueden descargar desde la releases page
  • En Windows puede ser necesario npcap, y durante la instalación hay que seleccionar Install Npcap in WinPcap API-compatible Mode
  • En Linux puede ser necesario otorgar permisos de red con sudo setcap CAP_NET_RAW+ep /path/to/arpchat
• El binario se ejecuta desde la terminal, y si el mensaje enviado aparece en tu propia pantalla, puede considerarse que está funcionando correctamente
• La compilación fue probada en la versión unstable más reciente de Rust, y para compilar en Windows se necesita WinPcap Developer's Pack y configurar la variable de entorno LIB a la carpeta WpdPack/Lib/x64/

[GN⁺]

Opiniones de Hacker News

• Soy quien hizo esto. También hice otra cosa que publiqué hoy en HN (https://news.ycombinator.com/item?id=37062422), y me resulta bastante curioso ver que ArpChat también apareció. Probablemente alguien vio mi perfil.
  Fue un proyecto realmente divertido y aprendí mucho sobre redes.
  Hace poco también tuve la oportunidad de usarlo de verdad en un entorno totalmente offline, y fue divertido. Pero después encontré un bug importante, y ese bug estaba causando una latencia enorme. Ya lo corregí, pero todavía no pude subir un nuevo artefacto de build, así que si piensas probarlo en un entorno real, conviene compilarlo directamente desde el código fuente. También agregué, por diversión, colores para los nombres de usuario y horas en los mensajes. Prometo subir pronto una nueva versión.
  Si les interesa, también hay un artículo que escribí hace aproximadamente un año sobre cómo funciona ArpChat: https://kognise.dev/writing/arp

  • Estuve leyendo todo esto y no paro de reírme. ArpChat probablemente le cause un infarto a un administrador de red, pero la idea en sí es realmente genial. Yo también era de los que leían libros sobre las capas OSI por diversión, así que lo entiendo.
    Espero que sigas jugando con código. Se parece un poco a lo que justine tunney mostró en trabajos como https://justine.lol/ape.html: meterse a fondo en un área que solo unos pocos entienden bien, por ejemplo los detalles de los formatos binarios de compiladores, y luego hacerse una pregunta loca como “¿no se podrían enlazar todos los formatos binarios en un único metaformato y hacer que realmente se ejecute en todos?”, para después construir algo que de verdad funciona.
  • El banner al final del README es realmente gracioso y hermoso. Gran trabajo.
  • ¿Esperas que funcione también en Linux?
    # sudo getcap ./arpchat
./arpchat cap_net_raw=ep
    Recibo “error getting channel, might be missing permissions”
    Agregado: este error viene de arpchat, no de la configuración de setcap.

• Justo esto era lo que quería. Travesuras en la capa de enlace de datos.
  Para quienes no sepan qué es Address Resolution Protocol (ARP), dicho muy a grandes rasgos, es el eslabón perdido que conecta las direcciones MAC (las que usa Ethernet) con las direcciones IP (las que usa Internet). Cuando la tabla de ruteo IP, que puedes ver con route, decide a qué dirección IP enviar luego un paquete, la caché ARP, que puedes ver con arp, determina la dirección MAC correspondiente a esa IP. Normalmente es la dirección IP local del router.
  Hoy en día, solo saber que ARP existe ya se considera casi como conocimiento místico no profesional, y su hermano del lado de IPv6, Neighbor Discovery Protocol, aún más. Aunque en despliegues modernos basados en la nube no se trate directamente muy seguido, saber que existe da una visión mucho más completa de todo el stack de red.

  • Me cuesta estar de acuerdo con que ARP sea un conocimiento esotérico. Para alguien que trabaja con redes, entender ARP, o al menos conocerlo, sigue siendo casi imprescindible. arping es muy útil para verificar si un equipo en el mismo segmento de red está encendido pero no responde a ping ICMP.
    Si miras volcados de tcpdump o Wireshark, tarde o temprano te lo vas a encontrar. Eso sí, como la nube y las redes tradicionales son muy distintas, un ingeniero de software quizá lo encuentre antes al depurar la red de su casa que una aplicación.
  • Hoy en día probablemente sea más común 802.11. Aun así, cuando un host necesita obtener una IP, ARP podría usarse sobre cualquier protocolo de capa de enlace de datos: https://en.wikipedia.org/wiki/Data_link_layer
  • Si de verdad ARP se está volviendo algo poco familiar, es una pena. Me cuesta imaginar que alguien diga entender cómo funcionan las redes IP y no tenga al menos una familiaridad mínima con ARP.
  • También puedes hardcodear las entradas ARP de otras computadoras de la red que tengan direcciones IP fijas.

• Es divertido abusar de que ARP pueda llevar un payload arbitrario, pero, volviendo a una perspectiva introductoria de redes, lo central en lo que se apoya el autor es el simple hecho de que un switch inunda todo el dominio de broadcast con los paquetes dirigidos a ff:ff:ff:ff:ff:ff.
  Incluso sin privilegios de superusuario ni permisos de paquetes raw, si envías paquetes a una dirección de broadcast L3, normalmente se inundan en L2, así que puedes lograr una propagación de mensajes similar. Es decir, hacer ping a una dirección de broadcast es divertido.
  Usar ARP no tiene ninguna ventaja especial. Además, muchos switches modernos tienen funciones para vigilar paquetes ARP, así que generar mucho tráfico ARP falso podría tener efectos realmente negativos. Aun así, es un trabajo divertido y me recuerda las travesuras que hacía cuando estaba aprendiendo. Personalmente, creo que habría abusado de ICMP para este propósito, y podría ser una dirección futura de desarrollo. Aplausos por un proyecto divertido.

  • También usa otro principio importante de introducción a redes: al final, todo son números.
    ARP, DNS, HTTP y TLS son, por un lado, exactamente esos protocolos que imaginamos, pero al mismo tiempo no son más que números. ARP accede al mismo espacio de números que HTTP. UDP no es el único que usa bytes de 11 bits, ni DNS tiene alguna instrucción especial de CPU que solo él pueda usar. Al final, todo son números. En última instancia puedes empujar los números que quieras por el cable, y el resto del mundo los recibe y sigue haciendo lo suyo.
  • Uno de los primeros ataques DDoS por amplificación que vi fue en los años 90: falsificaban como origen la dirección del host víctima y luego enviaban ping a la dirección de broadcast de una red universitaria ingenua.
    Hoy en día no debería funcionar, pero en ese entonces las implementaciones TCP/IP ingenuas —es decir, muchas— participaban con gusto.
  • ¿Te refieres a https://hpbn.co/?

• Me gusta abusar de protocolos que vienen integrados por defecto en la mayoría de los sistemas operativos. Como no encontré un sistema de mensajería GUI/CLI multiplataforma que no requiriera instalar software cliente aparte, una vez hice una tonta compartición Samba falsa en la que se podían ver mensajes desde Finder.app/Explorer.exe/Gnome/KDE
  En la red local, invocar netcat tampoco funcionaba muy bien, y para hacer broadcast también había diferencias de flags según el sistema operativo. La idea era ver el mensaje de la compartición Samba en el explorador de archivos, hacer clic y luego modificar el nombre del archivo para actualizar un “tablón” de 3 líneas
  https://github.com/jedahan/samba-haiku/blob/master/index.js
  Esto también era una reimplementación de algo que originalmente usaba el SSID de Wi-Fi para crear haikus de captive portal
  https://github.com/jedahan/haiku-wifi

• Puede ser más divertido de lo esperado. Estábamos separando la red usando VLAN con hardware de un proveedor importante y descubrimos que, aunque las VLAN funcionaban en la mayoría de los casos, el tráfico ARP se filtraba
  Las máquinas debían enviar todo el tráfico a través del router, pero a veces veían respuestas ARP que no debían ver y concluían que podían llegar directamente a otra máquina. Como resultado, no podían enviar tráfico hasta que expirara la entrada de la caché ARP, lo cual era un dolor de cabeza. El proveedor era demasiado grande como para importarle y no mostró interés en corregir el bug
  En ciertas circunstancias, esta app de chat podría atravesar VLAN

  • Interesante por la misma razón. Si se pueden enviar y recibir mensajes ARP con payloads arbitrarios, sin duda sería más fácil diagnosticar problemas de VLAN u otros temas de conectividad L2
  • Según mis pruebas, puede atravesar bastantes cosas

• Mi esposa, mis hijos y yo trabajamos o estudiamos mayormente desde casa, así que a menudo estamos cada uno en habitaciones separadas. Para mandarnos mensajes cuando hace falta usamos BeeBEEP. Fue decisivo que no necesite servidor y que tenga clientes tanto para Linux como para Windows
  Funciona bastante bien, aunque a veces hay que reiniciarlo después de que una laptop despierta de suspensión para volver a ver a las demás personas de la LAN. Y mi única queja real es que desde el ícono de la bandeja no se puede abrir directamente una ventana de mensaje a una persona concreta. También permite copiar y pegar fotos graciosas de gatos, y tiene funciones que no uso, como transferencia de archivos. No es publicidad pagada, solo me extendí demasiado
  https://www.beebeep.net/

  • Creo que la belleza de este proyecto no está en la mensajería en sí, sino en abusar de protocolos de red de bajo nivel para salirse de cosas como el aislamiento de clientes

• En la secundaria hice esto con net send y me metí en problemas

  • Encontré ese truco y se lo mostré a algunos amigos, pero el secreto no duró mucho. De pronto, un grupo más grande de gente que ni siquiera eran mis amigos lo estaba usando para hacer trampa en la clase de computación. Me molestaba la trampa descarada, y también me fastidiaba un poco que gente que no me caía especialmente bien se beneficiara de algo que yo había descubierto
    Así que falsifiqué el nombre de usuario del administrador del sistema (en Win9x no era difícil) y envié un mensaje de advertencia severo. Por lo visto se asustaron bastante, porque de repente todos los mensajes se detuvieron
  • write manda saludos
    https://en.wikipedia.org/wiki/Write_(Unix)
  • Recuerdo que net send tenía que estar conectado a un dominio, así que no creo que usara ARP
  • Si el analizador de red estaba mal o no prestaba atención a paquetes ARP extraños, probablemente la mensajería por ARP habría sido difícil de detectar
  • Qué tiempos. En la universidad, por accidente —bueno, intencionalmente— envié un mensaje a todo el dominio, y los profesores de TI nos miraron de inmediato a los problemáticos

• Muy bueno. Dicho eso, TCP/IP no sigue el modelo OSI, así que es difícil aplicar tal cual las distinciones sutiles de OSI
  En la práctica, ARP puede definirse como capa 2.5 según el modelo TCP/IP de Stevens, así que llamarla 2.5 parece lo más razonable. Y como las tramas ARP no se enrutan, claramente no es L3

• En la época en que NAT IPv4 era prácticamente el estándar —y todavía lo es, aunque hoy también existen IPv6 y CGNAT— hice algo llamado NATChat
  Básicamente creaba salas de chat según la dirección IPv4 pública, para que pudieras chatear con cualquiera en la misma red. Era bastante útil para usarlo con otras personas en la oficina. La oficina, por cierto, era algo que existía en aquella época

• También hay algo similar en C++: https://github.com/gbonacini/arpchatcpp