Tweet
Vamos a ver un poco la evolución de los "emuladores" KMS. Es evidente que estas notas no tienen por objeto propiciar la piratería, sino solo ver como ha ido desarrollándose por parte del mundo de los programadores la construcción de un verdadero "emulador" de KMS.
Recordemos lo primero que el protocolo KMS solo funciona si la maquina cliente tiene una licencia por Volumen. Es decir, la clave de activación es de Volumen (y en Windows 7 y anteriores, implicaba que la instalación era una especifica, es decir se necesitaba que el Sistema Operativo fuese un sistema de licenciamiento por Volumen - idéntico al normal excepto ciertas DLL's del sistema de activación. Los Windows "enterprise" por defecto son por Volumen, pero el resto hasta windows 8 era software diferente. (aunque esto también se puede forzar).
El tema, como casi todos en este ámbito, surgió como un reto. Microsoft cuando ofreció los KMS a las empresas tuco el desliz de comentar que era un protocolo inviolable y que garantizaba la genuidad de sus sistemas. Bajo mi punto de visto, una declaración un poco ingenua ya que propiciaba que el mundo de los desarrolladores se pusiese a trabajar. Y lo que es mas grave, esta vez trabajando en equipo ya que hubo distintos foros en la web en donde estos se reunían para ir compartiendo sus experiencias.
Sobre lo que he ido viendo, podemos distinguir 4 generaciones de "emuladores".
Primera generación: Un poco rupestre, pero funcionaba. Simplemente se investigó sobre KMS's reales como tenían configurados los ficheros de "token" (los que almacenan las claves reales). Estos eran en función del hardware, pero un hardware se puede emular en maquinas virtuales. El tema resultó simple: sustituir en maquinas virtuales mediante una instalación OEM (a medida) con cierto hardware predefinido (virtual) los ficheros de token. A todos los efectos, el Windows así recién instalado era un servidor KMS.
Hubo luego software en la red que era capaz de activarlo sin esta necesidad (ya que la virtual se la creaban transitoriamente mediante QEMU, por ejemplo (buscar QEMU en la red). La iniciaban, activaba y limpiaban. Pesado, pero funcionaba. (los MicrosoftToolKit iniciales y sobre todo el KmsPico, por ejemplo, asa como otros emuladores similares).
Segunda generación: romper el protocolo propiamente dicho, es decir, investigar los mensajes, ver su encriptación (SSL atípico no en el API de Windows), e intentar emularlos. En esto participaron varios grupos, cada encargado de una parte. Encriptación, ver en donde enganchaba en Windows, etc. Lo consiguieron al cabo de unos meses: con esto mejoraron los "emuladores anteriores". El protocolo KMS era el denominado v4 y valido hasta Windows Vista. Cambiaron el protocolo a v5 en Windows 7. Lo rompieron en pocos meses también. (ingeniería inversa y análisis del sistema de encriptación). Por tanto fueron capaces de crear un servidor KMS en la propia maquina a activar, iniciar el servidor, activar, y para el server.
Tercera generación: En Windows 8, el protocolo cambió; paso a ser v6, y además el sistema analizaba si la IP del servidor era una de las IP's locales en cuyo caso lo denegaba: el servidor no podía estar en la misma maquina que quería activarse. En la primera fase, la investigación del SSL usado y de los mensajes intercambiados se encontraron con muchos problemas. La encriptación en si no estaba soportada por el API nativo de Windows: había que crearse "a pelo" el sistema de encriptación / desencriptación: no es fácil la asignación de pesos y rotaciones en SSL. El análisis de los mensajes daba además 8 bytes de información que no se sabia en principio que significaban...algo debía querer decir.
Hubo una persona que parece que daba las directrices de búsqueda: firmaba como Mimik38 y los pocos mensajes que puso eran pistas sobre el siguiente paso: se llego a la conclusión que esos 8 bytes, aunque aparentemente los servidores KMS en Windows 8 y 8.1 no los usaban parecían llevar una clave del hardware del equipo. Un hash.
Con respecto a la dificultad de no poder usarse en local, la solución partió de instalar un driver TAP. Podéis ver información aquí: http://vtun.sourceforge.net/tun/faq.html Con este driver se emulaba una dirección IP virtual que era capaz de engañar al sistema al no ser una IP local. Esta solución no es del todo buena, ya que la instalación de ese driver (aparte de no estar firmado) creaba inestabilidades en Windows. Aun así esa solución se uso durante bastante tiempo.
Cuarta generación: y de repente surgión un chavalín Colombiano. No tenia mas de 17 años y parece que había nacido con la programación y Windows en la cabecera de su cama. Propuso la idea de inyectar una DLL en el rpc que parchease lo que fuese necesario para engañar a todo el sistema de activación (tanto en la IP de la cual provenía como de paso emular el KMS de activación). Evidentemente lo consiguió, pero el que a Windows le "inyecten" DLL's, a pesar de ser una técnica válida, no es que le guste mucho.
Una variante posterior, y bajo mi punto de vista la mejor y mas elegante, es usar los sistemas de debugger del propio Windows para que tome el control (en vez de inyectar la DLL). Esto por diseño de Windows no sería modificable y seria la solución perfecta. Provino de una persona que firmaba como QAD -y por cierto, idea sugerida unos días antes por un miembro de estos foros...que a no ser que él se identifique, ocultaré su nombre
En capítulos posteriores veremos cada una de estas ultimas versiones y sobre todo la solución mas limpia. Y recordad, no deben usarse excepto con fines didácticos por aquellos del mundo del desarrollo ya que realmente son "emuladores".
Recordemos lo primero que el protocolo KMS solo funciona si la maquina cliente tiene una licencia por Volumen. Es decir, la clave de activación es de Volumen (y en Windows 7 y anteriores, implicaba que la instalación era una especifica, es decir se necesitaba que el Sistema Operativo fuese un sistema de licenciamiento por Volumen - idéntico al normal excepto ciertas DLL's del sistema de activación. Los Windows "enterprise" por defecto son por Volumen, pero el resto hasta windows 8 era software diferente. (aunque esto también se puede forzar).
El tema, como casi todos en este ámbito, surgió como un reto. Microsoft cuando ofreció los KMS a las empresas tuco el desliz de comentar que era un protocolo inviolable y que garantizaba la genuidad de sus sistemas. Bajo mi punto de visto, una declaración un poco ingenua ya que propiciaba que el mundo de los desarrolladores se pusiese a trabajar. Y lo que es mas grave, esta vez trabajando en equipo ya que hubo distintos foros en la web en donde estos se reunían para ir compartiendo sus experiencias.
Sobre lo que he ido viendo, podemos distinguir 4 generaciones de "emuladores".
Primera generación: Un poco rupestre, pero funcionaba. Simplemente se investigó sobre KMS's reales como tenían configurados los ficheros de "token" (los que almacenan las claves reales). Estos eran en función del hardware, pero un hardware se puede emular en maquinas virtuales. El tema resultó simple: sustituir en maquinas virtuales mediante una instalación OEM (a medida) con cierto hardware predefinido (virtual) los ficheros de token. A todos los efectos, el Windows así recién instalado era un servidor KMS.
Hubo luego software en la red que era capaz de activarlo sin esta necesidad (ya que la virtual se la creaban transitoriamente mediante QEMU, por ejemplo (buscar QEMU en la red). La iniciaban, activaba y limpiaban. Pesado, pero funcionaba. (los MicrosoftToolKit iniciales y sobre todo el KmsPico, por ejemplo, asa como otros emuladores similares).
Segunda generación: romper el protocolo propiamente dicho, es decir, investigar los mensajes, ver su encriptación (SSL atípico no en el API de Windows), e intentar emularlos. En esto participaron varios grupos, cada encargado de una parte. Encriptación, ver en donde enganchaba en Windows, etc. Lo consiguieron al cabo de unos meses: con esto mejoraron los "emuladores anteriores". El protocolo KMS era el denominado v4 y valido hasta Windows Vista. Cambiaron el protocolo a v5 en Windows 7. Lo rompieron en pocos meses también. (ingeniería inversa y análisis del sistema de encriptación). Por tanto fueron capaces de crear un servidor KMS en la propia maquina a activar, iniciar el servidor, activar, y para el server.
Tercera generación: En Windows 8, el protocolo cambió; paso a ser v6, y además el sistema analizaba si la IP del servidor era una de las IP's locales en cuyo caso lo denegaba: el servidor no podía estar en la misma maquina que quería activarse. En la primera fase, la investigación del SSL usado y de los mensajes intercambiados se encontraron con muchos problemas. La encriptación en si no estaba soportada por el API nativo de Windows: había que crearse "a pelo" el sistema de encriptación / desencriptación: no es fácil la asignación de pesos y rotaciones en SSL. El análisis de los mensajes daba además 8 bytes de información que no se sabia en principio que significaban...algo debía querer decir.
Hubo una persona que parece que daba las directrices de búsqueda: firmaba como Mimik38 y los pocos mensajes que puso eran pistas sobre el siguiente paso: se llego a la conclusión que esos 8 bytes, aunque aparentemente los servidores KMS en Windows 8 y 8.1 no los usaban parecían llevar una clave del hardware del equipo. Un hash.
Con respecto a la dificultad de no poder usarse en local, la solución partió de instalar un driver TAP. Podéis ver información aquí: http://vtun.sourceforge.net/tun/faq.html Con este driver se emulaba una dirección IP virtual que era capaz de engañar al sistema al no ser una IP local. Esta solución no es del todo buena, ya que la instalación de ese driver (aparte de no estar firmado) creaba inestabilidades en Windows. Aun así esa solución se uso durante bastante tiempo.
Cuarta generación: y de repente surgión un chavalín Colombiano. No tenia mas de 17 años y parece que había nacido con la programación y Windows en la cabecera de su cama. Propuso la idea de inyectar una DLL en el rpc que parchease lo que fuese necesario para engañar a todo el sistema de activación (tanto en la IP de la cual provenía como de paso emular el KMS de activación). Evidentemente lo consiguió, pero el que a Windows le "inyecten" DLL's, a pesar de ser una técnica válida, no es que le guste mucho.
Una variante posterior, y bajo mi punto de vista la mejor y mas elegante, es usar los sistemas de debugger del propio Windows para que tome el control (en vez de inyectar la DLL). Esto por diseño de Windows no sería modificable y seria la solución perfecta. Provino de una persona que firmaba como QAD -y por cierto, idea sugerida unos días antes por un miembro de estos foros...que a no ser que él se identifique, ocultaré su nombre
En capítulos posteriores veremos cada una de estas ultimas versiones y sobre todo la solución mas limpia. Y recordad, no deben usarse excepto con fines didácticos por aquellos del mundo del desarrollo ya que realmente son "emuladores".
Comentario