Condividi tramite

  • Articolo

[Archivio newsletter ^] [< Volume 2, Numero 4] [Volume 3, Numero 1 >]

Newsletter Systems Internals Volume 2, Numero 5

www.sysinternals.com
Copyright (c) 2000 Mark Russinovich

30 novembre 2000 - In questo numero:

  1. EDITORIALE

  2. NOVITÀ DI SYSINTERNALS

    • PsLoggedOn v1.2
    • PsShutdown v1.0
    • PsTools v1.1
    • BgInfo v1.1
    • Tokenmon v1.0
    • Filemon v4.32
    • Regmon v4.32
    • Inside Windows 2000, 3rd Edition
    • November and Winter Windows 2000 Magazine
    • Sysinternals in Microsoft
    • Licenze Sysinternals

  3. INFORMAZIONI SU INTERNALS

    • NFI
    • Chiavi del Registro di sistema nascoste in Win9x

  4. SVILUPPI FUTURI

    • Nuove chiamate di sistema di Whistler

SPONSOR: WINTERNALS SOFTWARE

La newsletter Sysinternals è sponsorizzata da Winternals Software, presente sul Web all'indirizzo www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K. I prodotti Winternals Software includono FAT32 per Windows NT 4.0, NTFSDOS Professional Edition (driver NTFS di lettura/scrittura per DOS) e Remote Recover.

Il comando netstat, fornito con tutte le versioni di Windows 9x e Windows NT/2000, mostra quali porte TCP/IP sono aperte nel sistema, ma non mostra per quali processi sono aperte. TCPView Pro, lo strumento di monitoraggio più recente di Winternals, non solo include uno strumento da riga di comando equivalente a netstat, Tcpvstat, che mostra per quale processo è aperta ogni porta, ma include un'interfaccia utente grafica che mostra le stesse informazioni oltre a una traccia in tempo reale dell'attività TCP/IP. La traccia in tempo reale rivela l'applicazione che effettua un accesso di rete, gli indirizzi IP locali e remoti dell'accesso con la risoluzione facoltativa dei nomi DNS, il tipo di accesso, l'esito positivo dell'accesso e la quantità di dati trasferiti. TCPView Pro costa solo $ 69. Scaricare la versione di valutazione completamente funzionante di TCPView Pro, valida 14 giorni, all'indirizzo www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Ciao a tutti.

Benvenuti nella newsletter di Sysinternals. La newsletter conta attualmente 28.000 abbonati.

Uno dei vantaggi del passaggio da Windows NT a Windows 2000 è l'affidabilità notevolmente migliorata. In diversi articoli ho illustrato i motivi dei miglioramenti, che sono principalmente il risultato di uno strumento denominato Driver Verifier. È possibile configurare Verifier, che viene avviato digitando "verifier" nella finestra di dialogo Esegui del menu Start, per controllare attentamente l'esecuzione di specifici driver di dispositivo, in cerca di violazioni di una delle diverse regole di programmazione dei driver. Verifier non si limita tuttavia a un monitoraggio passivo, ma va oltre un passo oltre il monitoraggio passivo, ma esacerba anche le potenziali condizioni di errore allocando, ad esempio, blocchi di memoria per il driver con are non valide e identificando specifici campi nelle strutture dei dati passate al driver. Per attività più complesse, è possibile impostare Verifier per simulare condizioni di memoria insufficiente per il driver.

Microsoft sfrutta Verifier tramite il programma di firma dei driver, che richiede che qualsiasi driver firmato digitalmente da Microsoft superi i test rigorosi di Driver Verifier. Quando viene installato un driver, la procedura guidata hardware verifica se è firmato. Se non lo è, invia un avviso o non installa il driver, a seconda delle impostazioni specificate nella finestra di dialogo Driver Signing Options, accessibile dalla pagina Hardware dell'applet Sistema nel Pannello di controllo.

Il fatto che il criterio predefinito di firma del driver preveda l'invio di avvisi agli utenti finali in caso di driver non firmati è sufficiente per spingere la maggior parte dei fornitori di hardware di rendere i loro driver affidabili e firmati. Tuttavia, i driver di dispositivo possono inserirsi nel sistema non rilevati dal criterio di firma. La presenza di firme viene controllata solo nei driver installati usando file INF (file di installazione dei driver con estensione inf). I programmi di installazione possono consentire di installare manualmente i driver usando direttamente apposite API o configurando manualmente le impostazioni del Registro di sistema del driver. Le applicazioni Sysinternals sono ottimi esempi in questo caso: Filemon, Regmon e altri strumenti Sysinternals che hanno componenti di driver installano manualmente i driver, motivo per cui non si ricevono avvisi se non sono firmati da Microsoft.

I driver non comunemente installati con i file INF includono antivirus, software di crittografia e software di masterizzazione di CD-ROM. Tuttavia, ciò non impedisce ai driver correlati all'hardware di inserirsi. Il driver Sysinternals CtrL2cap per Windows 2000 (www.sysinternals.com/ctrl2cap.htm) è un esempio di driver correlato all'hardware che viene installato in modo da ignorare i controlli della presenza di firme. Questa falla porta alla presenza nel sistema di driver non verificati, il che può compromettere la stabilità del sistema (io verifico tutti i driver Sysinternals con le impostazioni più elevate). Microsoft dovrebbe forzare il controllo della presenza di firme in tutti i driver, non solo in quelli installati con i file INF.

Perché faccio questa invettiva? Il mio software di masterizzazione di CD-ROM, che è il più diffuso di questo tipo di software sul mercato, ha un driver che arresterà in modo anomalo e riproducibile il mio sistema Windows 2000 SP1. Se configuro Driver Verifier per controllarlo, il sistema non termina neanche l'avvio prima che Verifier rileva la prima violazione del driver e arresta il sistema in modo anomalo. Il driver viene installato senza un file INF, per cui non vengo avvisato che non è firmato. Sono certo che se il criterio di Microsoft fosse più rigoroso, questo fornitore ci penserebbe due volte prima di distribuire un driver non firmato (con bug).

Invitiamo a inoltrare la newsletter ad amici che potrebbero essere interessati al contenuto.

Grazie.

- Mark

NOVITÀ DI SYSINTERNALS

PSLOGGEDON V1.2

Oltre al cambiamento ovvio del nome da LoggedOn a PsLoggedOn, questo strumento da riga di comando, che offre la possibilità di vedere chi è connesso in locale e tramite condivisioni di risorse nel sistema locale o remoto, include alcune nuove funzionalità. Il primo è l'opzione da riga di comando '-l', aggiunta in base al feedback degli utenti. Molti usano PsLoggedOn per verificare se un account è connesso in locale ai loro server. Potrebbero essere connessi alcuni utenti tramite condivisioni file, ad esempio, ma ciò non è rilevante per decidere quando un account può essere aggiornato o il server può essere amministrato da remoto.

La seconda nuova funzionalità di PsLoggedOn mostra non solo chi è connesso, ma anche la data/ora dell'accesso. PsLoggedOn ottiene gratuitamente gli orari di accesso dalle condivisioni di risorse quando usa un'API di Win32, NetSessionEnum, per enumerare gli accessi tramite condivisioni di risorse (il comando Net della riga di comando usa NetSessionEnum anche per enumerare le sessioni). Tuttavia, non c'è alcuna API di Win32 che indica chi è connesso a un sistema in locale, tanto meno in quale data/ora ha effettuato l'accesso.

Per determinare chi è connesso a un sistema in locale, PsLoggedOn enumera gli ID di sicurezza (SID) che si trovano snella chiave HKEY_USERS del Registro di sistema del computer. Quando qualcuno accede a un computer in locale, alla console o tramite un servizio, il suo profilo viene caricato nella chiave HKEY_USERS. Le applicazioni possono accedere alle impostazioni del Registro di sistema del profilo tramite la chiave HKEY_CURRENT_USER, perché il sistema considera tale chiave come collegamento simbolico al proprio profilo specifico in HKEY_USERS. PsLoggedOn può quindi riconoscere chi è connesso in locale convertendo i SID trovati nella chiave HKEY_USERS del computer nel nome utente corrispondente. PsLoggedOn usa RegConnectKey per connettersi al Registro di sistema di un computer remoto quando si indica di elencare gli utenti connessi a un sistema remoto.

L'identificazione della data/ora di accesso può essere eseguita in modo simile. Quando il processo WinLogon carica il profilo di un utente in HKEY_USERS dopo l'accesso, WinLogon crea una sottochiave volatile (non salvata nel profilo su disco) nel profilo denominata, giustamente, Volatile Environment. Il Registro di sistema archivia i timestamp dell'ultima modifica per le chiavi e, poiché il sistema non modifica le sottochiavi Volatile Environment dopo la relativa creazione, PsLoggedOn può determinare quando un utente ha effettuato l'accesso ottenendo il timestamp della sua sottochiave Volatile Environment.

Scaricare PsLoggedOn v1.2 con codice sorgente completo all'indirizzo
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

PsShutdown è utile se risulta necessario arrestare o riavviare un sistema Windows NT/2000 locale o remoto. PsShutdown è un clone dello strumento Shutdown Windows NT/2000 Resource Kit. Accetta gli stessi argomenti della riga di comando che consentono di specificare un ritardo prima dell'arresto, se riavviare o meno, un messaggio facoltativo da visualizzare a qualsiasi utente attualmente connesso al sistema e il nome del computer da arrestare o riavviare.

Scaricare PsShutdown v1.0 all'indirizzo www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

Si sarà probabilmente notato il numero crescente di strumenti Sysinternals che iniziano con il prefisso "Ps". Il primo è PsList, uno strumento da riga di comando che elenca le informazioni sui processi attivi nel sistema Windows NT/2000 locale o remoto. PsList si chiama così perché lo strumento UNIX standard da riga di comando che elenca le informazioni sui processi è denominato "ps". Lo strumento successivo con il prefisso è PsKill, una utilità da riga di comando che consente di terminare i processi in esecuzione nei sistemi Windows NT/2000 locali o remoto. PsKill ha il prefisso "Ps" perché è un compagno perfetto di PsList.

Nel corso del tempo ho sviluppato altri strumenti che hanno condiviso le stesse caratteristiche distintive di PsList e PsKill: sono basati sulla riga di comando e funzionano sui sistemi Windows NT/2000 locali o remoti. Ad esempio, ElogList consente di eseguire il dump del contenuto dei log eventi di un sistema e GetSid visualizza il SID di un computer o di un account specifico. Di recente ho deciso di collegare tutti questi strumenti tra loro assegnando a tutti il prefisso "Ps" e rendendoli disponibili per il download come singolo pacchetto denominato PsTools.

PsTools, che include PsList, PsKill oltre a PsLogList e PsGetSid rinominati, è costituito da un totale di sette strumenti. Uno strumento Sysinternals con il prefisso "Ps" si riconosce automaticamente come strumento da riga di comando che funziona in locale e in remoto.

Scaricare PsTools v1.1 all'indirizzo www.sysinternals.com/pstools.htm.

BGINFO V1.1

In seguito a un notevole feedback degli utenti, Bryce ha aggiornato BgInfo, una utilità che imposta lo sfondo del desktop per visualizzare informazioni personalizzabili sulla configurazione di un sistema. Per impostazione predefinita, BgInfo aspetta 10 secondi prima di applicare le impostazioni specificate nella finestra di dialogo, ma una nuova opzione da riga di comando, /timer, consente di cambiare o eliminare completamente il conto alla rovescia. Ciò rende più pratico includere BgInfo in uno script di accesso o come collegamento nella cartella di avvio di un profilo.

La versione 1.1 include altre nuove funzionalità, ad esempio la possibilità di visualizzare testo arbitrario definito dall'utente e altre categorie di informazioni predefinite. Anche la bitmap desktop che BgInfo v1.1 crea è in genere più piccola, riducendo al minimo il footprint di memoria del desktop di BgInfo.

Scaricare BgInfo v1.1 all'indirizzo www.sysinternals.com/misc.htm.

TOKENMON V1.0

Tokenmon è l'ultimo componente aggiunto alla vasta gamma di strumenti di monitoraggio che è possibile scaricare da Sysinternals. Tokenmon, che condivide la stessa interfaccia utente di altri strumenti simili come Regmon e Filemon, monitora attività significative correlate alla sicurezza in un sistema Windows NT/2000. Che cos'è esattamente un'attività "significativa" correlata alla sicurezza? Alla base della sicurezza di Windows NT/2000 c'è l'oggetto token, una struttura di dati che contiene il SID di un account, i SID di gruppi e i privilegi. Ogni volta che un processo tenta di accedere a un oggetto protetto, Security Reference Monitor usa i SID nel relativo token come parte della convalida dell'accesso. Se un processo tenta di eseguire un'operazione con restrizioni, ad esempio un riavvio del sistema, il sistema verifica la presenza del privilegio appropriato nel token del processo.

Una delle funzionalità potenti (e brevettate) del modello di sicurezza Windows NT/2000 è la rappresentazione. La rappresentazione consente a un thread di ignorare temporaneamente l'identità basata su processo e di adottare un'identità alternativa tramite l'uso di un token di rappresentazione. Le applicazioni server sfruttano la rappresentazione quando accedono alle risorse per conto di un client, quando adottano l'identità del client per la durata dell'accesso.

Tokenmon installa hook di chiamata di sistema allo stesso modo di Regmon per le API del Registro di sistema, per monitorare la creazione e l'eliminazione di token, l'abilitazione e la disabilitazione dei privilegi e la rappresentazione. Tokenmon usa anche hook di creazione di processi forniti dal kernel NT/2000 per monitorare la creazione e l'eliminazione dei processi e altre API per determinare quando un utente accede e quando si disconnette.

Il codice sorgente completo di Tokenmon è pubblicato e vale la pena discutere alcune delle tecniche interessanti dimostrate dal codice. Tokenmon rileva un evento di accesso tramite hook alla chiamata di sistema NtCreateToken, ovvero quella usata dai broker di accesso come WinLogon per creare un token iniziale per il primo processo di una nuova sessione di accesso. I processi creati dal primo processo ereditano una copia del primo token. Per rilevare la disconnessione, Tokenmon si registra alla notifica di disconnessione tramite la funzione SeRegisterLogonSessionTerminatedRoutine in modalità kernel, un'API che esiste a vantaggio dei driver del file system, denominati redirector di rete, che memorizzano nella cache i dati delle sessioni di accesso e li ripuliscono quando un utente si disconnette. I redirector di rete implementano il lato client delle connessioni client/server di condivisione file.

Un'altra implementazione interessante di Tokenmon è il modo in cui Tokenmon crea hook per le API che monitora. Alcune API con gli hook di Tokenmon non vengono esportate per l'uso da parte dei driver di dispositivi, ma vengono esportate nella libreria NTDLL.DLL in modalità utente per l'uso da parte delle applicazioni che usano gli equivalenti Win32. Tutte le API del Registro di sistema con hook di Regmon vengono esportate in modalità kernel, rendendo possibile per il driver di dispositivo Regmon di ottenere i numeri di chiamate di sistema e di associare la tabella delle chiamate di sistema in modo appropriato. Per le API non esportate per l'uso da parte dei driver, l'interfaccia utente grafica di Tokenmon deve ottenere i numeri delle chiamate usando le esportazioni in NTDLL.DLL e quindi passarli al driver in modo che possa creare hook per la tabella di chiamate di sistema. Tokenmon dimostra quindi come creare hook per le chiamate di sistema che non vengono esportate in modalità kernel.

Scaricare Tokenmon v1.0 con codice sorgente completo all'indirizzo www.sysinternals.com/tokenmon.htm.

FILEMON V4.32

Nell'ultimo aggiornamento di Filemon sono state introdotte funzionalità di filtro più intuitive e complete, la visualizzazione di nomi di percorsi UNC completi per l'accesso ai file di rete di Windows 9x/Me e la visualizzazione dei nomi dei file di metadati NTFS.

Le versioni precedenti di Filemon richiedevano di immettere filtri con caratteri jolly obbligatori. Ad esempio, se si volevano monitorare gli accessi alla directory Temp nell'unità C:, era necessario immettere un filtro simile al seguente: "c:\temp\*". Con la nuova sintassi di filtro i caratteri jolly sono facoltativi, per cui anche se il filtro di esempio funzionerebbe, "c:\temp" otterrebbe lo stesso effetto. Inoltre, Filemon applica ora i filtri immessi per tutti i campi nella visualizzazione, inclusi il nome del processo, il tipo di richiesta, il percorso e la colonna "other". Questa flessibilità consente di controllare la presenza di specifici tipi di richieste o di richieste con specifici dati nella colonna "other", il che prima non era possibile.

Gli utenti di Filemon nei sistemi Windows 9x/Me ora vedranno i nomi dei percorsi di visualizzazione con la sintassi UNC completa quando accedono a risorse remote. Filemon in precedenza non visualizzava il nome del server o della condivisione per tali accessi, generando nomi di percorso incompleti.

Infine, se è stato usato Filemon in Windows NT/2000 si sarà sicuramente visto il testo "DASD" nella colonna dei percorsi per molti accessi ("DASD" è l'acronimo di "Direct Access Storage Device", un'espressione usata da Microsoft per descrivere gli accessi a un volume che bypassano le strutture del file system). Per la maggior parte delle attività sui volumi NTFS, DASD fa ormai parte del passato. Verranno invece visualizzati i nomi dei file di metadati NTFS letti e scritti. Ad esempio, un aggiornamento di un record MFT in precedenza avrebbe generato una riga di output DASD, mentre ora lo si vedrà come accesso a "$Mft", il nome del file di metadati interno di MFT.

Perché Filemon non ha mostrato i nomi dei file di metadati in precedenza e come ottiene ora questi nomi? Gli oggetti file che rappresentano i file di metadati NTFS non archiviano un nome file, pertanto Filemon non può estrarre il nome dall'oggetto file. Neanche il metodo alternativo di Filemon per ottenere il nome di un file, ovvero l'esecuzione di query sul driver del file system, funziona per i file di metadati NTFS. Anche se NTFS risponde con i nomi dei file di metadati, NTFS su NT 4 causa arresti anomali casuali e NTFS in Win2k si blocca occasionalmente quando risponde a tali query.

Filemon deve quindi ricorrere a un trucco per ottenere i nomi dei file di metadati. Quando vede una richiesta indirizzata a un oggetto file in un volume NTFS senza nome, invia una query NTFS per trovare l'indice del file. Si tratta dello stesso indice restituito dalla funzione GetFileInformationByHandle di Win32 e per i file nei volumi NTFS corrisponde all'indice MFT del file. Le prime 16 voci di MFT sono riservate per file di metadati specifici, quindi dato un indice in tale intervallo, Filemon cerca semplicemente il nome del file di metadati nella propria tabella.

Purtroppo, verrà ancora visualizzato il testo DASD per gli accessi a metadati di directory e FAT (File Allocation Table) nei volumi FAT, perché FAT non archivia i nomi dei file di metadati di directory o la tabella FAT. Si resterà sorpresi dalla frequenza degli accessi al file di log NTFS ($LogFile). Per inciso, NTFS su Whistler archivia i nomi dei file di metadati, quindi il trucco non è necessario su Whistler.

Il miglioramento finale di Filemon consente a Filemon di visualizzare i timestamp dell'ora del giorno con risoluzione in millisecondi. Questo supporto richiedeva hack nel driver Filemon di Windows 9x/Me a causa di bug in una funzione di temporizzazione nel kernel Windows 9x/Me. Per altre informazioni, vedere il codice sorgente.

Scaricare Filemon v4.32 con codice sorgente all'indirizzo www.sysinternals.com/filemon.htm.

REGMON V4.32

Le modifiche di Regmon non sono importanti come quelle di Filemon, ma Regmon ora supporta la stessa sintassi di filtro più intuitiva di Filemon e, analogamente a Filemon, applica i filtri a tutti i campi. Può anche visualizzare la risoluzione in millisecondi sui timestamp.

Chi ha iniziato a usare Whistler (il successore di Windows 2000) Beta 1 potrebbe aver notato che le versioni precedenti di Regmon arrestano Whistler in modo anomalo all'avvio. Il motivo è che Microsoft ha inserito la tabella di chiamate di sistema, modificata da Regmon per inserire i relativi hook, nella memoria protetta da scrittura. Regmon v4.32 aggira questo problema usando una tecnica per cui non ho fornito il codice sorgente su richiesta di Microsoft, perché la tecnica potrebbe interrompere la versione finale di Whistler e Microsoft sta esaminando soluzioni per supportare l'hook delle chiamate di sistema. Windows NT non è stato progettato per supportare l'hook delle chiamate di sistema, che è qualcosa che abbiamo introdotto inizialmente con la prima versione di Regmon a metà del 1996.

Ecco un suggerimento non documentato per Filemon/Regmon. Spesso ricevo email in cui mi chiedono come eseguire Regmon o Filemon da un account non amministrativo in Windows NT/2000. In molti casi una determinata applicazione funziona correttamente quando viene eseguita dall'account amministratore, ma non da quello di un utente senza privilegi, dove Regmon e Filemon sarebbero utili per determinare perché l'applicazione genera errori (solitamente si tratta di un problema correlato alle impostazioni di sicurezza in un file o in una chiave del Registro di sistema). Tuttavia, l'esecuzione di Regmon e Filemon da un account senza privilegi avrà esito negativo perché sia Filemon che Regmon installano i driver di dispositivo, il che richiede privilegi di amministratore.

Esiste però un trucco che consente di aggirare questo problema: se si accede come amministratore e si avvia Filemon o Regmon, successivamente sarà possibile eseguirli da account senza privilegi. Il motivo è che Filemon e Regmon installano un driver alla prima esecuzione e nelle esecuzioni seguenti accedono al driver già caricato. Poiché non implemento alcuna sicurezza nel driver, un utente senza privilegi può eseguire gli strumenti dopo il caricamento del driver. Problema di sicurezza? Sì, ma Filemon e Regmon sono strumenti progettati per la risoluzione dei problemi, per cui io e le persone che chiedono di eseguire le utilità da account senza privilegi consideriamo questo effetto come funzionalità.

Scaricare Regmon v4.32 con codice sorgente completo all'indirizzo www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

Una delle applicazioni per cui ho ricevuto la maggior quantità di feedback è, cosa alquanto sorprendente, DebugView. Questa nuova versione include alcuni miglioramenti significativi che rispondono a molte richieste di caratteristiche e funzionalità ricevute e che rendono DebugView più potente che mai.

In particolare, DebugView supporta ora fino a cinque filtri di evidenziazione diversi, ognuno con i propri colori personalizzabili. È quindi possibile inserire contemporaneamente parole chiave diverse nell'output di debug e distinguerle facilmente. Inoltre, DebugView implementa la stessa nuova sintassi di filtro di Filemon e Regmon, rendendo facoltativi i caratteri jolly per la corrispondenza delle sottostringhe.

Uno dei reclami ricevuti sulle versioni precedenti di DebugView è che, anche se si vuole solo acquisire l'output di debug Win32, sono ancora necessari privilegi amministrativi per eseguire DebugView, perché DebugView non verrebbe eseguito se non fosse in grado di installare il proprio driver di dispositivo. Questa nuova versione viene eseguita anche da account senza privilegi speciali. Se non riesce a installare o accedere al driver, disabilita semplicemente le voci di menu correlate all'acquisizione in modalità kernel.

Due funzionalità che semplificano l'acquisizione automatica dell'output di DebugView quando si esegue l'accesso sono l'opzione di riduzione a icona e il supporto per le opzioni della riga di comando. Usando le opzioni della riga di comando, è possibile avviare DebugView dalla barra delle applicazioni e registrare l'output che acquisisce in un file. Dopo aver avviato DebugView, è possibile usare un'opzione di menu per alternare il comportamento del pulsante tra riduzione a icona normale e riduzione a icona sulla barra delle applicazioni.

Per gli utenti che eseguono DebugView in sessioni remote nei servizi terminal di Windows 2000, DebugView acquisisce ora l'output di Win32 generato dalle applicazioni in esecuzione nella sessione remota e, facoltativamente, dalla sessione della console. Questa funzionalità è utile per eseguire il debug di server COM e servizi Win32 da remoto, perché questi tipi di programmi vengono eseguiti nella sessione della console.

Infine, DebugView ora funziona su Whistler Beta 1, con il supporto per l'acquisizione dell'output dalle diverse nuove varianti di Whistler nella funzione DbgPrint in modalità kernel.

Scaricare DebugView v4.02 all'indirizzo www.sysinternals.com/dbgview.htm.

INSIDE WINDOWS 2000, 3RD EDITION

Il libro ufficiale sui componenti interni di Windows 2000 è ora disponibile! Questa edizione, di cui sono coautori David Solomon (www.solsem.com) e Mark Russinovich, è più ampia del 40% rispetto alla precedente, con una nuova trattazione di reti, plug-and-play, gestione dell'alimentazione, servizi, Registro di sistema, WMI, avvio e arresto e archiviazione. Include anche un CD con diversi strumenti avanzati, non disponibili altrove, per l'analisi dei componenti interni di Windows 2000.

Uno degli strumenti che ho scritto appositamente per il libro è LiveKd, un programma che consente di eseguire entrambi i debugger del kernel Microsoft, i386kd e WinDbg, in un sistema live come se si stesse esaminando un dump di arresto anomalo. Molti degli esperimenti presentati nel libro funzionano su un sistema live quando vengono eseguiti con LiveKd. LiveKd funziona installando un driver di filtro del file system che presenta la memoria fisica del computer al debugger Microsoft come se fosse un file di dump di arresto anomalo. LiveKd crea un file di pseudo dump di lunghezza pari a 0 e quando il debugger legge dal file, LiveKd restituisce i dati dalla memoria fisica. Consultare la pagina di errata corrige e aggiornamenti del libro per trovare una patch di LiveKd che corregge un'incompatibilità tra LiveKd v1.0 e diversi antivirus all'accesso.

È possibile consultare il sommario del libro e ordinarlo ora all'indirizzo www.sysinternals.com/insidew2k.htm.

NOVEMBER AND WINTER WINDOWS 2000 MAGAZINE

Per sapere cosa è cambiato esattamente tra NTFS v4 e NTFS v5, consultare la mia serie in due parti in November and Winter Windows 2000 Magazine. La parte 1 descrive i reparse point, i punti di giunzione di directory, i punti di montaggio dei volumi, il supporto delle quote e le impostazioni di sicurezza consolidate. La parte 2 conclude con un'analisi dettagliata di crittografia, flussi, rilevamento dei collegamenti distribuiti e journal delle modifiche. Entrambi gli articoli consentono di approfondire le operazioni eseguite da altri, presentando le modifiche su disco e il comportamento interno di queste nuove funzionalità.

Una cosa di cui non parlo è che NTFS per Windows NT 4 non è in realtà una versione

I collegamenti a tutte le nostre pubblicazioni sono disponibili all'indirizzo www.sysinternals.com/publ.htm.

SYSINTERNALS IN WWW.MICROSOFT.COM

Dall'ultima newsletter, diversi nuovi articoli della Microsoft Knowledge Base (KB) citano Sysinternals e ho anche scovato alcuni articoli meno recenti della Knowledge Base che fanno riferimento a Sysinternals.

  • Q260513 PRB: Durante l'installazione di prodotti di Visual Studio si verifica un errore
    http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
    Questo articolo consiglia ai lettori di usare Filemon e Regmon per risolvere i problemi di installazione di Microsoft Visual Studio.

  • Q202258 XADM: Il sistema non riesce a trovare il percorso specificato - ID: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    Microsoft illustra in realtà agli utenti l'uso di Filemon per risolvere i problemi di aggiornamento del Service Pack di Exchange 5.0, con una riga di output di esempio di Filemon e raccomandazioni sulla configurazione dei filtri.

  • Q269383 PRB: Quando vengono visualizzati i riferimenti a VB/VBA, si riceve il messaggio 'Errore durante l'accesso al Registro di sistema'
    http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
    Regmon viene citato in questo articolo, che illustra come usarlo per determinare perché la finestra di dialogo di riferimenti dell'IDE di Visual Basic segnala di non riuscire ad accedere a una chiave del Registro di sistema come conseguenza di un bug in Seagate Crystal Reports che applica autorizzazioni non corrette a diverse chiavi.

  • Q269251 BUG: L'automazione di Windows Installer potrebbe bloccarsi durante l'enumerazione dei prodotti
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Regmon viene evidenziato di nuovo qui, dove viene usato per rivelare un bug dell'automazione di Windows Installer.

  • Q276525 Il computer potrebbe smettere di rispondere durante il monitoraggio di handle aperti
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    NtHandle è responsabile di rivelare un bug in Windows NT 4 SP6a, per cui il kernel si blocca in determinate condizioni quando si usa NtHandle. Microsoft ha collaborato con me per risolvere il problema e ha rilasciato un hotfix. Se il sistema NT 4 si blocca quando si usa NtHandle, è consigliabile seguire i collegamento a questo articolo.

  • Q160660 Ntregmon.exe causa l'arresto 0x0000001E con il nuovo Service Pack
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Quest'ultimo errore è vecchio ma ancora valido. La prima versione di Regmon usava numeri di chiamate di sistema hardcoded per applicare patch alla tabella del servizio di sistema e creare hook con le API del Registro di sistema. Poiché i numeri delle chiamate di sistema a volte cambiano da un Service Pack all'altro, questa tecnica è piuttosto fragile, e non avevo scritto codice di protezione in previsione di questo aspetto (contro il consiglio di Andrew Schulman, che temeva che Regmon avrebbe generato errori). Come previsto, nell'SP3 sono state introdotte alcune nuove chiamate di sistema e Regmon avrebbe arrestato in modo anomalo il sistema creando hook alle chiamate non corrette. Anche se questo problema ha infastidito diverse persone, è anche stato il motivo per cui ho ottenuto il mio articolo personale nella KB.

LICENZE SYSINTERNALS

Anche se il software scaricato da Sysinternals è freeware, vale a dire che è possibile usarlo senza pagare una tariffa, non si è autorizzati a ridistribuirlo o a derivare i prodotti distribuiti dal codice sorgente Sysinternals. Ad esempio, se si lavora in un'azienda in cui più utenti trovano utili specifici strumenti Sysinternals, non è possibile pubblicare gli strumenti in una condivisione interna o in un sito Web. Inserire invece un collegamento nel sito alla home page di ogni strumento in Sysinternals. Ciò consente anche di assicurarsi che i colleghi scarichino sempre le versioni più recenti.

Se si vogliono ridistribuire gli strumenti Sysinternals internamente, con un prodotto commerciale o su un CD in shareware, oppure se si vuole basare un prodotto commerciale o un programma ridistribuibile su codice sorgente Sysinternals, inviare un'email con i dettagli dell'uso desiderato a licensing@.

INFORMAZIONI SU INTERNALS

NFI

In una delle newsletter precedenti ho rivelato l'esistenza dello strumento DiskEdit che Microsoft ha inavvertitamente distribuito sul CD di NT 4 SP4. DiskEdit è un visualizzatore di strutture del file system molto potente, anche se peculiare, che è possibile usare per esaminare NTFS e FAT (anche se è il supporto NTFS che è interessante) sulle strutture di dati su disco. Se il CD di NT 4 SP 4 non è disponibile e si è interessati a esplorare le strutture NTFS su disco, esiste comunque una soluzione. Microsoft ha rilasciato uno strumento gratuito denominato NFI (NTFS Information) che riconosce e può eseguire il dump delle strutture interne dei volumi NTFS. Anche se l'output non è dettagliato come quello di DiskEdit, è interessante e rivelatore.

È possibile scaricare NFI come parte degli strumenti di supporto OEM all'indirizzo http://support.microsoft.com/support/kb/articles/q253/0/66.asp. L'esecuzione di NFI con un nome file esegue il dump del record MFT NTFS per tale file. L'esempio seguente mostra il dump di NFI del record MFT per il file di metadati $Quota, un file esistente solo se è abilitata la gestione delle quote in un volume:

C:\nfi c:\$extend\$quota
File 24
\$Extend\$Quota
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $O (resident)
$INDEX_ROOT $Q (resident)

L'output mostra che il file occupa la 24a voce in MFT (il relativo indice è 24) e che contiene quattro attributi, tra cui informazioni standard, nome file e due radici dell'indice (e l'indice è essenzialmente un elenco ordinato di voci, ad esempio una directory). Descrivo come NTFS usa gli indici $Quota nella mia ultima serie di Windows 2000 Magazine su NTFS v5.

Per eseguire il dump di tutti i file in un volume, specificare la lettera di unità nella riga di comando di NFI senza un nome di file, ad esempio nfi c:. Verrà visualizzato un elenco di ogni voce di MFT, inclusi tutti i file di metadati.

NFI offre altre funzionalità, come la possibilità di convertire un numero di settore nel file in cui risiede. Si vuole sapere in quale file si trova il settore 2345 nell'unità C:? Usare il comando nfi c: 2345. Si noti che questa procedura non riesce nei volumi RAID software, come set di volumi e set di striping. NFI funziona sia su NT 4 che su Windows 2000.

CHIAVI DEL REGISTRO DI SISTEMA NASCOSTE IN WIN9X

Due numeri fa avevo detto che avrei parlato delle chiavi del Registro di sistema nascoste in Win9x nella newsletter seguente, e mi è stato ricordato che lo avevo dimenticato. Quindi questo mese affronterò questo argomento.

Diversi anni fa ho scoperto un modo per creare chiavi del Registro di sistema nascoste in Windows NT. Per nascoste, intendo che, anche se è possibile vedere le chiavi a cui accede l'applicazione che le crea con Regmon, non è possibile scrivere un programma di Win32 per esaminare i valori delle chiavi, né è possibile esaminare le chiavi con gli editor del Registro di sistema Regedit o Regedt32. Le chiavi nascoste sono utili per archiviare i dati che non si desidera che gli utenti finali possano modificare, ad esempio la data di timeout di un prodotto di valutazione.

Il trucco per creare una chiave nascosta del Registro di sistema è nato quando ho capito che l'API nativa di NT, ossia l'interfaccia delle chiamate di sistema su cui si basa l'API di Win32, richiede che le chiavi del Registro di sistema vengano specificate come stringhe Unicode conteggiate. Una stringa Unicode conteggiata è quella la cui lunghezza è indicata da un campo di lunghezza, non dalla presenza di un carattere di terminazione Null. Usando l'API nativa è quindi possibile creare chiavi del Registro di sistema contenenti un carattere Null, ad esempio "test\0test". Poiché l'API delle chiavi del Registro di sistema dell'API di Win32 si basa su stringhe con terminazione Null, non è possibile aprire una chiave del Registro di sistema che contiene un carattere di terminazione Null usando l'API di Win32. Se si prova a passare il nome della chiave di esempio precedente a RegOpenKey o a RegCreateKey viene considerata come "test", con la stringa troncata in corrispondenza del carattere Null. Poiché tutti gli editor del Registro di sistema esistenti, inclusi quelli in bundle con Windows NT e Windows 2000, usano l'API di Win32, un'applicazione che usa l'API nativa per creare nomi incorporati con caratteri Null rende effettivamente nascoste le chiavi.

Questo metodo funziona con Windows NT, e con Windows 9x? Non pensavo che ci fosse un modo per rendere le chiavi del Registro di sistema nascoste in Windows 9x finché qualcuno non mi ha inviato tramite email un file di log di Regmon che mostra chiavi di accesso a Internet Explorer (IE) che non compaiono in Regedit. Per verificarlo, avviare Regmon e impostare il filtro di inclusione "policydata". Avviare quindi Internet Explorer (funziona per tutte le versioni di IE 4 e IE 5) e visitare un sito Web. Se non viene visualizzato alcun output in Regmon, passare alla finestra di dialogo di configurazione delle opzioni di IE e assicurarsi che Contenuto verificato sia abilitato.

Se Contenuto verificato è abilitato, o è stato abilitato nel sistema, verranno visualizzati gli accessi alla chiave HKLM\PolicyData e alle relative sottochiavi. Tuttavia, non si troverà una chiave PolicyData in HKEY_LOCAL_MACHINE quando si cerca in Regedit. Cercare di capire cosa succede.

La risposta è che IE sta caricando dinamicamente un hive del Registro di sistema usando l'API RegLoadKey di Win32, sta leggendo i valori necessari e quindi sta scaricando l'hive con RegUnloadKey. L'hive è denominato C:\Winows\System\Ratings.pol: il file è nascosto e di sola lettura, ma è possibile visualizzarlo digitando attrib –r –h c:\windows\system\ratings.pol.

Le tracce visualizzate in Regmon mostrano le informazioni cercate da Contenuto verificato nell'hive. Per esplorare il contenuto, scaricare la mia utilità Regload da www.sysinternals.com/regload.zip ed eseguirla con la sintassi seguente: regload test c:\windows\system\ratings.pol. Aprire quindi Regedit e passare a HKLM\test. I valori disponibili corrispondono alle impostazioni specificate in Contenuto verificato e sono correlati al file di configurazione specificato nel valore Users\FileName0 dell'hive. Il valore in genere punta a C:\Windows\System\RSACi.rat, il file di valutazioni definito dall'Internet Content Rating Association. Per inciso, si potrebbe vedere un valore con il nome divertente "PleaseMom" nelle impostazioni del Registro di sistema di Contenuto verificato, ad esempio in HKLM\Test\Users\Default. Questo valore deriva dalla casella di controllo "Il supervisore può inserire una password per consentire la visualizzazione di siti con restrizioni" nella pagina Generale della finestra di dialogo di impostazioni di Contenuto verificato.

Il motivo per cui Microsoft offusca l'esistenza di questi valori del Registro di sistema dovrebbe essere ovvio. Tuttavia, c'è un punto debole piuttosto grave nella progettazione. Quando si abilita Contenuto verificato, è necessario specificare una password che protegge la finestra di dialogo delle relative impostazioni. Questa password viene archiviata in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key. Eliminare tale valore ed è immediatamente possibile accedere alle impostazioni di Contenuto verificato senza immettere una password. Ora, se gli sviluppatori di IE si sono impegnati per offuscare le impostazioni di Contenuto Verificato, perché hanno lasciato aperta questa porta posteriore? Tipica progettazione della sicurezza di Microsoft, immagino. A proposito, per scaricare la chiave caricata con Regload, basta digitare regload test.

SVILUPPI FUTURI

NUOVE CHIAMATE DI SISTEMA DI WHISTLER

Whistler è un'evoluzione incrementale del sistema operativo Windows 2000 il cui obiettivo è aumentare l'affidabilità e semplificare la migrazione degli utenti dai sistemi operativi Windows 9x. Tuttavia, include alcune modifiche del kernel. Le più visibili sono le nuove chiamate di sistema e le funzioni del kernel esportate (disponibili per l'uso da parte dei driver di dispositivo). La prossima volta, fornirò un'anteprima di queste nuove API del kernel.

Grazie per aver letto la newsletter di Sysinternals.

Data di pubblicazione: giovedì 30 novembre 2000 19:05 da ottoh

[Archivio newsletter ^] [< Volume 2, Numero 4] [Volume 3, Numero 1 >]