Archivo
Hoy vengo a hablar de mi libro: Deep Web: TOR, FreeNET & I2P – Privacidad y Anonimato

Este es mi tercer libro y sigo fomentando el habito de investigar, escribir y compartir, algo que llevo haciendo desde hace mucho tiempo y que personalmente me resulta de lo más entretenido, lo hago simplemente porque me apasiona. Como he comentado y seguramente muchos de vosotros os podéis imaginar, redactar un libro con estas características no es fácil, requiere de mucho tiempo y dedicación constante, pero para mi, hacer este tipo de cosas me resulta alentador y una motivación adicional para seguir adelante, especialmente después de volver del trabajo, a veces muy cansado y con poco animo por “perder” tanto tiempo del día sin hacer aquellas cosas que realmente te gustan, por sentir que estás desperdiciando tiempo valioso que podrías emplear en hacer cosas interesantes y que la mayor parte de tu energía se va en cumplir unos objetivos, que realmente no son los tuyos. En fin, seguramente muchos de vosotros sabéis de lo que hablo, pero francamente creo que lo importante es no desistir y continuar buscando alternativas que te puedan ofrecer esa libertad que cualquier persona con un poco de “espíritu hacker” siempre está anhelando.
Pluggable transports en TOR para la evasión de Deep Packet Inspection
Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.
Funcionamiento de los Pluggable Transports en TOR
Pluggable Transports en TOR con Obsproxy
La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.
Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.
Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.
Configuración del cliente de TOR Browser
Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.
Selección de un PT en Tor Browser
Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.
El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.
Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239
Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9 Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6 UseBridges 1 |
Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.
Saludos y Happy Hack!
Adastra.
Generación personalizada de direcciones ONION de TOR con Shallot
Las direcciones ONION en TOR son cadenas con una longitud exacta de 16 caracteres, compuestas por los dígitos entre 2-7 y las letras en minúsculas de a-z. Dichas direcciones generalmente se crean de forma automática por cualquier cliente de TOR, pero en ocasiones, se pueden encontrar sitios en la web profunda de TOR con direcciones ONION que no parecen ser tan aleatorias como la mayoría, en ocasiones tienen patrones fijos que determinan el contenido y/o temática del servicio oculto. Un ejemplo es Facebook, que cuenta con un servicio oculto en la web profunda de TOR para aquellos que quieran acceder a esta popular red social y ya de paso, perder su privacidad y probablemente el anonimato que brinda TOR. La dirección ONION de facebook en la web profunda de TOR es esta: facebookcorewwwi.onion y como se puede apreciar, existe un patrón bastante claro que además, resulta fácil de memorizar. Ahora bien, lo cierto es que personalizar la dirección completa (16 caracteres) con la capacidad de computo que tenemos actualmente resulta imposible, tal como comentaba en un articulo que he escrito hace algún tiempo, calcular y en consecuencia, descubrir un servicio oculto en TOR, puede llevar millones de años, una escala de tiempo que evidentemente no es tolerable. No obstante, si que se puede personalizar una parte de dicha dirección en poco tiempo, todo depende del número de caracteres que se quiera aplicar al patrón. Para hacer esto, existe una herramienta muy fácil de instalar y utilizar, dicha utilidad es Shallot.
INSTALACIÓN Y USO DE SHALLOT
Shallot es una herramienta que permite aplicar un patrón para personalizar una parte de la dirección ONION de un servicio oculto. Los patrones que se pueden aplicar típicamente son expresiones regulares que permiten indicar la forma en la que se debe generar la clave privada del servicio oculto y en consecuencia, la dirección ONION del mismo. Es un programa que se encuentra escrito en lenguaje C y solamente tiene dos dependencias: libssl y libcrypto, librerías que son bastante comunes en sistemas Linux. El proyecto se puede descargar desde GitHub y el proceso de instalación es tan simple como ejecutar “configure” y “make”
>git clone https://github.com/katmagic/Shallot.git
>./configure |
Las opciones que admite Shallot se pueden ver a continuación
>./shallot
Usage: shallot [-dmopv] [-f <file>] [-t count] [-x time] [-e limit] pattern -d : Daemonize (requires -f) -m : Monitor mode (incompatible with -f) -o : Optimize RSA key size to improve SHA-1 hashing speed -p : Print ‘pattern’ help and exit -f <file> : Write output to <file> -t count : Forces exactly count threads to be spawned -x secs : Sets a limit on the maximum execution time. Has no effect without -m -e limit : Manually define the limit for e Version: 0.0.3-alpha |
El interruptor “-p” puede ser útil para conocer algunos de los patrones (expresiones regulares) que se pueden aplicar con Shallot.
./shallot -p
base32 alphabet allows letters [a-z] and digits [2-7] pattern can be a POSIX-style regular expression, e.g. xxx must contain ‘xxx’ bar$ must end with ‘bar’ ^foo must begin with ‘foo’ b[a4]r may contain leetspeech 😉 ^ab|^cd must begin with ‘ab’ or ‘cd’ [a-z]{16} must contain letters only, no digits ^dusk.*dawn$ must begin with ‘dusk’ and end with ‘dawn’ |
Como se puede apreciar, algunas de las expresiones de ejemplo permiten aplicar patrones muy variados, como por ejemplo que la dirección ONION debe comenzar y/o terminar con una cadena determinada, que contenga solamente números o letras o que contenga en cualquier posición de la dirección una cadena determinada.
También existen otras opciones que permiten controlar el tiempo máximo en el que se debe ejecutar la herramienta, si se debe ejecutar como un proceso en “background” y si el resultado (clave privada para el servicio oculto) se debe almacenar en un fichero. Algunos ejemplos del uso de estos interruptores se enseña a continuación
>./shallot -f /home/adastra/private_key ^hack
>./shallot -m -o ^hacker >./shallot -m -t 15 ^hacker |
En todos los casos, después de procesar y descubrir una clave privada cuya dirección ONION generada contenga el patrón, se pinta por pantalla o se crea un fichero con dicha clave privada para que sea utilizada por un servicio oculto.
Como comentaba antes, el número de caracteres especificados en el patrón es importante y determina si es posible obtener una clave privada que encaje con el patrón y cuánto tiempo puede tardar el calculo de dicha clave. En el proyecto de GitHub de Shallot se enseña la siguiente tabla que nos da una idea del número de caracteres que podemos personalizar en la dirección ONION.
characters | time to generate (approx.) |
1 | less than 1 second |
2 | less than 1 second |
3 | less than 1 second |
4 | 2 seconds |
5 | 1 minute |
6 | 30 minute |
7 | 1 day |
8 | 25 days |
9 | 2.5 years |
10 | 40 years |
11 | 640 years |
12 | 10 millenia |
13 | 160 millenia |
14 | 2.6 million years |
Las pruebas anteriores las ha realizado el autor con un ordenador de 1.5Gh de procesador. Si bien es cierto que se puede utilizar ordenadores mucho más potentes, las estimaciones anteriores no sufren cambios considerables con una mayor capacidad de computo, además, solamente se ha llegado a calcular hasta 14 caracteres, la cifra con 15 y 16 caracteres puede llegar a billones de años. Muchísimo más de lo que estamos dispuestos a esperar, por mucho que estemos acostumbrados a utilizar sistemas Windows.
Suponiendo que se utiliza un patrón con pocos caracteres, se puede generar una clave privada en muy poco tiempo, de hecho, las dificultades comienzan a partir de 7 o 8 caracteres, pero cualquier patrón que esté por debajo de dicho valor, puede ser procesado por Shallot en un tiempo bastante razonable.
Uno de los resultados que da la herramienta tras aplicar el patrón “^hack” es el siguiente
—————————————————————-
Found matching domain after 998147 tries: hacktkeocgipcjvv.onion —————————————————————- —–BEGIN RSA PRIVATE KEY—– MIICWwIBAAKBgQCmZx9BMoG55KOoyAa0T43rNRW4z8m9vjgdXRxX2ZOaFMbrMITC U6zm5CaauB0RYvu0m99/J9YhfXJQor69/YUIWMWGOXdn3CfVPML5kJWdCF68jhyE qmPJAaTuodv7rwlB0KyTzOYUGNLDN/yZey9aG2CKWLfTX/w3Aq7c/6Y20QIDBKSB AoGABFqfSWmx3CIHU40PJCv2ecf61m7LZcAQErvXddYZDCodEYKXDypWJZatQjKm Whl9DGCZIMR3jpfVrKlIVjwT8+ERk35DXdRGzWi0n/y8be5XokYMnTreEbkcsprR H8TeN6cJPwrjgXnd4g9Z2q9luKkDegdGLbsKY9nnh8lf5oUCQQDZi+lDL7S/jEoX k5Xs805cTLPnqdGT0RelivchoGm03U2ggIUycCLv0SM6VaRcKNsBrGBtWg5jznu9 Xm9865xvAkEAw9DuwqkXK+WixHVY+uoT+LUHmBRJiVV+ZHKUzCOvF4yTxqGNCMAM LcuCZtiamFbA4YQnBHAMRpMJt12/OSuAvwJAQjs2GYeqUmYE0MFt99KYhA2HHDny DpSzwriBqAKC/lzk/SnEyYw5nBb/+zLYS3+zNUEAEZ8ktwIF1eFVriczdQJAE6qG q9J5kLbmVuyhkBB0zO5hcCE5EFVren5/XUGrzOz1hJbv4Q+9TkqDO3xaQ/v+iIqt hmu8XPNRhi50Q4vXhwJAQywFaZosVqFLUPJB4AmMeKQ2nPHpSLVVWFVPNNTypDZC LDJgX849UGd0Nu9bCTWFtJaFROGUOa8U2cIsa8N6iQ== —–END RSA PRIVATE KEY—– |
A continuación, solamente es necesario incluir el contenido anterior en un fichero con nombre “private_key” que se deberá ubicar en el directorio que se declara en la propiedad “HiddenServiceDir” del fichero de configuración de TOR (torrc).
HidenServiceDir /home/adastra/servicioOculto
HiddenServicePort 80 127.0.0.1:80 |
Con las dos directivas anteriores se define un servicio oculto que va a procesar peticiones de los clientes por el puerto 80 en la dirección ONION generada. En este caso, el fichero “private_key” con la clave RSA generada por Shallot debe ubicarse en el directorio “/home/adastra/servicioOculto”. Una vez hecho esto, basta con arrancar la instancia de TOR utilizando el fichero torrc con las directivas anteriores y se podrá ver que en el directorio “/home/adastra/servicioOculto” existe un nuevo fichero llamado “hostname”, con la dirección ONION generada a partir de la clave privada definida en el fichero “private_key”.
Con estos sencillos pasos se puede personalizar una parte de la dirección ONION de un servicio oculto en TOR, algo que en algunos casos viene bien para tener direcciones que sean un poco más fáciles de recordar y compartir.
Saludos y Happy Hack!
Adastra.
Bridges en TOR y una introducción a los “Pluggable transports”
TOR se caracteriza por ser una red centralizada, en la que cada hora, una serie de servidores de confianza llamados “autoridades de directorio” se encargan de generar información sobre los repetidores que conforman la red y algunos datos adicionales sobre el estado general de la misma. Dicha información es pública y se puede consultar fácilmente ejecutando peticiones HTTP contra cualquiera de las autoridades de directorio o sus espejos. Dado que la información sobre los repetidores la puede consultar cualquiera, una de las principales medidas que toman las entidades represoras a la hora instaurar controles y censurar contenidos, consiste simplemente en incluir dichas direcciones IP en una lista negra para impedir que se puedan realizar conexiones contra cualquier repetidor de TOR. Es una medida que se utiliza muchísimo y que según algunos artículos publicados en el blog de TOR (https://blog.torproject.org/) es una de las medidas más utilizadas en países como Cuba, China, Etiopía, Corea del Norte, etc. Con el fin de hacer que la red sea resistente a este tipo de censura, el equipo de TOR ha desarrollado un sistema para que los ciudadanos de países como los anteriores puedan seguir utilizando TOR sin problemas, aunque las direcciones IP de los repetidores incluidos en los consensos o incluso las direcciones IP de las autoridades de directorio se encuentren bloqueadas. Dicho sistema es conocido como “Automatic Bridging” y es un mecanismo en el que se busca eludir la censura por parte de adversarios fuertes, como es el caso del gobierno de un país. Para conseguir esto, las autoridades de directorio utilizan unos repetidores especiales llamados “Bridges” o puentes, los cuales funcionan exactamente igual que cualquier repetidor que hace parte de un circuito en TOR, pero con la diferencia de que no se exponen públicamente en los descriptores emitidos cada hora por las autoridades de TOR. Los bridges pueden ser creados por cualquier usuario de TOR y si estás a favor de la libertad de expresión y te asquea ver como en ciertos países la gente no puede expresar libremente sus ideas sin temor a que sus vidas o las de sus familiares corran peligro, te recomiendo que configures tus instancias de TOR para que también funcionen como puentes y sean utilizadas por aquellas personas que desean reportar los abusos que se comenten en ciertos lugares del mundo.
Para aquellos que desean obtener un listado de bridges de TOR, dado que no se pueden conectar directamente con las autoridades de directorio o con los repetidores que conforman la red, existen dos formas:
1. Consultar los puentes en “BridgeDB”, el proyecto oficial de TOR para acceder a un conjunto reducido de puentes que servirán para eludir la censura. Dicho proyecto se encuentra ubicado en el siguiente enlace: https://bridges.torproject.org. Para obtener los bridges basta con pinchar sobre el botón en el que pone “Get Bridges” u “Obtener puentes” y después de ingresar un captcha, se enseñarán dos puentes que deben ser configurados en la instancia de TOR que no consigue llegar a las autoridades de directorio o a los repetidores de la red.
2. En el caso (bastante frecuente) de que el proyecto “BridgeDB” también se encuentre censurado, la otra alternativa para recibir un par de puentes validos es escribir un correo a la dirección “bridges@torproject.org”. El mensaje no tiene que tener un contenido, es simplemente una dirección de correo que responde de forma automática al remitente con lo que ha solicitado. En el asunto del mensaje se debe especificar un “comando” para obtener información sobre BridgeDB. Si se envía un mensaje a dicha dirección, sin asunto, la respuesta automática contendrá los posibles comandos que puede enviar el comando a la plataforma de BridgeDB.
El contenido del mensaje devuelto, en el caso de no incluir un asunto es el siguiente:
” Hey, debiadastra! Welcome to BridgeDB! COMMANDs: (combine COMMANDs to specify multiple options simultaneously) Currently supported transport TYPEs: BridgeDB can provide bridges with several types of Pluggable Transports[0], Some bridges with IPv6 addresses are also available, though some Pluggable Additionally, BridgeDB has plenty of plain-ol’-vanilla bridges – without any [0]: https://www.torproject.org/ |
En el caso de indicar el asunto “get bridges”, lo que se puede ver es lo siguiente:
“Hey, debiadastra! [This is an automated message; please do not reply.] Here are your bridges: 83.212.111.114:443 0A6EF34EDF047BFD51319268CD423E To enter bridges into Tor Browser, first go to the Tor Browser download When the ‘Tor Network Settings’ dialogue pops up, click ‘Configure’ and follow > Does your Internet Service Provider (ISP) block or otherwise censor connections Select ‘Yes’ and then click ‘Next’. To configure your new bridges, copy and [0]: https://www.torproject.org/ |
Como se puede ver, ha devuelto tres repetidores con la dirección IP, puerto y fingerprint del puente. Ahora, para que una instancia de TOR pueda utilizar dichos puentes, basta con especificar las siguientes líneas de configuración en el fichero “torrc”.
|
Si estas interesado en crear tu instancia de TOR para que funcione como puente, el procedimiento es bastante sencillo, sin embargo, no se puede configurar una instancia de TOR que funcione como repetidor y puente al mismo tiempo, lo cual es lógico, ya que los repetidores son públicos y los puentes privados y establecer una instancia que actúe como repetidor y puente es equivalente a crear un puente de acceso público y fácil de censurar, lo cual evidentemente no tiene ningún sentido.
Es necesario incluir las siguientes líneas de configuración en el fichero “torrc”:
SocksPort 0
ORPort 8080 Exitpolicy reject *:* DataDirectory /home/adastra/workspace/bridge/ BridgeRelay 1 |
Como se puede ver, tanto configurar como utilizar un puente es una tarea bastante simple y es una solución que se ajusta bastante bien al problema de la censura. Sin embargo, algunos “rivales fuertes”, tales como los gobiernos de China o Corea del Norte, ahora ya no solamente bloquean las direcciones IP que se encuentren relacionadas con la red de TOR, ahora aplican técnicas de análisis de paquetes que detectan si los paquetes intercambiados utilizan el protocolo de TOR. Ante una medida así, los puentes por si solos pierden efectividad y se hace muy difícil ocultar el trafico. Aquí entra en juego lo que se conoce como “Pluggable Transports”.
Introducción a los Pluggable Transports
Las técnicas DIP (Deep Packet Inspection) se han vuelto cada vez más comunes en aquellos países en los que el nivel de censura es alto. Las rutinas DIP se encargan de analizar un conjunto de paquetes y reensamblarlos para clasificarlos partiendo de patrones conocidos. De esta forma, con DIP es posible determinar que un conjunto de paquetes se encuentran transmitiendo datos en la red de TOR aunque la dirección IP no se encuentre bloqueada.
Ahora bien, la especificación de “Pluggable Transports” define a esta tecnología como la capacidad de convertir flujos de trafico de TOR entre el cliente y un puente, en flujos admitidos y no reconocidos por técnicas de DIP, como por ejemplo, una conversación inocente con cualquier servidor web en Internet. Notar que aunque el rival (censor), pueda monitorizar el trafico y analizar los paquetes en profundidad, no verá ningún patrón conocido que le permita determinar con exactitud que se trata de un paquete que viaja por TOR.
El objetivo de los PT (Pluggable Transports) consiste básicamente en ofuscar el trafico entre el cliente y sus puentes. Para ello, se utiliza un componente de software adicional tanto en el cliente como en la instancia de TOR que funciona como puente. Dichos componentes deben conocer una serie de reglas para poder ofuscar el trafico (cliente) y posteriormente, poder desofuscarlo (servidor). Actualmente existen varias herramientas y frameworks desarrollados siguiendo la especificación de PT ubicada en el siguiente enlace https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt y seguramente la más conocida y popular es OBFSPROXY, un framework implementado en Python del que os hablaré en un próximo articulo.
Un saludo y Happy Hack!
Adastra.