Zavolejte vzdálené postupy RPC ultrazvukový skener. Mechanismus vzdáleného volání procedur - RPC

Velmi důležitý mechanismus pro aplikace klient-server poskytuje RPC ( Vzdálené volání procedury). RPC byl vyvinut společností Sun Micrsystems a je sbírkou nástrojů a knihovních funkcí. Na RPC fungují zejména NIS (Network Information System) a NFS (Network File System).

Server RPC sestává ze systému takových procedur, ke kterým má klient přístup odesláním požadavku RPC na server spolu s parametry procedury. Server zavolá určenou proceduru a vrátí návratovou hodnotu procedury, pokud existuje. Aby byla na stroji nezávislá, všechna data vyměňovaná mezi klientem a serverem jsou převedena na tzv. externí datovou reprezentaci ( Externí reprezentace dat, XDR). RPC komunikuje s UDP a TCP sockety pro přenos dat ve formátu XDR. Sun prohlásil RPC za veřejnou doménu a jeho popis je k dispozici v řadě dokumentů RFC.

Někdy změny v aplikacích RPC zavádějí nekompatibilitu do procedury volání rozhraní. Jednoduchá změna by samozřejmě způsobila selhání serveru všech aplikací, které stále čekají na stejná volání. Proto mají programy RPC přiřazena čísla verzí, obvykle začínající 1. Každý novou verzi RPC sleduje číslo verze. Server může často nabízet několik verzí současně. Klienti v tomto případě určují číslo verze, kterou chtějí používat.

Síťová komunikace mezi servery RPC a klienty je trochu zvláštní. RPC server nabízí jednu nebo více systémových procedur, každá sada takových procedur se nazývá program ( program) a je jednoznačně identifikován číslem programu ( číslo programu). Seznam názvů služeb je obvykle uchováván v /etc/rpc, jehož příklad je uveden níže.

Příklad 12-4. Ukázkový soubor /etc/rpc

V sítích TCP/IP byli autoři RPC postaveni před úkol namapovat čísla programů na běžné síťové služby. Každý server poskytuje port TCP a UDP pro každý program a každou verzi. Obecně platí, že aplikace RPC používají UDP k přenosu dat a vrátí se k TCP, když se data, která mají být přenášena, nevejdou do jednoho datagramu UDP.

Klientské programy samozřejmě musí mít způsob, jak zjistit, který port odpovídá číslu programu. Použití konfiguračního souboru by bylo příliš neflexibilní; Vzhledem k tomu, že aplikace RPC nepoužívají vyhrazené porty, není zaručeno, že port není obsazen nějakou aplikací a je nám dostupný. Aplikace RPC si tedy vybírají libovolný port, který mohou přijímat, a registrují jej démon portmapper. Klient, který chce kontaktovat službu s daným číslem programu, nejprve požádá portmappera o zjištění čísla portu požadované služby.

Tato metoda má tu nevýhodu, že zavádí jediný bod selhání, podobně jako inetd démon Tento případ je však o něco horší, protože když portmapper selže, všechny RPC informace o portech jsou ztraceny. To obvykle znamená, že musíte ručně restartovat všechny servery RPC nebo restartovat počítač.

V Linuxu se portmapper nazývá /sbin/portmap nebo /usr/sbin/rpc.portmap . Kromě toho, že musí být spuštěn ze síťového spouštěcího skriptu, portmapper nevyžaduje žádnou konfigurační práci.

Vzdálené volání procedury(nebo Volání vzdálených procedur) (z angličtiny. Vzdálené volání procedur (RPC)) - třída technologií, které umožňují počítačovým programům volat funkce nebo procedury v jiném adresním prostoru (obvykle na vzdálených počítačích). Implementace technologie RPC obvykle zahrnuje dvě součásti: síťový protokol pro komunikaci klient-server a jazyk pro serializaci objektů (nebo struktury pro neobjektové RPC). Různé implementace RPC mají velmi odlišné architektury a liší se svými schopnostmi: některé implementují architekturu SOA, jiné CORBA nebo DCOM. Na transportní vrstvě RPC primárně používají protokoly TCP a UDP, avšak některé jsou postaveny na HTTP (což porušuje architekturu ISO/OSI, protože HTTP není nativně transportním protokolem).

Implementace

Existuje mnoho technologií, které poskytují RPC:

• Sun RPC (binární protokol založený na TCP a UDP a XDR) RFC-1831 druhé jméno ONC RPC RFC-1833
• .Net Remoting (binární protokol založený na TCP, UDP, HTTP)
• SOAP - Simple Object Access Protocol (textový protokol založený na HTTP) viz specifikace: RFC-4227
• XML RPC (textový protokol založený na HTTP) viz specifikace: RFC-3529
• Java RMI – Java Remote Method Invocation – viz specifikace: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Vzdálená volání procedur (textový protokol založený na HTTP) viz specifikace: RFC-4627
• DCE/RPC – Distributed Computing Environment / Remote Procedure Calls (binární protokol založený na různých transportních protokolech, včetně TCP/IP a Named Pipes z protokolu SMB/CIFS)
• DCOM – Distributed Component Object Model známý jako MSRPC Microsoft Remote Procedure Call nebo „Network OLE“ (objektově orientované rozšíření DCE RPC, které umožňuje předávat odkazy na objekty a volat objektové metody prostřednictvím takových odkazů)

Zásada

Myšlenkou vzdáleného volání procedur (RPC) je rozšířit dobře známý a srozumitelný mechanismus pro přenos řízení a dat v rámci programu běžícího na jednom stroji o přenos řízení a dat po síti. Nástroje vzdáleného volání procedur jsou navrženy tak, aby usnadnily organizaci distribuovaných výpočtů a vytvoření distribuovaného klient-server informační systémy. Největší efektivity využití RPC je dosaženo v těch aplikacích, ve kterých dochází k interaktivní komunikaci mezi vzdálenými komponentami s rychlou odezvou a relativně malým množstvím přenášených dat. Takové aplikace se nazývají orientované na RPC.

Implementace vzdálených volání je mnohem složitější než implementace volání místních procedur. Můžeme identifikovat následující problémy a úkoly, které je třeba vyřešit při implementaci RPC:

• Protože volající a volané procedury běží na různých počítačích, mají různé adresní prostory, což vytváří problémy při předávání parametrů a výsledků, zejména pokud na počítačích běží různé operační systémy nebo mají různé architektury (například little-endian nebo big- endian).). Vzhledem k tomu, že RPC se nemůže spoléhat na sdílenou paměť, znamená to, že parametry RPC nesmějí obsahovat ukazatele na místa v paměti bez zásobníku a že hodnoty parametrů musí být zkopírovány z jednoho počítače do druhého. Aby bylo možné kopírovat parametry procedury a výsledky provádění po síti, jsou serializovány.
• Na rozdíl od místního volání vzdálené volání procedury nutně používá transportní vrstvu síťové architektury (například TCP), ale to zůstává vývojáři skryto.
• Provádění volajícího programu a volané místní procedury na stejném počítači je implementováno v rámci jednoho procesu. Implementace RPC však zahrnuje minimálně dva procesy – jeden na každém počítači. Pokud jedna z nich selže, mohou nastat následující situace: pokud selže volající procedura, vzdáleně volané procedury „osiří“ a pokud vzdálené procedury selžou, volající procedury se stanou „opuštěnými rodiči“, kteří budou čekat marně. pro odpověď ze vzdálených procedur.
• Existuje řada problémů spojených s heterogenitou programovacích jazyků a operačních prostředí: datové struktury a struktury volání procedur podporované v jednom programovacím jazyce nejsou podporovány stejným způsobem ve všech ostatních jazycích. Existuje tedy problém s kompatibilitou, který dosud nebyl vyřešen ani zavedením jednoho obecně uznávaného standardu, ani implementací několika konkurenčních standardů na všech architekturách a ve všech jazycích.

Subsystémy

• Dopravní subsystém

Správa odchozích a příchozích připojení. - podpora konceptu „hranice zprávy“ pro transportní protokoly, které ji přímo nepodporují (TCP). - podpora garantovaného doručení pro transportní protokoly, které to přímo nepodporují (UDP).

• Zásobník nití (pouze callee). Poskytuje kontext spuštění pro kód vyvolaný přes síť.

• Marshalling (také nazývaný „serializace“). Balení parametrů volání do byte streamu standardním způsobem, nezávisle na architektuře (zejména pořadí bajtů ve slově). Zejména může ovlivnit pole, řetězce a struktury, na které ukazují parametry ukazatele.

• Šifrování balíčků a použití digitálního podpisu na ně.

• Autentizace a autorizace. Přenos informací identifikujících volajícího prostřednictvím sítě.

V některých implementacích RPC (.NET Remoting) jsou hranice subsystému otevřená polymorfní rozhraní a je možné napsat vlastní implementaci téměř všech uvedených subsystémů. V jiných implementacích (DCE RPC na Windows) tomu tak není.

viz také

Vzdálené volání procedur (RPC) Koncept vzdáleného volání procedur

Myšlenkou vzdáleného volání procedur (RPC) je rozšířit dobře známý a srozumitelný mechanismus pro přenos řízení a dat v rámci programu běžícího na jednom stroji o přenos řízení a dat po síti. Nástroje vzdáleného volání procedur jsou navrženy tak, aby usnadnily organizaci distribuovaných výpočtů. Největší efektivity využití RPC je dosaženo v těch aplikacích, ve kterých dochází k interaktivní komunikaci mezi vzdálenými komponentami s rychlou odezvou a relativně malým množstvím přenášených dat. Takové aplikace se nazývají orientované na RPC.

Charakteristické rysy volání místních procedur jsou:

• Asymetrie, to znamená, že jedna z interagujících stran je iniciátorem;
• Synchronicita, to znamená, že provádění volající procedury je pozastaveno od okamžiku vystavení požadavku a je obnoveno až po návratu volané procedury.

Implementace vzdálených volání je mnohem složitější než implementace volání místních procedur. Za prvé, protože volající a volané procedury jsou prováděny na různých počítačích, mají různé adresní prostory, což vytváří problémy při předávání parametrů a výsledků, zvláště pokud stroje nejsou identické. Vzhledem k tomu, že RPC se nemůže spoléhat na sdílenou paměť, znamená to, že parametry RPC nesmějí obsahovat ukazatele na místa v paměti bez zásobníku a že hodnoty parametrů musí být zkopírovány z jednoho počítače do druhého. Další rozdíl mezi RPC a místním voláním je ten, že nutně používá základní komunikační systém, ale to by nemělo být explicitně viditelné ani v definici procedur, ani v procedurách samotných. Odlehlost přináší další problémy. Provádění volajícího programu a volané místní procedury na stejném počítači je implementováno v rámci jednoho procesu. Implementace RPC však zahrnuje minimálně dva procesy – jeden na každém počítači. Pokud se některá z nich zhroutí, mohou nastat následující situace: pokud selže volající procedura, vzdáleně volané procedury „osiří“ a pokud vzdálené procedury selžou, volající procedury se stanou „osiřelými rodiči“ a marně čekají na odpověď ze vzdálených procedur.

Kromě toho existuje řada problémů spojených s heterogenitou programovacích jazyků a operačních prostředí: datové struktury a struktury volání procedur podporované v jednom programovacím jazyce nejsou podporovány stejným způsobem ve všech ostatních jazycích.

Tyto a některé další problémy řeší rozšířená technologie RPC, která je základem mnoha distribuovaných operačních systémů. Základní operace RPC

Abychom pochopili, jak RPC funguje, uvažujme nejprve o provedení místního volání procedury na typickém počítači běžícím offline. Nechť je to například systémové volání

count=read(fd, buf, nbytes);

kde fd je celé číslo, buf je pole znaků, nbytes je celé číslo.

Pro uskutečnění volání vloží volající procedura parametry do zásobníku v opačném pořadí (obrázek 3.1). Po provedení volání čtení umístí návratovou hodnotu do registru, přesune návratovou adresu a vrátí řízení volající proceduře, která vybere parametry ze zásobníku a vrátí jej do původního stavu. Všimněte si, že v jazyce C lze parametry volat buď odkazem (podle názvu) nebo hodnotou (podle hodnoty). Ve vztahu k volané proceduře jsou parametry hodnoty inicializované lokální proměnné. Volaná procedura je může změnit, aniž by to ovlivnilo původní hodnoty těchto proměnných ve volající proceduře.

Pokud je volané proceduře předán ukazatel na proměnnou, pak změna hodnoty této proměnné volanou procedurou znamená změnu hodnoty této proměnné pro volající proceduru. Tato skutečnost je pro RPC velmi významná.

Existuje také další mechanismus předávání parametrů, který se v C nepoužívá. Říká se mu call-by-copy/restore, který vyžaduje, aby volající zkopíroval proměnné do zásobníku jako hodnoty a poté je zkopíroval zpět po provedení volání přes původní hodnoty volací procedury.

O tom, který mechanismus předávání parametrů použít, rozhodují vývojáři jazyka. Někdy záleží na typu přenášených dat. Například v C jsou celá čísla a další skalární data vždy předávána hodnotou a pole jsou vždy předávána odkazem.

aplikace

Významná část nástrojů dálkové ovládání Operační systém Windows (Prohlížeč událostí, Správce serveru, správa tisku, seznamy uživatelů) používá DCE RPC jako prostředek komunikace po síti mezi spravovanou službou a aplikací pro ovládání uživatelského rozhraní. Podpora DCE RPC je ve Windows NT přítomna již od první verze 3.1. Klienti DCE RPC byli podporováni i v lehké řadě operační systémy Windows 3.x/95/98/Me.

Systémové knihovny Windows, které poskytují takové možnosti ovládání a slouží jako základní vrstva pro aplikace ovládání uživatelského rozhraní (netapi32.dll a částečně advapi32.dll), ve skutečnosti obsahují klientský kód pro rozhraní DCE RPC, která toto ovládání provádějí.

Toto architektonické rozhodnutí bylo předmětem aktivní kritiky společnosti Microsoft. Obecné zařazovací procedury přítomné v DCE RPC jsou velmi složité a mají obrovský potenciál pro zneužití defektů v síti zasláním záměrně zdeformovaného paketu DCE RPC. Významná část závad Zabezpečení Windows, objevené od konce 90. let do poloviny 21. století, byly přesně chyby v zařazovacím kódu DCE RPC.

Kromě DCE RPC Windows aktivně využívá technologii DCOM. Používá se například jako prostředek komunikace mezi nástroji pro správu webového serveru IIS a samotným spravovaným serverem. Na DCOM je založeno i plně funkční rozhraní pro komunikaci s poštovním systémem MS Exchange Server - MAPI.

Myšlenka volání vzdálených procedur (Vzdálené volání procedury – RPC) spočívá v rozšíření dobře známého a srozumitelného mechanismu pro přenos řízení a dat v rámci programu běžícího na jednom stroji na přenos řízení a dat po síti. Nástroje vzdáleného volání procedur jsou navrženy tak, aby usnadnily organizaci distribuovaných výpočtů.

Největší efektivity použití RPC je dosaženo v těch aplikacích, ve kterých existuje interaktivní komunikace mezi vzdálenými komponenty S krátká doba odezvy A relativně malé množství přenášených dat.Takové aplikace se nazývají orientované na RPC.

Charakteristické rysy volání místních procedur jsou:

asymetrie, to znamená, že jedna z interagujících stran je iniciátorem;

synchronicita, to znamená, že provádění volající procedury je pozastaveno od okamžiku, kdy je požadavek vydán, a obnoveno až po návratu volané procedury.

Implementace vzdálených volání je mnohem složitější než implementace volání místních procedur.

1. Začněme tím, že jelikož se volající a volané procedury provádějí na různých strojích, tak mají různé adresní prostory, a to vytváří problémy při přenosu parametrů a výsledků, zejména pokud stroje nejsou identické.

Protože RPC se nemůže spoléhat na sdílenou paměť, znamená to, že Parametry RPC nesmí obsahovat ukazatele na místa v paměti, která nejsou zásobníkem No a co hodnoty parametrů musí být zkopírovány z jednoho počítače do druhého.

2. Další rozdíl mezi RPC a místním hovorem je ten nutně využívá základní komunikační systém, nicméně toto by neměly být jasně viditelné ani v definici postupů, ani v postupech samotných .

Odlehlost přináší další problémy. Spuštění volajícího programu a volané místní procedury na stejném počítači implementováno uvnitřsingl proces. Ale podílí se na implementaci RPCalespoň dva procesy - jeden v každém voze. Pokud jeden z nich selže, mohou nastat následující situace:

Pokud volající procedura selže, vzdáleně volané procedury se stanou "osiřelými" a

Pokud vzdálené procedury skončí abnormálně, stanou se volající procedury "opuštěnými rodiči" a budou čekat na odpověď vzdálených procedur bez úspěchu.

Kromě toho existuje řadu problémů spojených s heterogenitou programovacích jazyků a operačních prostředí : Datové struktury a struktury volání procedur podporované v jednom programovacím jazyce nejsou podporovány stejným způsobem ve všech ostatních jazycích.

Tyto a některé další problémy řeší rozšířená technologie RPC, která je základem mnoha distribuovaných operačních systémů.

Smyslem RPC je zajistit, aby vzdálené volání procedury vypadalo co nejpodobněji volání místní procedury. Jinými slovy, zprůhlednit RPC: volající procedura nemusí vědět, že volaná procedura je na jiném počítači a naopak.

RPC dosahuje transparentnosti následujícím způsobem. Když je volaná procedura ve skutečnosti vzdálená, je do knihovny místo místní procedury umístěna jiná verze procedury, nazývaná klientský zakázaný inzert. Stejně jako původní procedura je stub volán pomocí volací sekvence (jako na obrázku 3.1) a při přístupu k jádru dojde k přerušení. Pouze na rozdíl od původní procedury neumisťuje parametry do registrů a nepožaduje data z jádra, místo toho generuje zprávu, která se odešle do jádra vzdáleného počítače..

Rýže. 3.2. Vzdálené volání procedury

Účelem tohoto článku je diskutovat o terminologii. Článek není o tom, jak a proč, ale pouze o používání terminologie. Článek odráží názor autora a nepředstírá, že je vědecký.

Úvod

Pokud pracujete v programování distribuované systémy nebo v systémovou integraci, pak pro vás většina toho, co je zde prezentováno, není novinkou.

Problém nastává, když se setkají lidé, kteří používají různé technologie, a když tito lidé začnou vést technické rozhovory. V tomto případě často dochází k vzájemným nedorozuměním kvůli terminologii. Zde se pokusím dát dohromady terminologii používanou v různých kontextech.

Terminologie

V této oblasti neexistuje jasná terminologie a klasifikace. Níže použitá terminologie je odrazem autorova modelu, to znamená, že je přísně subjektivní. Jakákoli kritika a diskuse jsou vítány.

Terminologii jsem rozdělil do tří oblastí: RPC (Remote Procedure Call), Messaging a REST. Tyto oblasti mají historické kořeny.

RPC

RPC technologie - nejstarší technologie. Nejvýznamnějšími představiteli RPC jsou - CORBA A DCOM.

V té době bylo potřeba hlavně propojovat systémy rychle a relativně spolehlivě lokální sítě. Hlavní myšlenkou RPC bylo učinit volání vzdálených systémů podobně jako volání funkcí v programu. Celá mechanika vzdálených volání byla programátorovi skryta. Alespoň se to snažili skrýt. Programátoři byli v mnoha případech nuceni pracovat na hlubší úrovni, kde se objevily termíny marshaling ( seřazování) A demarshaling(jak je to v ruštině?), což v podstatě znamenalo serializaci. Normální volání funkcí v rámci procesů byla zpracována na konci volajícího Proxy a na straně systému vykonávajícího funkci v Odesílatel. V ideálním případě by se ani volací systém, ani systém zpracování nezabývaly složitostí přenosu dat mezi systémy. Všechny tyto jemnosti byly soustředěny do svazku Proxy - Dispečer, jehož kód byl generován automaticky.

Takže si nevšimnete, neměli byste si všimnout žádného rozdílu mezi voláním místní funkce a voláním vzdálené funkce.
Nyní dochází k jakési renesanci RPC, jejíž nejvýraznější představitelé jsou: Google ProtoBuf, Thrift, Avro.

Zasílání zpráv

Postupem času se ukázalo, že pokus ochránit programátora před tím, že volaná funkce se stále liší od lokální, nevedl k kýžený výsledek. Podrobnosti implementace a zásadní rozdíly mezi distribuovanými systémy byly příliš velké na to, aby je bylo možné vyřešit pomocí automaticky generovaného proxy kódu. Postupně došlo k pochopení, že skutečnost, že systémy jsou propojeny nespolehlivým, pomalým a nízkorychlostním prostředím, se musí výslovně projevit v kódu programu.

Objevily se technologie webové služby. Dali jsme se do řeči ABC: Adresa, Vazba, Smlouva. Není zcela jasné, proč se objevily smlouvy, které jsou v podstatě obálkami pro vstupní argumenty. Smlouvy často celkový model spíše komplikují, než aby jej zjednodušovaly. Ale... to je jedno.

Nyní programátor explicitně vytvořil servis(Servis) nebo klienta(Klient) zavolání servisu. Služba se skládala ze sady operace (Úkon), z nichž každý přijal na vstupu žádost(Žádost) a vydáno Odpovědět(Odezva). Klient explicitně odesláno(Odesláno) požadavek, služba výslovně obdržela ( Dostávat) a odpověděl mu (Odesláno) a odeslal odpověď. Klient obdržel odpověď a hovor byl ukončen.

Stejně jako v RPC někde běžel Proxy a Dispečer. A stejně jako dříve se jejich kód generoval automaticky a programátor mu nemusel rozumět. Pokud klient explicitně nepoužíval třídy z Proxy.

Požadavky a odpovědi jsou výslovně převedeny do formátu určeného pro přenos po drátě. Nejčastěji se jedná o bajtové pole. Transformace se nazývá Serializace A Deserializace a někdy se skrývá v kódu proxy.
Vyvrcholení zasílání zpráv se projevilo ve vzniku paradigmatu ESB (Enterprise Service Bus). Nikdo nedokáže přesně vyjádřit, co to je, ale všichni souhlasí s tím, že data se přes ESB pohybují ve formě zpráv.

ODPOČINEK

V neustálém boji se složitostí kódu udělali programátoři další krok a vytvořili ODPOČINEK.

Hlavním principem REST je, že funkční operace jsou ostře omezeny a ponechávají pouze sadu operací CRUD: Vytvořit - Číst - Aktualizovat - Smazat. V tomto modelu jsou všechny operace vždy aplikovány na nějaká data. Operace dostupné v CRUD jsou dostatečné pro většinu aplikací. Vzhledem k tomu, že technologie REST ve většině případů zahrnují použití protokolu HTTP, příkazy CRUD se promítly do příkazů HTTP (Pošta - Dostat - Dát - Vymazat) . Neustále se uvádí, že REST není nutně vázán na HTTP. V praxi se však široce používá odraz operačních signatur do syntaxe HTTP příkazů. Například volání funkce

EntityAddress ReadEntityAddress(řetězec param1, řetězec param2)

Vyjádřeno takto:

GET: adresa entity?param1=hodnota1¶m2=hodnota2

Závěr

Před zahájením diskuse o distribuovaných systémech nebo integraci definujte terminologii. Pokud bude proxy vždy znamenat totéž v různých kontextech, pak například požadavek bude znamenat z hlediska RPC málo a seřazování způsobí zmatek při diskuzi o technologiích REST.

Po restartu počítače se služba nespustila" Vzdálené volání procedur (RPC)". Na této službě hodně záleží. V důsledku toho nefunguje obnovení systému, síťové prostředí, zvuk, Instalační služba Windows Installer, konzola pro správu (MMC) téměř nefunguje, otevřená okna se nezobrazují na hlavním panelu atd. atd. Pokus o ruční spuštění vede k chybě " Nelze spustit...(RPC) na xxxComp. Chyba 5: Přístup odepřen"Antivir nic nenašel. Dva dny kopání a počítač se vrátil k životu."

Podle doporučení Microsoftu jsem jako první zkusil najít a smazat klíč registru . Neměl jsem to, možná v důsledku některých nainstalovaných aktualizací.

Dále pokus o obnovení parametrů služby v registru. Protože regedit.exe byl pouze pro čtení/mazání (další vedlejší efekt), nebylo možné provádět změny. Ano, nebyly potřeba, protože... všechno bylo správně. Mělo by to vypadat takto:

Editor registru systému Windows verze 5.00 "Description"="Poskytuje mapování koncových bodů a dalších služeb RPC." "DisplayName"="Vzdálené volání procedur (RPC)" "ErrorControl"=dword:00000001 "Group"="Infrastruktura COM" "ImagePath"=hex(2):25,00,53,00,79,00,73, 00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\ 74,00,25,00,5c,00,73,00,79,00,73,00 ,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\ 00,76,00,63,00,68,00,6f,00,73,00, 74,00,20,00,2d,00,6b,00,20,00,72,00,70,00,\ 63,00,73,00,73,00,00,00 "ObjectName"="NT AUTHORITY\\NetworkService" "Start"=dword:00000002 "Typ"=dword:00000010 "FailureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,01 ,00,00,00,00,00,00,\ 00,02,00,00,00,60,ea,00,00 "ServiceSidType"=dword:00000001 "ServiceDll"=hex(2):25,00 ,53 ,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\ 00,74,00,25,00,5c,00, 73, 00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\ 72,00,70,00,63,00,73 ,00 ,73,00,2e,00,64,00,6c,00,6c,00,00,00 "Zabezpečení"=hex:01,00,14,80,a8,00,00,00,b4, 00, 00,00,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01 ,0f ,00,01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,78,00,05,00,00,00,00,00, 14, 00,8d,00,02,00,01,01,00,00,00,00,00,\ 05,0b,00,00,00,00,00,18,00,ff,01,0f ,00 ,01,02,00,00,00,00,00,05,20,00,00,00,\ 20,02,00,00,00,00,18,00,8d,00,02, 00, 01,02,00,00,00,00,00,05,20,00,00,00,23,\ 02,00,00,00,00,14,00,9d,00,00,00 ,01 ,01,00,00,00,00,00,05,04,00,00,00,00,00,\ 18,00,9d,00,00,00,01,02,00,00, 00, 00,00,05,20,00,00,00,21,02,00,00,01,01,00,\ 00,00,00,00,05,12,00,00,00,01 ,01 ,00,00,00,00,00,05,12,00,00,00 "0"="Root\\LEGACY_RPCSS\\0000" "Count"=dword:00000001 "NextInstance"=dword:00000001

Hodnota parametru Start se může lišit. Registr můžete stále změnit, ale musíte zavést systém velitel MS ERD.

Jednoduše popíšu další kroky bod po bodu. Obecná myšlenka je, že musíte nahradit soubory soubory, o kterých je známo, že fungují. Mohou být převzaty z jiného počítače nebo z distribuce Windows (jako jsem to udělal já).

• Spusťte konzolu (Start > Spustit: cmd)
• cd z:\i386(tam je distribuce Windows)
• rozbalte explorer.ex_ %TEMP%\explorer.exe
• rozbalte svchost.ex_ %TEMP%\svchost.exe
• Spusťte Správce úloh (Ctrl+Shift+Esc)
• Zastavte proces exlporer.exe
• zkopírujte %TEMP%\explorer.exe %SYSTEMROOT% /y
• Zastavte všechny procesy svchost.exe. Pozornost! Poté budete mít 60 sekund, než se počítač restartuje.
• zkopírujte %TEMP%\svchost.exe %systemroot%\system32 /y

Tato finta také nepřinesla výsledky. Další možnost: spustit kontrolu všech chráněných systémové soubory s výměnou špatné verze opravit. Ve spuštění konzole:

Nepomohlo to.. Pak je úplně brutálním krokem obnovení nastavení zabezpečení. Opět v konzoli:

Po restartu začal počítač fungovat základní služby začala. Objevil se nový problém (nebo tam možná byl od samého začátku): pod mým účtem se alespoň nespustil Správce správy disků a Windows Installer. Přístup odepřen. Přístupová práva k systémovému disku můžete obnovit na „výchozí“ prostřednictvím konzole:

Poté je třeba ručně definovat práva pro každý účet. nebo je znovu vytvořit, podle toho, co je jednodušší.

V mém případě jsem jednoduše přidělil stejná práva celému systémovému disku pomocí přístupu k . Svůj doménový účet jsem přidal do standardu s plnými právy k disku. Možná je to špatně z hlediska zabezpečení, ale nemám čas ponořit se do každého adresáře zvlášť.

Co jiného se dalo dělat

Zatímco byl počítač nemocný, toto nebylo v registru:

"ActiveService"="RpcSs"

Možná by manuální přidání nějak změnilo situaci.

Pokusy o ruční spuštění služby, například pomocí příkazu " net start rcpss"skončil chybně" Chyba 5: přístup odepřen". Předpokládám, že přístup je odepřen, protože služba musí být spuštěna pod systémovým účtem - "NT AUTHORITY". V registru je následující parametr:

"ObjectName"="NT AUTHORITY\\NetworkService"

Zkusil bych sem zadat účet správce a znovu spustit službu. Ale to je jen nápad, který se nedočkal realizace.

Další možnost: použijte exploit KiTrap0D k získání konzole se systémovými právy. O tomto exploitu se psalo v . Vlastně binární. Ale mám aktualizace Windows, takže to vypadá, že tento exploit už nefunguje.

Související materiály: