TOP
AutoresTOTAL
LecturasSET 21
146824 visitas
- Contenidos - SET Staff
- Editorial - Editor
- Noticias - SET Staff
- Bazar de SET - Varios Autores
- Como crackear Hexworkshop 1.0 (bazar) - Dark Angel
- Hackeando Screenlock (bazar) - 221bo"sKt
- Walker - Compuserve 3.0 Password Decrypter (bazar) - m0f0
- Tarjeta Universal UNI2 (bazar) - GND
- Cazando Fantasmas (Caller-ID Cutre) (bazar) - Maikel
- Revision del emu de TPT de JM Garcia (bazar) - +NetBuL
- Denial Of Service: Buffer Overflows Remotos (bazar) - Obocaman
- BookMarks - SET Staff
- En El Quiosco Virtual - SET Staff
- En linea con... ArMaND VanHell - GND
- Del PGP al Foton. Presente y Futuro - SiuL+Hacky
- Curso de Novell Netware Aps III & IV - Madfran
- Proyectos, peticiones, avisos - SET Staff
- ASM y Buffer Overflows - Doing
- The Bugs Top 10 - Falken
- UNDERCON III: El Hack Hispano se reune - GND
- SET Inbox - Paseante
- TEMPEST: Como nos vigilan? - Krip7ik
- SIMO 99: Que hay de nuevo? - SET Staff
- El Ultimo paquete - Paseante
- Terminales Graficas - FCA00000
- La Biblioteca del Hacker - SET Staff
- Crackeando L0pthcrack 2.0 - Madfran
- Jakin para anormales - Jnzero
- Real como la vida misma: Detenido! - SET Staff
- Fuentes Extract - SET Staff
- Llaves PGP - SET Staff
Terminales Graficas
Autor: FCA00000
-[ 0x0F ]-------------------------------------------------------------------- -[ Terminales Graficas ]----------------------------------------------------- -[ by FCA00000 ]------------------------------------------------------SET-21- Terminales Graficas ------------------- En este articulo voy a explicar el funcionamiento de las terminales de acceso a un ordenador, sobre todo las de tipo grafico. Ejemplo de esto es el sistema X-window. -Que? Un terminal es un aparato de hardware, generalmente con varios perifericos conectados, fundamentalmente teclado, raton, monitor y conexion. -Para que? Su aplicacion se encuentra en el uso de recursos compartidos por varios usuarios, sin necesidad de tener potencia alli donde no se necesita, sino centralizandola en un ordenador principal. -Como? Las terminales simplemente son dispositivos de entrada/salida de datos, mandando/recibiendolos a la maquina principal (host) mediante una conexion. -Quien? Se usa mayoritariamente en centros de calculo, donde existen ordenadores muy potentes, y varios usuarios que necesitan esa potencia, pero estan dispuestos a compartirla con otros, pues sus calculos son urgentes, pero hacen pocos. -Donde? Las terminales se instalan en lugares de acceso restringido: laboratorios, centros de proceso, entornos de seguridad, ... -Cuando? Tan pronto cuanto es posible. Se rentabilizan rapidamente. TERMINALES DE TEXTO En un principio (en los 60), la informatica era centralizada. Las empresas adquirian una computadora destinada al calculo, y los trabajadores o investigadores introducian sus datos mediante sus terminales. Esos datos se procesaban al momento o en batch, y el resultado era devuelto al teletipo. Esto permitia un optimo aprovechamiento de los recursos, pues cuando el 10% de los trabajadores estaban haciendo trabajar a la maquina, el restante 90% simplemente introducia datos, con lo que no se notaba retardo alguno. Los mismo pasaba con las tarjetas perforadas: la lectura, proceso y escritura ocupaba un tiempo minimo comparado con la creacion de las tarjetas por parte del usuario. Despues llegaron los terminales de texto. Eran sistemas con un teclado, una pantalla, y una linea de conexion RS-232. El monitor entendia secuencias ANSI del tipo "mueve el cursor a la posicion 80,25 e imprime la letra X". El teclado mandaba las combinaciones de teclas mediante la misma linea. El ordenador central necesitaba un monton de puertos serie (y, por supuesto, un sistema operativo multiusuario y multiproceso), o bien tarjetas multiplexoras. El sistema es barato, facil de instalar, y se usa mas de lo que creeis: centralitas de incendios, de telefonia, sistemas de semaforos, BBS, cajeros automaticos, cajeros de supermercados, pool de modems, lavadoras con interface serie, ... Creo que no me equivoco si digo que todos los ordenadores tienen un software que les hace actuar como terminal, y que un 90% de los aparatos "inteligentes" tienen un software que les hace actuar como servidor de terminal. El funcionamiento es muy sencillo: -un hardware minimo (puertos serie) -conexion con cable de 3 hilos (GR, TR, TS) -un protocolo de control (ej. 8N1, 2400) -protocolo de datos: ANSI -emulacion de terminal (ej. VT100) Desde el punto de vista de la seguridad, el sistema esta totalmente abierto: -el cable se puede husmear (sniffing) -un ordenador con 2 puertos series, puede modificar los datos (hijacking) -no hay autentificacion del host (spoofing) -no hay verificacion del cliente Hay que contar con otros problemas de seguridad -parametrizacion erronea -cortes en la linea -cortes en el terminal -debil chequeo de errores de transmision -el mas grave: los usuarios creen que apagando el monitor, se corta la conexion En conclusion, el uso fraudulento de una terminal es cosa de crios. Esto se supone que se mejora con el uso de autentificacion: usuario/password. Sin embargo, debo mencionar que hay muchos servidores de terminales que solo utilizan la password, y algunos ni siquiera esto. Y, por supuesto, el sniffing es una tecnica tan vieja como efectiva. Es cierto que las terminales de texto eran rapidas: incluso para redibujar toda la pantalla (80x25) con colores (2 bytes) hacia falta mandar 4000 bytes; a 9600 baudios, se tardaban 4 segundos en mandar los datos; pero redibujando solo las zonas que cambian, el retraso es inapreciable. Y, por supuesto, a mayor velocidad, menor retraso. Mas informacion de la que puedas procesar: Text-Terminal-HOWTO de Linux Serial-HOWTO de Linux Pero siempre se quiere algo mas. TERMINALES GRAFICOS El siguiente paso fueron las terminales graficas. La creacion del raton dio paso a una nueva generacion de interface: el GUI o Graphical User Interface. Ventanas, raton, botones, checkbox, ... todo un mundo de objetos. Y eso sin contar los dibujos, animaciones, sonido. Cuando los de Xerox desarrollaron la idea tuvieron que pensar mucho. Una de las cosas buenas que se les ocurrio era separar el software del hardware. Dicho de otro modo: nada de accesos a memoria, ni lectura continuada del raton, ni ocuparse de superposicion de ventanas. Eso lo tiene que hacer el hardware. Si una aplicacion quiere dibujar, que lo diga, y sera la terminal la que haga el trabajo estrictamente grafico. Asi inventaron las terminales graficas con estructura cliente-servidor, que llamaron sistema 'W' Como pasa con estos temas, unos cuantos fabricantes de terminales decidieron usar este sistema, estandarizarlo, formar comites, y cambiarle el nombre. Nace X-window, avalado por el X-Consortium. La primera implementacion para el publico era X9, a la que siguio X10, X11r1, X11R2, ... X11R6, X11R6.3 y las que vengan. La filosofia de X-Window (y no X-WindowS, como la gente se obceca) es tan sencilla como el modelo cliente-servidor: Una aplicacion quiere dibujar (o leer el raton o teclado), y le lanza una peticion al servidor. Notar que el cliente es la aplicacion, y el servidor es el terminal. Podria parecer que es al contrario, pero estamos hablando de servidor de graficos, no de servidor de procesamiento. Luego se subieron otros al carro del tele-control: PcAnywhere (Symantec) CarbonCopy RemoteControl VNC (dominio publico, de Olivetti & Oracle) WinFrame (Citrix) TerminalServer (Microsoft) Como el primero, el mas potente, el mas facil y el que mas me gusta es el sistema X-Window, lo explico el primero. PRIMER PASO: REQUISITOS La conexion entre un terminal y sus clientes se realiza fisicamente a traves de una red. Lo mas comun es Ethernet con TCP/IP, pero se admiten muchos tipos de variacions: PPP, FastEthernet, DECNET, ... con todo lo que esto implica: modems, firewalls, multicast, sniffing, ... Las terminales pueden tener disco duro, o no. En todo caso, siempre deben tener una conexion, que suele ser a traves de red local. Recordar que las terminales de texto ya incorporan un interface serie, una (o varias) emulacion de terminal, y soportan las secuencias de control ANSI. Pero las terminales graficas no suelen tener esto incluido en su memoria, sobre todo porque se incorporan mejoras (tarjetas graficas o de red, aceleracion de graficos, parches al Xserver) y seria engorroso tener que abrir el XTerminal cada vez que hay una modificacion de software. Si tienen disco duro (Xfree Linux, X-Reflection Win, X-Lite DOS, Xserver SUN) es necesario saber el tipo de tarjeta grafica para configurar el servidor, asi como conocer el puerto del raton, tener instalada la tarjeta de red, y configurar la resolucion/frecuencias del monitor. De esto se ha escrito mucho, y actualmente no deberia ser problema para cualquier aficionado al UN*X el tener un servidor X en marcha. Otro tema es configurar un diskless-station. Todo se hace con TFTP. Trivial File Transfer Protocol es un protocolo TCP/IP que sirve para hacer transferencia de ficheros, de modo simple. No hay usuario/clave, no hay directorios, no se pueden hacer listados, no se pueden meter archivos, y suele estar mal configurado. El funcionamiento es este: al encender el XTerminal, la tarjeta de red lanza una peticion a un ordenador servidor de TFTP (tambien se puede hacer un broadcast) muy simple; solo contiene el comando "get X" Gracias al protocolo TCP, se sabe cual es la direccion TCP origen (iaddr) Gracias al protocolo IP, se sabe cual es la direccion MAC origen (haddr) El servidor TFTP consulta el archivo /etc/tftpboot manda el archivo /tftpboot/MAC a la direccion que lo pidio. Por cierto, que lo manda con protocolo de datagramas udp (puerto 69). Hay una implementacion mas completa del TFTP que salio mas tarde: secure TFTP Esta es la que se suele encontrar en la mayoria de servidores TFTP, e incluye la posibilidad de configuraciones complejas, autentificacion segun TCP+MAC y permite copiar archivos (upload). Sin embargo, no permite copiar ficheros a un directorio distinto de /tftpboot (o el que haya configurado el administrador). En situaciones donde las Xterminales no tienen disco duro, todo el Sistema Operativo lo obtienen del servidor TFTP, por lo que este suele exportar parte del sistema de ficheros, habitualmente por NFS. Aqui tambien se pueden obtener algunos resultados agradables para el hacking. Sin embargo, es comun que se pueda bajar un fichero (download), modificarlo, y luego meterlo de nuevo, con lo que se tiene un servidorX crackeado. Asi es posible capturar pulsaciones de teclas, por ejemplo, o simularlas. Como digo, suele estar mal configurado, y, aunque poca gente usa terminalesX hoy en dia, se pueden hacer cosas muy, muy malas. Mas informacion: man tftp, man tftpboot , extension TFTP RFC1048, y el manual X Window System Administrator's Guide, de SunOS/Solaris. Tambien vale la pena The X window System. Volume 0. X Protocol, de O'Reilly SIGUIENTE PASO: CONEXIONES Aunque no lo parezca, tenemos ahora una aplicacion (el Xserver) que esta esperando peticiones de conexion por el puerto 6000. Efectivamente, un netstat indica que este puerto esta listening. Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:6000 *:* LISTEN tcp 0 0 localhost:1024 localhost:6000 ESTABLISHED tcp 0 0 localhost:6000 localhost:1024 ESTABLISHED Active UNIX domain sockets (including servers) Proto RefCnt Flags Type State I-Node Path unix 1 [ ACC ] STREAM LISTENING 25906 /tmp/.X11-unix/X0 unix 2 [ ] STREAM CONNECTED 25910 unix 2 [ ] STREAM 25932 /tmp/.X11-unix/X0 unix 2 [ ] STREAM CONNECTED 25934 unix 2 [ ] STREAM 25935 /tmp/.X11-unix/X0 Se ve claramente que por cada cliente, se establece una conexion con el servidor, a traves del puerto 6000. Notar tambien que, en local, la conexio nse lleva a cabo por un fichero. Asi que, si estas en un entorno multiusuario, ten cuidado con los permisos que se le dan a este fichero, no vaya a ser que otros usuarios puedan leer o escribir en el. Al igual que el resto de los protocolos TCP/IP (o DECNET), los comandos del sistema X-Window se componen de tramas de datos con origen, destino, tipo, modificadores, y datos. Esto es lo que hace grande y versatil este sistema: es independiente de las otras capas OSI. Cuando hay conexion, ya se puede trabajar. Ademas, la estructura los datos son de dominio publico y estan perfectamente documentadas por el X-Consortium (todo es trabajo del MIT), y asi cualquiera puede implementar un servidor X, o una aplicacion que hable protocolo X. Claro que para eso ya estan los chicos del XFree, sus servidores, y sus librerias para los clientes. Pero como el objetivo es aprender, comento la estructura de los paquetes: PETICION (request) Cada peticion contiene un codigo (opcode) de 8 bits , otro codigo secundario de 8 bits, seguido por 16 bits que indican la longitud de los datos (cada dato son 32 bits), y a continuacion los datos. Por ejemplo: comando Bell (pitar) opcode=104 (0x68) sec-opcode= tono longitud=1 (1+1+2= 4 bytes = 32 bits = 1 dato) Otro ejemplo: comando ChangePointerControl opcode=105 (0x69) sec-opcode=0 (no usado) longitud=3 (1+1+2 + 2+2+2 + 1+1 = 12 bytes = 36 bits = 3 datos) aceleracion-numerador = dividendo (2 bytes) aceleracion-denominadir = divisor (2 bytes) variacion-minima = numero_pixels (2 bytes) haz-aceleracion = 0/1 (1 byte) haz-variacion = 0/1 (1 byte) Otro mas: comando AllocColor (usa color) opcode=84 sec-opcode=0 longitud=4 mapa-colores nivel_rojo nivel_vede nivel_azul relleno RESPUESTA (reply) La longitud se marca como '0' El primer byte es siempre '1'. El siguiente es un codigo secundario. El siguiente (mide 2 bytes) es un numero secuencial, para no perder eventos Ej. respuesta a AllocColor opcode=1 sec-opcode=0 secuencia=xx longitud=0 nivel_rojo=rr nivel_verde=gg nivel_azul=bb relleno pixel relleno EVENTO (event) Los eventos son transmitidos desde el servidor hacia el cliente. No se especifica la longitud de la trama. comando KeyPress (tecla pulsada) opcode=2 sec-opcode=tecla numero_secuencia (2) hora (4) ventana_raiz (4) ventana_evento (4) ventana_hija (4) ventana_raiz_x (2) ventana_raiz_y (2) evento_x (2) evento_y (2) mascara_teclado (2) misma_pantalla (1) relleno (1) Toda la lista de codigos se puede encontrar en 'X Window System Protocol', y tambien en el volumen 0 de los libros de O'Reilly. Por supuesto, la quia oficial esta en X11R6/include/X11/XProto.h SIGUIENTE PASO: CLIENTES Ahora, lo que tenemos es un fondo de puntos blancos y negros, y una X grande que se mueve con el raton, mandando eventos como una loca, pero sin nadie que le haga caso. Entonces necesitamos clientes que quieran escribir en ese terminal. Hay cientos de aplicaciones que funcionan en X-Window, y la mas simple es una que se llama xbell. La manera de llamarla es xbell -display ordenador:0.0 que simplemente manda el comando Bell, y consigue que pite la terminal. Simple, y efectivo. Otra aplicacion bastante util es el manejador de ventanas (window manager), que usa casi todas los comandos del sistema X-window: trata fondos, teclas, aceleradores, marcos, crea/destruye ventanas, graphic context, fuentes, ... Sin el wm, es imposible mover ventanas. Pero ojo, no es una parte intrinseca del sistema, como puede serlo el manejador de ventanas de Win3.1, 95, NT, OS/2 o Amiga. Es, simplemente, un programa que manda eventos a las ventanas, para que ellas mismas se redibujen, se reposicionen, y cosas asi. Se obtiene lo mismo mandando los comandos directamente, abriendo una conexion telnet localhost 6000 y mandando (en binario) 104 100 0 1 (comando 'pitar') o cualquier cosa mas compleja que se os ocurra. Si lo habeis probado en vuestro ordenador, seguramente haya funcionado, pero no siempre es asi. PUESTOS EN RED Como se ha dicho, los datos viajan por la conexion, y, siendo esta de tipo TCP/IP, es posible que varias Xterminales usen varios hosts. Es decir, cada Xterminal puede tener clientes un uno o varios ordenadores. Para que no se forme mucho follon, y la seguridad funcione como tiene que ser, se incorpora un protocolo de autentificacion, tanto por parte del cliente-host como del servidor-terminal. XHOST Para que un Xterminal permita que un server lo use, es necesario que este en la lista de los permitidos. Esta lista se mantiene con el programa xhost, cuyo funcionamiento se basa simplemente en admitir o negar un server. No hay mas. Esto es: si el usuario PEPE quiere ejecutar aplicaciones X en el ordenador HOST, para que se visualicen en su terminal PEPEX, debe establecer una conexion con el servidor (ej. con telnet), arrancar el servidor X, y permitirlo: xhost +HOST (para permitir que todos los hosts del mundo pueda escribir en su terminal) Esto permite un ataque de tipo spoofing, si no fuera por que la mayoria de los Xterminales se encuentran en una red local, con lo que es mas complicado forzar el spoof. Por supuesto, cuando se escribe xhost + (para permitir que todos los hosts del mundo pueda escribir en su terminal) la seguridad se debilita totalmente. Estonces es facil hacer un scaning de todos los Xterminales (ej, con strobe) al puerto 6000, y arrancar cualquier aplicacion. Por supuesto, existe ya una aplicacion que captura las pulsaciones de teclas y el movimiento del raton, y se llama xspy. Una version mas depurada se llama xsniff, que muestra una salida de datos bastante mas mona. Al fin y al cabo, el comando 36 (GrabServer) esta para eso. Lamentablemente (para los hackers), no hay tantos Xterminales por el mundo. Y, por defecto, solo esta activado xhost +localhost por lo que es necesario spoofing con direccion 127.0.0.1; A ver como lo haceis. Una vez se tiene una aplicacion visualizandose en un Xterminal, es facil mandarle pulsaciones de teclas (comando SendEvent), y hala, a hackear. Tambien se puede mandar un dibujo, capturar lo que el usuario ve, o incluso redirigir sus entradas y salidas a otro Xterminal. Como te habras podido dar cuenta, no existe ninguna otra restriccion: no usuario, ni password, nada de nada. Por eso, en entornos multiusuario (compartiendo el mismo host) un usuario puede usar el servidor, aunque lo haya arrancado otro usuario. Eso permite facilmente ver lo que hace el usuario que esta sentado en la consolaX principal. Incluso mas: si varios usuarios de terminales X se validan contra el mismo servidor (de autentificacion), lo normal sea que lo tengan como (xhost +) , por lo que cualquier usuario puede usar el Xserver de otro impunemente. Esto se soluciona con un protocolo que implemente cifrado, tal como ssh. Y, tal como estan las cosas, crackear a ssh es practicamente imposible. Y tambien se puede aplicar xauth para aumentar la seguridad. Mas datos en: la mini-FAQ de Remote-X-Apps de Linux http://ciac.llnl.gov/ciac/documents/ciac2316.html comp.windows.x www.x.org RFC1013 OTROS SISTEMAS VNC Este es otro sistema de control remoto. En este modo no se opera con ventanas distintas, sino que se toma el control total del ordenador host. La nomenclatura cambia, y se llama servidor al ordenador que ejecuta las aplicaciones, y cliente al que lleva el control del raton, teclado y pantalla. Se arranca el/los servidor/es, se arranca el cliente, se conecta con el servidor deseado, y se maneja en remoto. En este caso el usuario que esta delante del servidor ve como se mueve el cursor, aunque puede tomar el control en cualquier momento. Hay unicamente servidor para Win9x/NT, pero clientes para Win3.1, Win9x/NT, Linux y otros UNIX. Los fuentes son publicos, y ademas muy instructivos. La gracia esta en mandar los eventos por parte del cliente, y refrescar la pantalla cada vez que cambia. Solo funciona con TCP/IP, pero se puede hacer a traves de Internet. El sistema de autentificacion es con puerto/clave, y la clave usa 16 bytes, asi que es bastante dificil de conseguir. Esto se comprueba mirando el codigo; la clave se le hace un hash, y esto es lo que se chequea. La verdad es que usa DES de simple longitud, tanto para archivar las claves como para el desafio/respuesta. Es uni-usuario; es decir, solo un terminal puede tomar control del servidor. De hecho, el servidor deja de ser operativo mientras esta siendo manejado en remoto. El puerto usado para escuchar es el 5900, y se comienza el protocolo con el comando RFB 003.003 , Asi que usa un protocolo llamado RFB, que esta muy bien explicado en el archivo rfbproto.h , y se parece mucho al que usa X-Window. Asi que ya sabes: telnet xxx.yyy.zzz.ttt 5900 , y a ver quien te responde. O se pueden usar otras herramientas; recomiendo strobe/iss para hacer un port-scaning masivo. Luego, probar todas las claves. O lo mas facil: parchear el fuente, y que lo haga por ti automaticamente: modulo vncclient.cpp funcion vncClientThread::InitAuthenticate donde dice // Compare them to the response Ojo que tiene un mecanismo de seguridad extra: cuando el cliente ha fallado demasiadas veces la clave, no le deja intentarlo hasta pasado un rato. Mas informacion (y fuentes) en www.orl.co.uk/vnc CARBON COPY Exactamente igual que el VNC, pero tambien permite que el cliente y el servidor sean de MS-DOS, con lo que el trafico es menor. Es posible arrancar Windows en el servidor, y que lo maneje el cliente. Lento, pero efectivo. El sistema de autentificacion es basado en clave, y es bastante seguro. Uni-usuario tambien. REMOTE CONTROL Lo mismo. Quizas un poco mas lento, supongo que porque decide mandar la pantalla en momentos innecesarios. Es barato, pero solo se puede hacer a traves de linea telefonica. La clave se puede establecer tanto en el cliente como en el servidor. Asi se evita el spoofing en ambas direcciones. Uni-usuario. PC ANYWHERE Nunca lo he usado. WINFRAME Merced a su protocolo ICA (Independent Computing Architecture), se afirma que es el sistema que mas rapido transmite los datos. Y creo que es verdad. Pero, como todos, se basa en enviar datos de uno a otro. El sistema es multiusuario. Usa un servidor de tipo NT con un "plug-in", por lo que la seguridad es exactamente la misma que Nt Server 3.51 o 4.0 Funciona por TCP/IP, IPX, NetBios, o uno propietario. En cualquier caso, se establece un protocolo superior llamado ICA que sirve para enviar los movimientos del raton y teclado, y para recibir las respuestas, que son siempre redibujar zonas de pantalla. Con TCP/IP, el puerto usado es el 1512, y hay 2 tipos de paquetes: -busqueda de servidor (broadcast) mide 512 y es UDP -paquete de datos: protocolo TCP, hasta 1460 bytes. y se reconoce que te atiende un servidor porque cada 2 segundos, manda el comando ICA para ver si le respondes. Hay clientes (redordar que la nomenclatura esta cambiada) para DOS, Windows 3.x, Win9x/NT, Mac, Linux, Sun, Otros UNIX, e incluso navegadores. La autentificacion se lleva a cabo mediante el sistema tipico de MicroSoft de desafio/respuesta, al igual que LanManager, es decir: -claves de 8-40 caracteres -el server envia un hash de desafio -el cliente envia un hash del desafio y la clave -el servidor chequea este hash contra el de la base de datos SAM Veamos mas detalle: En principio, se usan claves (keys) de 1024 que se dividen en: -dos claves RC5 de 128 bits para conectar -dos claves RC5 de 40, 56 o 128 bits tras el logon. Se usa el algoritmo RSA con bloques de 64 bits y 12 vueltas. -Se generan 2 numeros A y B usados de parametros del metodo Diffie-Hellman. -El servidor genera su clave privada K1 -El sevidor genera una llave publica P1=A*K1 mod B -El servidor envia A, B y P1 al cliente. -El cliente recibe estos valores -El cliente genera la clave privada K2 -El cliente genera una clave secreta S=(P1**K2) mod B -El cliente genera su clave publica P2=(A**K2) mod B -El cliente envia P2 al servidor -El servidor recibe P2 -El servidor averigua S=(P2**K1) mod B El hecho de poder obtener S es debido a que ((A**K1 mod B)**K2) mod B = (A**(K1*K2)) mod B ((A**K2 mod B)**K1) mod B = (A**(K2*K1)) mod B Aunque un intruso obtenga P2, P1, A y B (todos ellos viajan por a red), no se puede obtener S (eso es lo que opinan los de RSA laboratories) A partir de aqui, los datos entre el cliente y el servidor van cifrados con ese hash S. Una cosa buena que tiene es que si apagas el cliente, la conexion se guarda, por lo que si desde el mismo cliente, el mismo usuario vuelve a conectar, se queda donde estaba la ultima vez. El protocolo ICA no esta descrito libremente en ninguna parte (que yo sepa) TERMINAL SERVER Microsoft le compro a Citrix la tecnologia MultiWin para convertir sus servidores NT en multi usuario. Como, porque, cuando y quien se explican en www.gcisystems.com/thinclient/wts-faq.html El protocolo usado es RDP (Remote Desktop Protocol) compatible con las especificaciones T.120 para comunicaciones multipunto en tiempo real. Mas concretamente, en el modo T.128; mas info en: www.itu.org gw.databeam.com/ccts/t120primer.html Para consideraciones morales, consultar RFC949 y RFC505 *EOF*