Conoscere meglio il processo Svchost e capirne il funzionamento può aiutare a risolvere parecchi problemi e, tra le altre cose, è un requisito fondamentale per ripulire a mano computer infettati da virus o malware particolarmente ostinati.

Cominciamo con la definizione ufficiale di Microsoft: “Svchost.exe è il nome di un processo host generico per servizi eseguiti da librerie di collegamento dinamico (DLL)”. Detto così non è che sia granché chiaro, cerchiamo di capire un po’ meglio.

Svchost è nato quando Microsoft ha cominciato a mettere i servizi di sistema dentro file .dll invece di eseguibili .exe, per migliorare l’approccio verso la riusabilità. Ma una DLL non può essere lanciata da sola, ha bisogno di un eseguibile che la carichi e la mandi in esecuzione, e Svchost fa proprio questo. La definizione di “servizio” aiuta a integrare il concetto: un servizio è un programma destinato a girare continuamente, che espleta una funzione particolare e che non necessita input dall’utente e quindi non ha interfaccia (Wikipedia).

Vista la pletora di servizi necessaria al funzionamento del sistema, Svchost ha la possibilità di lanciare più di un servizio, in modo da non intasare l’elenco dei processi; per motivi di stabilità, affidabilità e organizzazione vengono lanciate diverse istanze del processo nelle quali i servizi sono distribuiti secondo la funzionalità. Per esempio una istanza di Svchost fa girare i servizi relativi al firewall, un’altra istanza contiene quelli per l’interfaccia utente, e così via. Ecco uno screenshot di un task manager (potrebbe essere necessario cliccare su “Mostra i processi di tutti gli utenti”):

Si vedono i diversi processi Svchost, ciascuno con il loro PID (Process ID), che girano contemporaneamente nel sistema. Sembra complicato ma le cose si chiariscono osservando direttamente. Il comando da console per elencare i processi è tasklist, e la sintassi per elencare i servizi collegati a ciascun processo è questa:

tasklist /svc /fi “imagename eq svchost.exe”

Lo switch /svc visualizza i servizi ospitati da ciascun processo, /fi è un filtro, usato con questa sintassi per elencare solo i processi che ci interessano in questo momento. Ecco cosa si ottiene:

Ciascun processo è elencato con il suo PID e con la lista di servizi che ha caricato. I nomi sono criptici, ma è sufficiente cercarli nella linguetta “servizi” del task manager (da Vista in poi) e leggerne la descrizione. Ad esempio, il servizio “WPDBusEnum” lanciato dal processo Svchost con PID 920, viene descritto come “Servizio Enumeratore Dispositivi Mobili”. Se usate ancora XP, faticherete un po’ di più per trovare questa informazione perché non è disponibile nel task manager.

Andiamo avanti: lanciamo la gestione servizi e cerchiamo il “Servizio Enumeratore Dispositivi Mobili”; doppio clic e la finestra che si apre ci fornisce ulteriori informazioni:

In particolare si nota che il servizio viene caricato dal processo Svchost che contiene il gruppo LocalSystemNetworkRestricted, che il tipo di avvio del servizio è manuale, che al momento sta girando e, cliccando sul tab “Relazioni di dipendenza”, che dipende dal servizio RCP — uno dei servizi fondamentali per il fuzionamento di Windows. Dipendenza in questo caso significa che WDBusEnum ha bisogno che RPC sia in esecuzione per essere avviato.

Approfondiamo ancora e andiamo nel registro di sistema, dove risiedono tutte queste relazioni e impostazioni; lanciamo regedit e navighiamo fino a:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost

Ogni valore di questa chiave rappresenta un diverso gruppo Svchost, ciascuno dei quali appare come una diversa istanza del processo, come abbiamo verificato in precedenza. I valori sono del tipo REG_MULTI_SZ e contengono la lista dei servizi che girano sotto quel particolare gruppo Svchost. Continuando con il nostro esempio, individuiamo la chiave con il nome del gruppo LocalSystemNetworkRestricted, doppio click e verifichiamo che effettivamente il servizio WPDBusEnum compare nell’elenco. Ma come fa Svchost a sapere dove trovare la DLL e i parametri necessari a caricare il servizio, visto che qui appare solo il nome? Il sistema fa riferimento a un’altra sezione del registro di configurazione:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

In questa sezione ciascuna chiave corrisponde ad un servizio; in quella chiamata WPDBusEnum si trovano diversi valori, tra cui quelli che contengono il percorso del file DLL da caricare (%SystemRoot%\system32\wpdbusenum.dll) e i parametri che ne controllano il comportamento e le dipendenze.

Queste chiavi di registro sono molto importanti perché rappresentano spesso un bersaglio per virus e malware: una delle varianti del famigerato Conficker si nasconde dentro un processo Svchost perfettamente legittimo, insieme ad altri servizi innocui e necessari al funzionamento del sistema. Molto spesso non è possibile arrestare un processo Svchost, e con esso tutti i servizi caricati tramite il relativo gruppo. In questo caso è necessario identificare il servizio del worm, trovarne il nome, cercarlo nel registro di configurazione in una delle istanze del processo Svchost e rimuoverlo manualmente dalla lista dei servizi caricati. Nel caso di Conficker il nome esteso del servizio è rappresentato da una coppia di parole inglesi in computer jargon, difficilmente identificabile senza una certa esperienza, mentre il nome vero e proprio del servizio sono solo lettere casuali e la descrizione manca del tutto.

Può essere utile incrociare tutte queste relazioni con il traffico di rete. Prendiamo per esempio un servizio innocuo: RDP, il desktop remoto. Sappiamo che il servizio ascolta sulla porta TCP/3389; verifichiamo il PID sotto il quale gira il processo utilizzando il comando

netstat -ao -p TCP | findstr :3389

Netstat visualizza informazioni sulle connessioni di rete TCP/IP, lo switch -ao visualizza tutte le connessioni in ascolto con le relative porte e numero di PID del processo, -p TCP restringe l’output al solo protocollo TCP, e findstr :3389 filtra solo la riga che ci interessa. Ecco l’output del comando:

L’informazione che ci serviva è il numero di PID, che è 1500. Guardando gli screenshot precedenti, si può verificare che il PID 1500 corrisponde a un Svchost che carica, tra gli altri, il servizio “TermService”, che il task manager descrive come “Servizi Desktop Remoto”.

Capire questi meccanismi e queste relazioni ci può aiutare molto a risolvere problemi particolarmente spinosi, perché arriva molto in profondità nel sistema e con un po’ di pazienza permette di ottenere risultati più efficaci di un generico tool di analisi e pulizia del sistema.

Uno dei pochi tool che fa bene questo tipo di lavoro è Process Explorer, con il quale potete ottenere le stesse informazioni che qui sopra sono state estratte solo con i normali strumenti di sistema. Il programma è stato creato da Mark Russnovich di Sysinternals, azienda acquisita da Microsoft nel 2006.