Partilhar via

  • Artigo

[Arquivo de boletins informativos ^] <[ Volume 2, Número 4] [Volume 3, Número 1 >]

The Systems Internals Newsletter Volume 2, Número 5

www.sysinternals.com
Direitos de autor (c) 2000 Mark Russinovich

30 de novembro de 2000 - Nesta edição:

  1. EDITORIAL

  2. O QUE HÁ DE NOVO NA SYSINTERNALS

    • PsLoggedOn v1.2
    • PsShutdown v1.0
    • PsTools v1.1
    • BgInfo v1,1
    • Tokenmon v1.0
    • Filemon v4.32
    • Regmon v4,32
    • Dentro do Windows 2000, 3ª Ed.
    • Novembro e inverno Windows 2000 Magazine
    • Sysinternals na empresa Microsoft
    • Licenciamento Sysinternals

  3. INFORMAÇÃO INTERNA

    • IFN
    • Chaves de registo Win9x ocultas

  4. O QUE VEM POR AÍ

    • Novas chamadas do sistema Whistler

PATROCINADOR: WINTERNALS SOFTWARE

A Newsletter Sysinternals é patrocinada pela Winternals Software, na Web em www.winternals.com. A Winternals Software é a principal desenvolvedora e fornecedora de ferramentas de sistemas avançados para Windows NT/2K. Os produtos Winternals Software incluem FAT32 para Windows NT 4.0, NTFSDOS Professional Edition (um driver NTFS de leitura/gravação para DOS) e Remote Recover.

O comando netstat, que vem com todas as versões do Windows 9x e Windows NT/2000, mostra quais portas TCP/IP estão abertas no seu sistema, no entanto, não mostra qual processo tem a porta aberta. O TCPView Pro, a mais recente ferramenta de monitoramento da Winternals, não só vem com uma ferramenta de linha de comando equivalente ao netstat, Tcpvstat, que mostra qual processo tem cada porta aberta, mas inclui uma GUI que mostra as mesmas informações e um rastreamento em tempo real da atividade do TCP/IP. O rastreamento em tempo real revela o aplicativo que faz um acesso à rede, os endereços IP locais e remotos do acesso com resolução de nome DNS opcional, o tipo de acesso, o sucesso do acesso e a quantidade de dados transferidos. TCPView Pro é apenas $69. Faça o download da versão de avaliação de 14 dias totalmente funcional do TCPView Pro hoje em www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Olá a todos,

Bem-vindo à newsletter da Sysinternals. A newsletter conta atualmente com 28.000 assinantes.

Um dos benefícios de mudar do Windows NT para o Windows 2000 é a confiabilidade muito melhorada. Eu escrevi sobre as razões para as melhorias em vários artigos, e eles são principalmente o resultado de uma ferramenta chamada Verificador de Driver. Você pode configurar o Verificador, que você inicia digitando "verificador" na caixa de diálogo Executar do menu Iniciar, para observar de perto a execução de drivers de dispositivo específicos, procurando violação de qualquer uma das várias regras de programação de driver. No entanto, o verificador vai um passo além do monitoramento passivo – também exacerba o potencial; condições de erro, por exemplo, alocando blocos de memória para o driver que estão sobrecarregados com regiões inválidas e zerando campos específicos em estruturas de dados que são passadas para o driver. Se você realmente quiser ficar difícil, você pode fazer com que o verificador simule condições de pouca memória para o driver.

A Microsoft aproveita o Verificador por meio de seu programa de assinatura de driver, que exige que qualquer driver assinado digitalmente pela Microsoft passe por testes rigorosos do Verificador de Driver. Quando um driver é instalado, o assistente de hardware verifica se o driver está assinado. Se não estiver, ele avisará ou não instalará o driver, dependendo das configurações inseridas na caixa de diálogo Opções de assinatura do driver, que pode ser acessada na página Hardware do miniaplicativo Sistema no Painel de Controle.

O fato de que a política de assinatura de driver padrão avisa os usuários finais sobre drivers não assinados é suficiente para fazer com que a maioria dos fornecedores de hardware se dê ao trabalho de tornar seus drivers robustos e assiná-los. No entanto, os drivers de dispositivo podem entrar sorrateiramente no seu sistema sem serem detetados pela política de assinatura de driver. Somente os drivers instalados usando arquivos INF (arquivos de instalação de driver que terminam na extensão .inf) são verificados quanto a assinaturas. Os aplicativos de instalação podem instalar drivers manualmente usando APIs de instalação diretamente ou configurando manualmente as configurações do Registro do driver. Os aplicativos Sysinternals são ótimos exemplos disso: Filemon, Regmon e outras ferramentas Sysinternals que têm componentes de driver instalam seus drivers manualmente, que é a razão pela qual você não é avisado de que eles não são assinados pela Microsoft.

Os drivers que não são normalmente instalados com arquivos INF incluem scanners de vírus, software de criptografia e software de gravação de CD-ROM. No entanto, isso não impede que os drivers relacionados ao hardware escapem. O driver Sysinternals Ctrl2cap para Windows 2000 (www.sysinternals.com/ctrl2cap.htm é um exemplo de um driver relacionado a hardware que é instalado de uma maneira que ignora as verificações de assinatura de driver. Esta lacuna leva à presença de drivers no seu sistema que não foram verificados, o que pode comprometer a estabilidade do sistema (eu verifico todos os drivers Sysinternals nas configurações mais altas). A Microsoft deve forçar todos os drivers, não apenas aqueles que instalam com arquivos INF, a passar pela verificação de assinatura.

Por que estou neste discurso? Meu software de gravação de CD-ROM, que é o mais popular desse tipo de software no mercado, tem um driver que irá reprodutivelmente travar meu sistema Windows 2000 SP1. Se eu configurar o Verificador de Driver para verificá-lo, o sistema nem sequer termina a inicialização antes que o Verificador detete a primeira violação do driver e trave o sistema. O driver instalado sem um arquivo INF, então eu não fui avisado que ele não estava assinado. Garanto que, se a política da Microsoft fosse mais rigorosa, esse fornecedor pensaria duas vezes antes de enviar um driver não assinado (e com bugs).

Por favor, passe a newsletter para amigos que você acha que podem estar interessados em seu conteúdo.

Obrigado!

-Marcar

O QUE HÁ DE NOVO NA SYSINTERNALS

PSLOGGEDON V1.2

Além de uma óbvia mudança de nome de LoggedOn para PsLoggedOn, esta ferramenta de linha de comando, que tem a capacidade de mostrar quem está conectado localmente e por meio de compartilhamentos de recursos no sistema local ou remoto, tem alguns novos recursos. O primeiro é a opção de linha de comando '-l' que resultou do feedback do usuário. Muitas pessoas usam o PsLoggedOn para ver se alguma conta está conectada localmente em seus servidores. Pode haver usuários conectados por meio de compartilhamentos de arquivos, por exemplo, mas isso não é relevante ao tomar uma decisão sobre quando uma conta pode ser atualizada ou o servidor pode ser administrado remotamente.

O segundo novo recurso do PsLoggedOn mostra não apenas quem está conectado, mas o momento em que o logon ocorreu. PsLoggedOn obtém tempos de logon para logons de compartilhamentos de recursos gratuitamente quando usa uma API do Win32, NetSessionEnum, para enumerar logons de compartilhamento de recursos (o comando Net da linha de comando também usa NetSessionEnum para enumerar sessões). No entanto, não há nenhuma API do Win32 que diga quem está conectado a um sistema localmente, muito menos em que momento eles fizeram logon.

Para determinar quem fez logon em um sistema localmente, PsLoggedOn enumera as IDs de segurança (SIDs) localizadas sob a chave do Registro de HKEY_USERS um computador. Quando alguém faz logon em um computador localmente, seja no console ou por meio de um serviço, seu perfil é carregado na HKEY_USERS chave. Os aplicativos podem acessar as configurações do Registro de seu perfil por meio da HKEY_CURRENT_USER chave porque o sistema trata essa chave como um link simbólico para seu perfil específico em HKEY_USERS. Assim, o PsLoggedOn pode saber quem está conectado localmente traduzindo os SIDs que encontra na chave de um computador para o nome de HKEY_USERS usuário correspondente. O PsLoggedOn usa RegConnectKey para se conectar ao Registro de um computador remoto quando você o direciona para listar usuários conectados a um sistema remoto.

Descobrir a que horas um usuário fez logon funciona usando um truque semelhante. Quando o processo WinLogon carrega o perfil de um usuário após HKEY_USERS o login, o WinLogon cria uma subchave volátil (não salva no perfil no disco) em seu perfil nomeado, apropriadamente, Ambiente Volátil. O Registro armazena carimbos de data/hora modificados pela última vez para chaves do Registro e, como o sistema não modifica subchaves de Ambiente Volátil subsequentes à sua criação, o PsLoggedOn pode determinar quando um usuário fez logon obtendo o carimbo de data/hora de sua subchave Ambiente Volátil.

Download PsLoggedOn v1.2 com fonte completa em
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

Se você já precisou desligar ou reiniciar um sistema Windows NT/2000 local ou remoto, então você vai querer baixar PsShutdown. PsShutdown é um clone da ferramenta Shutdown Windows NT/2000 Resource Kit. Ele usa os mesmos argumentos de linha de comando que permitem especificar um atraso antes do desligamento, se deve ou não reinicializar, uma mensagem opcional para exibir a qualquer usuário atualmente conectado ao sistema e o nome do computador a ser desligado ou reinicializado.

Download PsShutdown v1.0 em www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

Você provavelmente já notou o número crescente de ferramentas no Sysinternals que começam com o prefixo "Ps". O primeiro foi o PsList, uma ferramenta de linha de comando que lista informações sobre os processos ativos no sistema Windows NT/2000 local ou remoto. Eu dei PsList seu nome porque a ferramenta de informações de processo de linha de comando padrão UNIX é chamada "ps". A próxima ferramenta a obter o prefixo foi o PsKill, um utilitário de linha de comando que permite encerrar processos em execução em sistemas Windows NT/2000 locais ou remotos. Eu dei ao PsKill o prefixo "Ps" porque ele fez um companheiro perfeito para o PsList.

Ao longo do tempo desenvolvi outras ferramentas que partilhavam as mesmas características definidoras do PsList e do PsKill: são baseadas na linha de comandos e funcionam no sistema Windows NT/2000 local ou remoto. Por exemplo, ElogList permite que você despeje o conteúdo dos logs de eventos de um sistema e GetSid mostrou o SID de um computador ou conta específica. Recentemente, decidi unir todas essas ferramentas, dando-lhes todo o prefixo "Ps" e tornando-as para download como um único pacote chamado PsTools.

PsTools, que inclui PsList, PsKill, bem como os renomeados PsLogList e PsGetSid, consiste em um total de sete ferramentas. Se você vir uma ferramenta Sysinternals com o prefixo "Ps", saberá automaticamente que é uma ferramenta de linha de comando que funciona local e remotamente.

Download PsTools v1.1 em www.sysinternals.com/pstools.htm.

BGINFO V1.1

Como resultado do tremendo feedback dos usuários, Bryce atualizou o BgInfo, um utilitário que define o papel de parede da área de trabalho para exibir informações personalizáveis sobre a configuração de um sistema, como resultado do feedback do usuário que ele recebeu. Por padrão, o BgInfo faz uma contagem regressiva de 10 segundos antes de aplicar as configurações especificadas em sua caixa de diálogo, mas uma nova opção de linha de comando, /timer, permite que você altere ou elimine completamente a contagem regressiva. Isso torna mais conveniente incluir BgInfo em um script de logon ou como um atalho na pasta de inicialização de um perfil.

A versão 1.1 inclui outros novos recursos, como a capacidade de exibir texto arbitrário definido por você e mais categorias de informações predefinidas. O bitmap da área de trabalho que o BgInfo v1.1 cria também é geralmente menor, minimizando a pegada de memória da área de trabalho do BgInfo.

Download BgInfo v1.1 em www.sysinternals.com/bginfo.htm.

TOKENMON V1.0

Tokenmon é a mais recente adição ao variado conjunto de ferramentas de monitoramento que você pode baixar do Sysinternals. O Tokenmon, que compartilha a mesma interface do usuário de seus primos como Regmon e Filemon, monitora atividades significativas relacionadas à segurança em um sistema Windows NT/2000. O que é uma atividade "significativa" relacionada com a segurança? No centro da segurança do Windows NT/2000 está o objeto de token, uma estrutura de dados que contém um SID de conta, SIDs de grupo e privilégios. Sempre que um processo tenta acessar um objeto seguro, o Monitor de Referência de Segurança usa os SIDs em seu token como parte da validação de acesso. Se um processo tentar executar uma operação restrita, como reiniciar o sistema, o sistema verificará o privilégio apropriado no token do processo.

Um dos recursos poderosos (e patenteados) do modelo de segurança do Windows NT/2000 é a representação. A representação permite que um thread substitua temporariamente sua identidade baseada em processo e adote uma identidade alternativa por meio do uso de um token de representação. Os aplicativos de servidor aproveitam a representação ao acessar recursos em nome de um cliente, quando adotam a identidade do cliente durante o acesso.

O Tokenmon instala ganchos de chamada do sistema da mesma forma que o Regmon faz para APIs do Registro, a fim de monitorar a criação e exclusão de tokens, a ativação e desativação de privilégios e a representação. O Tokenmon também usa ganchos de criação de processos fornecidos pelo kernel NT/2000 para monitorar a criação e a exclusão de processos e outras APIs para determinar quando um usuário faz logon e quando faz logoff.

O código-fonte completo do Tokenmon é postado, e vale a pena discutir algumas das técnicas interessantes que o código demonstra. Tokenmon deteta um evento de logon conectando a chamada do sistema NtCreateToken, que é a usada por agentes de logon, como WinLogon, para criar um token inicial para o primeiro processo de uma nova sessão de logon. Os processos criados pelo primeiro processo herdam uma cópia do primeiro token. Para detetar logoff, o Tokenmon se registra para notificação de logoff por meio da função SeRegisterLogonSessionTerminatedRoutine do modo kernel, uma API que existe para o benefício dos drivers do sistema de arquivos, chamados redirecionadores de rede, que armazenam em cache os dados da sessão de logon e desejam limpar quando um usuário faz logoff. Os redirecionadores de rede implementam o lado do cliente das conexões cliente/servidor de compartilhamento de arquivos.

Outro detalhe interessante da implementação do Tokenmon é a maneira como o Tokenmon conecta as APIs que monitora. Algumas das APIs que Tokenmon hooks não são exportadas para uso por drivers de dispositivo, mas são exportadas na biblioteca de NTDLL.DLL de modo de usuário para uso por aplicativos que usam seus equivalentes Win32. Todas as APIs do Registro que os ganchos do Regmon são exportadas no modo kernel, tornando possível para o driver de dispositivo Regmon obter seus números de chamada do sistema e conectar a tabela de chamadas do sistema adequadamente. Para APIs não exportadas para uso por drivers, a GUI do Tokenmon deve obter os números de chamada usando as exportações em NTDLL.DLL e, em seguida, passar os números para o driver para que o driver possa conectar a tabela de chamadas do sistema. Assim, Tokenmon demonstra como conectar chamadas de sistema que não são exportadas no modo kernel.

Download Tokenmon v1.0 com fonte completa em www.sysinternals.com/tokenmon.htm.

FILÃO V4.32

Esta última atualização do Filemon introduz filtragem mais intuitiva e completa, exibição de nomes de caminho UNC completos para acesso a arquivos de rede do Windows 9x/Me e exibição de nomes de arquivos de metadados NTFS.

As versões anteriores do Filemon exigiam que você inserisse filtros com curingas obrigatórios. Por exemplo, se você quisesse monitorar os acessos ao diretório Temp na unidade C:, você tinha que inserir um filtro como este: "c:\temp\*". Com a nova sintaxe de filtragem, os curingas são opcionais, portanto, enquanto o filtro de exemplo funcionaria, "c:\temp" alcançaria o mesmo efeito. Além disso, Filemon agora aplica os filtros que você insere em todos os campos na exibição, incluindo o nome do processo, tipo de solicitação, caminho e coluna "outros". Essa flexibilidade permite que você observe tipos específicos de solicitações, ou solicitações com determinados dados na outra coluna, algo que não era possível anteriormente.

Os usuários de Filemon em sistemas Windows 9x/Me agora verão nomes de caminho de exibição Filemon com sintaxe UNC completa quando acessarem recursos remotos. Filemon anteriormente não exibia o servidor ou nome de compartilhamento para tais acessos, resultando em nomes de caminho incompletos.

Finalmente, se você usou Filemon no Windows NT/2000, sem dúvida viu o texto "DASD" na coluna de caminho para muitos acessos ("DASD" vem de "Direct Access Storage Device", um termo que a Microsoft usa para descrever acessos a um volume que ignoram estruturas do sistema de arquivos). Para a maioria das atividades em volumes NTFS, o DASD agora é uma coisa do passado. Em vez disso, você verá os nomes dos arquivos de metadados NTFS que estão sendo lidos e gravados. Por exemplo, uma atualização de um registro MFT teria resultado em uma linha de saída DASD antes, mas agora você a verá como um acesso a "$Mft", o nome do arquivo de metadados internos da MFT.

Por que o Filemon não mostrou nomes de arquivos de metadados antes e como ele obtém esses nomes agora? Os objetos de arquivo que representam arquivos de metadados NTFS não armazenam um nome de arquivo, portanto, Filemon não pode extrair o nome do objeto de arquivo. O método alternativo do Filemon para obter o nome de um arquivo, consultando o driver do sistema de arquivos, também não funciona para arquivos de metadados NTFS. Enquanto o NTFS responde com os nomes dos arquivos de metadados, o NTFS no NT 4 aleatoriamente causa falhas e o NTFS no Win2k ocasionalmente trava ao responder a essas consultas.

Filemon tem, portanto, que recorrer a um truque para obter os nomes de arquivo de metadados. Quando ele vê uma solicitação direcionada a um objeto de arquivo em um volume NTFS sem nome, ele envia ao NTFS uma consulta para o índice do arquivo. Este é o mesmo índice que a função Win32 GetFileInformationByHandle retorna e, para arquivos em volumes NTFS, o índice é o índice MFT do arquivo. As primeiras 16 entradas no MFT são reservadas para arquivos de metadados específicos, portanto, dado um índice nesse intervalo, Filemon simplesmente procura o nome do arquivo de metadados em sua própria tabela.

Infelizmente, você ainda verá DASD para metadados de diretório e acessos à tabela de alocação de arquivos (FAT) em volumes FAT, porque o FAT não armazena nomes para arquivos de metadados de diretório ou o FAT. Você ficará surpreso com a frequência com que o arquivo de log NTFS ($LogFile) é acessado. Aliás, NTFS em Whistler armazena os nomes para arquivos de metadados, então o truque é desnecessário em Whistler.

O aprimoramento final do Filemon permite que o Filemon mostre carimbos de data/hora do dia com resolução de milissegundos. Este suporte exigiu hacks feios no driver Filemon do Windows 9x/Me por causa de bugs em uma função de temporização no kernel do Windows 9x/Me. Consulte o código-fonte para obter mais informações.

Download Filemon v4.32 com código-fonte em www.sysinternals.com/filemon.htm.

REGMON V4,32

As alterações do Regmon não são tão importantes quanto as do Filemon, mas o Regmon agora suporta a mesma sintaxe de filtragem mais intuitiva do Filemon e, como Filemon, aplica os filtros a todos os campos. Ele também pode mostrar resolução de milissegundos em carimbos de data/hora.

Aqueles de vocês que começaram a jogar com Whistler (o sucessor do Windows 2000) Beta 1 podem ter notado que as versões anteriores do Regmon travam Whistler quando iniciado. Isso ocorre porque a Microsoft colocou a tabela de chamadas do sistema, que o Regmon modifica para inserir seus ganchos, na memória protegida contra gravação. O Regmon v4.32 contorna isso usando uma técnica para a qual eu não forneci código-fonte a pedido da Microsoft, porque a técnica pode quebrar na versão final do Whistler, e a Microsoft está explorando maneiras de suportar o gancho de chamadas do sistema. O Windows NT não foi projetado para suportar o gancho de chamadas do sistema, que é algo que fomos pioneiros com o primeiro lançamento do Regmon em meados de 1996.

Aqui está uma dica de Filemon/Regmon não documentada. Muitas vezes recebo e-mails perguntando como executar Regmon ou Filemon de uma conta não administrativa no Windows NT/2000 Há muitos casos em que um determinado aplicativo funciona corretamente quando executado a partir da conta de administrador, mas não a partir da de um usuário sem privilégios, onde Regmon e Filemon seriam úteis para determinar por que o aplicativo falha (geralmente é um problema relacionado às configurações de segurança em um arquivo ou chave do Registro). No entanto, a execução do Regmon e Filemon a partir de uma conta sem privilégios falhará porque tanto o Filemon quanto o Regmon instalam drivers de dispositivo, algo que requer privilégio de administrador.

No entanto, há um truque que permite contornar isso: se você fizer login como administrador e iniciar o Filemon ou o Regmon, poderá executá-los posteriormente a partir de contas sem privilégios. Isso ocorre porque Filemon e Regmon instalam um driver em sua primeira execução e, nas execuções seguintes, acessam o driver já carregado. Como eu não implemento nenhuma segurança no driver, um usuário sem privilégios pode executar as ferramentas depois que o driver é carregado. Problema de segurança? Sim, mas Filemon e Regmon destinam-se a ser ferramentas de solução de problemas, então eu, e as pessoas que perguntam como executar os utilitários a partir de contas sem privilégios, vejo isso como um recurso.

Download Regmon v4.32 com código fonte completo em www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

Um dos aplicativos para os quais recebi mais feedback dos usuários é, surpreendentemente, o DebugView. Esta nova versão tem alguns aprimoramentos significativos que atendem a muitas das solicitações de recursos e funcionalidades que recebi e tornam o DebugView mais poderoso do que nunca.

Mais visivelmente, o DebugView agora suporta até cinco filtros de realce diferentes, cada um com suas próprias cores personalizáveis. Isso permite que você simultaneamente hospede diferentes palavras-chave em sua saída de depuração e as distinga facilmente. Além disso, DebugView implementa a mesma nova sintaxe de filtragem que Filemon e Regmon, tornando os curingas opcionais para correspondência de substring.

Uma reclamação que recebi sobre versões anteriores do DebugView é que, mesmo se você quisesse apenas capturar a saída de depuração do Win32, você ainda precisava de privilégios administrativos para executar o DebugView, porque o DebugView não seria executado se não pudesse instalar seu driver de dispositivo. Esta nova versão é executada mesmo a partir de contas que não têm privilégios especiais. Se ele não puder instalar ou acessar seu driver, ele simplesmente desativará seus itens de menu relacionados à captura do modo kernel.

Dois recursos que facilitam que o DebugView comece a capturar a saída automaticamente quando você faz login são sua opção minimizar para bandeja e suporte para opções de linha de comando. Usando opções de linha de comando, você pode iniciar o DebugView na bandeja do sistema e registrar a saída que ele captura em um arquivo e, depois de iniciar o DebugView, você pode usar uma opção de menu para alternar o comportamento do botão minimizar entre minimizar normalmente e minimizar para a bandeja do sistema.

Para usuários que executam DebugView em sessões remotas nos serviços de terminal do Windows 2000, DebugView agora captura a saída Win32 gerada por aplicativos em execução em sua sessão remota e, opcionalmente, a partir da sessão de console. Isso é útil para depurar servidores COM e serviços Win32 remotamente, uma vez que esses tipos de programas são executados na sessão de console.

Por fim, o DebugView agora funciona no Whistler Beta 1, com suporte para capturar a saída das várias novas variantes do Whistler na função DbgPrint do modo kernel.

Download DebugView v4.02 em www.sysinternals.com/dbgview.htm.

POR DENTRO DO WINDOWS 2000, 3ª EDIÇÃO

O livro oficial sobre os internos do Windows 2000 já está disponível! Esta edição, em coautoria com David Solomon (www.solsem.com) e Mark Russinovich, é mais de 40% maior do que a anterior, com nova cobertura de rede, plug-and-play, gerenciamento de energia, serviços, Registro, WMI, inicialização e desligamento e armazenamento. Ele também inclui um CD com várias ferramentas poderosas, não disponíveis em nenhum outro lugar, para investigar os internos do Windows 2000.

Uma das ferramentas que escrevi especificamente para o livro é o LiveKd, um programa que permite executar ambos os depuradores do kernel da Microsoft, i386kd e WinDbg, em um sistema ao vivo como se você estivesse olhando para um crash dump. Muitos dos experimentos apresentados no livro funcionam em um sistema ao vivo quando executado usando LiveKd. LiveKd funciona instalando um driver de filtro do sistema de arquivos que apresenta a memória física do computador para o depurador da Microsoft como se fosse um arquivo de despejo de falha. O LiveKd cria um pseudo arquivo de despejo de 0 comprimento e, quando o depurador lê o arquivo, o LiveKd retorna dados da memória física. Confira a página de erratas e atualizações do livro para um patch LiveKd que corrige uma incompatibilidade entre o LiveKd v1.0 e vários scanners de vírus ao acessar.

Veja o sumário do livro e encomende agora através www.sysinternals.com/insidew2k.htm.

REVISTA WINDOWS 2000 DE NOVEMBRO E INVERNO

Curioso sobre o que mudou exatamente entre NTFS v4 e NTFS v5? Se sim, confira minha série de duas partes nas edições de novembro e inverno da revista Windows 2000. A Parte 1 descreve pontos de análise, junções de diretório, pontos de montagem de volume, suporte a cotas e configurações de segurança consolidadas. A Parte 2 termina com uma análise detalhada da criptografia, dos fluxos, do rastreamento de links distribuídos e do diário de alterações. Ambos os artigos levam você mais fundo do que outros, apresentando as alterações no disco e o comportamento interno desses novos recursos.

Uma coisa que eu não falo nos artigos é como NTFS para Windows NT 4 não é realmente versão

Encontre ligações para todas as nossas publicações em www.sysinternals.com/publ.htm.

SYSINTERNALS NA WWW.MICROSOFT.COM

Sysinternals apareceu em vários novos artigos da Base de Dados de Conhecimento Microsoft (KB) desde o último boletim informativo, e eu também rastreei alguns artigos mais antigos da Base de Dados de Conhecimento que se referem a Sysinternals.

  • Q260513 PROBLEMA: Ocorre um erro ao instalar produtos do Visual Studio
    http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
    Este artigo recomenda que os leitores usem Filemon e Regmon para solucionar problemas de instalação do Microsoft Visual Studio.

  • Q202258 XADM: O sistema não pode encontrar o caminho especificado - ID não: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    Na verdade, a Microsoft orienta os usuários sobre o uso do Filemon para solucionar problemas de atualização do Exchange 5.0 service pack, completo com uma linha de saída Filemon de exemplo e recomendações sobre como configurar filtros.

  • Q269383 PROBLEMA: Mensagem 'Erro ao acessar o registro do sistema' ao exibir referências VB/VBA
    http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
    Regmon obtém a referência deste artigo, que discute usá-lo para determinar por que a caixa de diálogo Referências no IDE do Visual Basic relata quando ele não pode acessar uma chave do Registro como resultado de um bug no Seagate Crystal Reports que aplica permissões incorretas a várias chaves.

  • Q269251 Erro: Automatizando o Windows Installer pode travar ao enumerar produtos
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Regmon é destacado novamente aqui, onde é usado para revelar um bug de automação do Windows Installer.

  • Q276525 seu computador pode parar de responder quando você monitora alças abertas
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    NtHandle é responsável por revelar um bug no Windows NT 4 SP6a, onde o kernel travaria sob certas condições ao usar NtHandle. A Microsoft trabalhou comigo para resolver o problema e eles emitiram um hotfix. Se o seu sistema NT 4 trava ao usar NtHandle, você deve obter o seguinte link para este artigo.

  • Q160660 Ntregmon.exe faz com que STOP 0x0000001E com o novo Service Pack
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Este último é um oldie, mas goodie. A primeira versão do Regmon usava números de chamada do sistema codificados para corrigir a tabela de serviço do sistema a fim de conectar APIs do Registro. Como os números de chamada do sistema às vezes mudam entre service packs, essa técnica é bastante frágil, e eu não tinha codificado defensivamente em antecipação a isso (contra o conselho de Andrew Schulman, que tinha medo de que Regmon quebrasse). Com certeza, o SP3 introduziu algumas novas chamadas do sistema, e o Regmon travava o sistema quando ele conectava chamadas incorretas do sistema. Embora isso certamente tenha irritado algumas pessoas, eu consegui meu próprio artigo KB!

LICENCIAMENTO SYSINTERNALS

Mesmo que o software que você baixa da Sysinternals seja freeware, o que significa que você pode usá-lo sem pagar uma taxa, você não tem permissão para redistribuí-lo ou derivar produtos que você distribui do código-fonte da Sysinternals. Por exemplo, se você trabalha em uma empresa onde vários usuários acham úteis determinadas ferramentas Sysinternals, você não pode postar as ferramentas em um compartilhamento interno ou site. Em vez disso, coloque um link em seu site para a página inicial de cada ferramenta no Sysinternals. Isso também ajuda a garantir que seus colegas de trabalho sempre baixem as versões mais recentes.

Se você deseja redistribuir as ferramentas Sysinternals internamente, com um produto comercial, ou em um CD shareware, ou você deseja basear um produto comercial ou programa redistribuível no código-fonte Sysinternals, envie um e-mail explicando os detalhes do seu uso desejado para licensing@....

INFORMAÇÃO INTERNA

IFN

Alguns boletins informativos atrás eu revelei a existência da ferramenta DiskEdit que a Microsoft inadvertidamente enviou no CD NT 4 SP4. O DiskEdit é um visualizador de estrutura de sistema de arquivos muito poderoso, embora peculiar, que você pode usar para examinar estruturas de dados em disco NTFS e FAT (embora seja o suporte NTFS que é interessante). Se você perdeu o CD NT 4 SP 4 e está interessado em explorar estruturas NTFS no disco, você não está totalmente no escuro, no entanto. A Microsoft lançou uma ferramenta gratuita chamada NFI (NTFS Information) que entende e pode despejar as estruturas internas de volumes NTFS. Embora sua saída não seja tão detalhada quanto a do DiskEdit, ela é interessante e reveladora.

Você pode baixar o NFI como parte das Ferramentas de Suporte OEM em http://support.microsoft.com/support/kb/articles/q253/0/66.asp. A execução de NFI com um nome de arquivo despeja o registro MFT NTFS desse arquivo. O exemplo a seguir mostra NFI despejando o registro MFT para o $Quota arquivo de metadados, um arquivo que só existe se você tiver o gerenciamento de cotas habilitado em um volume:

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

A saída mostra que o arquivo ocupa a 24ª entrada no MFT (seu índice de arquivo é 24), e que ele contém quatro atributos, incluindo informações padrão, nome do arquivo e duas raízes de índice (e índice é essencialmente uma lista agrupada de entradas, como um diretório). Eu descrevo como o NTFS usa os $Quota índices na minha última série Windows 2000 Magazine no NTFS v5.

Para despejar todos os arquivos em um volume, especifique a letra da unidade na linha de comando do NFI sem um nome de arquivo, por exemplo, nfi c:. Você verá uma lista de cada entrada MFT, incluindo todos os arquivos de metadados.

A NFI tem alguns outros talentos, como a capacidade de traduzir um número de setor para o arquivo em que reside. Quer saber em que setor de arquivos 2345 na unidade C: está? Utilize o comando nfi c: 2345. Observe que isso falha em volumes de software-RAID, como conjuntos de volumes e conjuntos de distribuição. O NFI funciona no NT 4 e no Windows 2000.

CHAVES DE REGISTO WIN9X OCULTAS

Duas questões atrás eu disse que eu iria cobrir "chaves de registro Win9x escondidas" na seguinte newsletter, e vários de vocês me lembraram que eu tinha esquecido. Então, este mês vou dizer-lhe sobre chaves de registro ocultas no Windows 9x.

Vários anos atrás, descobri uma maneira de criar chaves de registro ocultas no Windows NT. Por oculto, quero dizer que, embora você possa ver as chaves sendo acessadas pelo aplicativo que as cria com o Regmon, você não pode escrever um programa Win32 para olhar os valores da chave, nem pode olhar para as chaves com os editores do Registro Regedit ou Regedt32. As chaves ocultas são úteis para armazenar dados que você não deseja que os usuários finais possam modificar, como a data de tempo limite de um produto de avaliação.

O truque para criar uma chave de Registro oculta foi minha perceção de que a API NT nativa, que é a interface de chamada do sistema sobre a qual a API Win32 é construída, requer que as chaves do Registro sejam especificadas como cadeias de caracteres Unicode contadas. Uma cadeia de caracteres Unicode contada é aquela cujo comprimento é indicado por um campo de comprimento, não pela presença de um terminador nulo. Usando a API nativa, você pode, portanto, criar chaves do Registro que contêm um caractere nulo, como "test\0test". Como a API de chave do Registro da API do Win32 é baseada em cadeias de caracteres terminadas em nulo, não há como abrir uma chave do Registro que contenha um terminador nulo usando a API do Win32. Se você tentasse passar o nome da chave de exemplo anterior para RegOpenKey ou RegCreateKey ele seria tratado como "test" , com a cadeia de caracteres truncada no caractere nulo. Como todos os editores do Registro existentes, incluindo aqueles fornecidos com o Windows NT e o Windows 2000, usam a API do Win32, um aplicativo que usa a API nativa para criar nomes incorporados de caracteres nulos efetivamente cria chaves ocultas.

Este método funciona no Windows NT, mas e o Windows 9x? Eu não pensei que havia uma maneira de fazer chaves de registro ocultas no Windows 9x até que alguém me enviou um e-mail com um arquivo de log Regmon que mostra o Internet Explorer (IE) acessando chaves que não aparecem no Regedit. Para ver isso por si mesmo, inicie o Regmon e defina o seguinte filtro include: "policydata". Em seguida, inicie o IE (isso funciona para todas as versões do IE 4 e IE 5) e visite um site. Se você não vir nenhuma saída no Regmon, vá para a caixa de diálogo de configuração de opções do IE e verifique se o Supervisor de Conteúdo está ativado.

Se o Supervisor de Conteúdo estiver habilitado ou já tiver sido habilitado em seu sistema, você verá acessos à HKLM\PolicyDatchave a e suas subchaves. No entanto, você não encontrará uma chave PolicyData quando HKEY_LOCAL_MACHINE procurar no Regedit. Reserve um minuto e veja se você consegue descobrir o que está acontecendo.

A resposta é que o IE está carregando dinamicamente um hive do Registro usando a API do RegLoadKey Win32, lendo os valores necessários e, em seguida, descarregando o hive com RegUnloadKey. O hive é nomeado C:\Winows\System\Ratings.pol – o arquivo está oculto e somente leitura, mas você pode revelá-lo digitando attrib –r –h c:\windows\system\ratings.pol.

Os rastreamentos que você vê no Regmon mostram as informações que o Supervisor de Conteúdo está procurando na colmeia. Se você quiser explorar seu conteúdo, baixe meu utilitário Regload do www.sysinternals.com/regload.zip e execute-o com a seguinte sintaxe: regload test c:\windows\system\ratings.pol. Em seguida, abra o Regedit e navegue .HKLM\test Os valores que você encontrará correspondem às configurações especificadas no Supervisor de Conteúdo e estão relacionados ao arquivo de configuração nomeado no Users\FileName0 valor na colmeia. O valor normalmente aponta para C:\Windows\System\RSACi.rat, o arquivo de classificação definido pela Internet Content Rating Association. Aliás, você pode ver um valor com o nome um tanto bem-humorado de "PleaseMom" nas configurações do Registro do Content Advisor, por exemplo, em HKLM\Test\Users\Default. Esse valor deriva da caixa de seleção "O supervisor pode digitar uma senha para permitir que os usuários visualizem conteúdo restrito" na página Geral da caixa de diálogo Configurações do Supervisor de conteúdo.

A razão pela qual a Microsoft ofuscaria a existência desses valores do Registro deve ser óbvia. No entanto, há uma fraqueza bastante séria em seu design. Observe que, ao ativar o Supervisor de Conteúdo, você deve especificar uma senha que proteja a caixa de diálogo de configurações do Supervisor de Conteúdo. Esta palavra-passe é armazenada em HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key. Exclua esse valor e, presto, você pode acessar as configurações do Content Advisor sem digitar uma senha! Agora, se os desenvolvedores do IE se deram ao trabalho de ofuscar as configurações do Content Advisor, por que eles deixam essa porta dos fundos aberta? Design de segurança típico da Microsoft, eu acho. By the way, para descarregar a chave que você carregou com Regload basta digitar regload test.

O QUE VEM POR AÍ

NOVO SISTEMA WHISTLER CHAMA

Whistler é uma evolução incremental do sistema operacional Windows 2000 com foco no aumento da confiabilidade e fácil migração de usuários de sistemas operacionais Windows 9x. No entanto, ele inclui algumas mudanças no kernel. Os mais visíveis são o punhado de novas chamadas de sistema e exportado (disponível para uso por drivers de dispositivo) funções do kernel. Da próxima vez, darei uma prévia dessas novas APIs do kernel.

Obrigado por ler a Newsletter da Sysinternals.

Publicado quinta-feira, 30 de novembro de 2000 19:05 por ottoh

[Arquivo de boletins informativos ^] <[ Volume 2, Número 4] [Volume 3, Número 1 >]