• Cikk

[Hírlevelek archívuma ^][< 2. kötet, 4. szám][3. kötet, 1 >. szám ]

The Systems Internals Newsletter Volume 2, Number 5

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

2000. november 30. – Ebben a kérdésben:

  1. SZERKESZTŐI

  2. A SYSINTERNALS ÚJDONSÁGAI

    • PsLoggedOn v1.2
    • PsShutdown 1.0-s verzió
    • PsTools v1.1
    • BgInfo v1.1
    • Tokenmon v1.0
    • Filemon v4.32
    • Regmon v4.32
    • A Windows 2000-ben, 3.
    • Novemberi és téli Windows 2000 Magazin
    • Sysinternals a Microsoftnál
    • Sysinternals-licencelés

  3. BELSŐ ADATOK

    • NFI
    • Rejtett Win9x beállításkulcsok

  4. MI VÁRHATÓ?

    • Új whistler rendszerhívások

SZPONZOR: WINTERNALS SZOFTVER

A Sysinternals Hírlevél által szponzorált Winternals Software, a weben www.winternals.com. A Winternals Software a Windows NT/2K fejlett rendszereszközök vezető fejlesztője és szolgáltatója. A Winternals software termékek közé tartozik a FAT32 a Windows NT 4.0-hoz, az NTFSDOS Professional Edition (a DOS olvasási/írási NTFS-illesztőprogramja) és a Távoli helyreállítás.

A Netstat parancs, amely a Windows 9x és a Windows NT/2000 összes verziójával rendelkezik, megmutatja, hogy milyen TCP/IP-portok vannak megnyitva a rendszeren, de nem mutatja meg, hogy melyik folyamat nyitotta meg a portot. A TCPView Pro, Winternals legújabb monitorozási eszköze nem csak egy netstat-egyenértékű tcpvstat parancssori eszközzel rendelkezik, amely megmutatja, hogy melyik folyamat rendelkezik nyitva az egyes portokkal, de tartalmaz egy grafikus felhasználói felületet, amely ugyanazokat az információkat jeleníti meg, valamint a TCP/IP-tevékenység valós idejű nyomkövetését. A valós idejű nyomkövetés megmutatja a hálózati hozzáférést biztosító alkalmazást, a hozzáférés helyi és távoli IP-címét opcionális DNS-névfeloldással, a hozzáférés típusát, a hozzáférés sikerességét és az átvitt adatok mennyiségét. A TCPView Pro csak 69 dollár. Töltse le a TCPView Pro 14 napos, teljesen működőképes próbaverzióját a www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Üdvözlök mindenkit!

Üdvözöljük a Sysinternals hírlevélben. A hírlevélnek jelenleg 28 000 előfizetője van.

A Windows NT-ről a Windows 2000-re való áttérés egyik előnye a nagymértékben továbbfejlesztett megbízhatóság. Számos cikkben írtam a fejlesztések okairól, és ezek elsősorban a Driver Verifier nevű eszköz eredményei. A Start menü Futtatás párbeszédpanelén a "hitelesítő" beírásával konfigurálhatja a verifiert, hogy szorosan figyelemmel kísérje az adott eszközillesztők végrehajtását, és a különböző illesztőprogram-programozási szabályok bármelyikét megsértse. A Verifier egy lépéssel tovább megy, mint a passzív monitorozás, azonban – ez is súlyosbítja a potenciált; hibafeltételek például az érvénytelen régiókkal ütköző illesztőprogram memóriablokkainak kiosztásával, valamint az illesztőprogramnak átadott adatstruktúrák adott mezőinek nullázásával. Ha valóban kemény akar lenni, a Verifier alacsony memóriafeltételeket szimulálhat az illesztőprogram számára.

A Microsoft az illesztőprogram-aláíró programon keresztül használja a Verifiert, amely megköveteli, hogy a Microsoft által digitálisan aláírt illesztőprogramok szigorú illesztőprogram-ellenőrző tesztelésen haladjanak át. Az illesztőprogram telepítésekor a hardvervarázsló ellenőrzi, hogy az illesztőprogram aláírt-e. Ha nem, akkor vagy figyelmezteti, vagy nem telepíti az illesztőprogramot az Illesztőprogram-aláírási beállítások párbeszédpanelen megadott beállításoktól függően, amely a rendszer kisalkalmazás hardveroldaláról érhető el a Vezérlőpult.

Az a tény, hogy az alapértelmezett illesztőprogram-aláírási szabályzat figyelmezteti a végfelhasználókat az aláíratlan illesztőprogramokra, elegendő ahhoz, hogy a legtöbb hardvergyártónak gondot okoz az illesztőprogramok robusztussá tétele és aláírása. Az eszközillesztők azonban észrevétlenül belopódhatnak a rendszerbe az illesztőprogram-aláírási szabályzat által. Csak az INF-fájlokkal telepített illesztőprogramok (az .inf bővítményben végződő illesztőprogram-telepítési fájlok) kapnak ellenőrzést az aláírásokért. A telepítőalkalmazások manuálisan is telepíthetik az illesztőprogramokat közvetlenül a telepítő API-k használatával, vagy az illesztőprogram beállításjegyzék-beállításainak manuális konfigurálásával. A Sysinternals-alkalmazások kiváló példák erre: Filemon, Regmon és más Olyan Sysinternals-eszközök, amelyek illesztőprogram-összetevői manuálisan telepítik az illesztőprogramokat, ezért nem figyelmeztetik, hogy a Microsoft nem írta alá őket.

Az INF-fájlokkal gyakran nem telepített illesztőprogramok közé tartoznak a vírusolvasók, a titkosítási szoftverek és a CD-ROM-égő szoftverek. Ez azonban nem zárja ki, hogy a hardverrel kapcsolatos illesztőprogramok átcsússzon. A Windows 2000 Sysinternals Ctrl2cap illesztőprogramja (www.sysinternals.com/ctrl2cap.htm egy hardverrel kapcsolatos illesztőprogram példája, amely úgy települ, hogy áthalad az illesztőprogram aláírási ellenőrzésein. Ez a kiskapu olyan illesztőprogramok jelenlétéhez vezet a rendszeren, amelyek nem lettek ellenőrizve, ami veszélyeztetheti a rendszer stabilitását (a legmagasabb beállításokon ellenőrizem az összes Sysinternals illesztőprogramot). A Microsoftnak nem csak az INF-fájlokkal telepített illesztőprogramokat kell kényszerítenie az aláírás ellenőrzésére.

Miért vagyok ezen a zsarnokságon? A CD-ROM égő szoftverem, amely a legnépszerűbb ilyen típusú szoftver a piacon, rendelkezik egy illesztőprogrammal, amely reprodukálhatóan összeomlik a Windows 2000 SP1 rendszerem. Ha úgy konfigurálom a Driver Verifiert, hogy ellenőrizze, a rendszer nem is fejezi be a rendszerindítást, mielőtt a Hitelesítő észleli az illesztőprogram első szabálysértését, és összeomlik a rendszer. Az illesztőprogram INF-fájl nélkül lett telepítve, ezért nem figyelmeztettek, hogy nincs aláírva. Garantálom, hogy ha a Microsoft szabályzata szigorúbb lenne, akkor ez a gyártó kétszer is meggondolná, mielőtt egy aláíratlan (és hibás) illesztőprogramot szállítana.

Kérjük, adja át a hírlevelet barátainak, akikről úgy gondolja, hogy érdeklik a tartalmai.

Thanks!

-Mark

A SYSINTERNALS ÚJDONSÁGAI

PSLOGGEDON V1.2

A Naplózott névről PsLoggedOn-ra történő nyilvánvaló névváltoztatás mellett ez a parancssori eszköz, amely képes megmutatni, hogy ki van bejelentkezve helyileg és erőforrásmegosztásokon keresztül a helyi vagy távoli rendszeren, új funkciókkal rendelkezik. Az első a felhasználói visszajelzésekből származó "-l" parancssori kapcsoló. Sokan használják a PsLoggedOnt annak megtekintésére, hogy van-e helyileg bejelentkezett fiók a kiszolgálóikra. Előfordulhat például, hogy a felhasználók fájlmegosztásokon keresztül vannak bejelentkezve, de ez nem releváns, amikor döntést hoz arról, hogy mikor frissíthető egy fiók, vagy a kiszolgáló távolról felügyelhető.

A PsLoggedOn második új funkciója nemcsak azt mutatja be, hogy ki van bejelentkezve, hanem azt az időpontot is, amikor a bejelentkezés megtörtént. A PsLoggedOn ingyenesen szerzi be az erőforrás-megosztásokból származó bejelentkezések bejelentkezési idejét, ha Win32 API-t ( NetSessionEnumot) használ az erőforrás-megosztási bejelentkezések számbavételéhez (a parancssori Net-parancs a NetSessionEnumot is használja a munkamenetek számbavételéhez). Azonban nincs olyan Win32 API, amely elárulja, hogy ki van helyileg bejelentkezve egy rendszerbe, sokkal kevesebbet, amikor bejelentkeztek.

Annak megállapításához, hogy ki jelentkezett be helyileg a rendszerbe, a PsLoggedOn a számítógép beállításkulcsa alatt található biztonsági azonosítókat (SID-ket) sorolja HKEY_USERS fel. Amikor valaki helyileg, a konzolon vagy egy szolgáltatáson keresztül jelentkezik be egy számítógépre, a rendszer betölti a profilját a HKEY_USERS kulcsba. Az alkalmazások a kulcson keresztül férhetnek hozzá a HKEY_CURRENT_USER profil beállításjegyzék-beállításaihoz, mert a rendszer ezt a kulcsot szimbolikus hivatkozásként kezeli az adott profilhoz a következő alatt HKEY_USERS: . A PsLoggedOn így a számítógép HKEY_USERS kulcsában található SID-k lefordításával a megfelelő felhasználónévre fordítva tudja tudni, hogy ki van helyileg bejelentkezve. A PsLoggedOn egy távoli számítógép beállításjegyzékéhez való csatlakozásra szolgál RegConnectKey , amikor átirányítja a távoli rendszerbe bejelentkezett felhasználók listázására.

Hasonló trükkel megtudhatja, hogy egy felhasználó mikor jelentkezett be. Amikor a WinLogon-folyamat betölti a felhasználó profilját HKEY_USERS a bejelentkezés után, a WinLogon létrehoz egy illékony (lemezen lévő profilba nem mentett) alkulcsot a profilban, megfelelő módon, illékony környezetben. A beállításjegyzék a beállításkulcsok utolsó módosított időbélyegeit tárolja, és mivel a rendszer nem módosítja az Illékony környezet alkulcsait a létrehozásuk után, a PsLoggedOn a változó környezeti alkulcs időbélyegének lekérésével meghatározhatja, hogy mikor jelentkezett be a felhasználó.

A PsLoggedOn 1.2-s verzió letöltése teljes forrással:
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

Ha valaha is le kellett állítania vagy újra kellett indítania egy helyi vagy távoli Windows NT/2000 rendszert, akkor le kell töltenie a PsShutdownt. A PsShutdown a Windows NT/2000 Resource Kit leállítási eszköz klónja. Ugyanazokat a parancssori argumentumokat használja, amelyek lehetővé teszik, hogy a leállítás előtt késleltetést adjon meg, függetlenül attól, hogy újraindul-e, egy opcionális üzenet jelenik meg a rendszerbe jelenleg bejelentkezett felhasználók számára, valamint a számítógép nevét a leállításhoz vagy újraindításhoz.

Töltse le a PsShutdown 1.0-s verziót a www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

Valószínűleg észrevette, hogy egyre több olyan eszköz van a Sysinternalsben, amelyek a "Ps" előtaggal kezdődnek. Az első a PsList nevű parancssori eszköz volt, amely a helyi vagy távoli Windows NT/2000 rendszeren futó aktív folyamatokkal kapcsolatos információkat sorolja fel. A PsListnek azért adtam nevet, mert a standard UNIX parancssori folyamatinformációs eszköz neve "ps". Az előtag lekérésének következő eszköze a PsKill nevű parancssori segédprogram volt, amely lehetővé teszi a helyi vagy távoli Windows NT/2000 rendszereken futó folyamatok leállítását. Adtam PsKill a "Ps" előtagot, mert tökéletes társsá tette a PsList-et.

Idővel más eszközöket is kifejlesztettem, amelyek ugyanazokat a meghatározó jellemzőket osztották meg, mint a PsList és a PsKill: parancssori alapúak, és helyi vagy távoli Windows NT/2000 rendszeren működnek. Az ElogList például lehetővé teszi a rendszer eseménynaplóinak tartalmát, és a GetSid egy számítógép vagy egy adott fiók SID-azonosítóját mutatta. Nemrég úgy döntöttem, hogy kösse össze ezeket az eszközöket azáltal, hogy az összes "Ps" előtagot, és így letölthető egyetlen csomag neve PsTools.

A PsTools, amely magában foglalja a PsListet, a PsKillt, valamint az átnevezett PsLogList és PsGetSid eszközt, összesen hét eszközből áll. Ha megjelenik egy Sysinternals-eszköz a "Ps" előtaggal, automatikusan tudja, hogy ez egy parancssori eszköz, amely helyileg és távolról is működik.

Töltse le a PsTools 1.1-et a www.sysinternals.com/pstools.htm.

BGINFO V1.1

A hatalmas felhasználói visszajelzések eredményeképpen a Bryce frissítette a BgInfo segédprogramot, amely az asztali háttérképet úgy állítja be, hogy testre szabható információkat jelenítsen meg a rendszer konfigurációjáról a felhasználói visszajelzések eredményeként. A BgInfo alapértelmezés szerint 10 másodpercig számlál le a párbeszédpanelen megadott beállítások alkalmazása előtt, /timerde egy új parancssori lehetőség lehetővé teszi a visszaszámlálás teljes módosítását vagy megszüntetését. Ez kényelmesebbé teszi, ha a BgInfo-t befoglalja egy bejelentkezési szkriptbe, vagy parancsikonként a profil Indítás mappájába.

Az 1.1-es verzió egyéb új funkciókat is tartalmaz, például az Ön által definiált tetszőleges szöveg megjelenítésének lehetőségét és az előre definiált információkategóriákat. A BgInfo v1.1 asztali bitképe is általában kisebb, így minimálisra csökkenti a BgInfo asztali memóriaigényét.

Töltse le a BgInfo 1.1-et a www.sysinternals.com/bginfo.htm.

TOKENMON V1.0

A Tokenmon a Sysinternalsből letölthető monitorozási eszközök legújabb kiegészítője. A Tokenmon, amely ugyanazzal a felhasználói felülettel rendelkezik, mint az unokatestvéreinek, például a Regmonnak és a Filemonnak, jelentős biztonsági tevékenységet figyel egy Windows NT/2000 rendszeren. Mi a "jelentős" biztonsággal kapcsolatos tevékenység? A Windows NT/2000 biztonságának középpontjában a jogkivonat-objektum, egy olyan adatstruktúra áll, amely egy fiók SID-jét, csoportazonosítóit és jogosultságait tartalmazza. Amikor egy folyamat megpróbál hozzáférni egy védett objektumhoz, a biztonsági referenciamonitor a jogkivonatában lévő SID-ket használja a hozzáférés-ellenőrzés részeként. Ha egy folyamat korlátozott műveletet kísérel meg végrehajtani, például újraindítja a rendszert, a rendszer ellenőrzi a megfelelő jogosultságot a folyamat jogkivonatában.

A Windows NT/2000 biztonsági modell egyik hatékony (és szabadalmaztatott) funkciója a megszemélyesítés. A megszemélyesítés lehetővé teszi, hogy egy szál ideiglenesen felülbírálja a folyamatalapú identitását, és alternatív identitást fogadjon el egy megszemélyesítési jogkivonat használatával. A kiszolgálóalkalmazások kihasználják a megszemélyesítés előnyeit, amikor egy ügyfél nevében férnek hozzá az erőforrásokhoz, amikor a hozzáférés időtartama alatt elfogadják az ügyfél identitását.

A Tokenmon ugyanúgy telepíti a rendszerhívási horgokat, mint a Regmon a Beállításjegyzék API-k esetében, a jogkivonatok létrehozásának és törlésének, a jogosultságok engedélyezésének és letiltásának, valamint a megszemélyesítésnek a monitorozása érdekében. A Tokenmon az NT/2000 kernel által biztosított folyamatlétrehozási horgokat is használja a folyamatok létrehozásának és törlésének figyeléséhez, valamint más API-k segítségével határozza meg, hogy egy felhasználó mikor jelentkezik be és mikor jelentkezik be.

A Tokenmon teljes forráskódja közzé van adva, és érdemes megvitatni a kód által bemutatott érdekes technikák némelyikét. A Tokenmon az NtCreateToken rendszerhívás csatlakoztatásával észlel egy bejelentkezési eseményt, amelyet a bejelentkezési közvetítők, például a WinLogon használnak egy kezdeti token létrehozásához az új bejelentkezési munkamenet első folyamatához. Az első folyamat által létrehozott folyamatok öröklik az első jogkivonat másolatát. A logoff észleléséhez a Tokenmon a kernel módú SeRegisterLogonSessionTerminatedRoutine függvényen keresztül regisztrál a logoff-értesítésre, amely egy olyan API, amely a fájlrendszer-illesztőprogramok, úgynevezett hálózati átirányítók javára létezik, és gyorsítótárazza a bejelentkezési munkamenet adatait, és törölni szeretné a felhasználó kijelentkezésekor. A hálózati átirányítók a fájlmegosztási ügyfél-/kiszolgálókapcsolatok ügyféloldalát implementálják.

Egy másik érdekes Tokenmon implementálási részlet az, ahogyan a Tokenmon csatlakoztatja a figyelt API-kat. Egyes API-k, amelyeket a Tokenmon-horgok nem exportálnak az eszközillesztők általi használatra, de a win32-ekvivalenseket használó alkalmazások által használt felhasználói módú NTDLL.DLL-kódtárba exportálják őket. A Regmon-horgokat kernel módban exportálja a Rendszerregisztrációs API-k, így a Regmon-eszközillesztő lekérheti a rendszerhívószámokat, és megfelelően csatlakoztathatja a rendszerhívási táblát. Az illesztőprogramok által nem exportált API-k esetében a Tokenmon GUI-nak be kell szereznie a hívószámokat az NTDLL.DLL exportálásával, majd át kell adnia a számokat az illesztőprogramnak, hogy az illesztőprogram csatlakoztathassa a rendszerhívási táblát. Így a Tokenmon bemutatja, hogyan kapcsolhatja össze a rendszerhívásokat, amelyek nem kernel módban vannak exportálva.

Töltse le a Tokenmon 1.0-s verziót teljes forrással a www.sysinternals.com/tokenmon.htm.

FILEMON V4.32

Ez a legújabb Filemon-frissítés intuitívabb és teljesebb szűrést vezet be, megjeleníti a Windows 9x/Me hálózati fájlhozzáférés teljes UNC elérési útját, valamint megjeleníti az NTFS metaadatfájlneveket.

A Filemon korábbi verzióiban kötelező helyettesítő karaktereket tartalmazó szűrőket kellett megadnia. Ha például a temp könyvtárhoz való hozzáféréseket szeretné figyelni a meghajtón C:, be kellett írnia egy ilyen szűrőt: "c:\temp\*". Az új szűrési szintaxis nem kötelező, így míg a példaszűrő működik, a "c:\temp" ugyanazt a hatást érné el. A Filemon emellett a megjelenített összes mezőre alkalmazza a megadott szűrőket, beleértve a folyamat nevét, a kérelem típusát, az elérési utat és az "egyéb" oszlopot. Ez a rugalmasság lehetővé teszi bizonyos típusú kérések vagy kérések megtekintését a másik oszlopban található bizonyos adatokkal, amelyek korábban nem lehetségesek.

A Windows 9x/Me rendszereken futó Filemon felhasználói mostantól teljes UNC szintaxissal jelenítik meg az elérési utak nevét, amikor távoli erőforrásokhoz férnek hozzá. A Filemon korábban nem jeleníti meg az ilyen hozzáférések kiszolgáló- vagy megosztásnevét, ami hiányos elérési utakat eredményezett.

Végül, ha Windows NT/2000 rendszeren használta a Filemont, kétségtelenül sok hozzáférés elérési útja oszlopában a "DASD" szöveg látható ("DASD" a "Direct Access Storage Device" kifejezésből származik, amelyet a Microsoft a fájlrendszerstruktúrákat megkerülő kötetek hozzáféréseinek leírására használ). Az NTFS-köteteken végzett legtöbb tevékenység esetében a DASD már a múlté. Ehelyett az olvasandó és írott NTFS-metaadatfájlok nevét fogja látni. Egy MFT-rekord frissítése például korábban DASD-kimeneti sort eredményezett volna, de most az MFT belső metaadatfájljának neve, a "$Mft" eléréseként fogja látni.

Miért nem jeleníti meg a Filemon korábban a metaadat-fájlneveket, és hogyan szerzi be most ezeket a neveket? Az NTFS metaadatfájlokat képviselő fájlobjektumok nem tárolnak fájlnevet, így a Filemon nem tudja kinyerni a nevet a fájlobjektumból. A Filemon alternatív metódusa a fájl nevének lekéréséhez, a fájlrendszer-illesztőprogram lekérdezéséhez sem működik NTFS metaadatfájlok esetében. Míg az NTFS a metaadatfájlok nevével válaszol, az NT 4-en lévő NTFS véletlenszerűen összeomlásokat okoz, és a Win2k ntfs-jei időnként lefagynak az ilyen lekérdezésekre való válaszadáskor.

A Filemonnak ezért egy trükköt kell alkalmaznia a metaadat-fájlnevek beszerzéséhez. Ha egy NTFS-köteten lévő fájlobjektumra irányuló kérést lát név nélkül, az NTFS-lekérdezést küld a fájl indexéhez. Ez ugyanaz az index, amelyet a Win32 GetFileInformationByHandle függvény ad vissza, az NTFS-köteteken lévő fájlok esetében pedig az index a fájl MFT-indexe. Az MFT első 16 bejegyzése adott metaadatfájlok számára van fenntartva, így az adott tartományban lévő index alapján a Filemon egyszerűen megkeresi a metaadat-fájl nevét a saját táblájában.

Sajnos továbbra is látni fogja a DASD-t a címtár metaadataihoz és a FAT-kötetekhez való hozzáféréshez, mert a FAT nem tárolja a címtár metaadat-fájljainak vagy a FAT-nak a nevét. Meg fog lepődni, hogy milyen gyakran érhető el az NTFS-naplófájl ($LogFile). Az NTFS a Whistleren egyébként tárolja a metaadatfájlok nevét, ezért a trükk szükségtelen a Whistler esetében.

A Filemon végleges továbbfejlesztése lehetővé teszi a Filemon számára, hogy ezredmásodperc felbontással mutassa a napi időbélyegeket. Ez a támogatás csúnya hackeléseket igényelt a Windows 9x/Me Filemon illesztőprogramban a Windows 9x/Me kernel időzítési függvényének hibái miatt. További információt a forráskódban talál.

Töltse le a Filemon v4.32-t a forráskóddal a www.sysinternals.com/filemon.htm.

REGMON V4.32

A Regmon módosításai nem olyan jelentősek, mint a Filemoné, de a Regmon mostantól ugyanazt az intuitívabb szűrési szintaxist támogatja, mint a Filemon, és a Filemonhoz hasonlóan a szűrőket minden mezőre alkalmazza. Ezredmásodpercben is megjeleníthető az időbélyegek felbontása.

Azok, akik elkezdtek játszani a Whistlerrel (a Windows 2000 utódja) 1. bétaverziója, észrevehettek, hogy a Regmon korábbi verziói összeomlanak a Whistler indításakor. Ennek az az oka, hogy a Microsoft írásvédett memóriába helyezte a rendszerhívási táblát, amelyet a Regmon módosít a horgok beszúrásához. A Regmon 4.32-es verziójának használata olyan technikát használ, amelyhez nem adtam meg forráskódot a Microsoft kérésére, mert a technika a Whistler végleges kiadásában megszakadhat, és a Microsoft a rendszerhívások csatlakoztatásának támogatásának módjait vizsgálja. A Windows NT-t nem a rendszerhívások csatlakoztatásának támogatására tervezték, ami a Regmon első kiadásának úttörője volt 1996 közepén.

Íme egy nem dokumentált Filemon/Regmon tipp. Gyakran kapok olyan e-maileket, amelyek a Regmon vagy a Filemon futtatását kérik egy nem rendszergazdai fiókból a Windows NT/2000 rendszeren Számos esetben működik megfelelően egy adott alkalmazás a rendszergazdai fiókból való futtatáskor, de nem a jogosulatlan felhasználóktól, ahol a Regmon és a Filemon hasznos lenne annak meghatározásához, hogy miért hiúsul meg az alkalmazás (általában egy fájl vagy beállításkulcs biztonsági beállításaival kapcsolatos probléma). A Regmon és a Filemon nem jogosult fiókból való futtatása azonban sikertelen lesz, mert a Filemon és a Regmon is telepíti az eszközillesztőket, ami rendszergazdai jogosultságot igényel.

Van azonban egy trükk, amellyel megkerülheti a problémát: Ha rendszergazdaként jelentkezik be, és elindítja a Filemon vagy a Regmon alkalmazást, később futtathatja őket nem jogosultsági jogosultságokkal rendelkező fiókokból. Ennek az az oka, hogy a Filemon és a Regmon egy illesztőprogramot telepít az első végrehajtásukra, és a következő végrehajtások során hozzáférnek a már betöltött illesztőprogramhoz. Mivel nem implementálok semmilyen biztonságot az illesztőprogramban, a nem jogosult felhasználók futtathatják az eszközöket az illesztőprogram betöltése után. Biztonsági probléma? Igen, de a Filemon és a Regmon hibaelhárítási eszközöknek szánták, ezért én és azok a személyek, akik megkérdezik, hogyan kell futtatni a segédprogramokat a nem hátrányos helyzetű fiókokból, ezt szolgáltatásként tekintem.

Töltse le a Regmon v4.32-t teljes forráskóddal a www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

Az egyik alkalmazás kaptam a legtöbb felhasználói visszajelzést, némileg meglepő, DebugView. Ez az új verzió jelentős fejlesztéseket tartalmaz, amelyek a kapott funkció- és funkciókérések nagy részét kezelik, és minden eddiginél hatékonyabbá teszik a DebugView-t.

A DebugView most már legfeljebb öt különböző kiemelő szűrőt támogat, amelyek mindegyike saját testreszabható színekkel rendelkezik. Ez lehetővé teszi, hogy egyszerre otthon különböző kulcsszavakat a hibakeresési kimenet, és könnyen megkülönböztetni őket. Emellett a DebugView ugyanazt az új szűrési szintaxist implementálja, mint a Filemon és a Regmon, így a helyettesítő karakterek nem kötelezőek a részszűréshez.

A DebugView korábbi verzióival kapcsolatos panasz az, hogy még ha csak a Win32 hibakeresési kimenetét is rögzíteni szeretné, akkor is rendszergazdai jogosultságokra volt szüksége a DebugView futtatásához, mert a DebugView nem futna, ha nem tudná telepíteni az eszközillesztőt. Ez az új verzió még a különleges jogosultságokkal nem rendelkező fiókokból is fut. Ha nem tudja telepíteni vagy elérni az illesztőprogramot, egyszerűen letiltja a kernel módú rögzítéssel kapcsolatos menüelemeket.

Két olyan funkció, amely megkönnyíti, hogy a DebugView automatikusan rögzítse a kimenetet bejelentkezéskor, ez a kis méretű a tálcáról a tálcára lehetőség, és támogatja a parancssori kapcsolókat. Parancssori kapcsolók használatával elindíthatja a DebugView-t a rendszertálcában, és naplózhatja a fájlhoz rögzített kimenetet, és a DebugView elindítása után egy menübeállítással válthatja a kis méretű gomb viselkedését a normál méret minimalizálása és a rendszertálcára való minimalizálás között.

A Windows 2000 terminálszolgáltatások távoli munkameneteiben debugView szolgáltatást futtató felhasználók számára a DebugView mostantól rögzíti a távoli munkamenetben futó alkalmazások által létrehozott Win32-kimenetet, és opcionálisan a konzol munkamenetéből. Ez hasznos a COM-kiszolgálók és a Win32-szolgáltatások távoli hibakereséséhez, mivel ezek a programok a konzol munkamenetében futnak.

Végül a DebugView mostantól a Whistler 1. bétaverzióján működik, és támogatja a kernel módú DbgPrint függvény több új Whistler-változatának kimenetének rögzítését.

Töltse le a DebugView 4.02-s verziót a www.sysinternals.com/dbgview.htm.

A WINDOWS 2000 3. KIADÁSÁBAN

A Windows 2000 belső részeiről szóló hivatalos könyv már elérhető! Ez a kiadás David Solomon (www.solsem.com) és Mark Russinovich társszerzőségével több mint 40%-kal nagyobb az előzőnél, új lefedettséggel a hálózatkezelés, a plug-and-play, az energiagazdálkodás, a szolgáltatások, a beállításjegyzék, a WMI, a rendszerindítás és a leállítás, valamint a tárolás területén. Emellett tartalmaz egy CD-t is, amely számos olyan hatékony eszközzel rendelkezik, amely máshol nem érhető el a Windows 2000 belső elemeinek vizsgálatához.

Az egyik eszköz, amit kifejezetten a könyvhöz írtam, a LiveKd, egy program, amely lehetővé teszi mindkét Microsoft kernel hibakereső, i386kd és WinDbg futtatását egy élő rendszeren, mintha összeomlási memóriaképet nézne. A könyvben bemutatott kísérletek közül sok élő rendszeren működik, amikor a LiveKd használatával fut. A LiveKd úgy működik, hogy olyan fájlrendszerszűrő-illesztőprogramot telepít, amely úgy jeleníti meg a számítógép fizikai memóriáját a Microsoft hibakeresőjének, mintha összeomlási memóriaképfájl lenne. A LiveKd létrehoz egy 0 hosszúságú álképfájlt, és amikor a hibakereső a fájlból olvas, a LiveKd a fizikai memóriából ad vissza adatokat. Tekintse meg a könyv hibakeresési és frissítési oldalát egy LiveKd-javításhoz, amely javítja a LiveKd 1.0-s és több hozzáférésen keresztüli vírusolvasó közötti kompatibilitást.

Tekintse meg a könyv tartalomjegyzékét és sorrendjét www.sysinternals.com/insidew2k.htm.

NOVEMBERI ÉS TÉLI WINDOWS 2000 MAGAZIN

Kíváncsi arra, hogy mi változott pontosan az NTFS v4 és az NTFS v5 között? Ha igen, nézd meg a kétrészes sorozat novemberi és téli kérdések a Windows 2000 magazin. Az 1. rész ismerteti az újraelemzési pontokat, a címtár-csomópontokat, a kötetcsatlakozási pontokat, a kvótatámogatást és az összevont biztonsági beállításokat. A 2. rész a titkosítást, a streameket, az elosztott hivatkozáskövetést és a változásnaplót tekinti át. Mindkét cikk mélyebbre viszi önt, mint mások, bemutatva a lemezen végzett módosításokat és az új funkciók belső viselkedését.

Egy dolog, amiről nem beszélek a cikkekben, hogy a Windows NT 4 NTFS nem igazán verzió

A www.sysinternals.com/publ.htm minden kiadványunkra mutató hivatkozásokat talál.

SYSINTERNALS AT WWW.MICROSOFT.COM

A Sysinternals a legutóbbi hírlevél óta számos új Microsoft Tudásbázis-cikkben jelent meg, és a Sysinternalsre hivatkozó régebbi TUDÁSBÁZIS-cikkeket is nyomon követtem.

  • Q260513 PRB: Hiba történik a Visual Studio-termékek telepítésekor
    http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
    Ez a cikk azt javasolja az olvasóknak, hogy a Filemon és a Regmon használatával hárítsák el a Microsoft Visual Studio telepítési problémáit.

  • Q202258 XADM: A rendszer nem találja a megadott elérési utat – azonosító: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    A Microsoft valójában végigvezeti a felhasználókat az Exchange 5.0 szervizcsomag frissítési problémáinak elhárításán a Filemon használatával, kiegészítve egy filemon kimeneti sor mintával és a szűrők beállítására vonatkozó javaslatokkal.

  • Q269383 PRB: "Hiba a rendszerregisztrációs adatbázis elérésekor" üzenet a VB/VBA-hivatkozások megjelenítésekor
    http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
    A Regmon megkapja a cikk javaslatát, amely azt ismerteti, hogy a Visual Basic IDE Hivatkozások párbeszédpanelje miért jelenti, ha nem fér hozzá a Beállításkulcshoz a Seagate Crystal Reportsban egy olyan hiba miatt, amely helytelen engedélyeket alkalmaz több kulcsra.

  • Q269251 HIBA: A Windows Installer automatizálása lefagyhat a termékek számbavételekor
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    A Regmon itt ismét ki van emelve, ahol egy Windows Installer-automatizálási hiba feltárására szolgál.

  • Q276525 előfordulhat, hogy a számítógép nem válaszol a nyitott fogópontok figyelésekor
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    Az NtHandle feladata, hogy feltárjon egy hibát a Windows NT 4 SP6a-ban, ahol a kernel bizonyos feltételek mellett lefagy az NtHandle használatakor. A Microsoft velem dolgozott a probléma megoldásán, és kiadott egy gyorsjavítást. Ha az NT 4 rendszer lefagy az NtHandle használatakor, a cikkre mutató hivatkozást kell kapnia.

  • Q160660 Ntregmon.exe a STOP 0x0000001E okoz az Új szervizcsomaggal
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Ez az utolsó egy öreg, de goodie. A Regmon első verziója kemény kóddal kódolt rendszerhívószámokkal javította a rendszerszolgáltatás-táblát a beállításjegyzék API-k összekapcsolása érdekében. Mivel a rendszer hívási számai időnként változnak a szervizcsomagok között, ez a technika elég törékeny, és nem kódolt védekezően előre erre (Andrew Schulman tanácsára, aki attól félt, hogy Regmon megtörik). Persze elég, SP3 bevezetett néhány új rendszerhívások, és Regmon összeomlik a rendszer, amikor csatlakozik helytelen rendszerhívások. Bár ez biztosan bosszantott néhány embert, én is kap a saját KB cikket belőle!

SYSINTERNALS-LICENCELÉS

Annak ellenére, hogy a Sysinternals-ből letöltött szoftver ingyenes, vagyis díjfizetés nélkül használhatja, nem terjesztheti újra, és nem származtathatja a Sysinternals forráskódjából származó termékeket. Ha például olyan vállalatnál dolgozik, ahol több felhasználó is hasznosnak találja az adott Sysinternals-eszközöket, előfordulhat, hogy nem teszi közzé az eszközöket egy belső megosztáson vagy webhelyen. Ehelyett helyezzen el egy hivatkozásokat a webhelyen az egyes eszközök otthonára a Sysinternalsben. Ez segít abban is, hogy munkatársai mindig a legújabb verziókat töltsák le.

Ha a Sysinternals-eszközöket belsőleg, kereskedelmi termékkel vagy shareware CD-n szeretné terjeszteni, vagy kereskedelmi terméket vagy terjeszthető programot szeretne a Sysinternals forráskódjára alapozni, küldjön egy e-mailt, amely ismerteti a kívánt használat részleteit licensing@....

BELSŐ ADATOK

NFI

Néhány hírlevél vissza én felfedte létezését a DiskEdit eszköz, hogy a Microsoft véletlenül szállított az NT 4 SP4 CD. A DiskEdit egy nagyon hatékony, bár furcsa fájlrendszerszerkezet-megjelenítő, amellyel megvizsgálhatja az NTFS-t és a FAT-t (bár ez az NTFS-támogatás érdekes) lemezen lévő adatstruktúrák. Ha kihagyta az NT 4 SP 4 CD-t, és érdekli az NTFS lemezen lévő struktúrák felfedezése, akkor nem teljesen a sötétben van. A Microsoft kiadott egy NFI (NTFS Information) nevű ingyenes eszközt, amely megérti és képes az NTFS-kötetek belső struktúráit kibocsátni. Bár a kimenete közel sem olyan részletes, mint a DiskEdit, érdekes és tanulságos.

Az OEM támogatási eszközeinek részeként letöltheti az NFI-t a következő címen: http://support.microsoft.com/support/kb/articles/q253/0/66.asp. Az NFI fájlnévvel való futtatása a fájl NTFS MFT rekordját adja meg. Az alábbi példa azt mutatja be, hogy az NFI a metaadatfájl MFT rekordját $Quota memóriaképezi, amely csak akkor létezik, ha engedélyezve van a kvótakezelés egy köteten:

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

A kimenet azt mutatja, hogy a fájl a 24. bejegyzést foglalja el az MFT-ben (a fájlindexe 24), és négy attribútumot tartalmaz, beleértve a standard információkat, a fájlnevet és a két indexgyökeret (az index pedig lényegében a bejegyzések csoportosított listája, például egy könyvtár). Leírom, hogyan használja az NTFS az indexeket a $Quota legújabb Windows 2000 Magazine sorozatban az NTFS v5-en.

Ha egy kötet összes fájlját ki szeretné dobni, adja meg a meghajtóbetűjelet az NFI parancssorában fájlnév nélkül, például. nfi c: Megjelenik az egyes MFT-bejegyzések listája, beleértve az összes metaadatfájlt.

Az NFI más tehetségekkel is rendelkezik, például képes egy szektorszámot lefordítani abba a fájlba, amelyben található. Szeretné tudni, hogy a meghajtón C: található 2345-ös fájlszektor melyikben van? Használja a parancsot nfi c: 2345. Vegye figyelembe, hogy ez nem sikerül a szoftveres RAID-köteteken, például a kötetkészleteken és a csíkkészleteken. Az NFI az NT 4 és a Windows 2000 rendszeren is működik.

REJTETT WIN9X BEÁLLÍTÁSKULCSOK

Két kérdés ezelőtt azt mondtam, hogy én is fedezze a "rejtett Win9x Beállításkulcsok" a következő hírlevélben, és többen emlékeztettek, hogy elfelejtettem. Szóval ebben a hónapban elmondom a rejtett beállításkulcsokat a Windows 9x-ben.

Néhány évvel ezelőtt felfedeztem egy módot a rejtett beállításkulcsok létrehozására a Windows NT-ben. Rejtett, úgy értem, hogy bár láthatja a kulcsokat, hogy az alkalmazás, amely létrehozza őket a Regmon, akkor nem tud írni egy Win32 programot, hogy vizsgálja meg a kulcs értékeit, és nem tudja nézni a kulcsokat a Regedit vagy Regedt32 Beállításszerkesztők. A rejtett kulcsok olyan adatok tárolásához hasznosak, amelyeket nem szeretne, hogy a végfelhasználók módosíthassanak, például egy próbatermék időtúllépési dátumát.

A rejtett beállításkulcs létrehozásának trükkje az volt, hogy felismertem, hogy a natív NT API, amely a Rendszerhívási felület, amelyre a Win32 API épül, megköveteli, hogy a beállításkulcsok meg legyenek adva megszámolt Unicode-sztringekként. A megszámlált Unicode-sztring olyan, amelynek hosszát egy hosszmező jelzi, nem pedig null terminátor jelenléte. A natív API használatával ezért létrehozhat olyan beállításkulcsokat, amelyek null karaktert tartalmaznak, például "test\0test". Mivel a Win32 API Beállításkulcs API-ja null értékű sztringeken alapul, nem lehet null terminátort tartalmazó beállításkulcsot megnyitni a Win32 API használatával. Ha az előző példakulcs nevét RegOpenKey próbálta átadni, vagy RegCreateKey a rendszer úgy kezeli, hogy "test" a sztring csonkolt a null karakternél. Mivel az összes meglévő beállításszerkesztő, beleértve a Windows NT és a Windows 2000 csomagokat is, a Win32 API-t használja, amely a natív API-t használja null karakterbe ágyazott nevek létrehozásához, hatékonyan rejtett kulcsokat hoz létre.

Ez a módszer működik a Windows NT-en, de mi a helyzet a Windows 9x-szel? Nem gondoltam, hogy van mód rejtett beállításkulcsok készítésére a Windows 9x rendszeren, amíg valaki e-mailben nem küldött nekem egy Regmon naplófájlt, amely azt mutatja, hogy az Internet Explorer (IE) hozzáfér olyan kulcsokhoz, amelyek nem jelennek meg a Regeditben. Ennek megtekintéséhez indítsa el a Regmon alkalmazást, és állítsa be a következő szűrőt: "policydata". Ezután indítsa el az IE-t (ez az IE 4 és az IE 5 összes verziójához használható), és látogasson el egy webhelyre. Ha nem lát kimenetet a Regmonban, nyissa meg az IE beállítások konfigurációs párbeszédpaneljét, és győződjön meg arról, hogy a Content Advisor engedélyezve van.

Ha a Content Advisor engedélyezve van, vagy már engedélyezve van a rendszeren, akkor a kulcshoz és annak alkulcsaihoz HKLM\PolicyDatvaló hozzáférések fognak megjelenni. A Regeditben való kereséskor azonban nem talál PolicyData-kulcsot HKEY_LOCAL_MACHINE . Szánjon egy percet, és derítse ki, mi folyik itt.

A válasz az, hogy az IE dinamikusan betölt egy beállításjegyzék-hive-t a RegLoadKey Win32 API-val, beolvassa a szükséges értékeket, majd eltávolítja a kaptárat RegUnloadKey. A kaptár neve el van nevezve C:\Winows\System\Ratings.pol – a fájl rejtett és írásvédett, de a beírással attrib –r –h c:\windows\system\ratings.polfelfedheti.

A Regmonban látható nyomkövetések azokat az információkat mutatják, amelyeket a Content Advisor keres a kaptárban. Ha saját maga szeretné megismerni a tartalmát, töltse le a Regload segédprogramot www.sysinternals.com/regload.zip, és futtassa a következő szintaxissal: regload test c:\windows\system\ratings.pol. Ezután nyissa meg a Regeditet, és tallózással keresse meg a elemet HKLM\test. A megtalált értékek megfelelnek a Content Advisorban megadott beállításoknak, és a hive értékében Users\FileName0 elnevezett konfigurációs fájlhoz kapcsolódnak. Az érték általában az C:\Windows\System\RSACi.ratInternet Content Rating Association által definiált minősítési fájlra mutat. Egyébként előfordulhat, hogy a Content Advisor beállításjegyzék-beállításaiban egy "PleaseMom" nevű, kissé humoros nevű érték jelenik meg, például a HKLM\Test\Users\Default. Ez az érték a "Felügyelő beírhat egy jelszót, amely lehetővé teszi a felhasználók számára a korlátozott tartalmak megtekintését" jelölőnégyzetből származik a Tartalomtanács-beállítások párbeszédpanel Általános lapján.

A Microsoftnak nyilvánvalónak kell lennie annak az oknak, amely miatt a Microsoft elfedné ezeknek a beállításjegyzék-értékeknek a meglétét. Azonban a kialakításuk meglehetősen komoly gyengeséget mutat. Vegye figyelembe, hogy a Content Advisor engedélyezésekor meg kell adnia egy jelszót, amely védi a Content Advisor beállításainak párbeszédpaneljét. Ezt a jelszót a rendszer a következő helyen HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Keytárolja: . Törölje ezt az értéket, és jelszó megadása nélkül is hozzáférhet a Content Advisor beállításaihoz! Most, ha az IE-fejlesztők problémába keveredtek a Content Advisor beállításainak elrejtéséhez, miért hagyják nyitva ezt a hátsó ajtót? Tipikus Microsoft biztonsági kialakítás, azt hiszem. Egyébként a Regloadtal betöltött kulcs eltávolításához egyszerűen írja be a következőt regload test: .

MI VÁRHATÓ?

ÚJ WHISTLER-RENDSZERHÍVÁSOK

A Whistler a Windows 2000 operációs rendszer növekményes fejlődése, amelynek középpontjában a felhasználók nagyobb megbízhatósága és egyszerű migrálása áll a Windows 9x operációs rendszerekről. Tartalmaz azonban néhány kernelmódosítást is. A legláthatóbbak az új rendszerhívások és exportált (eszközillesztők által használható) kernelfüggvények. Legközelebb bemutatom az új kernel API-k előnézetét.

Köszönjük, hogy elolvasta a Sysinternals hírlevelet.

Közzétéve: 2000. november 30. csütörtök, 19:05 ottoh

[Hírlevelek archívuma ^][< 2. kötet, 4. szám][3. kötet, 1 >. szám ]