 |
| Fuente: onodo.org/visualizations/98748/ |
Plataformas:
- De momento sólo se ha probado en Kali linux, pero se puede experimentar en otras plataformas.
- Se recomienda si se va a probar Syndicate en Windows, usar Cygwin o WSL, aunque nos garantiza nada.
- En Android técnicamente debería funcionar con Userland, aunque Tmux no es mala elección.
Primero clonamos el repositorio:
git clone https://github.com/DtxdF/Syndicate
cd SyndicateY luego instalamos los requisitos:
Se puede optar por una instalación fácil con PIP, pero hay algunos inconvenientes que dependen de uno mismo.
En primer lugar, lo que si es necesario ejecutar es requirements/requirements.txt:
python3 -m pip install -r requirements/requirements.txtEn el archivo podemos encontrar:
PySocks==1.7.1
pycryptodome==3.9.4
PyYAML==5.1.2
pager==3.3
requests==2.22.0
urllib3==1.25.7
certifi==2019.9.11
chardet==3.0.4
idna==2.8
pyperclip==1.7.0Estos son los requisitos para que funcione lo principal de Syndicate, mientras que para los complementos se tendrían que seguir los siguientes pasos, no obstante no es necesario instalar para las funcionalidades anteriormente mencionadas, esto sirve para aumentar las funcionalidades...
python3 -m pip install -r requirements/requirements.complements.txtEn el archivo podemos encontrar:
requests==2.22.0
pynput==1.4.5
six==1.13.0
python-xlib==0.25
pygame==1.9.6
mss==4.0.3Un último requisito para los complementos predeterminados sería "PyAudio", pero esto requiere un poco más de colaboración:
En el caso de Windows:
Seleccionar la versión correspondiente: PyAudio
En mi caso es: PyAudio‑0.2.11‑cp37‑cp37m‑win32.whl
Mientras que en Linux:
sudo apt-get install libasound-dev portaudio19-dev libportaudio2 libportaudiocpp0
sudo apt-get install ffmpeg
sudo pip install PyAudio==0.2.11Ahora te estarás preguntado: ¿Windows?, ya mencioné que sólo funciona en Linux... claro, estos requisitos son para los complementos dependiendo del SO a atacar.
Una vez hecha la instalación, vamos con lo bueno...
Importante:
Antes de continuar quiero aclarar unas cosas...
En Syndicate Project prefiero tener sinonimos para algunas cosas:
- Evie: El servidor root; centro de comando y control; servidor inicial o nodo inicial
- Rook: El bot cliente
- Jacob: El administrador que mantiene al Rook
- Administrador del servidor: Es el que se encarga de crear, asignar privilegios, configurar y mucho más, para un correcto funcionamiento
Tratare de englobar todas las caracteristicas posibles de Syndicate, espero no me falte nada :)...
- Múltiples conexiones a la vez
- Cifrado híbrido en las conexiones. Usando AES256 y RSA a nuestro favor podremos cifrar nuestras comunicaciones oficiales entre Evie's (Servidor), Jacob's (Ciente-Administrador de los Rook's) y Rook's (Cliente-bot).
- Cifrado simétrico en las bases de datos, tanto de Evie, como la de los rook's. Aunque en los accesos públicos también se usá el mismo esquema.
- Red punto a punto. La red de los Rook's, no es igual a la de los Evie's, aunque puede haber comunicación entre ellas.
- Multi-usuario. El administrador del servidor se encarga de crear tanto usuarios Jacob's cómo Rook's con sus respectivos privilegios.
- Compartir Rook's (Bot's) entre Evie's (Servidores). -Cómo una red social :D-
- Comunicación por nodos o lo que quiere decir, que creando una red entre Evie's puede hacer pasar cada paquete a una dirección o podría decirse nodos intermedios hasta llegar a un punto final o nodo final (Que vendría siendo otro Evie). La red está diseñada para que no se pueda saber que dirección envío qué y dónde, exceptuando algunas cosas que ya explicaré después y además se tiene que configurar toda la red manualmente; eso brinda más seguridad.
- Uso de proxy's para mayor privacidad (Tanto en los Evie's, Rook's y Jacob's).
- Sistema antí-fuerza bruta. Es relativo. Relativo según las configuraciones que ejerce el administrador y el mismo usuario. porque el administrdor decide cómo Evie, va a bloquear a un usuario, cuándo y porqué. Dejaré la explicación más adelante.
- Los complementos se pueden actualizar de forma transparente o lo que quiere decir, que sí tenemos una máquina infectada podremos cambiar el código desde el servidor y ejecutarlo en la máquina correspondiente.
- Además del cifrado que viene incorporado, podemos agregarle una capa más con https
- Puedes crear tu propia forma de comunicarte, por lo tanto tiene dinamismo.
- Los complementos le temen al disco duro, prefieren quedarse en memoria.
- En el lado de los rook's podemos hacer que el router de la victima abra un puerto con UPnP (Sí está disponible)
Tipos de configuración
- Configuración Dinámica: Este tipo de configuración puede cambiar en plena ejecución de Evie dependiendo de lo que haga el administrador del servidor.
- Configuración Estática: También se puede llamar configuración global, porque en la mayoría de utilidades, herramientas y todo lo que tenga que ver con Syndicate la utiliza; además esta no cambia en plena ejecucion.
En Syndicate Project trato de implementar diferencias entre usuarios para simplificar las explicaciones; en el proyecto se puede encontrar cuatro tipos de usuario:
- Administrador del servidor: El administrador del servidor es una pieza obligatoria para armar el tablero. Éste se encarga de crear, configurar, manejar y mucho más, de lo que tenga que ver con el funcionamiento interno de Syndicate.
- Jacob: Él es el cliente-administrador de los rook's. Jacob podrá controlar tantos rook's cómo el Administrador del servidor desee.
- Rook: El cliente-bot que se encarga de hacer lo que le pida Jacob
- Public: Yo no diría que es un usuario en sí, se podría decir que es un cliente que quiere usar nuestros servicios públicos. Entre los cuales están:
- getPubKey: Obtener la Clave Pública de Evie; Puede tener muchos fines esta operación, pero la más importante es cuando compartirmos un rook.
- saveData: Guarda los datos de perfil del rook
- resend: Re-envía datos a otro nodo, tanto un nodo final como podría ser un nodo intermedio
- sendSOS: Comunicación estilo correo electrónico entre Evie's (Incluso envío de archivos)
Aclaraciones:
Tengo que explicar algunas cosas que iré mencionando poco a poco a lo largo de este documento:
- Redirector: Es un Rook que passa hacer un servidor (No un Evie) dentro de la máquina infectada; consiste en crear un servidor capaz de recibir datos, almacenarlos en una base de datos cifrada dentro de la misma máquina victima, para que luego el administrador del servidor, pueda conectarse, descargar los datos y simular ser Evie, con el único fín de obtener un resultado y enviarselo a un rook de forma transparante o como si no fuera sucedido nada. El redirector es buena opción, cuando deseas crear un "Backup" dentro de las máquinas infectadas ¿Por qué?, ¿Te imaginas que tu servidor central cayera? y luego cuando lo vuelvas a levantar ya es muy tarde, no tienes como recuperar la perdida de datos; hay es cuando entra redirector al rescate. Claro que necesitas abrir un puerto en el corta fuegos de la victima. Syndicate se encarga de crear la conexión, tú te encargas de todo lo demás.
- Hash dinámico: En syndicate se usa un Hash dinámico, para hacer todo lo posble para evitar un ataque de fuerza bruta o por diccionario, usando iteraciones, Número de seguridad, Número de disminución y Caracteres de seguridad; todo esto tiene que ver con el algoritmo utilizado, pero haciendo una aclaratoria:
- Iteraciones: Las iteraciones son el número de veces que se repite el proceso.
- Número de seguridad: El número de seguridad se multiplica primero por el mismo y el resultado se usa para delimitar la ofuscación de caracteres de seguridad y luego en la siguiente iteración (Si es que la hay) disminuye usando el número de disminución.
- Número de disminución: El número de disminución se encarga de disminuir el número de seguridad por cada segunda iteración.
- Caracteres se seguridad: Los caracteres de seguridad se codifican a base64 y se "parten" y ofuscan usando el número de seguridad y disminución, para luego sumarlos con el resultado verdadero, que quiere decir, el hash.
sha256( sha512( string ).digest()).hexdigest()
- Token de Acceso: Usado para verificar que tenga acceso público al sistema y cifrar los datos, posteriormente se usaría algún servicio antes mencionado.
- Clave secreta: La clave secreta cifra algunos datos (Cómo la dirección URL de los nodos) antes de usar "resend" o un reenvio de paquetes en una red, porque que si llega a hacer interceptada, no se pueda "leer" esos datos, por eso su nombre, ésta sólo se debe compartir con las personas de confianza, igual que pasa con el token de acceso.
- Clave única: La clave única es una clave generada aleatoriamente en la creación de un nuevo Jacob, es importante darsela al administrador correspondiente, porque gracias a ella puede acceder. La clave única cada vez que inicie sesión, cambiará, eso es para mantener aún más seguro la estructura.
- Jacob y Rook: Quiero aclarar, a pesar de que la aplicación payload.py es la que interectua con el servidor, no es más que una simple herramienta de pruebas, el conejo debajo del sombrero enrealidad es rook.py; mientras que para controlar a los rook's sería control.py en este caso es jacob.py.
Notas:
- Tú, como administrador del servidor te debes encargar de repartir a personas de confianza el token de acceso, claro sí es qué desean usar los servicios públicos. No es aplicable si es un Jacob y tiene el permiso getToken, porque la puede obtener sin necesidad de perdirla.
- El token de acceso se tiene que usar mayormente para Compatir un rook o usar resend.
- En el caso de usar resend, tiene que usar además del token de acceso, la clave secreta.
- Prefiero que usted usé sendSOS y se comunique con el Evie que desee, para que tenga más seguridad en sus datos y sin limitaciones por parte de servidores externos. Aclaro ésto, porque así es la mejor manera de enviar claves secretas de forma segura. Hay otras alternativas, pero es bueno que uno mismo sea el propio servicio y no depender de otros.
- Tenga absoluto cuidado con los números y caracteres de seguridad, pueden volver el proceso más lento, pero eso no es tan malo, porque si un atacante quiere hacer fuerza bruta, tiene que esperar a que el servidor genere el hash y luego verificar si es correcto o no. ¿Una maravilla no? :')
- Sí quieres saber más acerca del algoritmo, puedes hacerlo Aquí
Algunas veces es mejor dejar una simulación en vez de palabras, por lo tanto Aquí, podrá encontrar el cómo sería la red con todas las caracteristicas y Aquí el cómo sería cuando Jacob envía datos a través de varios nodos en diferentes países.
Nota: Aunque en esta demostración no explico como es el proceso en que se usan los datos encriptados, en la practica si pasa éso.
Ahora pasemos a la explicación: Es sencilla la red, hay que saber usarla y cuándo, pero para poder entenderla hay que crear desde un principio lo que necesitamos e ir aumentando a medida que vayan incrementando los conocimientos.
Primero crearemos un Jacob (Administrador de los Rook's):
Pero antes de hacer éso, quiero aclarar que algunas herramientas necesitan acceso seguro a la base de datos que está encriptada, por lo tanto sí usted no introduce los parámetros se le va abrir un pequeño formulario requiriendo los datos. Sí no me cree, mirelo usted o mejor aún Pruébelo:
./addadmin.py -u -p -P
* Datos para desencriptar la frase de contraseña *
----------------------------------------------
Ingrese la frase de contraseña:
: **************
Ingrese los caracteres de seguridad:
: abcdefghijklmnopqrstuvwxyz1234567890
Ingrese el número de iteraciones:
: 43
Ingrese el número de seguridad:
: 30
Ingrese el número de disminución:
: 18
Se guardo satisfactoriamente en -> conf/pass Notas:
Lo que acabo de introducir se genera lento en mi computadora, usted tiene que introducir lo necesario para obtener una mayor seguridad pero que el proceso no se vuelva tan lento; al fin y al cabo usted decide. Sí ejecutan alguna herramienta que requiera la información para desencriptar la base de datos, se guardará en vez de comparar en caso de que conf/pass no exista Sí ejecutan alguna herramienta que requiera la información para desencriptar la base de datos, se guardará en vez de comparar en caso de que conf/pass no exista conf/pass es guardado con permisos "444", por favor verifique que sea así con "ls -l conf/pass" o si no hagalo de forma manual: chmod 444 conf/pass una vez ha sido creada.
# Primero veamos que regla estamos usando para guardar los comandos en el historial:
echo $HISTCONTROL
ignoreboth
# ¡Bien!, esa es la regla perfecta.
# Eso nos servirá para cuando introducimos un comando y no queramos que se guarde en el historial, ya que la idea es que no se registre una contraseña o algo sensible.
# Así que ahora guardemos lo que necesitamos en una variable
declare -x params='-db-passphrase -db-iterations -db-chars -db-decrement-number -db-security-number '
# Cómo pueden notar, usé un espacio antes de escribir el comando, para que no se almacene en el historial.
# Claro, pueden hacer éso o pueden crear un script y lo cargan usando "source" o ".", pero se los dejo para la casa... Ahora simplemente puede ejecutar:
./addadmin.py -u -p -P $params -*- ¿Es correcta la siguiente información? -*-
Nombre de usuario ::
Frase de contraseña ::
Contraseña RSA ::
Iteraciones :: 43
Número de seguridad :: 30
Número de disminución :: 18
Caracteres de seguridad :: abcdefghijklmnopqrstuvwxyz1234567890
Privilegios :: ALL
Max. de bot's :: 0 (infinito)
Tamaño de la clave :: 2048
¿Root? :: 0
-> Debe introducir "1" para continuar o "0" para salir, aunque "CTRL-C", también ayuda.
Notas:
Sí no quiere que le confirme los datos, usé "-no-confirm". Cómo puede observar, hay caracteres rellenados automáticamente, puede editarlos introduciendo los parámetros correspondientes cómo: "-i, --iterations" para las Iteraciones "-sn, --security-number" para el "número de seguridad", "-c, --security-chars" para los Caracteres de seguridad y "-d, --decrement-number" para el Número de disminución o puede editarlos en el archivo de configuración global. Ser root no es lo mismo en Linux que en Syndicate, no se confunda; significa que todos los rook's ahora pertenecerán a todos los jacob's que son root, aunque esto es relativo, ya que si el maximo de bot's es mayor a "0" no se incluirá si llegó a su maximo. Puede usar el generador de hashes de prueba para Syndicate, si desea saber cuanto puede durar la generación y la comparación de su Hash antes de salir al campo de batalla.
./addadmin.py -show $paramsEse comando le mostrará todos los Jacob's registrados.
Ahora pasemos a algo mejor. Creemos nuestro rook para un jacob:
./addbot.py -u -p -P -a $params Vemos un parámetro nuevo, "-a" o también podría llamarse "--admin". Si no razonaste correctamente, te digo que es para agregar a los Jacob's a el nuevo rook.
Notas:
- Puedes crear tantos rook's para jacob's dependiendo del maximo de bot's
- El parámetro "-a, --admin" es de tipo lista, lo que quiere decir que para agregar a más de uno, tienes que usar una "," (coma) y sí el nombre tiene espacios usa comíllas cómo apoyo. Ejemplo: --admin "usuario, soy un usuario, otro"
./auto-config.sh $paramsUsted vería cada Clave, Sub-Clave y Valor. Los segundos de duración por cada uno, varian dependiendo de sus recursos, esto se debe a que se está encriptado cada dato.
A pesar de que se muestre la configuración al finalizar, tal vez usted quiera apreciarla para un después. Lo puede hacer así:
./evie-config.py -print-configuration $paramsNotas:
- Aunque auto-config.sh es un script, la herramienta que tiene el poder de hacer esta mágia es evie-config.py, pero es mejor automatizar todo, para ahorrar tiempo.
- Puede obtener más información del significado de las Claves, Sub-Claves y Valores desde el mismo Archivo de Configuración.
Ejecutamos evie.py para iniciar el servidor:
./evie.py -P $params Sí ejecutamos por primera vez, verá algo así:
(00:33:04 ~ 26/11/2019)[Evie:ADVERTENCIA]:---:!: El par de claves aún no son son generados ... generando ...
(00:33:04 ~ 26/11/2019)[Evie:PERSONAL]:------:+: Tamaño a generar: "2048"
(00:33:11 ~ 26/11/2019)[Evie:INFORME]:-------:*: El par de claves fueron generadas ...
(00:33:11 ~ 26/11/2019)[Evie:INFORME]:-------:*: Desencriptando ...
(00:33:12 ~ 26/11/2019)[Evie:INFORME]:-------:*: ¡Clave desencriptada!
(00:33:12 ~ 26/11/2019)[Evie:INFORME]:-------:*: Generando clave secreta ...
(00:33:12 ~ 26/11/2019)[Evie:PERSONAL]:------:+: Clave secreta generada -> b22f 34b4 1c48 b8dd dad3 dcfc d0b6 986d 081f 80f3 959d 3de0 1075 6ea1 dfc2 ad45
(00:33:12 ~ 26/11/2019)[Evie:INFORME]:-------:*: Generando un nuevo token de acceso ...
(00:33:12 ~ 26/11/2019)[Evie:PERSONAL]:------:+: Token de acceso generado -> 8502382584368ce06c336c793750815f400697daaff7dc8244e849b75135d638
(00:33:12 ~ 26/11/2019)[Evie:ADVERTENCIA]:---:!: No se encontraron los requerimientos necesarios para usar el protocolo de forma (más) segura. Usando HTTP ...
(00:33:12 ~ 26/11/2019)[Evie:PERSONAL]:------:+: Escuchando en :: http://0.0.0.0:8081/hmKReYEJrMWB8l48yvsENaLlMT1ijqIiU2nU6RGiKnanCZEkimT0lh2xW-xS1xYP6rJX1uWmxbp2bOeSVCCfJQNo explicaré todo, porque hay cosas que son sencillas y otras ya las explique, pero sí que hay algo nuevo. ¿Qué deminios es esa ruta?; la ruta se genera de forma aleatoria y segura, puede usar los archivos de configuración para evitarlo, pero recomiendo que lo deje así.
Lo negativo de usar una ruta aleatoria es que si el servidor se "apaga" y se inicia nuevamente, tendrá otra ruta, lo que quiere decir que los Jacob's tendran que saberlo; es recomendable sólo cuando hay pocos Jacob's.
Ahora para que Evie tenga algún sentido en la vida, que tal si ejecutamos la Carga útil, pero antes quiero aclarar algo que tiene que ver con los complementos, aunque aún no me adentraré en aguas turbulentas, por ahora estamos en la orilla del mar (Eso es en otra sección). Prosigamos:
Tenemos que tener en cuenta que los complementos necesitan requerimientos, cosa que mencionaré en la instalación, aunqué podemos edítar El archivo de configuración del payload y remover o agregar lo que necesitemos.
Bien, una vez aclarado, necesitamos la Clave Pública de Evie y la Clave Privada del Rook; La obtenemos de la siguiente forma:
./show_server_keys.py $params | more
...
Clave Pública:
...
Clave Privada:
...Usamos "more" para delimitar la salida y ver lo que necesitamos, la clave pública. La seleccionamos, copiamos y la guardamos en una ruta segura, cómo "/tmp":
nano /tmp/ # Una vez abierto "nano" pegamos la clave pública y la guardamos
... Hacemos el mismo procedimiento, pero esta vez será para la Clave Privada del Rook:
./addbot.py -show -option keys -P : $params Nota: Puede asignarle permisos de escritura y lectura dependiendo de su usuario al par de claves para mayor seguridad.
Recordatorio: Cómo ve, deje un espacio para que no se guarde el comando en el historial
Esta vez vemos nuevos parámetros con argumentos interesantes:
- -show: Mostramos los usuarios disponibles.
- -option: Usamos una clave especifica para ver algo especifico de la información del usuario. Podemos usar el parámetro "-h, --help" para ver la ayuda dónde también nos mostrara las claves que acepta.
- -P: La frase de contraseña de la clave privada, siguiendo la siguiente sintaxis: <identificador del rook>:<Frase de contraseña para desencriptarla>
nano /tmp/ # Una vez abierto "nano" pegamos la clave privada y la guardamos
... Ahora sí, ejecutemos el Payload
./payload.py -b -pass -a -p -pub-key -priv-key -proto -sleep-check -db-path -db-pass Explico poco a poco lo que siento que pueden tener dudas:
-sleep-check: Rook hace una petición a el/los servidor/es para verificar si algún Jacob propuso un comando en cola cada intervalo de segundo determinado -db-path: Los rook's tienen bases de datos que se almacenan en el directorio temporal del sistema operativo (encriptada, por supuesto), si no especificamos un nombre se genera de forma aleatoria y si ejecutamos otra vez el payload tendremos otra ruta aleatoria, por éso, es mejor especificarla. -db-pass: La frase de contraseña para cifrar la base de datos
Esto es una prueba, por lo que todo se hará por la consola, ya hablare sobre como usar la programación a nuestro favor.
Necesitamos interactuar con el Rook para ello ejecutamos control.py.
./control.py $paramsPuedes observar en las Las capturas de pantalla cómo se vería
Nota: Quiero aclarar que la aplicación es una DEMO, no es para entornos reales, por lo tanto no te sorprendas si no es igual de bonita que Vim ;).
Nos mostrara primero un panel de inicio de sesión, tenemos que rellenar los datos deacuerdo a lo aprendido
Al terminar de iniciar sesión lo primero que hará será enviar un comando "ping" para verificar si sus credenciales son correctas, luego enviara el comando "listBots" para obtener la lista de rook's que le pertenecen.
Sí ocurre un error puede ser por los siguientes motivos:
No tiene privilegios para listar rook's o ejecutar ping Ingreso una ruta incorrecta El servidor lo está bloqueando El servidor no existe Ingreso datos incorrectos Faltan valores No existe la clave pública o la clave privada
Sistema anti fuerza bruta:
El sistema anti fuerza bruta de Syndicate es sencillo, primero tendremos que comprender que es el Hash dinámico, cosa que ya explique en las aclaratorias.
En Syndicate al crear un usuario además de la información de perfil, existen algunos datos de seguridad, cómo son los Caracteres de seguridad, Número de seguridad, Número de disminución e Iteraciones; Los cuales su funcionamiento principal es generar un Hash. El hash puede tener el mismo dato (Como una contraseña), pero si se introduce cualquier dato diferente al resto de los datos de seguridad el Hash será diferente.
Mientras el proceso sea más lento, mejor en un buen sentido, ¿Por qué?, simplemente porque si un atacante quiere hacer fuerza bruta al servidor, obligatoriamente tiene que tener: El usuario, Frase de contraseña, Los datos de seguridad, La clave pública del servidor, la clave privada y la clave única inclusive.
De hecho otra cosa que es muy importante en cuanto a la seguridad es la Clave única que cambia cada vez que el Jacob al que le pertenece, inicia sesión.
Claro que eso no es todo, el atacante debe conocer la ruta del servidor que puede ser una aguja en un pajar.
Sumando todo esto, también nos vemos que en la configuración especificamente las claves honeypot y login vemos unas sub claves, como pueden ser:
Login: max_retry: El maximo de intentos fallídos retry_seconds: El tiempo de espera denied_method: El método de denegación que pueden ser: forIP: Bloquea a un usuario por dirección IP. Tiene sus pros y contras; entre sus pros puede ser que no es tan fastidioso, ya que si un atacante está bloqueado por dirección IP, nosotros (Los usuarios) podemos acceder cómo si no fuera pasado nada, pero entre sus contras, muy fácil de bypassear forRetry: Bloquea a un usuario por el nombre en vez de la dirección IP. Es bueno porque así no se bypassea tan fácil, pero también nos bloquearía a nosotros. honeypot: Si un dato coincide con lo requerido, se ejecuta una de estas operaciones: user_agent_black_list: La lista para bloquear a un usuario por Agente de usuario blacklist: La lista para bloquear a un usuario por Dirección IP honeypot_list: En vez de bloquear ¿Qué tal si usaramos una herramienta cuando haya un coincidencia?; así es, por ejemplo podriamos usar nmap, cuando haya una coincidencia en la lista para escanear a ese usuario. *Necesitamos especificar las herramientas a usar en la clave tools *
¿Eso es todo?... ¡NO!. Si ingresamos por la URL del servidor en nuestro navegador, vemos que nos salta una autenticación le digo que ese es el panel de control web falso, es mera distracción 3:).
De hecho trato de simular Apache en la información que se pueda obtener. Puedes editar los valores en el Archivo de configuración y las plantillas en templates/
¿Segunda parte?
Lo mostrado anteriormente fue un poco de la documentación. Puede encontrar mucha más información acerca del proyecto, pero aún me falta mucho que redactar, así que poco a poco lo ire actualizando.
Respecto a la segunda parte tratara sobre cómo usar el proyecto para construir una Botnet Punto a Punto, cómo usar la red en cadena para comunicarse con otro Evie y está vez co-protagonizare esta pelicula con un compañero del foro .
Puede encontrar la documentación en mi repositorio, donde también podras descargar el proyecto: github.com/DtxdF/Syndicate
Capturas de pantalla:
Inicio de sesión para los Jacob's:
Interactuando con un Rook:
Red en cadena:
 |
Compartiendo un Rook:
Creador:
~ DtxdF (Jesús D. Colmenares)
Agradecimientos:
Kirari: Gracias a tí, si estás leyendo ésto. Tú me ayudaste mucho con los complementos antes de que me surgiera la idea, es admirable que alguien dedique parte de su tiempo a escribir código a alguien que apenas sabe su nombre, pero mucho más a alguien que seguira aportando a este proyecto. Muchas gracias Kirari.
n1nj4sec: Gracias por aportar a la comunidad con su proyecto pupy-rat, gracias a él, muchos complementos de Syndicate existen.
jfdelgad: Creador de port-forward, una pequeña pero poderosa libreria para hacer desastres con el router usando UPnP :D. Gracias por compartirlo y por dar vida a una caracteristica especial de los rook's
Sí hay alguien que me falta, comunicame inmediantamente
~ DtxdF
Comentarios
Publicar un comentario