Me he puesto a echar un ojo al post de ps2dev, y estas son las conclusiones que he podido sacar, a ver si alguno me corrige lo que pueda haber entendido mal u os ayuda a los que os interese a saber un poco más como va el rollo.
IDEA ORIGINAL
--------------------
- Hay un parametro del Hypervisor que permite por hardware realizar un bitblt (primitiva gráfica implementada en la propia tarjeta
en la cual dos mapas de bits son combinados en uno).
- Al parecer ese parámetro es el mismo que se usaría en los drivers de Windows (miniport) para hacer un buffer FIFO si se tuviera acceso completo al RSX, por lo que en teoria podría ser el mismo sistema que se utiliza en Windows.
- Se ha comprobado que el hypervisor utiliza realmente una pila FIFO (Push buffer), en una zona circular de memoria, donde se escriben unos pocos dwords (tipo comando + parametro). El area es muy pequeña, unicamente se pueden usar comandos + parametros de tipo bitblt.
- Al ser una pila FIFO, hay casi seguro un puntero que apunta al final de la pila.
- Si este puntero cambia, implica que se han escrito nuevos comandos en la pila, y posiblemente una escritura
directa a los registros de GPU que están mapeados se hará simultáneamente para avisar a la GPU de que tiene
que empezar a leer los nuevos comandos y hasta donde tiene que leer.
- Si se consigue saber el valor de esa variable, y se consigue "inyectar" nuestros propios comandos y parámetros en
el buffer FIFO justo después de que el puntero cambie, se podrían ejecutar los comandos bitblt que nosotros "inyectáramos".
COMENTARIOS VARIOS
------------------------------
- El puntero o variable de fin de FIFO estará en zona de memoria no-DMA. En vez de monitorizar la variable puntero, podemos consultar el primer comando que haya en la pila y asísaber el comando que es y los parámetros que tiene.
- Si sabemos el comando y parámetros, y presuponiendo que la pila FIFO normalmente no se borra por cada operación
sino que se sobreescribe, la memoria es un buffer FIFO por lo que es circular, podemos sacar buscando en zonas de memoria
comandos bitblt que se repitan cada X (que los comandos bitblt no tienen valores en memoria tipicos).
CONCLUSION
------------------
Se ha conseguido de esta forma calcular el tamaño de memoria, aislarlo, volcarlo, estudiarlo e "inyectar" código ya que hay parte de la zona estudiada que se puede mapear para lectura/escritura, con lo que se puede leer y escribir en zonas de video protegidas.