In Memoriam - 2 - ¡¡ Rescoldos !!

Seguimos al tajo con In Memoriam.

Extraer todos los recursos que necesitamos de Archive.org, aunque tedioso, es perfectamente posible. Afortunadamente estamos hablando de webs en las que la mayor parte de sus páginas son estáticas, con muy poco contenido dinámico que obviamente Archive.org no hubiera podido recoger en su totalidad. Es una solución laboriosa, pero al menos hay una salida.

Continuamos investigando sobre el dominio desaparecido y buscando por el dominio "www.inmemoriamdev.com" que aún sigue en pie, encontramos que el mismo servidor alberga mucho otros dominios. En otra página encontramos la información que nos interesa de manera gratuita. El servidor que alberga actualmente a "inmemoriamdev.com" albergó en su momento a "xineph.com", "skl-network.com", etc... o al menos esos dominios en su momento apuntaron a la misma dirección IP.

Sería genial que los contenidos estuvieran aún ahí...

Deep web

Mucho se ha hablado de la "Deep Web", y su acceso a través de la red TOR. Lo que se va a ver aquí no es tan enrevesado, ni tan anónimo, ni tan "Deep", pero igualmente permite servir contenidos que permanecen ocultos para el público general. Alguno pensará que para eso se coloca un control de acceso con usuario y contraseña, pero no, esto es aún mejor.

Todo comienza por la necesidad de servir varios sitios webs desde un mismo equipo. Hay una gran cantidad de sitios web que no precisan de una gran carga de proceso por parte del servidor que los hospeda. Unificar varios sitios webs en un único equipo permite un importante ahorro de costes.

Cabeceras HTTP

En estos casos, el software que sirve contenidos web en nuestro servidor debe poder distinguir, para cada cliente que le inicia una sesión HTTP, qué sitio web de los que comparten servidor es el que quiere acceder el cliente. Esto se consigue mediante una de las cabeceras que aporta el protocolo HTTP, la cabecera "Host". Cada vez que en nuestro navegador intentamos acceder a una página web, por ejemplo http://www.dominio1.com/index.html, nuestro navegador construye una petición HTTP y coloca en la cabecera "Host" el nombre del alias o dominio. Previamente, el servidor DNS que tengamos configurado informará a nuestro sistema operativo en qué dirección IP es alcanzable dicho dominio. Así, nuestro navegador enviará una petición HTTP con esta forma:

GET /index.html HTTP/1.1
Host: www.dominio1.com

En realidad nuestro navegador enviará muchos más datos, pero lo único que define el World Wide Web Consortium (W3C) como obligatorio en una petición HTTP es la cabecera "Host", además de la propia petición de la primera línea (salvo en casos que se especifique el enlace de manera absoluta, en cuyo caso el "Host" ya va incluido en la primera línea).

Otro cliente puede querer acceder a http://www.dominio2.com/index.html. La petición HTTP será casi igual:

GET /index.html HTTP/1.1
Host: www.dominio2.com

Puesto que tenemos ambos dominios configurados en un mismo servidor, los servidores DNS resolverán ambos dominios a la misma IP, por lo que el software servidor instalado en la máquina debe poder distinguir entre ambos dominios. Eso lo consigue mirando la cabecera "Host".

Virtual Hosts

En el servidor, se definen lo que se conocen como "Virtual Hosts". Para cada "Virtual host" se define cual es el directorio raíz en el servidor que alberga las páginas web para es dominio o alias. Al recibir una petición HTTP, el servidor usa la cabecera "Host" en conjunción con su configuración de "Virtual Hosts" para definir el directorio raíz, y junto con el directorio relativo indicado para la propia petición, calcula la ruta absoluta del contenido que tiene que servir.

En caso de recibir una petición HTTP con una cabecera "Host" que no coincide con ninguno de los "Virtual hosts" configurados, dependiendo de la configuración del servidor, éste puede resolver a una web por defecto, o bien devolver un error de página desconocida.

El truco

Tal y como se ha definido, es el contenido de la cabecera "Host" el que define a qué "Virtual host" queremos acceder.

¿Qué ocurriría si definimos un "Virtual host" para un dominio "erróneo", bien no exista, o bien porque está apuntando a una IP distinta de la de nuestro servidor?

En teoría, dicho sitio web sería inaccesible ya que ningún servidor DNS resolvería dicho nombre de dominio hacia nuestra IP, ya sea porque el dominio no existe, o ya sea porque apunta a otra IP.

El truco consiste en eso, en conseguir que nuestro equipo, cuando intente acceder al dominio "erróneo", resuelva dicho nombre de dominio a la IP del servidor donde se ha definido un "Virtual host" para dicho dominio. Solo aquéllos que accedan a dicha IP con la cabecera HTTP "Host" correcta, podrán acceder al sitio web. Los que no lleven la cabecera "Host" adecuada, obtendrán un bonito error 404 o cualquier otra página web por defecto que tenga configurada el servidor.

La manera más sencilla de establecer la resolución de un nombre de dominio a una dirección IP determinada es editando el archivo "hosts" de nuestro sistema operativo. En el caso de Windows NT, 2000, XP y posteriores se encuentra en:

[WINDOWS_DIR]\System32\drivers\etc\hosts

Y si usamos Linux, ese archivo está en:

/etc/hosts

En ambos casos es un archivo de texto plano en el que se definen pares IP - Dominio para establecer resoluciones estáticas. Por ejemplo, encontraremos el par:

127.0.0.1 localhost

Este par permite que el nombre "localhost" se resuelva hacia nuestro propio equipo. Es ahí donde colocaríamos la dirección IP del servidor y el nombre de dominio ficticio necesario para acceder al contenido oculto. Para una mayor seguridad, una vez que se accede a los contenidos protegidos, se puede colocar un esquema de autenticación como una capa más de seguridad. Un listado más completo de la localización del archivo "hosts" en distintos sistemas operativos se puede encontrar en la Wikipedia.

Y aparecen rescoldos

Volvemos a nuestro tema. Habíamos encontrado que en un tiempo pasado la IP a la que apunta uno de los dominios del juego que quedan en pie albergó otros dominios necesarios para el juego. Vamos a ver si siguen los contenidos perdidos en ese servidor...

Colocamos al final de nuestro archivo "hosts" una linea adicional con el siguiente contenido:

93.188.168.154 www.skl-network.com

La IP corresponde a la que nos devuelven los DNS cuando intentamos resolver el dominio "www.inmemoriamdev.com", y "www.skl-network.com" es el dominio en el que se albergaba la web de la supuesta agencia para la que trabajan los dos secuestrados del juego. Salvamos, vamos al navegador, tecleamos http://www.skl-network.com y...

Bingo. Procedemos a colocar en el archivo "hosts" algunas líneas más que redirijan hacia las misma IP otros dominios que nos devolvía esta web y que puedan estar relacionados con el juego, como puede ser xineph.com.

De los datos de registro de "inmemoriamdev.com" podemos deducir que dicho servidor pertenece a Lexis Numérique, los desarrolladores del juego, y por lo que aparece en distintas webs, dicha empresa anunció su liquidación el 16 de junio de 2014, por lo que han dejado de renovar los dominios conforme van venciendo, y de un momento a otro es de esperar que cierren el servidor que alberga los contenidos.

Parece ser que su última apuesta, Alt-Minds, aparecida finales de 2012 con el padrinazgo de Orange, no ha sido todo lo exitosa que se esperaba. Además por los trailers se puede apreciar que en comparación con In Memoriam, Alt-Minds era toda una superproducción.

Así que salvo que los editores principales del juego, Ubisoft y Nordic Games, hagan algo, tanto "In Memoriam" como sus secuelas que compartían la misma mecánica,  sin la infraestructura online, sencillamente serán injugables...