MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Liste des UUID MS‑RPC : comment cartographier toutes les interfaces Windows

Liste des UUID MS‑RPC : comment cartographier toutes les interfaces Windows

Windows Server

Vous cherchez une liste officielle de tous les services Microsoft RPC et de leurs UUID ? Voici pourquoi elle n’existe pas, et surtout comment construire votre propre référentiel exhaustif et maintenable.

Sommaire

Existe‑t‑il un tableau public répertoriant l’ensemble des services MS‑RPC et leurs UUID ?

Vue d’ensemble du problème

Chaque composant Windows digne de ce nom – service système, rôle serveur, application bureautique, client lourd ou simple applet de configuration – peut exposer une ou plusieurs interfaces MS‑RPC (aussi appelées DCE/RPC). À chacune de ces interfaces est associé un identifiant universel unique (UUID) complété d’un numéro de version majeure et mineure. La question est donc simple : « Puis‑je télécharger un fichier CSV unique récapitulant tous les couples {interface, UUID, version} publiés par Microsoft ? »

La réponse courte est non. Il n’existe aucun répertoire public, exhaustif et maintenu par l’éditeur. Microsoft documente de façon sélective les interfaces concernées par ses protocoles ouverts (Windows Protocols), mais ces listes restent, par nature, partielles. Dans les paragraphes qui suivent, nous détaillons :

  • Pourquoi cette table unique n’a jamais été publiée.
  • Comment l’UUID garantit l’unicité d’une interface.
  • En quoi consiste la notion de « super‑UUID » (indice : elle n’existe pas).
  • La façon dont la gestion de versions impacte – ou non – l’UUID.
  • Un guide pas‑à‑pas pour créer, automatiser et maintenir votre propre cartographie.

Tableau récapitulatif des points clés

Point cléSolution / Explication
Catalogue exhaustifMicrosoft ne publie pas de table complète. Les ressources disponibles (documentations protocolaires, fichier uuid.txt de Wireshark, bases issues d’éditeurs tiers) ne couvrent qu’une partie du périmètre. Pour un inventaire à jour, il faut mesurer son environnement (dump RPC, capture réseau, analyse statique).
Unicité de l’UUIDDans DCE/RPC, l’interface est identifiée par le couple {UUID, version}. L’UUID est mondialement unique ; deux services différents ne partagent jamais le même UUID.
UUID « composite »Le standard ne prévoit aucun « super‑UUID » pouvant agréger plusieurs interfaces. Chaque interface est enregistrée séparément via RpcServerRegisterIf.
Versions• Changement mineur : on conserve l’UUID, on incrémente la version mineure.
• Changement majeur : soit on augmente la version majeure avec le même UUID, soit – solution souvent préférée – on génère un nouvel UUID.
Se fabriquer la tableCollecte dynamique (dump RPC / Registry), analyse réseau (Wireshark), analyse statique (extraction d’IDL), puis fusion dans une base interne mise à jour.

Pourquoi Microsoft n’entretient‑elle pas une liste globale ?

L’implémentation RPC de Windows existe depuis 1993. Des milliers d’équipes, de produits et de versions se sont succédé. Maintenir une unique référence centrale supposerait de :

  • Regrouper les interfaces issues de produits encore supportés et obsolètes.
  • Publier des informations parfois considérées comme internes ou réservées à la défense en profondeur.
  • Mettre à jour la liste à chaque build Windows Insider, Patch Tuesday, CU ou Hotfix.

Au regard de ce coût et de la faible valeur perçue pour la majorité des clients, l’éditeur préfère documenter au cas par cas les UUID liés aux protocoles officiellement ouverts (SMB, FSCC, DNS, etc.) ou aux surface d’API destinées aux développeurs.

Comprendre l’unicité d’un UUID MS‑RPC

Le générateur d’UUID (RFC 4122) garantit mathématiquement l’absence de collision. À l’enregistrement (RpcServerRegisterIfEx), le service indique son UUID et sa version. Si un autre service tente de publier exactement le même couple {UUID, version}, il se heurtera à un status = RPC_S_DUPLICATE_ENDPOINT. Ainsi :

  • Aucune duplication d’UUID entre services distincts.
  • Un même service applicatif peut cependant offrir plusieurs interfaces (authentification, réplication, diagnostic), chacune avec son propre UUID.

La légende du « super‑UUID »

Dans certains forums, on lit l’idée qu’un « super‑UUID » représenterait la somme de plusieurs interfaces. Cette supposition vient souvent de l’observation du port mapper (⟂ EPMapper / EndPoint Mapper) : celui‑ci retourne une liste d’UUID pour un même processus. En réalité, il ne fait que juxtaposer les interfaces enregistrées dans le même espace mémoire ; aucun mécanisme RPC ne regroupe ces interfaces sous un identifiant global.

Gestion de versions : quand changer d’UUID ?

La décision dépend d’un seul critère : la compatibilité binaire.

  • Évolution compatible (ajout d’une méthode optionnelle, nouvel opnum en fin de table) : on conserve l’UUID et on incrémente la version mineure.
  • Rupture de compatibilité (modification de la signature d’une méthode, suppression d’un opnum, changement de comportement non rétro‑compatible) : on génère un nouvel UUID ou, dans de rares cas, on incrémente la version majeure.

Méthodes pour constituer votre propre référentiel d’UUID

1. Énumération dynamique depuis le système

  1. Installez le Windows SDK correspondant à votre build.
  2. Ouvrez PowerShell en administrateur et exécutez :
    rpcdump.exe /v > rpcdump.txt
  3. Le fichier généré contient pour chaque PID le couple {UUID, version}, le protocole (ncacn_ip_tcp, ncalrpc, ncacn_np…), le port ou le nom de canal nommé.
  4. Nettoyez puis importez ces données dans un entrepôt (sqlite, PostgreSQL, etc.).

2. Inspection du registre

Toutes les interfaces déclarées par des services persistant au boot figurent sous :

HKLM\SOFTWARE\Microsoft\Rpc\Interface

Chaque sous‑clé se nomme exactement par l’UUID (formatté en {xxxxxxxx‑xxxx‑xxxx‑xxxx‑xxxxxxxxxxxx}). Les valeurs Protocol et Annotation fournissent respectivement le binding (ex : ncalrpc) et un libellé lisible (ex : « LSA »).

3. Analyse réseau en live

Lancez Wireshark sur la machine cible et appliquez le filtre :

tcp.port == 135 || udp.port == 135

La colonne Info affiche le champ UUID extrait de l’appel bind vers l’Endpoint Mapper. Copiez‑collez ou exportez en CSV pour ingestion.

4. Analyse statique des binaires

Les DLL et EXE Windows compilés à partir de fichiers IDL conservent l’attribut [uuid(...)] dans la section .rdata. Avec dumpbin /strings ou rizin‑cutter, vous pouvez repérer ces motifs. Les symboles publics (PDB) exposent la même information de façon structurée.

5. Agrégation et déduplication

Fusionnez les quatre sources dans une table uuid_catalog dotée de ces colonnes :

  • uuid (PRIMARY KEY)
  • version_major
  • version_minor
  • service_name (PID, process name, annotation, description)
  • binding (protseq)
  • first_seen, last_seen
  • source (dump, registry, network, static)

En définissant uuid + version_major + version_minor comme clé composite, vous évitez tout doublon involontaire.

6. Automatisation CI/CD

  1. Intégrez le script rpcdump.exe dans votre pipeline d’inventaire (Azure DevOps, GitHub Actions ou Jenkins).
  2. Déclenchez‑le chaque premier lundi du mois ou dès qu’un patch Windows est appliqué.
  3. Envoyez le diff (EXCEPT SELECT) vers un channel Teams « RPC‑UUID changes » afin de documenter toute variation.

7. Exemple de script PowerShell pour extraire les UUID

# Requires Windows SDK
$uuidList = ""
rpcdump.exe /f "ncacn_ip_tcp" | ForEach-Object {
    if ($_ -match "^{[0-9a-f\-]{36}}") {
        $uuidList += $_ + "`n"
    }
}
$uuidList | Out-File "uuids_$(Get-Date -Format yyyyMMdd).txt"

8. Exemple de requête SQL pour détecter les nouveautés

INSERT INTO uuid_catalog (uuid, version_major, version_minor, service_name, binding, first_seen, last_seen, source)
SELECT * FROM staging_uuid s
WHERE NOT EXISTS (
    SELECT 1 FROM uuid_catalog c
    WHERE c.uuid = s.uuid
      AND c.version_major = s.version_major
      AND c.version_minor = s.version_minor
);

Bonnes pratiques de documentation

  • Conservez toujours le numéro de version conjointement à l’UUID.
  • Enregistrez la date d’observation ; cela facilite les audits de configuration.
  • Stockez le binding complet (protseq + endpoint), surtout pour ncalrpc, sinon impossible de reproduire un appel de test.
  • Faites signer votre base interne par le RSSI avant toute diffusion hors de l’entreprise.

Questions fréquentes

Un UUID peut‑il changer après un patch de sécurité ?

Très rarement. Microsoft préfère maintenir la compatibilité. Toutefois, un patch peut introduire une nouvelle version majeure, en parallèle de la version existante (deux UUID différents). Puis‑je utiliser un UUID existant pour mon propre service interne ?

C’est techniquement possible mais fortement déconseillé : risque de collision si un composant Windows futur réutilise le même identifiant dans une machine jointe au domaine. Générez toujours vos UUID via uuidgen.exe. L’Endpoint Mapper est‑il suffisant pour tout découvrir ?

Non : il ne liste que les interfaces enregistrées au runtime. Les interfaces dormant dans une DLL mais non chargées ne seront pas visibles.

Conclusion

Aucune base publique ne recense l’intégralité des services Microsoft RPC et leurs UUID. Pourtant, construire et maintenir votre propre inventaire est non seulement possible, mais devient vite indispensable pour l’audit, la gestion de configuration et la cybersécurité. À l’aide d’outils gratuits (rpcdump, Wireshark), de scripts maison et d’un minimum d’automatisation, vous obtiendrez une cartographie fiable, versionnée et diffable. Prenez le temps de documenter UUID + version + binding + date ; votre équipe de sécurité vous en remerciera.

Windows Server
sécurité UUID troubleshooting Windows Server MS‑RPC
Sommaire