Se ha hablado en varias ocasiones sobre los beneficios que aporta I2P al anonimato y en alguna ocasión se ha hablado sobre cómo crear rutinas simples que permitan acceder a I2P utilizando la librería “Streming Library”, la cual se encuentra escrita en Java. Si quieres hacer cualquier tipo de prueba con Python contra I2P, actualmente hay pocas librerías que realmente te lo permitan y que sean estables. Por lo que he podido apreciar en los foros oficiales de desarrolladores, al parecer las personas clave en el desarrollo de plugins, utilidades y el propio core de la red no muestran mucho interés en desarrollar otra librería en un lenguaje distinto para hacer lo que sobradamente ya hace la Streaming Library y francamente tienen toda la razón del mundo, ya que tienen un “roadmap” con cientos de frentes abiertos y es mucho más interesante crear cosas nuevas y mejorar las existentes que reinventar la rueda. Al equipo de I2P le ha costado muchísimo desarrollar la Streaming Library y la cantidad de errores que se reportaban al principio era enorme, es normal que después del número de horas invertidas y el nivel de estabilidad en el que se encuentra ahora, haya sido declarada como la librería de referencia para crear aplicaciones que requieran el uso del protocolo de control de I2P (I2CP) sobre TCP. No obstante, seguimos con los mismos problemas:
1. Aun sigue siendo poca, muy poca la documentación sobre su uso. Si realmente quieres aprender los elementos clave de la librería, tienes que meterte en los JavaDocs y empezar a crear un mapa mental de como están relacionadas las clases y cómo puedes usarlas.
2. Si eres un desarrollador en Python o tienes alguna herramienta para acceder a la web profunda de I2P aunque sea para consultar “Destinations”. Bueno, lo tienes un poco complicado por lo que comentaba antes. Aunque existe el proyecto python-i2cp (https://github.com/majestrate/python-i2cp) para utilizar directamente el protocolo interno de I2P, pero no avanza al ritmo que se esperaría y aun no funciona correctamente a la hora de consultar un destination. Además, utilizar directamente I2CP está desaconsejado por el equipo de I2P. Nos queda utilizar Jython o la JSR de Java correspondiente para ejecutar código de scripting con Python desde la máquina virtual de Java.
Es este artículo intentaré centrarme en el primer punto y explicaré algunas características interesantes en Streaming library para Java y en un próximo articulo, intentaré explicar algunas alternativas a la hora de acceder a I2P desde Python.
No en todos los casos resulta viable utilizar la Streaming Library de I2P, pero por norma general, cuando se habla de aplicaciones punto a punto, como es el caso de descargas de torrents y cosas similares, resulta bastante conveniente y óptimo utilizar esta librería, de hecho, un ejemplo bastante claro lo tenemos con el proyecto I2PSnark, un cliente bittorrent que utiliza la Streaming Library para descargar y compartir torrents utilizando la red de I2P. El código fuente del proyecto se encuentra licenciado con la GNU/GPL y se está disponible en el siguiente repositorio GitHub: https://github.com/i2p/i2p.i2p/tree/master/apps/i2psnark Si se mira con atención las clases y métodos que se incluyen en el proyecto, es mucho más fácil comprender el funcionamiento de la Streaming Library y cómo utilizarla.
En primer lugar, cualquier rutina de código utilizando esta librería puede funcionar en uno de dos modos, o bien como cliente que consulta “destinations” (un destino en I2P es similar a la combinación de una dirección IP y un puerto) o simplemente como servidor. Las principales clases disponibles en la API son “wrappers” de las clases SocketServer y Socket de Java, aunque evidentemente las clases en la Streaming Library adicionan las funcionalidades necesarias para que todas las conexiones se lleven a cabo utilizando la red de I2P.
Por otro lado, en una instancia de I2P, un programa escrito en Java y utilizando la Streaming Library puede actuar como emisor o receptor (recordar que I2P es una red que basada en paquetes y no en circuitos como TOR), con lo cual desde un programa se puede generar el “destination” para que otros usuarios envíen paquetes a la instancia o se pueden buscar (lookup) destinos y enviarles paquetes. El siguiente código sería la clase más simple que se puede crear utilizando la Streaming Library para crear un emisor.
|
[sourcecode language=»java»] public class Server { |
Como se puede apreciar, se crea una instancia de la clase “I2PSocketManager” utilizando la factoría “I2PSocketManagerFactory” y posteriormente se crea un objeto “I2PServerSocket”, el cual será utilizado para atender a las peticiones de otros usuarios en la red de I2P. Finalmente, se pinta por pantalla el destination local del proceso recién iniciado. La clase “net.i2p.data.Destination” cuenta con los métodos “toBase64” y “toBase32” que serán utilizados por el cliente para comunicarse con la instancia de I2P.
El código anterior solamente se encarga de obtener una sesión I2P y pintar por pantalla el destination generado, pero una vez hecho esto, el hilo principal del programa termina. Las siguientes instrucciones que se deben añadir, deben permitir que el proceso se quede en estado de escucha para procesar los mensajes que envían los clientes, para ello la clase I2PThread permite crear un hilo de ejecución ininterrumpido que permitirá al emisor actuar como servidor y recibir mensajes.
|
[sourcecode language=»java»] |
En este caso se crea una nueva clase que procesará los mensajes de los clientes de forma indefinida en un bucle “while true”. En dicho bucle se aceptarán las conexiones de los clientes por I2P y posteriormente, se realizará algún tipo de procesamiento, el cual, típicamente consiste en recibir las conexiones por parte de los clientes y responder a los mensajes.
|
[sourcecode language=»java»] |
Por otro lado, el cliente debe conocer cuál es la dirección (destination) del emisor para poder transmitirle un mensaje y recibir su respuesta. El código necesario en la parte del cliente es mucho más simple, ya que solamente requiere utilizar la clase I2PSocket y conectarse con el destination especificado.
|
[sourcecode language=»java»] public class Client { |
El código anterior es la base para crear cosas mucho más elaboradas, por ejemplo, en lugar de utilizar las clases BufferedReader y BufferedWriter se podría utilizar clases como ObjectInputStream y ObjectOutputStream que permiten enviar objetos serializados (aquellos que extienden de la interfaz java.io.Serializable) y de esta forma, construir aplicaciones muy robustas al interior de I2P. Por otro lado, también se puede utilizar para crear plugins que se puedan desplegar directamente desde la consola de administración de I2P. Sobre estas cosas hablaré en un próximo articulo.
Saludos y Happy Hack!
Adastra.

2 respuestas a «Uso de Streaming Library para aplicaciones en I2P»
[…] Seguridad en Sistemas y Técnicas de Hacking.: “Uso de Streaming Library para aplicaciones en I2P” Visitar Fuente Original […]
[…] En la entrada anterior se ha venido hablado de los beneficios que aporta la Streaming Library si eres un usuario de I2P y quieres automatizar el proceso de crear “peers” descentralizados que, utilizando la red de I2P, puedan comunicarse y transferir información. Esta librería se encuentra escrita en Java y cuenta con todas las características necesarias para poder interactuar con el protocolo I2CP y poder desplegar servicios que utilicen/establezcan puentes de entrada y salida desde la instancia local de I2P. Tal como mencionaba en el artículo anterior, el procedimiento para crear un emisor y un receptor es bastante simple y si el lector alguna vez ha tenido que trabajar con sockets y programación en entornos de red en cualquier lenguaje, rápidamente podrá apreciar que aunque la librería aporta clases nuevas, su funcionamiento es muy similar a los clásicos sockets “servidor” y “cliente”, de hecho, las clases principales de la Streaming library son “wrappers” de las las clases “ServerSocket” y “Socket” de Java, aunque evidentemente implementando toda la lógica necesaria para poder interactuar con I2P. No obstante, cuando se navega por Internet en busca de información sobre el uso avanzado de está librería normalmente es muy complicado encontrar detalles técnicos que permitan adentrarse en su uso y casi en todos los casos, se implementa el típico ejemplo del servidor “echo”, en el que existe un cliente que actúa como emisor, un servidor que actúa como receptor y el receptor devuelve los mensajes de texto que envía el emisor, funcionando como un servidor “echo” muy simple, no obstante, uno de los principales beneficios con los que cuenta Java, es que tiene un sistema muy potente de serialización de objetos que permite compartir información entre diferentes JVM, algo que potencio enormemente la evolución de tecnologías tales como RMI, CORBA, JINI y posteriormente los tan conocidos EJB en el mundo de J2EE. En este caso, también es posible serializar objetos entre emisores y receptores I2P, lo que supone un abanico de posibilidades enorme a la hora de crear aplicaciones que utilicen la capa de anonimato que aporta I2P a sus usuarios, ya que se pueden crear objetos debidamente preparados para transmitir mucha más información que una cadena de texto. Para los que no lo sepáis, para poder serializar un objeto en Java, dicho objeto, sus atributos y todas las clases padre de las que hereda deben ser serializables también, lo cual se consigue implementando la interfaz “java.io.Serializable”, además, si alguno de los atributos de dicha clase no es serializable, debe utilizarse el modificador de acceso “transient” con el fin de indicarle a la JVM que dicho atributo debe utilizarse únicamente en el contexto de la JVM local y no se debe incluir en el proceso de serialización del objeto. Dicho esto, queda claro que una de las labores más importantes a la hora de diseñar una aplicación que aproveche los beneficios de la Streaming Library, consiste precisamente en definir una estructura de objetos que contenga todas las relaciones y atributos necesarios para transmitir información entre los túneles de entrada y salida de la instancia de I2P. La estructura de clases en cuestión, además de ser serializable, debe de ser conocida por todos los “peers” que la utilicen, ya que de no ser así, un emisor puede enviar un objeto Java a un receptor, perfectamente serializado, pero dado que el receptor no cuenta el “.class” de la clase, simplemente no sabrá cómo se debe deserializar el objeto. Lo que normalmente se suele hacer, es distribuir un fichero JAR con todos los elementos necesarios en cada uno de los peers, esto quiere decir que aunque la comunicación entre todos los receptores y emisores en I2P sea descentralizada, tienen que haber elementos de comunicación comunes que les permitan comprender los mensajes que se transmiten por sus túneles, exactamente igual que ocurre con las normas que se definen en cualquier protocolo de red con el fin de garantizar la interoperabilidad en las capas de transporte y aplicación. Además de esto, los receptores y emisores deben conocer los “destinations” de las entidades con las que se desean comunicar. Es posible implementar un mecanismo de descubrimiento automático utilizando un servicio oculto en I2P que sea accesible únicamente por aquellas personas que se desean comunicar y en dicho servicio, cada uno podría depositar el “destination” correspondiente a su instancia de I2P con el fin de que otros usuarios puedan enviarse información. […]