DeathSleep

Ante todo

Todo lo expuesto aquí proviene de mi comprensión de los diferentes temas tratados, ya sea por lectura o experiencia durante el desarrollo. Soy consciente de que no soy un experto y lo último que quiero es difundir información errónea, así que si crees que algo no es correcto, me encantaría que me lo hicieras saber, puedes contactarme en twitter, o abriendo issues en este repositorio. Muchas gracias por tu comprensión. :)

Conceptos básicos

El objetivo principal de esta técnica es claro, terminar el hilo actual y restaurarlo antes de reanudar la ejecución, pero ¿qué significa exactamente esto y qué nuevas restricciones impone?

Para poder restaurar la ejecución, necesitamos guardar dos cosas antes de terminar el hilo: primero, el estado de la CPU, y segundo, la pila, y configurarlos nuevamente después de que se lance el nuevo hilo.

Hablé sobre nuevas restricciones que aparecerán en esta técnica, y hay dos grandes: Primero, necesitamos almacenar fuera de la pila cualquier cosa que se necesite desde el momento en que el hilo termina hasta que se restaura la pila, y como verás, crea algunos nuevos desafíos.

Segundo, siempre necesitamos al menos otro hilo ejecutándose en nuestro proceso, ya que estamos terminando nuestro hilo, si no hay otros hilos, el proceso finalizará. No creo que esto sea un gran problema, ya que la mayoría de los agentes se inyectan en otros procesos, podemos suponer que ese proceso mantendrá al menos un hilo ejecutándose.

Componentes de DeathSleep:

Podemos ver en este PoC 4 funciones principales:

• Programa principal: Aquí es donde escribirías el código de tu agente, y es la parte del código que hará uso de DeathSleep
• Función Awake: este es el punto de entrada de todos nuestros hilos, y se encarga de guardar el punto de inicio de la pila que restauraremos. También se encarga de restaurar la pila y el contexto de CPU cuando sea necesario, o simplemente lanzar nuestro programa principal.
• DeathSleep: esta es la función principal de esta técnica, y se encarga de realizar una copia de seguridad del contexto del hilo y la pila, y también de configurar todo para que ocurra la magia.
• Rebirth: Una función simple solo encargada de lanzar nuestros nuevos hilos.

Guardando la pila.

Cuando estamos a punto de guardar la pila, surge una pregunta: ¿cuánto de la pila necesita ser guardado?

Revisemos primero qué hay en la pila después de que llamamos a la función DeathSleep (esta es la función que guarda el contexto, la pila y prepara todo para la ofuscación y restauración)

Como podemos ver, cada función tiene tres partes:

• Shadow space: este es un espacio de 32 bytes, asignado por la persona que llama, pero utilizado por la persona llamada. Hasta donde sé y pude ver, su función principal es contener, si es necesario, los argumentos pasados a la función llamada en los registros, pero puede ser utilizado para cualquier cosa que la función llamada decida.
• Dirección de retorno: esta es la dirección de la siguiente instrucción a ejecutar en la función que llama, insertada por la instrucción CALL, por lo que la instrucción RET en la función llamada simplemente tomará esta dirección y "saltará" a ella cuando termine.
• Espacio de pila de la función: Este es el espacio reservado por la función llamada para almacenar el valor de los registros que deben restaurarse y el valor de sus variables locales.

La porción mínima de la pila que obviamente necesitamos guardar es todo lo que está dentro de nuestro programa principal, eso significa su shadow space, su dirección de retorno y todo hasta la función DeathSleep. Cualquier cosa anterior no es realmente necesaria (guardar la pila utilizada por la función de entrada tiene sus ventajas, pero discutiremos eso más adelante), ya que esa es la pila utilizada por las rutinas de Windows para lanzar nuestro nuevo hilo. Aparte de esto, también decidí almacenar el shadow space de la función DeathSleep (no es realmente necesario, pero facilita el cálculo de Rsp en el momento de despertar).

Entonces, al final, estamos guardando esto:

Cómo encontrar nuestras direcciones de pila:

Cada función en una compilación estándar debe estar compuesta por 3 partes: el prólogo, el código de la función y el epílogo.

Rsp (puntero de pila) solo debe modificarse en el prólogo y epílogo de la función. El prólogo incrementa el puntero de la pila (recuerda que incrementar la pila significa reducir direcciones, ya que van en direcciones opuestas), para guardar registros, para contener todas sus variables locales y luego para contener el shadow space, y el epílogo hace exactamente lo contrario.

Esto significa que el puntero de pila dentro del código de la función siempre debe apuntar al final del shadow space (púrpura en la imagen anterior), y la suma del tamaño de pila de la función y el shadow space se puede encontrar calculando cuánto incrementa el puntero de la pila el prólogo. Este valor se puede calcular fácilmente utilizando la información contenida en las tablas de desenrollado (unwind tables), una explicación sobre su uso es algo que no cubriremos aquí, pero en resumen, esas tablas se utilizan para permitir que cualquier otro hilo o proceso se mueva correctamente a través de la pila para ver su contenido, manejar excepciones o analizarla.

Capturando y preparando el contexto para restaurar.