Mysterie's blog

Je me suis demandé comment fonctionnait l'affichage sous windows (afficher un pixel à l'écran). Quand j'ai fait mes premiers pas en assembleur je me suis amusé à afficher une lettre, c'était sous win98 grâce au mode cga qu'on obtient avec ces instructions INT 10h / AH 6h. Puis j'ai essayé de lancer le même code sous XP et la c'est le drame, rien. Depuis windows xp & co il y a eu pas mal de changement et mon programme ne fonctionne plus. En réalité on ne peut plus lire/écrire directement dans la mémoire physique réservée au mode cga car:

• Les systèmes d'exploitation actuels utilisent un mécanisme de mémoire virtuelle.
• L'espace mémoire en question se situe après l'adresse 0x7ffeffff (Ring 0).

Je me suis mis à la recherche de la mémoire vidéo, le mode cga n'étant plus utilisé depuis longtemps. Une des façons de procéder est d'écrire un driver (pour accéder au noyau) et d'envoyer des requêtes au bus pci pour trouver la carte graphique et ses caractéristiques. Je me suis basé sur un article de rAsM à lire absolument si vous voulez comprendre le code. J'ai ajouté des KeAcquireSpinLock et KeReleaseSpinLock histoire de ne pas avoir de surprise avec les READ/WRITE_PORT.

Le code du driver, Le résultat:

Bien sûr se sont des adresses physique, on peu ensuite utiliser la fonction MmMapIoSpace pour y accéder mais sa reviendrai à faire une copie de la mémoire physique vers la mémoire virtuelle et on se retrouve avec DEUX buffer vidéo en ram :/.
Alors on vas essayer de retrouver le premier qui est déjà en mémoire. J'ai donc fait un programme en C qui affiche un pixel rose en haut à gauche de l'écran.

Et ensuite je débugge tout ça, donc dans notre programme on commence par un appel a la fonction SetPixel qui se trouve dans gdi32.dll. La GDI permet de faire le lien entre les applications et les pilotes graphiques. et à la fin de gdi32!SetPixel on as un appel à une petite routine assez spécifique:

Pour ceux qui n'ont pas compris la subtilité de ses quelques instructions, en fait on a un appel à KiFastSystemCall() avec comme argument 0x111A. Puis vient le SYSENTER et on entre dans le noyau (pas directement bien sûr), la fonction KiFastCallEntry() récupère notre argument puis on passe par la fonction KiSystemService() qui va se charger de trouver la fonction équivalente a 0x111A. Ce numéro ne représente pas vraiment une fonction, je pense qu'il y a un 0x1000 AND 0x111A, pour indiquer si on a affaire à la SSDT ou à la SSDT Shadow.

On voit bien que le nombre de fonction dans la SSDT Shadow est de 0x29b, donc 0x111A c'est trop grand. Par contre après avoir viré ce 0x1000 on se retrouve avec le numéro 0x11A et là ça le fait.

Le nom de la fonction est assez explicite, elle fait appel a de moult autre fonctions dans win32k.sys. je trace un peu tout ça pour en ressortir les fonctions qui nous intéressent.

// arbre d'appel
win32k!NtGdiSetPixel 
 -> win32k!SURFACE::pfnBitBlt 
  -> win32k!SpBitBlt 
   -> win32k!OffBitBlt
    -> win32k!CLIPOBJ_vOffset
     -> win32k!EngBitBlt 
      -> win32k!PDEVOBJ::vSync 
       -> win32k!vDIBSolidBlt
        -> win32k!vSolidFillRect1 
// code qui rox
mov eax,dword ptr [ebp+18h] ; eax=00ff00ff code de la couleur
mov dword ptr [edi],eax ; edi=f9234000 adresse pointant dans la mémoire vidéo.

Je vérifie que cette adresse corresponde bien à l'adresse physique 0xf0000000.

Woot! Je ne sais pas comment procède windows pour retrouver l'adresse 0xf9234000 (si quelqu'un peu m'éclairer). Par contre je m'aperçois qu'après f9234000+1D4C00 (1D4C00 = 800*600*4 la résolution de l'écran) la mémoire est à zéro, de 0xf9408c00 à 0xf9434000 se qui fait 177ko de libre. Vu la place je pense à la technique du Shadow Walker, le principe serai de faire croire au système que les pages non utilisées de la mémoire vidéo sont swappées. On pourrai y cacher du code ou des datas. Mais cette technique commence à dater et nécessite un hook dans l'idt ce qui peut être détectable. Et dans le cas où l'utilisateur changerai sa résolution d'écran il y aurai surement un conflit, dommage...