Comment est calculé le hash Windows Prefetch

Un nom comme NOTEPAD.EXE-1B4A5887.pf laisse penser que les huit caractères hexadécimaux sont une somme de contrôle. Ce n'en sont pas. C'est un hash du chemin de lancement de l'exécutable, encodé en UTF-16, préfixé par \DEVICE\HARDDISKVOLUME{n}\. Le contenu binaire de notepad.exe n'entre jamais dans le calcul. Deux copies du binaire identique sous C:\Windows\System32\notepad.exe et C:\Users\analyst\notepad.exe produisent deux fichiers .pf différents parce que leurs chemins diffèrent.

C'est la raison entière pour laquelle Prefetch peut distinguer psexec.exe dans C:\Program Files\ de psexec.exe déposé dans C:\Users\victim\AppData\Local\Temp\. Le hash de chemin est l'identifiant par emplacement de lancement.

Trois algorithmes, trois époques

La fonction a été remplacée deux fois dans l'histoire de l'OS :

• Windows XP / Server 2003. Le hash SuperFetch original. Calcul rolling simple sur le chemin UTF-16.
• Windows Vista / 2008. Même famille, multiplicateur constant différent, seed de départ différent. Les hashes Vista ne correspondent pas aux hashes XP pour le même chemin et vice versa.
• Windows 7 et ultérieur. « Hash Function 5 » dans la terminologie Microsoft. Toujours en service sous Windows 10 et Windows 11. Plie des groupes d'octets du chemin UTF-16 via une boucle multiply-and-XOR, masque à 32 bits, et cela est rendu sous forme des huit caractères hexadécimaux du nom.

La chaîne envoyée aux trois inclut un préfixe \DEVICE\HARDDISKVOLUME{n}\ et le chemin de fichier en UTF-16 LE en majuscules. Sur les versions Windows plus récentes, il existe quelques particularités sur la manière dont les arguments de ligne de commande et certains formats de volumes entrent dans le calcul, mais dans le cas commun le chemin est exactement ce à quoi on s'attend.

Pourquoi cela compte en pratique

Un fichier Prefetch planté est l'un des trucs anti-forensiques les moins coûteux : copier un .pf d'un autre hôte sur la cible. Le chemin à l'intérieur du payload SCCA est celui qu'il avait sur la machine source ; le hash du nom est ce que la machine source a calculé. Un fichier planté n'a pas un hash qui correspond à son propre chemin embarqué quand il est recalculé sous l'algorithme de la destination, surtout d'une version majeure de Windows à l'autre.

La vérification est mécanique :

1. Parsez le payload SCCA.
2. Extrayez le chemin de l'exécutable (le champ Executable filename plus les infos de volume).
3. Reconstituez la chaîne canonique UTF-16 LE en majuscules avec le préfixe \DEVICE\HARDDISKVOLUME{n}\.
4. Passez-la dans l'algorithme correspondant au champ de version du payload (v17 utilise la fonction XP, v23 celle de Vista, v26/v30/v31 utilisent Hash Function 5).
5. Comparez aux huit caractères du nom de fichier.

Une discordance est concluante. Soit le fichier vient d'une machine sur une version d'OS différente, soit quelqu'un l'a façonné à la main et s'est trompé d'algorithme.

Quand le hash est tout ce qui reste

Les payloads SCCA modernes ne conservent plus une chaîne de chemin brute comme le faisait XP. Ils conservent le nom de l'exécutable (sans chemin), les numéros de série de volumes et la liste de métriques de fichiers de tout ce que le binaire a touché. La question « d'où cela a-t-il tourné » se résout souvent à partir du hash du nom combiné à la section d'information de volume. Couplez cela aux enregistrements de volumes de la MFT et aux seriaux de lecteur des LNK, qui portent le même numéro de série NTFS, et vous pouvez en général ancrer le binaire à un volume physique ou amovible spécifique.

Si le binaire vivait sur une clé USB désormais retirée et que le numéro de série de volume ne correspond à aucun volume de l'hôte, le hash du nom est votre dernière piste. Inverser la fonction de hachage dans le sens évident (impossible, elle est à sens unique), ou plus utilement, hasher les chemins candidats d'où vous pensez que le binaire a tourné et chercher la correspondance. Les praticiens tiennent de petites tables de hashes attendus pour les emplacements habituels d'outils d'attaquant précisément pour cela.

Notes d'implémentation

Des implémentations open-source des trois fonctions vivent dans la documentation de libscca de libyal et dans le crate Rust frnsc-prefetch. Les fonctions Vista et Win7+ sont assez courtes pour être inlinées, une douzaine de lignes chacune, sans tirer de dépendance. PECmd expose le chemin parsé ; recalculer le hash à partir de là tient sur une ligne.

Le parser de ce site ne vérifie pas encore le hash automatiquement. Il expose à la fois le chemin de l'exécutable parsé et le suffixe du nom de fichier pour que vous croisiez à la main. Ajouter un drapeau de discordance est sur la liste.

Pour aller plus loin

• libyal, documentation du format libscca — l'écrit public le plus détaillé sur les trois algorithmes.
• Yogesh Khatri, publications sur le hashing Prefetch à travers les versions Windows — exemples pratiques avec vecteurs de test connus.