Обадете се на дистанционни процедури rpc ултразвуков скенер. Механизъм за извикване на отдалечена процедура - RPC

Много важен механизъм за приложения клиент-сървър се предоставя от RPC ( Извикване на отдалечена процедура). RPC е разработен от Sun Micrsystems и представлява колекция от инструменти и библиотечни функции. По-специално NIS (Мрежова информационна система) и NFS (Мрежова файлова система) работят върху RPC.

RPC сървърът се състои от система от такива процедури, до които клиентът има достъп чрез изпращане на RPC заявка до сървъра заедно с параметрите на процедурата. Сървърът ще извика определената процедура и ще върне върнатата стойност на процедурата, ако има такава. За да бъдат независими от машината, всички данни, обменени между клиент и сървър, се преобразуват в така нареченото представяне на външни данни ( Външно представяне на данни, XDR). RPC комуникира с UDP и TCP сокети за прехвърляне на данни в XDR формат. Sun обяви RPC за обществено достояние и описанието му е достъпно в поредица от RFC документи.

Понякога промените в RPC приложенията въвеждат несъвместимост в процедурата за извикване на интерфейс. Разбира се, една проста промяна би накарала сървъра да срине всички приложения, които все още чакат същите повиквания. Следователно RPC програмите имат присвоени номера на версии, обикновено започващи с 1. Всяка нова версия RPC следи номера на версията. Често сървърът може да предлага няколко версии едновременно. В този случай клиентите посочват номера на версията, която искат да използват.

Мрежовата комуникация между RPC сървъри и клиенти е малко специална. RPC сървър предлага една или повече системни процедури, всеки набор от такива процедури се нарича програма ( програма) и се идентифицира уникално чрез номера на програмата ( номер на програмата). Списък с имена на услуги обикновено се съхранява в /etc/rpc, пример за който е даден по-долу.

Пример 12-4. Примерен /etc/rpc файл

В TCP/IP мрежите авторите на RPC бяха изправени пред задачата да съпоставят програмните номера към общите мрежови услуги. Всеки сървър предоставя TCP и UDP порт за всяка програма и всяка версия. Като цяло RPC приложенията използват UDP за предаване на данни и се връщат към TCP, когато данните, които трябва да бъдат предадени, не се побират в една UDP дейтаграма.

Разбира се, клиентските програми трябва да имат начин да разберат кой порт отговаря на номера на програмата. Използването на конфигурационен файл за това би било твърде негъвкаво; Тъй като RPC приложенията не използват запазени портове, няма гаранция, че портът не е зает от някое приложение и е достъпен за нас. Следователно RPC приложенията избират всеки порт, който могат да получат и да го регистрират демон на portmapper. Клиент, който иска да се свърже с услуга с даден номер на програма, първо ще направи заявка до portmapper, за да разбере номера на порта на желаната услуга.

Този метод има недостатъка, че въвежда една единствена точка на повреда, подобно на inetdдемон Този случай обаче е малко по-лош, защото когато portmapper се повреди, цялата RPC информация за портовете се губи. Това обикновено означава, че трябва да рестартирате всички RPC сървъри ръчно или да рестартирате машината.

В Linux portmapper се нарича /sbin/portmap или /usr/sbin/rpc.portmap. Освен факта, че трябва да се стартира от скрипта за стартиране на мрежата, portmapper не изисква никаква работа по конфигуриране.

Извикване на отдалечена процедура(или Извикване на отдалечени процедури) (от английски. Извикване на отдалечена процедура (RPC)) - клас технологии, които позволяват на компютърни програми да извикват функции или процедури в друго адресно пространство (обикновено на отдалечени компютри). Обикновено изпълнението на RPC технологията включва два компонента: мрежов протокол за комуникация клиент-сървър и език за сериализиране на обекти (или структури, за необектен RPC). Различните реализации на RPC имат много различни архитектури и се различават по своите възможности: някои прилагат SOA архитектурата, други CORBA или DCOM. На транспортния слой RPC основно използват TCP и UDP протоколи, но някои са изградени върху HTTP (което нарушава ISO/OSI архитектурата, тъй като HTTP не е транспортен протокол по същество).

Реализации

Има много технологии, които осигуряват RPC:

• Sun RPC (двоичен протокол, базиран на TCP и UDP и XDR) RFC-1831 второ име ONC RPC RFC-1833
• .Net Remoting (двоичен протокол, базиран на TCP, UDP, HTTP)
• SOAP - Simple Object Access Protocol (HTTP-базиран текстов протокол) вижте спецификацията: RFC-4227
• XML RPC (HTTP базиран текстов протокол) вижте спецификация: RFC-3529
• Java RMI - Java Remote Method Invocation - вижте спецификацията: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (HTTP-базиран текстов протокол) вижте спецификацията: RFC-4627
• DCE/RPC – Разпределена изчислителна среда/Извиквания на отдалечени процедури (двоичен протокол, базиран на различни транспортни протоколи, включително TCP/IP и Named Pipes от протокола SMB/CIFS)
• DCOM – Разпределен компонентен обектен модел, известен като MSRPC Microsoft Remote Procedure Call или „Network OLE“ (обектно-ориентирано разширение към DCE RPC, което ви позволява да предавате препратки към обекти и да извиквате обектни методи чрез такива препратки)

Принцип

Идеята на Remote Procedure Call (RPC) е да разшири добре познатия и разбираем механизъм за прехвърляне на контрол и данни в рамките на програма, работеща на една машина, за да прехвърли контрол и данни през мрежа. Инструментите за отдалечено извикване на процедури са предназначени да улеснят организирането на разпределени изчисления и създаването на разпределен клиент-сървър информационни системи. Най-голямата ефективност при използването на RPC се постига в тези приложения, в които има интерактивна комуникация между отдалечени компоненти с бързо време за реакция и относително малко количество прехвърлени данни. Такива приложения се наричат ​​RPC-ориентирани.

Прилагането на отдалечени повиквания е много по-сложно от прилагането на извиквания на локални процедури. Можем да идентифицираме следните проблеми и задачи, които трябва да бъдат решени при внедряването на RPC:

• Тъй като извикващите и извикваните процедури се изпълняват на различни машини, те имат различни адресни пространства и това създава проблеми при предаване на параметри и резултати, особено ако машините работят с различни операционни системи или имат различни архитектури (например little-endian или big- endian). ). Тъй като RPC не може да разчита на споделена памет, това означава, че параметрите на RPC не трябва да съдържат указатели към местоположения в паметта без стек и че стойностите на параметрите трябва да се копират от един компютър на друг. За да копирате параметрите на процедурата и резултатите от изпълнението през мрежата, те се сериализират.
• За разлика от локалното повикване, извикването на отдалечена процедура задължително използва транспортния слой на мрежовата архитектура (например TCP), но това остава скрито за разработчика.
• Изпълнението на извикващата програма и извиканата локална процедура на една и съща машина се осъществява в рамките на един процес. Но внедряването на RPC включва поне два процеса - по един на всяка машина. Ако една от тях се срине, могат да възникнат следните ситуации: ако извикващата процедура се срине, дистанционно извиканите процедури ще станат „осиротели“, а ако отдалечените процедури се сринат, извикващите процедури ще станат „бедни родители“, които ще чакат напразно за отговор от отдалечените процедури.
• Съществуват редица проблеми, свързани с разнородността на езиците за програмиране и операционните среди: структурите от данни и структурите за извикване на процедури, поддържани във всеки един език за програмиране, не се поддържат по същия начин във всички други езици. По този начин има проблем със съвместимостта, който все още не е решен нито чрез въвеждането на един общоприет стандарт, нито чрез внедряването на няколко конкуриращи се стандарта на всички архитектури и на всички езици.

Подсистеми

• Транспортна подсистема

Управлявайте изходящи и входящи връзки. - поддръжка на концепцията за „граница на съобщение“ за транспортни протоколи, които не я поддържат директно (TCP). - поддръжка за гарантирана доставка за транспортни протоколи, които не го поддържат директно (UDP).

• Пул от нишки (само за извиквания). Осигурява контекст на изпълнение за код, извикан през мрежата.

• Маршалиране (наричано още "сериализация"). Пакетиране на параметри на повикване в поток от байтове по стандартен начин, независимо от архитектурата (по-специално реда на байтовете в една дума). По-специално, може да засегне масиви, низове и структури, посочени от параметрите на указателя.

• Криптиране на пакети и прилагане на цифров подпис към тях.

• Удостоверяване и оторизация. Предаване по мрежата на информация, идентифицираща субекта, извършващ повикването.

В някои реализации на RPC (.NET Remoting) границите на подсистемите са отворени полиморфни интерфейси и е възможно да напишете своя собствена реализация на почти всички изброени подсистеми. При други реализации (DCE RPC на Windows) това не е така.

Вижте също

Извикване на отдалечена процедура (RPC) Концепция за извикване на отдалечена процедура

Идеята на Remote Procedure Call (RPC) е да разшири добре познатия и разбираем механизъм за прехвърляне на контрол и данни в рамките на програма, работеща на една машина, за да прехвърли контрол и данни през мрежа. Инструментите за отдалечено извикване на процедури са предназначени да улеснят организацията на разпределени изчисления. Най-голямата ефективност при използването на RPC се постига в тези приложения, в които има интерактивна комуникация между отдалечени компоненти с бързо време за реакция и относително малко количество прехвърлени данни. Такива приложения се наричат ​​RPC-ориентирани.

Характерните особености на извикването на местни процедури са:

• Асиметрия, тоест една от взаимодействащите страни е инициаторът;
• Синхронността, тоест изпълнението на извикващата процедура се преустановява от момента на подаване на заявката и се възобновява само след връщане на извиканата процедура.

Прилагането на отдалечени повиквания е много по-сложно от прилагането на извиквания на локални процедури. Като начало, тъй като извикващите и извикваните процедури се изпълняват на различни машини, те имат различни адресни пространства и това създава проблеми при предаване на параметри и резултати, особено ако машините не са идентични. Тъй като RPC не може да разчита на споделена памет, това означава, че параметрите на RPC не трябва да съдържат указатели към местоположения в паметта без стек и че стойностите на параметрите трябва да се копират от един компютър на друг. Следващата разлика между RPC и локално повикване е, че той задължително използва основната комуникационна система, но това не трябва да се вижда изрично нито в дефиницията на процедурите, нито в самите процедури. Отдалечеността създава допълнителни проблеми. Изпълнението на извикващата програма и извиканата локална процедура на една и съща машина се осъществява в рамките на един процес. Но внедряването на RPC включва поне два процеса - по един на всяка машина. Ако една от тях се срине, могат да възникнат следните ситуации: ако извикващата процедура се срине, дистанционно извиканите процедури ще станат „осиротели“, а ако отдалечените процедури се сринат, извикващите процедури ще станат „осиротели родители“, чакащи напразно отговор от отдалечените процедури.

Освен това съществуват редица проблеми, свързани с хетерогенността на езиците за програмиране и операционните среди: структурите от данни и структурите за извикване на процедури, поддържани във всеки един език за програмиране, не се поддържат по същия начин във всички други езици.

Тези и някои други проблеми се решават от широко разпространената RPC технология, която е в основата на много разпределени операционни системи. Основни операции RPC

За да разберем как работи RPC, нека първо обмислим извикването на локална процедура на типична машина, работеща офлайн. Нека това е например системно повикване

count=read(fd, buf, nbytes);

където fd е цяло число, buf е масив от знаци, nbytes е цяло число.

За да извърши повикването, извикващата процедура избутва параметрите в стека в обратен ред (Фигура 3.1). След като извикването за четене се изпълни, то поставя върнатата стойност в регистър, премества адреса за връщане и връща контрола на извикващата процедура, която изважда параметри от стека, връщайки го в първоначалното му състояние. Имайте предвид, че в езика C параметрите могат да се извикват или чрез препратка (по име), или по стойност (по стойност). По отношение на извиканата процедура параметрите на стойността са инициализирани локални променливи. Извиканата процедура може да ги промени, без да засяга първоначалните стойности на тези променливи в извикващата процедура.

Ако указател към променлива се предаде на извиканата процедура, тогава промяната на стойността на тази променлива от извиканата процедура води до промяна на стойността на тази променлива за извикващата процедура. Този факт е много важен за RPC.

Има и друг механизъм за предаване на параметри, който не се използва в C. Нарича се call-by-copy/restore, който изисква извикващият да копира променливи в стека като стойности и след това да ги копира обратно, след като извикването бъде направено оригиналните стойности на процедурата за извикване.

Решението кой механизъм за предаване на параметри да се използва се взема от разработчиците на езика. Понякога зависи от вида на прехвърляните данни. В C, например, целите числа и другите скаларни данни винаги се предават по стойност, а масивите винаги се предават по референция.

Приложение

Значителна част от инструментите дистанционноОперационната система Windows (преглед на събития, мениджър на сървъри, управление на печат, потребителски списъци) използва DCE RPC като средство за комуникация по мрежата между управляваната услуга и приложението за контрол на потребителския интерфейс. Поддръжката на DCE RPC присъства в Windows NT от първата версия 3.1. DCE RPC клиентите също се поддържат в леката линия операционна система Windows 3.x/95/98/Me.

Системните библиотеки на Windows, които предоставят такива възможности за контрол и служат като базов слой за приложения за контрол на потребителския интерфейс (netapi32.dll и частично advapi32.dll), всъщност съдържат клиентски код за DCE RPC интерфейсите, които изпълняват този контрол.

Това архитектурно решение беше обект на активна критика срещу Microsoft. Общите процедури за сортиране, присъстващи в DCE RPC, са много сложни и имат огромен потенциал за използване на дефекти в мрежата чрез изпращане на умишлено неправилно образуван DCE RPC пакет. Значителна част от дефектите Защита на Windows, открити от края на 90-те до средата на 2000-те, бяха точно грешки в DCE RPC маршалинг кода.

В допълнение към DCE RPC, Windows активно използва технологията DCOM. Например, той се използва като средство за комуникация между инструментите за управление на IIS уеб сървър и самия управляван сървър. Напълно функционален интерфейс за комуникация с пощенската система на MS Exchange Server - MAPI - също е базиран на DCOM.

Идеята за извикване на отдалечени процедури (Извикване на отдалечена процедура - RPC)се състои от разширяване на добре познатия и разбираем механизъм за прехвърляне на управление и данни в рамките на програма, работеща на една машина, до прехвърляне на управление и данни през мрежа. Инструментите за отдалечено извикване на процедури са предназначени да улеснят организацията на разпределени изчисления.

Най-голямата ефективност при използването на RPC се постига в тези приложения, в които има интерактивна комуникация между отдалечени компонентис кратко време за реакцияИ относително малко количество предадени данни.Такива приложения се наричат ​​RPC-ориентирани.

Характерните особености на извикването на местни процедури са:

асиметрия,тоест една от взаимодействащите страни е инициаторът;

синхронност,тоест изпълнението на извикващата процедура се спира от момента на подаване на заявката и се възобновява едва когато извиканата процедура се върне.

Прилагането на отдалечени повиквания е много по-сложно от прилагането на извиквания на локални процедури.

1. Нека започнем с факта, че тъй като извикващите и извикваните процедури се изпълняват на различни машини, те имат различни адресни пространства, а това създава проблеми при прехвърляне на параметри и резултати, особено ако машините не са идентични.

Тъй като RPC не може да разчита на споделена памет, това означава, че Параметрите на RPC не трябва да съдържат указатели към места в паметта без стекКакво от това? стойностите на параметрите трябва да се копират от един компютър на друг.

2. Следващата разлика между RPC и локално повикване е, че то задължително използва основната комуникационна система, обаче това не трябва да се вижда ясно нито в дефиницията на процедурите, нито в самите процедури .

Отдалечеността създава допълнителни проблеми. Изпълнение на извикващата програма и извиканата локална процедура на една и съща машина реализирани в рамките наединичен процес. Но участва в прилагането на RPCпоне два процеса - по един във всяка кола. Ако някой от тях не успее, могат да възникнат следните ситуации:

Ако извикващата процедура се срине, дистанционно извиканите процедури ще станат „осиротели“ и

Ако отдалечените процедури прекратят необичайно, извикващите процедури ще станат „бедни родители“ и ще чакат отговор от отдалечените процедури без резултат.

Освен това има редица проблеми, свързани с разнородността на езиците за програмиране и операционните среди : Структурите от данни и структурите за извикване на процедури, поддържани във всеки един език за програмиране, не се поддържат по същия начин във всички други езици.

Тези и някои други проблеми се решават от широко разпространената RPC технология, която е в основата на много разпределени операционни системи.

Идеята зад RPC е извикването на отдалечена процедура да изглежда възможно най-подобно на извикване на локална процедура. С други думи, направете RPC прозрачен: извикващата процедура не трябва да знае, че извиканата процедура е на друга машина и обратното.

RPC постига прозрачност по следния начин. Когато извиканата процедура всъщност е отдалечена, друга версия на процедурата, наречена клиентски файл, се поставя в библиотеката вместо локалната процедура. Подобно на оригиналната процедура, стълбът се извиква с помощта на извикваща последователност (както на Фигура 3.1) и прекъсване възниква при достъп до ядрото. Само, за разлика от оригиналната процедура, тя не поставя параметри в регистрите и не изисква данни от ядрото; вместо това генерира съобщение, което да бъде изпратено до ядрото на отдалечената машина.

Ориз. 3.2. Извикване на отдалечена процедура

Целта на тази статия е да обсъдим терминологията. Статията не е за това как и защо, а само за използването на терминологията. Статията отразява мнението на автора и не претендира за научност.

Въведение

Ако работите в областта на програмирането разпределени системиили в системна интеграция, тогава повечето от представеното тук не е ново за вас.

Проблемът идва, когато се срещнат хора, които използват различни технологии, и когато тези хора започнат да водят технически разговори. В този случай често възникват взаимни недоразумения поради терминология. Тук ще се опитам да събера терминологиите, използвани в различни контексти.

Терминология

В тази област няма ясна терминология и класификация. Използваната по-долу терминология е отражение на модела на автора, тоест е строго субективна. Всякакви критики и всякакви дискусии са добре дошли.

Разделих терминологията на три области: RPC (Remote Procedure Call), Съобщения и REST. Тези райони имат исторически корени.

RPC

RPCтехнологии - най-старите технологии. Най-видните представители на RPC са - CORBAИ DCOM.

В онези дни беше необходимо главно системите да се свързват бързо и сравнително надеждно локални мрежи. Основната идея зад RPC беше да направи извикването на отдалечени системи подобно на извикване на функции в програма. Цялата механика на отдалечените разговори беше скрита от програмиста. Поне се опитаха да го скрият. Програмистите в много случаи бяха принудени да работят на по-дълбоко ниво, където се появиха термините marshaling ( сортиране) И демаршалиране(как е това на руски?), което по същество означаваше сериализация. Нормалните извиквания на функции в процесите бяха обработени от края на повикващия Прокси, а от страната на системата, изпълняваща функцията, в Диспечер. В идеалния случай нито системата за повикване, нито системата за обработка биха се справили със сложността на прехвърлянето на данни между системите. Всички тези тънкости бяха концентрирани в пакета Proxy - Dispatcher, чийто код се генерира автоматично.

Така че няма да забележите, не би трябвало да забележите разлика между извикване на локална функция и извикване на отдалечена функция.
Сега има един вид RPC ренесанс, най-ярките представители на който са: Google ProtoBuf, Thrift, Avro.

Съобщения

С течение на времето се оказа, че опитът да се защити програмистът от факта, че извиканата функция все още се различава от локалната, не доведе до желан резултат. Подробностите за изпълнението и фундаменталните разлики между разпределените системи бяха твърде големи, за да бъдат разрешени с помощта на автоматично генериран прокси код. Постепенно дойде разбирането, че фактът, че системите са свързани с ненадеждна, бавна, нискоскоростна среда, трябва да бъде изрично отразен в програмния код.

Появиха се технологии уеб услуги. Започнахме да говорим ABC: Адрес, обвързване, договор. Не е съвсем ясно защо се появиха договори, които по същество са пликове за входни аргументи. Договорите често усложняват цялостния модел, вместо да го опростяват. Но... няма значение.

Сега програмистът изрично създаде обслужване(Обслужване) или клиент(Клиент) обаждане на сервиза. Услугата се състоеше от комплект операции (Операция), всеки от които взе на входа искане(Заявка) и издадени отговор(Отговор). Клиент изрично изпратено(Изпратено) заявка, услугата изрично получена ( Получете) и му отговори (Изпратено), изпращайки отговора. Клиентът получи отговор и разговорът приключи.

Точно както при RPC, някъде имаше прокси и диспечер. И както преди, кодът им се генерираше автоматично и програмистът не трябваше да го разбира. Освен ако клиентът изрично не е използвал класове от прокси.

Заявките и отговорите се преобразуват изрично във формат, предназначен за предаване по кабела. Най-често това е байтов масив. Трансформацията се нарича СериализацияИ Десериализацияи понякога се крие в прокси кода.
Кулминацията на съобщенията се проявява в появата на парадигмата ESB (Enterprise Service Bus). Никой не може наистина да формулира какво е това, но всички са съгласни, че данните се движат през ESB под формата на съобщения.

ПОЧИВКА

В постоянната борба със сложността на кода програмистите направиха следващата стъпка и създадоха ПОЧИВКА.

Основният принцип на REST е, че функционалните операции са рязко ограничени и оставят само набор от операции CRUD: Създаване - Четене - Актуализиране - Изтриване. В този модел всички операции винаги се прилагат към някои данни. Операциите, налични в CRUD, са достатъчни за повечето приложения. Тъй като технологиите REST в повечето случаи предполагат използването на HTTP протокола, командите CRUD бяха отразени в командите HTTP (Публикувай - Вземете - Слагам - Изтрий) . Постоянно се заявява, че REST не е непременно свързан с HTTP. Но на практика широко се използва отразяването на сигнатурите на операцията върху синтаксиса на HTTP командите. Например извикване на функцията

EntityAddress ReadEntityAddress(низ параметър1, низ параметър2)

Изразено така:

GET: entityAddress?param1=value1¶m2=value2

Заключение

Преди да започнете дискусия за разпределени системи или интеграция, дефинирайте терминологията. Ако прокси винаги ще означава едно и също нещо в различни контексти, тогава, например, заявката ще означава малко в термините на RPC и маршалингът ще предизвика объркване при обсъждането на REST технологии.

След рестартиране на компютъра услугата не стартира" Извикване на отдалечена процедура (RPC)". Много зависи от тази услуга. В резултат на това възстановяването на системата, мрежовата среда, звукът, Windows Installer не работят, конзолата за управление (MMC) почти не работи, отворените прозорци не се показват на лентата на задачите и т.н., и т.н. Опит за ръчно стартиране води до грешката " Не може да се стартира...(RPC) на xxxComp. Грешка 5: Достъпът е отказан„Антивирусната не откри нищо. Два дни ровене и компютърът беше върнат към живот.

Според препоръката на Microsoft, първото нещо, което опитах, беше да намеря и изтрия ключа на системния регистър . Нямах го, може би в резултат на някои инсталирани актуализации.

След това се прави опит за възстановяване на параметрите на услугата в системния регистър. Тъй като regedit.exe беше само за четене/изтриване (друг страничен ефект), не беше възможно да се правят промени. Да, не бяха необходими, защото... всичко беше точно. Трябва да изглежда така:

Windows Registry Editor Version 5.00 "Description"="Предоставя картографиране на крайни точки и други RPC услуги." "DisplayName"="Извикване на отдалечена процедура (RPC)" "ErrorControl"=dword:00000001 "Group"="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" "Старт"=dword:00000002 "Тип"=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 "Сигурност"=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

Стойност на параметъра започнетеможе да варира. Все още можете да промените регистъра, но трябва да стартирате от Командир на MS ERD.

Просто ще опиша следващите стъпки точка по точка. Общата идея е, че трябва да замените файловете с такива, за които е известно, че работят. Те могат да бъдат взети от друга машина или от Windows дистрибуция (както направих аз).

• Стартирайте конзолата (Старт > Изпълнение: cmd)
• cd z:\i386(разпространение на Windows там)
• разгънете explorer.ex_ %TEMP%\explorer.exe
• разгънете svchost.ex_ %TEMP%\svchost.exe
• Стартирайте диспечера на задачите (Ctrl+Shift+Esc)
• Спрете процеса exlporer.exe
• копирайте %TEMP%\explorer.exe %SYSTEMROOT% /y
• Спрете всички процеси svchost.exe. внимание! След това ще имате 60 секунди, докато машината се рестартира.
• копирайте %TEMP%\svchost.exe %systemroot%\system32 /y

Този финт също не даде резултат. Друг вариант: стартирайте сканиране на всички защитени системни файловесъс замяна грешни версииправилно. В изпълнение на конзолата:

Не помогна. Тогава напълно брутален ход е да възстановите настройките за сигурност. Отново в конзолата:

След рестартиране компютърът започна да работи основни услугизапочна. Появи се нов проблем (или може би беше там от самото начало): поне Disk Management Manager и Windows Installer не стартираха под моя акаунт. Отказан достъп. Можете да възстановите правата за достъп до системния диск до „по подразбиране“ чрез конзолата:

След това трябва ръчно да дефинирате правата за всеки акаунт. или да ги пресъздадете, което е по-лесно.

В моя случай просто присвоих същите права на целия системен диск, използвайки достъп до . Добавих моя домейн акаунт към стандарта с пълни права върху диска. Може би това не е наред от гледна точка на сигурността, но нямам време да се ровя във всяка директория поотделно.

Какво друго можеше да се направи

Докато компютърът беше болен, това не беше в системния регистър:

"ActiveService"="RpcSs"

Може би ръчното добавяне по някакъв начин ще промени ситуацията.

Опитите за ръчно стартиране на услугата, например чрез командата " net start rcpss"завърши с грешка" Грешка 5: достъпът е отказан". Предполагам, че достъпът е отказан, защото услугата трябва да се стартира под системния акаунт - "NT AUTHORITY". В системния регистър има следния параметър:

"ObjectName"="NT AUTHORITY\\NetworkService"

Бих опитал да вляза в администраторския акаунт тук и да стартирам услугата отново. Но това е само идея, която не се осъществи.

Друг вариант: използвайте експлойта KiTrap0D, за да получите конзола със системни права. За този експлойт е писано в . Всъщност двоичен файл. Но имам актуализации на Windows, така че изглежда, че този експлойт вече не работи.

Свързани материали: