2000. november 30. – Ebben a problémában:

  1. SZERKESZTŐI

  2. A SYSINTERNALS ÚJDONSÁGAI

    • PsLoggedOn v1.2
    • PsShutdown v1.0
    • PsTools v1.1
    • BgInfo v1.1
    • Tokenmon v1.0
    • Filemon v4.32
    • Regmon v4.32
    • A Windows 2000,3rd Ed.
    • November és Téli Windows 2000 Magazine
    • Sysinternals a Microsoftnál
    • Sysinternals-licencelés
  3. BELSŐ INFORMÁCIÓK

    • NFI
    • Rejtett Win9x beállításkulcsok
  4. MI LESZ A KÖVETKEZŐ?

    • Új Rendszerhívások

SZPONZOR: A TÉLI SZOFTVER

A Sysinternals hírlevelet a Télies szoftver szponzorálja, a weben a www.winternals.com. A Modern szoftver az NT/2K-hez használható fejlett rendszereszközök vezető fejlesztője Windows szolgáltatója. A Téli szoftvertermékek közé tartozik a FAT32 az Windows NT 4.0, az NTFSDOS Professional Edition (a DOS írási/olvasási NTFS-illesztőprogramja) és a Távoli helyreállítás.

A netstat parancs, amely az Windows 9x és az Windows NT/2000 összes verzióját tartalmaz, megmutatja, hogy mely TCP/IP-portok vannak megnyitva a rendszeren, de azt nem, hogy melyik folyamatnál van megnyitva a port. A TcpView Pro, a Télials legújabb monitorozási eszköze nem csupán egy netstat-egyenértékű parancssori eszközt tartalmaz, amely megmutatja, hogy melyik folyamatnál vannak nyitva az egyes portok, de tartalmaz egy grafikus felhasználói felületet, amely ugyanazt az információt és a TCP/IP-tevékenységek valós idejű nyomkövetését jeleníti meg. A valós idejű nyomkövetés felfedi a hálózati hozzáférést adó alkalmazást, a hozzáférés helyi és távoli IP-címeit opcionális DNS-névfeloldással, a hozzáférés típusával, a hozzáférés sikerességével és az átvitt adatok mennyiségével. A TCPView Pro csak 69 dollár. Töltse le a TCPView-alkalmazás 14 napos, teljes körűen működő próbaverzióját Pro a www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Üdvözlök mindenkit!

Üdvözöljük a Sysinternals hírleveleben. A hírlevelenek jelenleg 28 000 előfizetője van.

Az NT-ről 2000 Windows re való Windows egyik előnye a nagymértékben nagyobb megbízhatóság. Számos cikkben megírtam a fejlesztések okait, és ezek elsődlegesen a Driver Verifier nevű eszköz eredménye. Az elindított Verifier konfigurálható úgy, hogy beírja a "verifier" (ellenőrző) szöveget a Start menü Futtatás párbeszédpaneljére, hogy szorosan figyelje az adott eszközillesztők végrehajtását, és hogy megsértse a számos illesztőprogram-programozási szabály valamelyikét. A Verifier egy lépéssel továbbmegy, mint a passzív monitorozás – de a lehetőségeket is tovább példáz; hibafeltételeket jeleznek, például memóriablokkokat foglalnak le az érvénytelen régiókkal lemaradó illesztő számára, és nulláznak bizonyos mezőket az illesztőnek átadott adatstruktúrákban. Ha nagyon nehéz feladatra van szükség, a Verifier képes szimulálni az illesztőprogram kevés memória-feltételét.

A Microsoft az illesztőprogram-aláíró programon keresztül használja a Verifiert, amelyhez a Microsoft által digitálisan aláírt illesztőprogramnak szigorú Driver Verifier teszten kell átesni. Az illesztőprogram telepítésekor a hardvervarázsló ellenőrzi, hogy az illesztőprogram alá van-e írva. Ha nem, akkor vagy figyelmezteti, vagy nem telepíti az illesztőprogramot, attól függően, hogy milyen beállításokat adott meg az Illesztőprogram-aláírási beállítások párbeszédpanelen, amely a rendszer-kis- és Vezérlőpult.

Az a tény, hogy az alapértelmezett illesztőprogram-aláírási házirend figyelmezteti a végfelhasználókat az aláíratlan illesztőprogramokkal kapcsolatban, elég ahhoz, hogy a legtöbb hardvergyártó ne tegye robusztusra és aláírásra az illesztőprogramokat. Az eszközillesztők azonban az illesztőprogram-aláírási házirend által észrevétlenül rá tudnak ásni a rendszerre. Csak az INF-fájlokkal telepített illesztőprogramok (az .inf kiterjesztésű illesztőprogram-telepítőfájlok) ellenőrzik az aláírásokat. A telepítőalkalmazások manuálisan telepítik 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 egyéb, illesztőprogram-összetevőkkel telepített Sysinternals-eszközök manuálisan telepítik az illesztőprogramokat, ezért nem kap figyelmeztetést arról, hogy azokat nem a Microsoft írta alá.

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 szoftver. Ez azonban nem zárja ki a hardverrel kapcsolatos illesztőprogramok kiesését. Az Windows 2000 (www.sysinternals.com/ctrl2cap.htm) Sysinternals Ctrl2cap illesztőprogramja például olyan hardverrel kapcsolatos illesztőprogram, amely úgy telepíthető, hogy megkerülje az illesztőprogram-aláírási ellenőrzéseket. Ez a hurok olyan illesztőprogramok jelenlétét eredményezi a rendszeren, amelyek nem ellenőrizve vannak, ami veszélyeztetheti a rendszer stabilitását (a Sysinternals összes illesztőprogramja a legmagasabb beállításokon van ellenőrizve). A Microsoftnak nem csak azokat, amelyek INF-fájlokkal telepítik az illesztőprogramokat, kényszerítenie kell az aláírás-ellenőrzést.

Miért vagyok ilyen fontos? A CD-ROM szoftverem, amely a piacon legnépszerűbb ilyen típusú szoftver, rendelkezik egy olyan illesztővel, amely reprodukálhatóan összeomlik Windows 2000 SP1 rendszeren. Ha úgy konfigurálom az Illesztőprogram-ellenőrzőt, hogy ellenőrizze, a rendszer nem is fejezi be a rendszerindítást, mielőtt a Verifier észlelni fogja az illesztő első szabálysértéseit, és összeomlik a rendszer. Az illesztőprogram INF-fájl nélkül lett telepítve, így nem figyelmeztetett, hogy aláíratlan. Garantálom, hogy ha a Microsoft szabályzata szigorúbb lenne, akkor ez a szállító kétszer gondolkodna, mielőtt aláíratlan (és hibás) illesztőprogramot szállít.

Kérjük, adja át a hírlevelet a barátainak, akik szerint érdekelheti a tartalma.

Köszönjük!

-Mark (Megjelölés)

A SYSINTERNALS ÚJDONSÁGAI

PSLOGGEDON V1.2

A nyilvánvaló névváltozás mellett a LoggedOn helyett PsLoggedOn névre vált, ez a parancssori eszköz, amely képes megmutatni, hogy ki jelentkezett be helyileg és a helyi vagy távoli rendszeren található erőforrás-megosztásokkal, rendelkezik néhány új funkcióval. Az első az "-l" parancssori kapcsoló, amely felhasználói visszajelzések eredményeként jött létre. Sokan használják a PsLoggedOnt annak lássa, hogy van-e helyileg bejelentkezett fiók a kiszolgálóikra. Előfordulhat például, hogy vannak olyan felhasználók, akik fájlmegosztásokkal jelentkeztek be, de ez nem releváns a fiók frissítésével vagy a kiszolgáló távoli felügyeletével kapcsolatos döntések meghozatalakor.

A PsLoggedOn második új funkciója nem csak azt mutatja meg, hogy ki van bejelentkezve, hanem azt is, hogy mikor történt a bejelentkezés. A PsLoggedOn ingyenes bejelentkezési időt szerez be az erőforrás-megosztásból, ha Win32 API-t (NetSessionEnum) használ az erőforrás-megosztási bejelentkezések számbavételekor (a parancssori Net-parancs a NetSessionEnum parancs használatával is enumerál munkameneteket). Nincs azonban olyan Win32 API, amelyből megtudhatja, hogy ki jelentkezett be helyileg a rendszerbe, sokkal kevesebbet, amikor bejelentkezett.

Annak megállapításához, hogy ki jelentkezett be helyileg a rendszerbe, a PsLoggedOn számba veszi a számítógép beállításkulcsában található biztonsági azonosítókat HKEY_USERS (SID-ket). Amikor valaki helyileg jelentkezik be egy számítógépre a konzolon vagy egy szolgáltatáson keresztül, a profilja be lesz töltve a HKEY_USERS kulcsba. Az alkalmazások a kulcson keresztül férhetnek hozzá a profiljuk Beállításjegyzék-beállításaihoz, mert a rendszer ezt a kulcsot az adott profiljukra mutató szimbolikus hivatkozásként HKEY_CURRENT_USER kezeli a HKEY_USERS alatt. A PsLoggedOn így a számítógép kulcsában talált SID-ket a megfelelő felhasználónévre lefordítva tudja, hogy ki van helyileg HKEY_USERS bejelentkezve. A PsLoggedOn a segítségével csatlakozik egy távoli számítógép beállításjegyzékéhez, amikor egy távoli rendszerbe bejelentkezett felhasználók RegConnectKey listázához irányítja.

Egy hasonló trükk segítségével kideríti, hogy egy felhasználó mikor jelentkezett be. Amikor a WinLogon-folyamat betölti a felhasználói profilt a bejelentkezés után, a WinLogon létrehoz egy volatile (nem mentve a lemezen lévő profilba) alkulcsot a profiljukban( megfelelően, volatile HKEY_USERS environment). A beállításjegyzék a beállításkulcsok utolsó módosításának időbélyegeit tárolja, és mivel a rendszer létrehozásuk után nem módosítja a volatile environment alkulcsokat, a PsLoggedOn a volatile environment alkulcs időbélyegének lekért értékével meg tudja határozni, hogy a felhasználó mikor jelentkezett be.

Töltse le a PsLoggedOn v1.2-t teljes forrással itt:
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

Ha bármikor le kellett volna állnia vagy újra kellett indítania egy helyi vagy távoli Windows NT/2000 rendszert, akkor töltse le a PsShutdownt. A PsShutdown a Shutdown Windows NT/2000 Resource Kit eszköz klónja. Ugyanazokra a parancssori argumentumokra van szükség, amelyek lehetővé teszik a leállítás előtti késleltetés megadását, újraindítást vagy újraindítást, opcionális üzenetet, amely a rendszerbe jelenleg bejelentkezett bármely felhasználó számára megjeleníthető, valamint a leállítani vagy újraindítani kívánt számítógép nevét.

Töltse le a PsShutdown v1.0-s www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

Valószínűleg észrevette, hogy a Sysinternals egyre több olyan eszközt tartalmaz, amelyek a "Ps" előtaggal kezdődnek. Az első a PsList, egy parancssori eszköz, amely a helyi vagy távoli nt/2000 rendszeren futó aktív folyamatokra vonatkozó információkat Windows listázza. Megadtuk a PsList nevet, mert UNIX parancssori folyamatinformációs eszköz neve "ps". Az előtag lekért következő eszköze a PsKill parancssori segédprogram volt, amely lehetővé teszi az NT/2000 rendszereken helyi vagy távoli Windows futó folyamatok megszüntetését. A PsKill a "Ps" előtagot adta meg, mert tökéletesen illeszkedett a PsListhez.

Idővel olyan eszközöket fejlesztettem, amelyek a PsList és a PsKill alapvető jellemzőivel rendelkeznek: parancssori alapúak, és a helyi vagy távoli Windows NT/2000 rendszeren működnek. Az ElogList segítségével például kiadhatja egy rendszer eseménynaplóinak tartalmát, a GetSid pedig megmutatta egy számítógép vagy egy adott fiók BIZTONSÁGI azonosítóját. Nemrég úgy döntöttünk, hogy összekötöm ezeket az eszközöket úgy, hogy az összes "Ps" előtagot elérhetővé teszim egyetlen PsTools nevű csomagként.

A PsList, PsKill, valamint az átnevezett PsLogList és PsGetSid eszközöket tartalmazó PsTools összesen hét eszközből áll. Ha egy Sysinternals eszközt lát a "Ps" előtaggal, automatikusan tudni fogja, hogy ez egy helyileg és távolról is használható parancssori eszköz.

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

BGINFO V1.1

A rengeteg felhasználói visszajelzés eredményeként Bryce frissítette a BgInfo segédprogramot, amely asztali háttérképet állít be a rendszer konfigurációjának testreszabható információinak megjelenítéséhez a kapott felhasználói visszajelzések alapján. Alapértelmezés szerint a BgInfo 10 másodpercig számol a párbeszédpanelen megadott beállítások alkalmazása előtt, de egy új parancssori kapcsoló , amely lehetővé teszi a visszaszámlálás teljes módosítását vagy /timer megszüntetését. Ez kényelmesebbé teszi a BgInfo bejelentkezéskori szkriptbe vagy parancsikonként való bevésést egy profil Indítás mappájába.

Az 1.1-es verzió más új funkciókat is tartalmaz, például egy tetszőleges ön által definiált szöveg megjelenítésének képességét, valamint több előre definiált információkategóriát. A BgInfo 1.1-es verzió által létrehozott asztali bitmap általában kisebb is, így minimalizálja a BgInfo asztali memóriaigényét.

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

TOKENMON V1.0

A Tokenmon a Sysinternals szolgáltatásból letölthető monitorozási eszközök legújabb kiegészítője. A Tokenmon, amely ugyanazokkal a felhasználói felülettel rendelkezik, mint a Regmon és a Filemon, az NT/2000 rendszerek jelentős biztonsági tevékenységét Windows figyeli. Mi az a "jelentős" biztonsággal kapcsolatos tevékenység? Az NT/2000 Windows a jogkivonat objektuma, amely egy fiók biztonsági azonosítóját, csoport-SID azonosítóit és jogosultságait tartalmazó adatstruktúra. Amikor egy folyamat megpróbál hozzáférni egy biztonságos objektumhoz, a biztonsági referenciafigyelő a hozzáférési ellenőrzés részeként a jogkivonatában az AZONOSÍTÓkat használja. 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 egyik hatékony (és szabadalmazott) jellemzője 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 egy alternatív identitást használjon megszemélyesítési jogkivonattal. A kiszolgálóalkalmazások akkor használják ki a megszemélyesítést, amikor az ügyfél nevében férnek hozzá az erőforrásokhoz, amikor az ügyfél identitását használják a hozzáférés időtartamára.

A Tokenmon ugyanúgy telepíti a rendszerhívási hookokat, mint a Regmon a beállításjegyzék API-jaihoz, hogy monitorozással figyelje a jogkivonatok létrehozását és törlését, a jogosultságok engedélyezését és letiltését, valamint a megszemélyesítést. A Tokenmon az NT/2000 kernel által biztosított folyamat-létrehozási hookokat is használ a folyamatok létrehozásának és törlésének figyelése érdekében, valamint más API-kat annak meghatározásához, hogy a felhasználó mikor jelentkezik be és mikor jelentkezik ki.

A Tokenmon teljes forráskódja közzé van adva, és érdemes megvitatni néhány érdekes technikát a kódban. A Tokenmon az NtCreateToken rendszerhívás gombra való becsatolása által észleli a bejelentkezési eseményt. Ezt használják a bejelentkezési közvetítők, például a WinLogon, amikor létrehoznak egy kezdeti jogkivonatot az új bejelentkezési munkamenet első folyamatához. Az első folyamat által létrehozott folyamatok öröklik az első jogkivonat másolatát. Az kijelentkezés észlelése érdekében a Tokenmon a kernel módú SeRegisterLogonSessionTerminatedRoutine függvényen keresztül regisztrál az kijelentkezésért, amely hálózati átirányítóknak nevezett fájlrendszer-illesztőprogramok előnyére létezik, és amely a bejelentkezési munkamenet adatait gyorsítótárazza, és a felhasználó kijelentkezésekor meg szeretné tisztítani az adatokat. A hálózati átirányítók a fájlmegosztási ügyfél-/kiszolgálókapcsolatok ügyféloldalát valósítják meg.

A Tokenmon egy másik érdekes megvalósítási részlete, hogy a Tokenmon hogyan köti össze a figyelt API-kat. A Tokenmon-hookokat használó API-k némelyikét nem exportálják az eszközillesztők, hanem felhasználói módú NTDLL.DLL kódtárba exportálják, hogy azok a Win32-nek megfelelő alkalmazásokat használják. A Regmon-hoz illesztő összes Registry API-t rendszermag módban exportálja a rendszer, így a Regmon-eszközillesztő le tudja szerezni a rendszer hívószámait, és a rendszerhívási táblázatot ennek megfelelően kapcsolhatja össze. Az illesztőprogramok által nem használt API-k esetében a Tokenmon GUI-nak be kell szereznie a hívószámokat a NTDLL.DLL exportálási szolgáltatásával, majd át kell adnia a számokat az illesztőprogramnak, hogy az illesztő össze tudja hívni a rendszerhívási táblát. Így a Tokenmon bemutatja, hogyan kapcsolhatók össze a rendszerhívások, amelyek nincsenek kernel módban exportálva.

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

FILEMON V4.32

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

A Filemon korábbi verziói kötelező helyettesítő karakterekkel kellett megadnia a szűrőket. Ha például figyelni szeretné a temp könyvtár hozzáférését a meghajtón, meg kellett adnia egy ehhez hasonló C: szűrőt: " c:\temp\* ". Az új szűrési szintaxis esetén a helyettesítő karakterek használata nem kötelező, így míg a példaszűrő működne, a c:\temp " eredmény ugyanaz lenne. A Filemon emellett a megjelenített összes mezőre alkalmazza a 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 bizonyos adatokat tartalmazó kérések figyelését a másik oszlopban, ami korábban nem volt lehetséges.

A 9x/Me rendszereken Windows Filemon felhasználói mostantól teljes UNC szintaxissal látják a Filemon megjelenítési útvonalneveket a távoli erőforrások elérésekor. 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 már használta Windows Filemont Windows NT/2000-en, akkor a "DASD" szöveget láthatta számos hozzáférés útvonaloszlopában ("a DASD a "Direct Access Storage Device" kifejezésből származik, amely kifejezés a Microsoft által a fájlrendszerstruktúrákat megkerülő kötetekhez való hozzáférés leírására használatos). Az NTFS-köteteken végzett tevékenységek nagy része esetén a DASD már a múlté. Ehelyett az olvasott és írt NTFS-metaadatfájlok neveit fogja látni. Egy MFT-rekord frissítése például korábban egy DASD kimeneti sort eredményezett volna, de most már az "$Mft" elérésének, az MFT belső metaadatfájlnevének hozzáféréseként fog látni.

Miért nem mutatta meg korábban a Filemon a metaadatfájlneveket, és hogyan szerezheti be ezeket a neveket? Az NTFS-metaadatfájlokat képviselő fájlobjektumok nem tárolnak fájlnevet, ezért a Filemon nem tudja kinyerni a nevet a fájlobjektumból. A Filemon alternatív metódusa a fájl nevének lekért és a fájlrendszer-illesztőprogram lekérdezésére sem működik NTFS-metaadatfájlok esetén. Bár az NTFS a metaadatfájlok nevére válaszol, az NT 4-en található NTFS véletlenszerűen okoz összeomlásokat, win2k rendszeren pedig az NTFS időnként lefagy, amikor válaszol az ilyen lekérdezésekre.

A Filemonnak ezért egy trükknek kell kihozni a metaadatfájl-neveket. Ha egy OLYAN kérést lát, amely egy NTFS-kötet egy fájlobjektumához van irányítva név nélkül, a rendszer a fájl indexére vonatkozó lekérdezést küld az NTFS-nek. Ez megegyezik a GetFileInformationByHandle Win32-függvény által visszaadott indexszel, az NTFS-köteteken található fájlok esetén pedig az index a fájl MFT-indexe. Az MFT első 16 bejegyzése adott metaadatfájlok számára van fenntartva, ezért az adott tartományba vonatkozó index alapján a Filemon egyszerűen a saját táblájában keres metaadatfájl-nevet.

Sajnos továbbra is látni fogja a DASD-nek a FAT-kötetek könyvtár-metaadat- és fájlfoglalási táblához való hozzáférését, mert a FAT nem tárolja a könyvtár-metaadatfájlok vagy a FAT-fájlok nevét. Meglepő, hogy milyen gyakran fér hozzá az NTFS$LogFile fájlhoz. A Ntfs a Tárolóban véletlenül tárolja a metaadatfájlok nevét, így a trükk szükségtelen a Következőn: .

A Filemon utolsó fejlesztése lehetővé teszi, hogy a Filemon ezredmásodperc felbontással mutassa a napi időbélyegeket. Ehhez a támogatáshoz a Windows 9x/Me Filemon illesztőben a 9x/Me kernel időzítési függvényének Windows miatt volt szükség. További információért tekintse meg a forráskódot.

Töltse le a Filemon 4.32-es és a www.sysinternals.com/filemon.htm.

REGMON V4.32

A regmon változásai nem annyira jelentősek, mint a Filemon módosításai, de a Regmon már ugyanazt az intuitívabb szűrési szintaxist támogatja, mint a Filemon, és a Filemonhoz hasonló szűrőket alkalmaz az összes mezőre. Ezredmásodperc felbontást is képes mutatni az időbélyegek alapján.

Azok, akik 2000-ben kezdték el játszani a Windows 2000 utódját, észrevehették, hogy a Regmon Crash Fogr korábbi verziói már az első lépésekben felfigyeltek rá. Ennek az az oka, hogy a Microsoft a rendszerhívási táblát helyezte el, amelyet a Regmon úgy módosít, hogy beszúrja a hookokat az írás által védett memóriába. A Regmon 4.32-es verziójának használata egy olyan technikával oldja meg a rendszert, amelyhez nem adott meg forráskódot a Microsoft kéréséhez, mert a technika a Ther utolsó kiadásában meg is szakíthatja a működését, és a Microsoft a rendszerhívások összehívásának támogatását vizsgálja. Windows NT-t nem arra tervezték, hogy támogassa a rendszerhívások hordozását. Ezt a regmon első kiadásának 1996 közepén való használatának úttörőjeként alakítottuk ki.

Itt 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 az Windows NT/2000-en. Számos esetben előfordulhat, hogy egy adott alkalmazás megfelelően működik a rendszergazdai fiókból való futtatáskor, de nem egy rendszer-jogosultságú felhasználótól, ahol a Regmon és a Filemon hasznos lenne meghatározni az alkalmazás sikertelen működését (ez á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 rendszer-jogosultságú fiókból való futtatása azonban sikertelen lesz, mert a Filemon és a Regmon egyaránt telepít eszközillesztőket, ami rendszergazdai jogosultságot igényel.

Van azonban egy trükk, amelyet meg kell dolgoznia: Ha rendszergazdaként jelentkezik be, és elindítja a Filemont vagy a Regmont, akkor a jogosultságokkal nem rendelkező fiókokból is futtathatja őket. Ennek az az oka, hogy a Filemon és a Regmon az első végrehajtáskor telepít egy illesztőt, és a következő végrehajtások során hozzáférnek a már betöltött illesztőprogramhoz. Mivel az illesztőben nem valósítok meg semmilyen biztonságot, a rendszer-jogosultságokkal nem felkelt felhasználók futtathatja 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, így én és azok, akik a segédprogramok nem rendszer-jogosultságú fiókokból való futtatását kérik, ezt funkcióként tekintse meg.

Töltse le a Regmon 4.32-es és a teljes forráskódot a www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

Az egyik alkalmazás, amelyről a legtöbb felhasználói visszajelzést kaptam, meglepő módon a DebugView. Ez az új verzió jelentős fejlesztéseket tartalmaz, amelyek számos funkció- és funkciókérésre választ adnak, és a DebugView minden korábbinál hatékonyabb lesz.

A legtöbb látható módon a DebugView mostantól akár öt különböző kiemelési szűrőt is támogat, amelyek mindegyikének saját testreszabható színei vannak. Ez lehetővé teszi, hogy egyidejűleg különböző kulcsszavakat ad vissza a hibakeresési kimenetben, és könnyen meg tudja különböztetni őket. A DebugView emellett ugyanazt az új szűrési szintaxist valósítja meg, mint a Filemon és a Regmon, így a helyettesítő karakterek nem kötelezők a karakterláncok alsztring-egyeztetéséhez.

A DebugView korábbi verzióival kapcsolatban kaptam egy bejelentést, hogy még ha csak rögzíteni is szeretné a Win32 hibakeresési kimenetét, akkor is rendszergazdai jogosultságra van szüksége a DebugView futtatásához, mert a DebugView nem futna, ha nem tudná telepíteni az eszközillesztőjét. Ez az új verzió még olyan fiókokból is fut, amelyek nem rendelkezik speciális jogosultságokkal. Ha nem tudja telepíteni vagy elérni az illesztőprogramját, egyszerűen letiltja a kernelmódú rögzítéssel kapcsolatos menüpontokat.

Két funkció, amelyek megkönnyítik a DebugView számára a kimenet automatikus rögzítését a bejelentkezéskor, a kis mérettől a tálcáig lehetőség és a parancssori kapcsolók támogatása. Parancssori kapcsolók használatával elindíthatja a DebugView nézetet a rendszertálcán és a naplókimenetben, amit egy fájlba rögzít, majd a DebugView megnyitása után egy menüpont segítségével válthat a kis méretű gomb viselkedése között a normál működés minimalizálása és a rendszertálca minimalizálása között.

Azok a felhasználók, akik a DebugView alkalmazást távoli munkamenetekben futtatják Windows 2000 terminálszolgáltatáson, a DebugView mostantól rögzíti a távoli munkamenetben futó alkalmazások által létrehozott Win32-kimenetet, és opcionálisan a konzol-munkamenetből. Ez a COM-kiszolgálók és a Win32-szolgáltatások távoli hibakereséséhez hasznos, mivel az ilyen típusú programok a konzol-munkamenetben futnak.

Végül a DebugView mostantól működik a Betar Beta 1-ben, és támogatja a kernel módú DbgPrint függvény számos új Foger változatának kimenetének rögzítését.

Töltse le a DebugView 4.02-es www.sysinternals.com/dbgview.htm.

WINDOWS 2000, 3. KIADÁS

A 2000-es év Windows hivatalos könyve már elérhető! Ez a Kiadás, amelyet David Plugin (www.solsem.com) és Mark Russinovich is koaforált, több mint 40%-kal nagyobb az előzőnél, és ú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 leállítás, valamint a tárolás terén. Emellett tartalmaz egy CD-t is, amely számos hatékony eszközt tartalmaz, amelyek máshol nem érhetők el, Windows 2000 belső vizsgálathoz.

Az egyik olyan eszköz, amelyet kifejezetten a könyvhöz írtam, a LiveKd program, amely lehetővé tette, hogy futtassa a Microsoft kernel hibakeresőit (i386kd és WinDbg) egy élő rendszeren, mintha összeomlási memóriaképet nézne. A könyvben bemutatott kísérletek nagy része élő rendszeren működik a LiveKd használatával való futtatáskor. A LiveKd egy fájlrendszerszűrő-illesztőprogram telepítésével működik, amely úgy mutatja be a számítógép fizikai memóriáját a Microsoft hibakeresője számára, mintha az egy összeomlási memóriaképfájl lenne. A LiveKd létrehoz egy 0 hosszúságú pszeudo-memóriaképfájlt, és amikor a hibakereső beolvassa a fájlt, a LiveKd fizikai memóriából ad vissza adatokat. A LiveKd 1.0-s és több elérhető vírusolvasó közötti inkompatibilitást javító LiveKd-javításért tekintse meg a könyv hiba- és frissítésoldalát.

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

NOVEMBER ÉS TÉLI WINDOWS 2000 MAGAZINE

Kíváncsi arra, hogy pontosan mi változott az NTFS v4 és az NTFS v5 között? Ha igen, tekintse meg a 2000-es év novemberi és téli problémáiról Windows sorozatot. Az 1. rész az újraelemzési pontokat, a könyvtár-illesztéseket, a kötetcsomópontokat, a kvótatámogatást és az összevont biztonsági beállításokat ismerteti. A 2. rész lezárul a titkosítás, a streamek, az elosztott hivatkozáskövetés és a változásnaplók közelebbről való betekintését. Mindkét cikk mélyebbre ássa a többinél, és bemutatja a lemezen végrehajtott módosításokat és az új funkciók belső működését.

A cikkekben nem az a helyzet, hogy az NT 4-hez Windows NTFS fájlrendszer nem igazán verziószám

Az összes publikációra mutató hivatkozásokat a www.sysinternals.com/publ.htm.

SYSINTERNALS AT WWW.MICROSOFT.COM

A Sysinternals számos új Microsoft tudásbázis (KB) cikkben jelent meg a legutóbbi hírlevele óta, és a Sysinternals-ra hivatkozó régebbi TUDÁSBÁZIS-cikkeket is nyomon követtem.

  • 260513. negyedévi prB: Hiba történik a Visual Studio 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 a Filemon használatán Exchange 5.0-s verziófrissítési problémák elhárításához, egy Filemon-mintakimeneti vonallal és a szűrők beállításával kapcsolatos javaslatokkal.

  • Q269383 PRB: "Error Accessing the System Registry" (Hiba történt a beállításjegyzék 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 referenciát ebből a cikkből, amely annak meghatározásához ismerteti, hogy a Visual Basic IDE-jelentések Hivatkozások párbeszédpanele miért nem tud hozzáférni egy beállításkulcshoz a Seagate Crystal Reportsban található hiba miatt, amely helytelen engedélyeket alkalmaz több kulcsra.

  • 269251. NEGYEDÉVI HIBA: A Windows telepítője lefagyhat a termékek számbavételekor
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Itt ismét ki van emelve a regmon, ahol egy telepítő automatizálási Windows látható.

  • 276525. negyedév Előfordulhat, hogy a számítógép nem válaszol a megnyitott leírók figyelésekor
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    Az NtHandle felelős azért, hogy felfedje a Windows NT 4 SP6a programhibáját, amelyben a kernel bizonyos körülmények között lefagyna az NtHandle használata során. A Microsoft velem együtt oldotta meg a problémát, és kiadott egy gyorsjavítást. Ha az NT 4 rendszer lefagy az NtHandle használata esetén, kövesse az erre a cikkre mutató hivatkozást.

  • A Q160660 Ntregmon.exe a STOP 0x0000001E az új szervizcsomaggal
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Ez az utolsó egy régi, de goodie. A Regmon első verziója nem szoftveres rendszerhívási számokkal javítja ki a rendszerszolgáltatás tábláját a beállításjegyzék API-jaihoz való kapcsolás érdekében. Mivel a rendszerhívási számok időnként változnak a szervizcsomagok között, ez a technika elég sebezhető, és nem kellett védekező módon kódolni erre a kódra (Andrew Schulman tanácsára, aki félt, hogy a Regmon megtörne). Persze az SP3 is bevezetett néhány új rendszerhívást, és a Regmon összeomlott, amikor helytelen rendszerhívásokat hoz létre. Bár ez a temett több ember számára is felbosszantott, kihoztam belőle a saját tudásbáziscikkemet!

SYSINTERNALS-LICENCELÉS

Annak ellenére, hogy a Sysinternals szolgáltatásból letöltött szoftver ingyenes, tehát díj fizetése nélkül is használhatja, nem terjesztheti újra, és nem származtathatja a Sysinternals forráskódból terjesztett termékeket. Ha például egy olyan vállalatnál dolgozik, ahol több felhasználó is hasznosnak találja a Sysinternals adott eszközeit, akkor előfordulhat, hogy nem teszi közzé az eszközöket belső megosztáson vagy webhelyen. Ehelyett helyezzen el egy hivatkozást a webhelyen az egyes eszközök Sysinternals-kezdőlapjain. Ez azt is segít, hogy munkatársai mindig a legújabb verziókat töltsék le.

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

BELSŐ INFORMÁCIÓK

NFI

Néhány hírlevelemből kiderült, hogy létezik a DiskEdit eszköz, amit a Microsoft véletlenül az NT 4 SP4 CD-n szállított. A DiskEdit egy rendkívül hatékony, bár egyszerű fájlrendszer-struktúrát megjelenítő megjelenítő, amely segítségével megvizsgálhatja az NTFS és a FAT fájlrendszert (bár ez az NTFS-támogatás érdekes) a lemezen lévő adatstruktúrákban. Ha kihagyta az NT 4 SP 4 CD-t, és meg szeretne ismerkedni a lemezen található NTFS-struktúrákkal, akkor azonban nem teljesen a sötétben van. A Microsoft kiadott egy NFI (NTFS-információ) nevű ingyenes eszközt, amely megérti és ki tudja szabadítani az NTFS-kötetek belső szerkezetét. Bár a kimenete közel sem olyan részletes, mint a DiskEdit kimenete, érdekes és feltáró.

Az NFI-t az OEM támogatási eszközeinek részeként a következő ről töltheti le: http://support.microsoft.com/support/kb/articles/q253/0/66.asp. Ha az NFI-t fájlnévvel futtatja, a rendszer kiadja a fájl NTFS MFT-rekordját. Az alábbi példa azt mutatja be, hogy az NFI a metaadatfájl MFT-rekordjának biztonsági mentése. Ez a fájl csak akkor létezik, ha egy köteten engedélyezve van $Quota a kvótakezelés:

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 foglalja el az MFT 24. bejegyzését (a fájlindexe 24), és négy attribútumot tartalmaz, beleértve a szabványos információkat, a fájlnevet és a két indexgyökeret (és az index lényegében a bejegyzések, például egy könyvtár) egy listában található. Leírjuk, hogyan használja az NTFS a legújabb Windows $Quota 2000 Magazine sorozat NTFS v5-ös verziójában.

A köteten található összes fájl memóriaképének megadásához adja meg a meghajtó betűjelét az NFI parancssorában fájlnév (például ) nfi c: nélkül. Megjelenik az összes MFT-bejegyzés listája, beleértve az összes metaadatfájlt.

Az NFI más képességekkel is rendelkezik, például képes szektorszámokat lefordítani arra a fájlra, amelyben található. Szeretné tudni, hogy melyik fájl szektorban található a meghajtón a 2345-ös C: fájl? Használja a nfi c: 2345 parancsot. Vegye figyelembe, hogy ez a szoftveres RAID-kötetek, például kötetkészletek és csíkkészletek esetén sikertelen lesz. Az NFI NT 4 és 2000 Windows is működik.

REJTETT WIN9X BEÁLLÍTÁSKULCSOK

Két évvel ezelőtt említettem, hogy a következő hírlevelemben a "rejtett Win9x beállításkulcsokkal" is ki fogunk fedni, és többen is emlékeztettek rá, hogy elfelejtettem. Ebben a hónapban tehát a 9x-es 9x-es, rejtett beállításkulcsokat Windows el.

Néhány évvel ezelőtt felfedeztem, hogyan hozhatok létre rejtett beállításkulcsokat a Windows NT-n. Rejtettség alatt azt értem, hogy bár láthatja a kulcsokat, amelyekhez az alkalmazás a Regmon használatával hozzáfér, nem írhat olyan Win32-programot, amely a kulcs értékeit nézi meg, és a Regedit vagy a Regedt32 beállításszerkesztővel sem tudja megnézni a kulcsokat. A rejtett kulcsok olyan adatok tárolására hasznosak, amelyek módosítását nem szeretné lehetővé tenni a végfelhasználók számára, például egy próbaverziós termék időtúllépési dátumát.

A rejtett beállításkulcsok készítésének trükkje az volt, hogy a natív NT API, amely a Win32 API-t használó rendszerhívási felület, megköveteli, hogy a beállításkulcsok megszámolt Unicode-sztringekként legyen megadva. A megszámolt Unicode-sztring egy olyan sztring, amelynek hosszát egy hosszmező jelzi, nem pedig null lezáró jelenléte. A natív API-val tehát létrehozhat null karaktert tartalmazó beállításkulcsokat, például a következőt: "test\0test" . Mivel a Win32 API Beállításkulcs API-ja null értékű sztringekon alapul, nem lehet olyan beállításkulcsot megnyitni, amely null lezárót tartalmaz a Win32 API használatával. Ha az előző példakulcs nevét próbálta volna átadhatja a vagy a számára, akkor az a következőként lenne kezelve: , és a sztringet a null karakternél RegOpenKeyRegCreateKey"test" csonkoltuk. Mivel az összes meglévő beállításszerkesztő, beleértve az Windows NT és az Windows 2000 csomagba csomagolt beállításszerkesztőket is, a Win32 API-t használja, amely a natív API-val hoz létre null karakterrel beágyazott neveket, gyakorlatilag rejtett kulcsokat hoz létre.

Ez a módszer nt Windows működik, de mi a helyzet a Windows 9-esével? Nem hiszem Windows, hogy van mód rejtett beállításkulcsok 9x-re való beállítására, amíg valaki el nem küldött egy Regmon-naplófájlt, amely azt mutatja, hogy Internet Explorer (IE) olyan kulcsokat fér hozzá, amelyek nem jelennek meg a Regeditben. Ha ezt saját maga is látnia kell, indítsa el a Regmont, é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 működik), és látogasson el egy webhelyre. Ha nem lát kimenetet a Regmonban, válassza az IE beállításkonfigurációs párbeszédpanelé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 hozzáféréseket fog látni a kulcshoz és annak HKLM\PolicyDat alkulcsaihoz. A Alatt azonban nem fog találni PolicyData kulcsot, amikor a HKEY_LOCAL_MACHINE Regedit elembe keres. Egy perc alatt kiderítheti, mi történik.

A válasz az, hogy az IE dinamikusan betölt egy Beállításjegyzék-struktúrát a Win32 API használatával, be olvassa a szükséges értékeket, majd eltávolítja a RegLoadKey struktúrát a RegUnloadKey használatával. A struktúra neve – a fájl rejtett és csak olvasható, de a beírásával C:\Winows\System\Ratings.polattrib –r –h c:\windows\system\ratings.pol felfedheti.

A Regmonban látható nyomkövetések megmutatják a Content Advisor által a struktúra által keresett információkat. Ha saját maga szeretné felderíteni a tartalmát, töltse le a Regload segédprogramot a www.sysinternals.com/regload.zip, és futtassa a következő szintaxissal: regload test c:\windows\system\ratings.pol . Ezután nyissa meg a Regedit et, és tallózással HKLM\test keresse meg a et. A megtalált értékek megfelelnek a Content Advisorban megadott beállításoknak, és a struktúra értékében megnevezett konfigurációs Users\FileName0 fájlhoz kapcsolódnak. Az érték általában a C:\Windows\System\RSACi.rat fájlra mutat, amelyet az Internetes tartalom minősítési társítása határoz meg. Előfordulhat, hogy a Content Advisor beállításjegyzék-beállításaiban egy némileg eltérő "PleaseMom" nevű érték látható, például a HKLM\Test\Users\Default alatt. Ez az érték a "Supervisor can type a password to allow users to view restricted content" (A felügyelő begépelhet egy jelszót a korlátozott tartalmak megtekintéséhez) jelölőnégyzetből származik a Content Advisor beállítások párbeszédpanelének Általános lapján.

A Microsoftnak nyilvánvalónak kell lennie annak, hogy a Microsoft eltenné ezeknek a beállításjegyzék-értékeknek a meglétét. A tervezésük azonban elég súlyos gyengeséggel rendelkezik. Vegye figyelembe, hogy ha engedélyezi a Content Advisort, meg kell adnia egy jelszót, amely védi a Content Advisor beállításainak párbeszédpanelét. Ezt a jelszót a következő HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key tárolja: . Törölje ezt az értéket, és a presto parancs beírása nélkül is hozzáférhet a Content Advisor beállításaihoz. Ha az IE-fejlesztők nem tudják elfedni a Content Advisor beállításait, miért nem tudják nyitva hagyni ezt a hátsó ajtó? A Microsoft tipikus biztonsági kialakítása, azt hiszem. By the way, to unload the key youloaded with Regload just type regload test .

MI LESZ A KÖVETKEZŐ?

ÚJ RENDSZERHÍVÁSOK A SYSTEMRBEN

A The Windows 2000 operációs rendszer növekményes fejlődése, amely a felhasználók nagyobb megbízhatóságára és a 9x Windows való egyszerű áttelepítésére összpontosít. Ez azonban kernelváltozásokat is tartalmaz. A legláthatóbb néhány új rendszerhívás és exportált (eszközillesztők számára elérhető) kernelfunkció. A következő alkalommal az új kernel API-k előzetesét adjuk meg.


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

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

[Hírlevelek archívuma ^][ Volume 2, Number 4][Volume 3, Number 1 ]

[Hírlevelek archívuma ^][ Volume 2, Number 4][Volume 3, Number 1 ]

A rendszerek belső hírlevele, 2. kötet, 5. szám

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