Jump List Parser
← Retour au blog

Les AppID de Jump List : ce qu'ils sont et comment en résoudre un

2026-06-156 min de lecture

La chaîne hexadécimale de 16 caractères devant .automaticDestinations-ms n'est pas un numéro de série que Windows a distribué. C'est un hachage, et une fois que vous comprenez ce qu'il hache, vous cessez de traiter un AppID inconnu comme du bruit et commencez à le traiter comme une question.

Tous les autres articles de cette série s'appuient sur la correspondance d'AppID. Le guide DFIR vous dit de trier d'abord par AppID. Voici l'article vers lequel il aurait dû pointer.

Le nom de fichier est l'identité

Un fichier Jump List porte le nom de l'application qui le possède. 1b4dd67f29cb1962.automaticDestinations-ms appartient à une application précise, et 9b9cdc69c1c24e2b.automaticDestinations-ms à une autre. La valeur hexadécimale est l'AppID. Il n'y a pas de champ séparé dans le fichier qui nomme l'application. Le nom est le nom de fichier, et il est haché.

Il y a deux façons dont ce hachage est produit, et la distinction compte quand une recherche échoue.

La plupart des applications de bureau ne définissent jamais leur propre identité. Pour celles-là, le shell calcule l'AppID à partir du chemin complet de l'exécutable, mis en minuscules et normalisé, et le passe dans un CRC-64. Déplacez le même binaire vers un chemin différent et vous obtenez un AppID différent. Notepad lancé depuis C:\Windows\System32\notepad.exe et le binaire identique copié dans C:\Temp\notepad.exe sont deux AppID différents pour Windows, parce que l'entrée du hachage a changé.

L'autre cas est une application qui définit explicitement un Application User Model ID (AppUserModelID), une chaîne comme Microsoft.Windows.Explorer ou une identité d'application packagée. Quand cette chaîne est présente, Windows hache la chaîne au lieu du chemin. Les applications UWP et packagées, Office, et une poignée d'outils Microsoft font tous cela. Leurs AppID sont stables quel que soit l'endroit où réside le binaire, ce qui est tout l'intérêt du mécanisme.

On résout par recherche, pas en inversant

Le CRC-64 est à sens unique. Vous ne pouvez pas prendre 1b4dd67f29cb1962 et en recalculer "Notepad". Quiconque vous dit avoir inversé un AppID veut dire l'une de deux choses : il l'a cherché dans une table, ou il a haché des entrées candidates jusqu'à en trouver une qui corresponde. Il n'y a pas de troisième option, alors ne perdez pas de temps à essayer d'inverser le hachage.

En pratique, presque tout le monde utilise la liste de référence fournie avec JLECmd. C'est la table de facto, maintenue par la communauté, et elle couvre les applications courantes sur les versions de Windows. Hexacorn a publié la recherche d'origine sur la dérivation et maintient une grande table de correspondance également. Pour le triage quotidien, la liste résout les AppID que vous verrez dans la grande majorité des cas sans que vous ayez à calculer quoi que ce soit.

Quand la liste revient vide, vous construisez la correspondance vous-même. Énumérez les exécutables présents sur l'hôte, calculez le CRC-64 basé sur le chemin pour chacun, et cherchez votre AppID dans les résultats. Cela ne fonctionne que pour le cas dérivé du chemin. Une application à AppUserModelID explicite ne correspondra jamais à un hachage de chemin, donc si l'hôte a clairement l'application installée et que vos hachages calculés ne produisent pas l'AppID, c'est un signe que l'application définit sa propre chaîne d'identité et qu'il vous faut plutôt la liste des chaînes connues.

Un moyen rapide d'énumérer les AppID explicites déjà enregistrés sur un hôte actif, c'est PowerShell :

Get-StartApps | Sort-Object Name | Format-Table Name, AppID

Cela retourne l'AppUserModelID de tout ce qui est épinglé ou enregistré dans Démarrer. Cela ne couvrira pas les applications de bureau dérivées du chemin, mais cela résout les identités packagées et Microsoft que l'approche par hachage de chemin ne peut pas atteindre.

Quand un AppID ne figure dans aucune liste

C'est là que ça devient utile pour une enquête. Un blanc dans la table de correspondance n'est pas une impasse, c'est un signal. Les explications bénignes viennent d'abord, comme toujours :

  • Une application portable lancée depuis une clé USB ou un dossier de téléchargements. Chemin différent, hachage inconnu.
  • Un logiciel installé quelque part de non standard, ce qui est courant sur les postes de développeurs et d'administrateurs.
  • Une application légitime qui n'est simplement pas encore dans la liste publique.

Puis l'explication qui justifie le triage :

  • Un binaire renommé ou déplacé. Les attaquants copient cmd.exe, powershell.exe, ou une charge utile déposée vers un chemin étrange et l'exécutent. La Jump List, si le binaire touche le shell d'une manière qui en génère une, enregistre un AppID que personne n'a jamais catalogué parce que personne n'a jamais exécuté ce binaire exact depuis ce chemin exact auparavant. Un AppID non répertorié avec un horodatage DestList récent est exactement le genre de fil qui se transforme en constatation.

Pour le débusquer, prenez l'AppID inconnu et traitez-le comme la question "quel exécutable, à quel chemin, donne ce hachage ?". Pivotez à travers le reste de l'hôte : Prefetch, AmCache et ShimCache vous donnent des chemins d'exécutables candidats. Hachez ces chemins, cherchez la correspondance. Quand un chemin issu d'AmCache donne votre AppID mystère, vous avez lié la Jump List à un binaire précis qui s'est exécuté sur la machine, et souvent à un qui n'aurait pas dû y être.

Une note sur l'usurpation

Parce que le nom de fichier n'est qu'un hachage et que Windows ne l'authentifie pas, un AppID peut être planté. Quelqu'un qui veut tromper un analyste peut déposer un fichier nommé d'après une application bénigne et le remplir des entrées qu'il veut, ou polluer un vrai. C'est une technique offensive, pas un détail d'analyse, et elle est couverte dans l'article côté attaquant. Pour l'instant, le point à retenir est étroit : l'AppID vous dit à quelle application un shell Windows bien élevé a attribué l'activité. Sur un hôte que vous soupçonnez déjà de falsification, traitez cette attribution comme une affirmation à vérifier, pas comme un fait à citer.

Pour aller plus loin