Ring fjärrprocedurer rpc ultraljudsskanner. Fjärrproceduranropsmekanism - RPC

En mycket viktig mekanism för klient-serverapplikationer tillhandahålls av RPC ( Fjärrproceduranrop). RPC utvecklades av Sun Micrsystems och är en samling verktyg och biblioteksfunktioner. I synnerhet fungerar NIS (Network Information System) och NFS (Network File System) på RPC.

En RPC-server består av ett system med sådana procedurer som en klient kan komma åt genom att skicka en RPC-begäran till servern tillsammans med procedurparametrarna. Servern anropar den angivna proceduren och returnerar procedurens returvärde, om något finns. För att vara maskinoberoende konverteras all data som utbyts mellan klient och server till en så kallad extern datarepresentation ( Extern datarepresentation XDR). RPC kommunicerar med UDP- och TCP-uttag för att överföra data i XDR-format. Sun har deklarerat RPC som en allmän egendom, och dess beskrivning finns tillgänglig i en serie RFC-dokument.

Ibland inför ändringar i RPC-applikationer inkompatibilitet i gränssnittsanropsproceduren. Naturligtvis skulle en enkel ändring få servern att krascha alla applikationer som fortfarande väntar på samma samtal. Därför har RPC-program versionsnummer tilldelade, vanligtvis med 1. Varje en ny version RPC håller reda på versionsnumret. Ofta kan servern erbjuda flera versioner samtidigt. Klienter anger i detta fall vilket versionsnummer de vill använda.

Nätverkskommunikationen mellan RPC-servrar och klienter är lite speciell. En RPC-server erbjuder en eller flera systemprocedurer, varje uppsättning av sådana procedurer kallas ett program ( program) och identifieras unikt av programnumret ( programnummer). En lista över tjänstnamn hålls vanligtvis i /etc/rpc, ett exempel på det ges nedan.

Exempel 12-4. Exempel på filen /etc/rpc

I TCP/IP-nätverk ställdes författarna till RPC inför uppgiften att mappa programnummer till vanliga nätverkstjänster. Varje server tillhandahåller en TCP- och UDP-port för varje program och varje version. I allmänhet använder RPC-applikationer UDP för att överföra data och faller tillbaka till TCP när data som ska överföras inte passar in i ett enda UDP-datagram.

Givetvis måste klientprogram ha ett sätt att ta reda på vilken port som motsvarar programnumret. Att använda en konfigurationsfil för detta skulle vara för oflexibelt; Eftersom RPC-applikationer inte använder reserverade portar finns det ingen garanti för att porten inte är upptagen av någon applikation och är tillgänglig för oss. Därför väljer RPC-applikationer vilken port de kan ta emot och registrerar den med portmapper-demon. En klient som vill kontakta en tjänst med ett givet programnummer kommer först att göra en förfrågan till portmapper för att ta reda på portnumret för den önskade tjänsten.

Denna metod har nackdelen att den introducerar en enda punkt av fel, ungefär som inetd demon Det här fallet är dock lite värre eftersom när portmappern misslyckas går all RPC-information om portarna förlorad. Detta innebär vanligtvis att du måste starta om alla RPC-servrar manuellt eller starta om maskinen.

På Linux heter portmappern /sbin/portmap eller /usr/sbin/rpc.portmap . Förutom att det måste startas från nätverksstartskriptet, kräver portmapper inget konfigurationsarbete.

Fjärrproceduranrop(eller Ringer fjärrprocedurer) (från engelska. Remote Procedure Call (RPC)) - en klass av teknologier som tillåter datorprogram att anropa funktioner eller procedurer i ett annat adressutrymme (vanligtvis på fjärrdatorer). Vanligtvis inkluderar en implementering av RPC-teknik två komponenter: ett nätverksprotokoll för klient-serverkommunikation och ett objektserialiseringsspråk (eller strukturer, för icke-objekt RPC). Olika RPC-implementeringar har väldigt olika arkitekturer och varierar i deras kapacitet: vissa implementerar SOA-arkitekturen, andra CORBA eller DCOM. På transportlagret använder RPC:er främst TCP- och UDP-protokoll, men vissa är byggda ovanpå HTTP (vilket bryter mot ISO/OSI-arkitekturen, eftersom HTTP inte är ett inbyggt transportprotokoll).

Genomföranden

Det finns många tekniker som tillhandahåller RPC:

• Sun RPC (binärt protokoll baserat på TCP och UDP och XDR) RFC-1831 andra namn ONC RPC RFC-1833
• .Net Remoting (binärt protokoll baserat på TCP, UDP, HTTP)
• SOAP - Simple Object Access Protocol (HTTP-baserat textprotokoll) se specifikation: RFC-4227
• XML RPC (HTTP-baserat textprotokoll) se specifikation: RFC-3529
• Java RMI - Java Remote Method Invocation - se specifikation: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (HTTP-baserat textprotokoll) se specifikation: RFC-4627
• DCE/RPC - Distributed Computing Environment / Remote Procedure Calls (binärt protokoll baserat på olika transportprotokoll, inklusive TCP/IP och Named Pipes från SMB/CIFS-protokollet)
• DCOM - Distributed Component Object Model känd som MSRPC Microsoft Remote Procedure Call eller "Network OLE" (ett objektorienterat tillägg till DCE RPC som låter dig skicka referenser till objekt och anropa objektmetoder genom sådana referenser)

Princip

Tanken med ett Remote Procedure Call (RPC) är att utöka den välkända och förstådda mekanismen för att överföra kontroll och data inom ett program som körs på en maskin för att överföra kontroll och data över ett nätverk. Fjärrproceduranropsverktyg är utformade för att underlätta organisationen av distribuerad datoranvändning och skapandet av distribuerad klient-server informationssystem. Den största effektiviteten med att använda RPC uppnås i de applikationer där det finns interaktiv kommunikation mellan fjärrkomponenter med snabba svarstider och en relativt liten mängd överförd data. Sådana applikationer kallas RPC-orienterade.

Att implementera fjärranrop är mycket mer komplicerat än att implementera lokala proceduranrop. Vi kan identifiera följande problem och uppgifter som behöver lösas när vi implementerar RPC:

• Eftersom anrops- och anropsprocedurerna körs på olika maskiner, har de olika adressutrymmen, och detta skapar problem vid överföring av parametrar och resultat, särskilt om maskinerna kör olika operativsystem eller har olika arkitekturer (till exempel little-endian eller big-endian). endian). ). Eftersom RPC inte kan förlita sig på delat minne, betyder det att RPC-parametrar inte får innehålla pekare till icke-stackminnesplatser och att parametervärden måste kopieras från en dator till en annan. För att kopiera procedurparametrar och exekveringsresultat över nätverket serialiseras de.
• Till skillnad från ett lokalt samtal använder ett fjärranrop nödvändigtvis nätverksarkitekturens transportlager (till exempel TCP), men detta förblir dolt för utvecklaren.
• Exekveringen av det anropande programmet och den anropade lokala proceduren på samma maskin implementeras inom en enda process. Men implementeringen av RPC involverar minst två processer - en på varje maskin. Om en av dem kraschar kan följande situationer uppstå: om anropsproceduren kraschar, kommer de fjärranropade procedurerna att bli "föräldralösa", och om fjärrprocedurerna kraschar, kommer anropsprocedurerna att bli "utlösa föräldrar", vilket kommer att vänta förgäves för svar från fjärrprocedurerna.
• Det finns ett antal problem förknippade med heterogeniteten hos programmeringsspråk och operativa miljöer: datastrukturer och strukturer för proceduranrop som stöds i ett programmeringsspråk stöds inte på samma sätt på alla andra språk. Det finns alltså ett kompatibilitetsproblem som ännu inte har lösts vare sig genom införandet av en allmänt accepterad standard, eller genom implementeringen av flera konkurrerande standarder på alla arkitekturer och på alla språk.

Delsystem

• Transportdelsystem

Hantera utgående och inkommande anslutningar. - Stöd för konceptet "meddelandegräns" för transportprotokoll som inte direkt stöder det (TCP). - stöd för garanterad leverans för transportprotokoll som inte direkt stöder det (UDP).

• Trådpool (endast callee). Ger en exekveringskontext för kod som anropas över nätverket.

• Marshalling (även kallad "serialisering"). Packa anropsparametrar i en byteström på ett standard sätt, oberoende av arkitekturen (särskilt ordningen på bytes i ett ord). I synnerhet kan det påverka arrayer, strängar och strukturer som pekas på av pekparametrar.

• Kryptera paket och applicera en digital signatur på dem.

• Autentisering och auktorisering. Överföring över nätverket av information som identifierar personen som ringer.

I vissa RPC-implementeringar (.NET Remoting) är delsystemsgränser öppna polymorfa gränssnitt, och det är möjligt att skriva en egen implementering av nästan alla listade delsystem. I andra implementeringar (DCE RPC på Windows) är detta inte fallet.

se även

Remote Procedure Call (RPC) Remote Procedure Call Concept

Tanken med ett Remote Procedure Call (RPC) är att utöka den välkända och förstådda mekanismen för att överföra kontroll och data inom ett program som körs på en maskin för att överföra kontroll och data över ett nätverk. Fjärrproceduranropsverktyg är utformade för att underlätta organisationen av distribuerad datoranvändning. Den största effektiviteten med att använda RPC uppnås i de applikationer där det finns interaktiv kommunikation mellan fjärrkomponenter med snabba svarstider och en relativt liten mängd överförd data. Sådana applikationer kallas RPC-orienterade.

De karakteristiska egenskaperna för att anropa lokala procedurer är:

• Asymmetri, det vill säga en av de interagerande parterna är initiativtagaren;
• Synkronicitet, det vill säga exekveringen av anropsproceduren avbryts från det ögonblick då begäran utfärdas och återupptas först efter att den anropade proceduren återvänder.

Att implementera fjärranrop är mycket mer komplicerat än att implementera lokala proceduranrop. Till att börja med, eftersom de anropande och anropade procedurerna exekveras på olika maskiner, har de olika adressutrymmen, och detta skapar problem vid överföring av parametrar och resultat, särskilt om maskinerna inte är identiska. Eftersom RPC inte kan förlita sig på delat minne, betyder det att RPC-parametrar inte får innehålla pekare till icke-stackminnesplatser och att parametervärden måste kopieras från en dator till en annan. Nästa skillnad mellan RPC och ett lokalt samtal är att det nödvändigtvis använder det underliggande kommunikationssystemet, men detta bör inte vara explicit synligt vare sig i definitionen av procedurerna eller i själva procedurerna. Avstånd inför ytterligare problem. Exekveringen av det anropande programmet och den anropade lokala proceduren på samma maskin implementeras inom en enda process. Men implementeringen av RPC involverar minst två processer - en på varje maskin. Om en av dem kraschar kan följande situationer uppstå: om anropsproceduren kraschar, kommer de fjärranropade procedurerna att bli "föräldralösa", och om fjärrprocedurerna kraschar, kommer anropsprocedurerna att bli "föräldralösa föräldrar" och väntar förgäves på en svar från fjärrprocedurerna.

Dessutom finns det ett antal problem förknippade med heterogeniteten hos programmeringsspråk och operativa miljöer: datastrukturerna och strukturerna för proceduranrop som stöds i ett programmeringsspråk stöds inte på samma sätt på alla andra språk.

Dessa och några andra problem löses av den utbredda RPC-tekniken, som ligger till grund för många distribuerade operativsystem. Grundläggande operationer RPC

För att förstå hur RPC fungerar, låt oss först överväga att göra ett lokalt proceduranrop på en typisk maskin som körs offline. Låt detta till exempel vara ett systemanrop

count=read(fd, buf, nbytes);

där fd är ett heltal, buf är en array av tecken, nbytes är ett heltal.

För att ringa anropet trycker anropsproceduren parametrarna till stacken i omvänd ordning (Figur 3.1). Efter att läsanropet har utförts, placerar den returvärdet i ett register, flyttar returadressen och återställer kontrollen till anropsproceduren, som poppar upp parametrar från stacken och återställer den till sitt ursprungliga tillstånd. Observera att i C-språket kan parametrar anropas antingen genom referens (med namn) eller genom värde (efter värde). I förhållande till den anropade proceduren är värdeparametrar initierade lokala variabler. Den anropade proceduren kan ändra dem utan att påverka de ursprungliga värdena för dessa variabler i anropsproceduren.

Om en pekare till en variabel skickas till den anropade proceduren, innebär ändring av värdet på denna variabel genom den anropade proceduren att ändra värdet på denna variabel för anropsproceduren. Detta faktum är mycket viktigt för RPC.

Det finns också en annan mekanism för att skicka parametrar som inte används i C. Den kallas call-by-copy/restore, vilket kräver att anroparen kopierar variabler till stacken som värden och sedan kopierar tillbaka dem efter att anropet har gjorts om. de ursprungliga värdena för anropsproceduren.

Beslutet om vilken parameteröverföringsmekanism som ska användas tas av språkutvecklarna. Ibland beror det på vilken typ av data som överförs. I C, till exempel, skickas heltal och annan skalär data alltid genom värde, och matriser skickas alltid genom referens.

Ansökan

En betydande del av instrumenten fjärrkontroll Windows-operativsystemet (Event Viewer, Server Manager, utskriftshantering, användarlistor) använder DCE RPC som ett kommunikationsmedel över nätverket mellan den hanterade tjänsten och kontrollapplikationen för användargränssnittet. DCE RPC-stöd har funnits i Windows NT sedan den allra första versionen 3.1. DCE RPC-klienter stöddes också i ljuslinjen operativsystem Windows 3.x/95/98/Me.

Windows-systembiblioteken som tillhandahåller sådana kontrollmöjligheter och fungerar som baslager för kontrollapplikationer för användargränssnitt (netapi32.dll och delvis advapi32.dll) innehåller faktiskt klientkod för DCE RPC-gränssnitten som utför denna kontroll.

Detta arkitektoniska beslut var föremål för aktiv kritik mot Microsoft. De generiska rangeringsprocedurerna som finns i DCE RPC är mycket komplexa och har en enorm potential för att defekter kan utnyttjas i nätverket genom att skicka ett avsiktligt missformat DCE RPC-paket. En betydande del av defekterna Windows säkerhet, som upptäcktes från slutet av 90-talet till mitten av 2000-talet, var just fel i DCE RPC-rangeringskoden.

Förutom DCE RPC använder Windows aktivt DCOM-teknik. Det används till exempel som ett kommunikationsmedel mellan IIS webbserverhanteringsverktyg och själva servern som hanteras. Ett fullt fungerande gränssnitt för att kommunicera med MS Exchange Server-postsystemet - MAPI - är också baserat på DCOM.

Idén med att ringa fjärrprocedurer (Remote Procedure Call - RPC) består av att utöka den välkända och förstådda mekanismen för att överföra kontroll och data inom ett program som körs på en maskin till att överföra kontroll och data över ett nätverk. Fjärrproceduranropsverktyg är utformade för att underlätta organisationen av distribuerad datoranvändning.

Den största effektiviteten av att använda RPC uppnås i de applikationer där det finns interaktiv kommunikation mellan fjärrkomponenter Med kort svarstid Och relativt liten mängd överförd data.Sådana applikationer kallas RPC-orienterade.

De karakteristiska egenskaperna för att anropa lokala procedurer är:

asymmetri, det vill säga en av de interagerande parterna är initiativtagaren;

Synkronicitet, det vill säga att exekveringen av anropsproceduren avbryts från det ögonblick då begäran utfärdas och återupptas först när den anropade proceduren återkommer.

Att implementera fjärranrop är mycket mer komplicerat än att implementera lokala proceduranrop.

1. Låt oss börja med det faktum att eftersom anrops- och anropsprocedurerna exekveras på olika maskiner, har olika adressutrymmen, och detta skapar problem vid överföring av parametrar och resultat, speciellt om maskinerna inte är identiska.

Eftersom RPC inte kan förlita sig på delat minne, betyder detta det RPC-parametrar får inte innehålla pekare till icke-stackminnesplatserÄn sen då parametervärden måste kopieras från en dator till en annan.

2. Nästa skillnad mellan RPC och ett lokalsamtal är att det använder nödvändigtvis det underliggande kommunikationssystemet, dock detta bör inte synas tydligt vare sig i definitionen av förfaranden eller i själva förfarandena .

Avstånd inför ytterligare problem. Utför det anropande programmet och den anropade lokala proceduren på samma maskin genomförs inomenda bearbeta. Men involverade i implementeringen av RPCminst två processer - en i varje bil. Om en av dem misslyckas kan följande situationer uppstå:

Om anropsproceduren kraschar kommer de fjärranropade procedurerna att bli "föräldralösa" och

Om fjärrprocedurer avslutas på ett onormalt sätt, kommer anropsprocedurerna att bli "utblottade föräldrar" och väntar på ett svar från fjärrprocedurerna utan resultat.

Dessutom finns det ett antal problem förknippade med heterogeniteten hos programmeringsspråk och operativa miljöer : Datastrukturer och proceduranropsstrukturer som stöds i ett programmeringsspråk stöds inte på samma sätt på alla andra språk.

Dessa och några andra problem löses av den utbredda RPC-tekniken, som ligger till grund för många distribuerade operativsystem.

Tanken bakom RPC är att få ett fjärrproceduranrop att se ut så likt ett lokalt proceduranrop som möjligt. Med andra ord, gör RPC transparent: anropsproceduren behöver inte veta att den anropade proceduren finns på en annan maskin, och vice versa.

RPC uppnår transparens på följande sätt. När den anropade proceduren faktiskt är avlägsen, placeras en annan version av proceduren, kallad en klientstub, i biblioteket istället för den lokala proceduren. Liksom den ursprungliga proceduren anropas stubben med hjälp av en anropssekvens (som i figur 3.1), och ett avbrott inträffar när man kommer åt kärnan. Bara, till skillnad från den ursprungliga proceduren, placerar den inte parametrar i register och begär inte data från kärnan; istället genererar den ett meddelande som ska skickas till kärnan på fjärrmaskinen.

Ris. 3.2. Fjärrproceduranrop

Syftet med denna artikel är att diskutera terminologi. Artikeln handlar inte om hur och varför, utan bara om användningen av terminologi. Artikeln återspeglar författarens åsikt och utger sig inte för att vara vetenskaplig.

Introduktion

Om du arbetar med programmering distribuerade system eller in systemintegration, då är det mesta av det som presenteras här inte nytt för dig.

Problemet kommer när människor som använder olika tekniker möts och när dessa människor börjar ha tekniska samtal. I det här fallet uppstår ofta ömsesidiga missförstånd på grund av terminologi. Här ska jag försöka få ihop de terminologier som används i olika sammanhang.

Terminologi

Det finns ingen tydlig terminologi och klassificering inom detta område. Terminologin som används nedan är en återspegling av författarens modell, det vill säga den är strikt subjektiv. All kritik och alla diskussioner är välkomna.

Jag har delat in terminologin i tre områden: RPC (Remote Procedure Call), Messaging och REST. Dessa områden har historiska rötter.

RPC

RPC teknologier - de äldsta teknologierna. De mest framstående representanterna för RPC är - CORBA Och DCOM.

På den tiden var det främst nödvändigt att koppla ihop system snabbt och relativt pålitligt lokala nätverk. Huvudidén bakom RPC var att göra anropande fjärrsystem ungefär som anropsfunktioner i ett program. Hela mekaniken för fjärrsamtal gömdes för programmeraren. De försökte åtminstone dölja det. Programmerare tvingades i många fall arbeta på en djupare nivå, där termerna marshaling dök upp ( rangering) Och unmarshalling(hur är det på ryska?), vilket i huvudsak innebar serialisering. Normala funktionsanrop inom processer hanterades vid den som ringer in Ombud, och på sidan av systemet som utför funktionen, i Avsändare. Helst skulle varken anropssystemet eller bearbetningssystemet hantera krångligheterna med att överföra data mellan system. Alla dessa subtiliteter var koncentrerade i paketet Proxy - Dispatcher, vars kod genererades automatiskt.

Så du kommer inte att märka, du ska inte märka, någon skillnad mellan att anropa en lokal funktion och anropa en fjärrfunktion.
Nu finns det en slags RPC-renässans, vars mest framstående representanter är: Google ProtoBuf, Thrift, Avro.

Meddelanden

Med tiden visade det sig att försöket att skydda programmeraren från det faktum att den anropade funktionen fortfarande skiljer sig från den lokala inte ledde till önskat resultat. Implementeringsdetaljerna och grundläggande skillnader mellan distribuerade system var för stora för att kunna lösas med automatiskt genererad proxykod. Efter hand kom förståelsen att det faktum att systemen är sammankopplade av en opålitlig, långsam miljö med låg hastighet måste uttryckligen återspeglas i programkoden.

Teknologier har dykt upp webbservice. Vi började prata ABC: Adress, Bindande, Kontrakt. Det är inte helt klart varför kontrakt dök upp, som i huvudsak är kuvert för inmatningsargument. Kontrakt komplicerar ofta den övergripande modellen snarare än att förenkla den. Men... det spelar ingen roll.

Nu skapade programmeraren uttryckligen service(Service) eller klient(Klient) ringer tjänsten. Tjänsten bestod av ett set operationer (Drift), som var och en tog till sig ingången begäran(Begäran) och utfärdas svar(Svar). Kunden uttryckligen skickas(Skickat) begäran, tjänsten mottogs uttryckligen ( Motta) och svarade honom (Skickat), skickade svaret. Kunden fick ett svar och samtalet avslutades.

Precis som i RPC fanns det en Proxy och Dispatcher igång någonstans. Och som tidigare genererades deras kod automatiskt och programmeraren behövde inte förstå den. Såvida inte klienten uttryckligen använde klasser från Proxy.

Förfrågningar och svar konverteras uttryckligen till ett format som är avsett för överföring via tråden. Oftast är detta en byte-array. Förvandlingen kallas Serialisering Och Deserialisering och gömmer sig ibland i proxykoden.
Kulmen av meddelanden manifesterade sig i framväxten av paradigmet ESB (Enterprise Service Bus). Ingen kan riktigt formulera vad det är, men alla är överens om att data rör sig genom ESB i form av meddelanden.

RESTEN

I den ständiga kampen med kodkomplexitet tog programmerare nästa steg och skapade RESTEN.

Huvudprincipen för REST är att funktionsoperationer är kraftigt begränsade och lämnade endast en uppsättning operationer CRUD: Skapa - Läs - Uppdatera - Ta bort. I denna modell tillämpas alltid alla operationer på vissa data. Operationerna som finns tillgängliga i CRUD är tillräckliga för de flesta applikationer. Eftersom REST-teknologier i de flesta fall innebär användning av HTTP-protokollet, återspeglades CRUD-kommandona i kommandona HTTP (Posta - Skaffa sig - Sätta - Radera) . Det sägs hela tiden att REST inte nödvändigtvis är kopplat till HTTP. Men i praktiken används reflektion av operationssignaturer på syntaxen för HTTP-kommandon i stor utsträckning. Till exempel att anropa funktionen

EntityAddress ReadEntityAddress(sträng param1, sträng param2)

Uttryckt så här:

GET: entityAddress?param1=värde1¶m2=värde2

Slutsats

Innan du börjar en diskussion om distribuerade system eller integration, definiera terminologin. Om Proxy alltid kommer att betyda samma sak i olika sammanhang, så kommer till exempel begäran att betyda lite i RPC-termer, och rangordning kommer att orsaka förvirring när man diskuterar REST-teknologier.

Efter omstart av datorn startade inte tjänsten" Remote Procedure Call (RPC)". Mycket beror på den här tjänsten. Som ett resultat fungerar inte systemåterställning, nätverksmiljö, ljud, Windows Installer, hanteringskonsolen (MMC) fungerar nästan inte, öppna fönster visas inte i aktivitetsfältet, etc., etc. Ett försök att starta manuellt resulterar i felet " Kan inte starta...(RPC) på xxxComp. Fel 5: Åtkomst nekad"Antiviruset hittade ingenting. Två dagars grävande och datorn väcktes till liv igen.

Enligt Microsofts rekommendation var det första jag försökte hitta och ta bort registernyckeln . Jag hade det inte, kanske som ett resultat av några installerade uppdateringar.

Därefter ett försök att återställa tjänstens parametrar i registret. Eftersom regedit.exe endast var läs/radera (en annan bieffekt) var det inte möjligt att göra ändringar. Ja, de behövdes inte, för... allt stämde. Det ska se ut så här:

Windows Registerredigerare version 5.00 "Description"="Tillhandahåller mappning av slutpunkter och andra RPC-tjänster." "DisplayName"="Remote Procedure Call (RPC)" "ErrorControl"=dword:00000001 "Group"="COM Infrastructure" "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 "Type"=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 "Säkerhet"=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

Parametervärde Start kan variera. Du kan fortfarande ändra registret, men du måste starta från MS ERD-befälhavare.

Jag kommer helt enkelt att beskriva nästa steg punkt för punkt. Den allmänna tanken är att du måste byta ut filerna med de som är kända för att fungera. De kan tas från en annan maskin eller från en Windows-distribution (som jag gjorde).

• Starta konsolen (Start > Kör: cmd)
• cd z:\i386(Windows distribution där)
• expandera explorer.ex_ %TEMP%\explorer.exe
• expandera svchost.ex_ %TEMP%\svchost.exe
• Starta Aktivitetshanteraren (Ctrl+Skift+Esc)
• Stoppa exlporer.exe-processen
• kopiera %TEMP%\explorer.exe %SYSTEMROOT% /y
• Stoppa alla svchost.exe-processer. Uppmärksamhet! Efter detta har du 60 sekunder på dig tills maskinen startar om.
• kopiera %TEMP%\svchost.exe %systemroot%\system32 /y

Denna finte gav inte heller resultat. Ett annat alternativ: kör en genomsökning av alla skyddade systemfiler med byte fel versioner korrekt. I konsolen kör:

Det hjälpte inte.. Sedan är ett helt brutalt drag att återställa säkerhetsinställningarna. Återigen i konsolen:

Efter omstart började datorn fungera grundläggande tjänster satte igång. Ett nytt problem dök upp (eller kanske var det där från början): åtminstone startade inte Diskhanteringshanteraren och Windows Installer under mitt konto. Tillträde beviljas ej. Du kan återställa åtkomsträttigheter till systemdisken till "standard" via konsolen:

Sedan måste du manuellt definiera rättigheterna för varje konto. eller återskapa dem, beroende på vilket som är lättare.

I mitt fall tilldelade jag helt enkelt samma rättigheter till hela systemdisken med åtkomst till . Jag lade till mitt domänkonto till standarden med fullständiga rättigheter till disken. Kanske är detta fel ur säkerhetssynpunkt, men jag har inte tid att fördjupa mig i varje katalog separat.

Vad mer kunde göras

Medan datorn var sjuk fanns inte detta i registret:

"ActiveService"="RpcSs"

Kanske skulle manuell tillägg på något sätt förändra situationen.

Försök att manuellt starta tjänsten, till exempel genom kommandot " net start rcpss"slutade med misstag" Fel 5: åtkomst nekad". Jag antar att åtkomst nekats eftersom tjänsten måste startas under systemkontot - "NT AUTHORITY". Det finns följande parameter i registret:

"ObjectName"="NT AUTHORITY\\NetworkService"

Jag skulle försöka ange administratörskontot här och starta tjänsten igen. Men detta är bara en idé som inte levde upp till genomförandet.

Ett annat alternativ: använd KiTrap0D-utnyttjandet för att få en konsol med systemrättigheter. Denna exploit skrevs om i . Egentligen en binär. Men jag har Windows-uppdateringar, så det ser ut som att denna exploit inte längre fungerar.

Relaterat material: