Llame al escáner de ultrasonido rpc para procedimientos remotos. Mecanismo de llamada a procedimiento remoto-RPC

RPC proporciona un mecanismo muy importante para aplicaciones cliente-servidor ( Llamada a procedimiento remoto). RPC fue desarrollado por Sun Micrsystems y es una colección de herramientas y funciones de biblioteca. En particular, NIS (Sistema de información de red) y NFS (Sistema de archivos de red) funcionan en RPC.

Un servidor RPC consta de un sistema de procedimientos al que un cliente puede acceder enviando una solicitud RPC al servidor junto con los parámetros del procedimiento. El servidor llamará al procedimiento designado y devolverá el valor de retorno del procedimiento, si lo hubiera. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten en la llamada representación de datos externos ( Representación de datos externos, XDR). RPC se comunica con sockets UDP y TCP para transferir datos en formato XDR. Sun ha declarado RPC como dominio público y su descripción está disponible en una serie de documentos RFC.

A veces, los cambios en las aplicaciones RPC introducen incompatibilidad en el procedimiento de llamada de la interfaz. Por supuesto, un simple cambio provocaría que el servidor bloqueara cualquier aplicación que todavía esté esperando las mismas llamadas. Por lo tanto, los programas RPC tienen números de versión asignados, generalmente comenzando con 1. Cada una nueva version RPC realiza un seguimiento del número de versión. A menudo el servidor puede ofrecer varias versiones al mismo tiempo. En este caso, los clientes especifican el número de versión que desean utilizar.

La comunicación de red entre servidores y clientes RPC es un poco especial. Un servidor RPC ofrece uno o más procedimientos del sistema, cada conjunto de dichos procedimientos se denomina programa ( programa) y se identifica de forma única por el número de programa ( número de programa). Generalmente se guarda una lista de nombres de servicios en /etc/rpc, de la cual se proporciona un ejemplo a continuación.

Ejemplo 12-4. Archivo /etc/rpc de muestra

En las redes TCP/IP, los autores de RPC se enfrentaron a la tarea de asignar números de programas a servicios de red comunes. Cada servidor proporciona un puerto TCP y UDP para cada programa y cada versión. En general, las aplicaciones RPC utilizan UDP para transmitir datos y recurren a TCP cuando los datos a transmitir no caben en un único datagrama UDP.

Por supuesto, los programas cliente deben tener una forma de determinar qué puerto corresponde al número de programa. Usar un archivo de configuración para esto sería demasiado inflexible; Dado que las aplicaciones RPC no utilizan puertos reservados, no hay garantía de que el puerto no esté ocupado por alguna aplicación y esté disponible para nosotros. Por lo tanto, las aplicaciones RPC eligen cualquier puerto que puedan recibir y lo registran. demonio mapeador de puertos. Un cliente que quiera ponerse en contacto con un servicio con un número de programa determinado primero realizará una solicitud a portmapper para averiguar el número de puerto del servicio deseado.

Este método tiene la desventaja de que introduce un único punto de falla, muy parecido a inetd demonio Sin embargo, este caso es un poco peor porque cuando falla el mapeador de puertos, se pierde toda la información RPC sobre los puertos. Por lo general, esto significa que debe reiniciar todos los servidores RPC manualmente o reiniciar la máquina.

En Linux, el mapeador de puertos se llama /sbin/portmap o /usr/sbin/rpc.portmap. Aparte del hecho de que debe iniciarse desde el script de inicio de la red, portmapper no requiere ningún trabajo de configuración.

Llamada a procedimiento remoto(o Llamar a procedimientos remotos) (De inglés. Llamada a procedimiento remoto (RPC)): una clase de tecnologías que permiten que los programas de computadora llamen a funciones o procedimientos en otro espacio de direcciones (generalmente en computadoras remotas). Normalmente, una implementación de la tecnología RPC incluye dos componentes: un protocolo de red para la comunicación cliente-servidor y un lenguaje de serialización de objetos (o estructuras, para RPC que no es de objetos). Las diferentes implementaciones de RPC tienen arquitecturas muy diferentes y varían en sus capacidades: algunas implementan la arquitectura SOA, otras CORBA o DCOM. En la capa de transporte, los RPC utilizan principalmente los protocolos TCP y UDP; sin embargo, algunos están construidos sobre HTTP (lo que viola la arquitectura ISO/OSI, ya que HTTP no es un protocolo de transporte nativo).

Implementaciones

Existen muchas tecnologías que proporcionan RPC:

• Sun RPC (protocolo binario basado en TCP, UDP y XDR) RFC-1831 segundo nombre ONC RPC RFC-1833
• .Net Remoting (protocolo binario basado en TCP, UDP, HTTP)
• SOAP: Protocolo simple de acceso a objetos (protocolo de texto basado en HTTP), consulte la especificación: RFC-4227
• XML RPC (protocolo de texto basado en HTTP) consulte la especificación: RFC-3529
• Java RMI: invocación de método remoto de Java; consulte la especificación: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC Llamadas a procedimientos remotos de notación de objetos JavaScript (protocolo de texto basado en HTTP) consulte la especificación: RFC-4627
• DCE/RPC: entorno informático distribuido/llamadas a procedimientos remotos (protocolo binario basado en varios protocolos de transporte, incluidos TCP/IP y Named Pipes del protocolo SMB/CIFS)
• DCOM: modelo de objetos componentes distribuido conocido como MSRPC llamada a procedimiento remoto de Microsoft o "Network OLE" (una extensión orientada a objetos de DCE RPC que le permite pasar referencias a objetos y llamar a métodos de objetos a través de dichas referencias)

Principio

La idea de una llamada a procedimiento remoto (RPC) es ampliar el mecanismo bien conocido y comprendido para transferir control y datos dentro de un programa que se ejecuta en una máquina para transferir control y datos a través de una red. Las herramientas de llamada a procedimientos remotos están diseñadas para facilitar la organización de la informática distribuida y la creación de cliente-servidor distribuido. sistemas de información. La mayor eficiencia del uso de RPC se logra en aquellas aplicaciones en las que existe comunicación interactiva entre componentes remotos con tiempos de respuesta rápidos y una cantidad relativamente pequeña de datos transferidos. Estas aplicaciones se denominan orientadas a RPC.

Implementar llamadas remotas es mucho más complicado que implementar llamadas a procedimientos locales. Podemos identificar los siguientes problemas y tareas que deben resolverse al implementar RPC:

• Debido a que los procedimientos llamados y llamados se ejecutan en máquinas diferentes, tienen espacios de direcciones diferentes, y esto crea problemas al pasar parámetros y resultados, especialmente si las máquinas ejecutan sistemas operativos diferentes o tienen arquitecturas diferentes (por ejemplo, little-endian o big-endian). endian). ). Dado que RPC no puede depender de la memoria compartida, esto significa que los parámetros de RPC no deben contener punteros a ubicaciones de memoria que no sean de pila y que los valores de los parámetros deben copiarse de una computadora a otra. Para copiar los parámetros del procedimiento y los resultados de la ejecución a través de la red, se serializan.
• A diferencia de una llamada local, una llamada a procedimiento remoto utiliza necesariamente la capa de transporte de la arquitectura de red (por ejemplo, TCP), pero esto permanece oculto para el desarrollador.
• La ejecución del programa que llama y el procedimiento local llamado en la misma máquina se implementa dentro de un solo proceso. Pero la implementación de RPC implica al menos dos procesos: uno en cada máquina. Si uno de ellos falla, pueden surgir las siguientes situaciones: si el procedimiento que llama falla, los procedimientos llamados remotamente quedarán “huérfanos”, y si los procedimientos remotos fallan, los procedimientos que llaman se convertirán en “padres indigentes”, que esperarán en vano. para una respuesta de los procedimientos remotos.
• Hay una serie de problemas asociados con la heterogeneidad de los lenguajes de programación y los entornos operativos: las estructuras de datos y las estructuras de llamadas a procedimientos admitidas en cualquier lenguaje de programación no lo son de la misma manera en todos los demás lenguajes. Por tanto, existe un problema de compatibilidad que aún no se ha resuelto ni mediante la introducción de un estándar generalmente aceptado ni mediante la implementación de varios estándares competitivos en todas las arquitecturas y en todos los lenguajes.

Subsistemas

• Subsistema de transporte

Gestionar conexiones salientes y entrantes. - soporte para el concepto de "límite de mensaje" para protocolos de transporte que no lo soportan directamente (TCP). - soporte para entrega garantizada para protocolos de transporte que no lo admiten directamente (UDP).

• Grupo de subprocesos (solo destinatario). Proporciona un contexto de ejecución para el código invocado a través de la red.

• Marshalling (también llamado "serialización"). Empaquetar parámetros de llamada en un flujo de bytes de forma estándar, independientemente de la arquitectura (en particular, el orden de los bytes en una palabra). En particular, puede afectar matrices, cadenas y estructuras a las que apuntan parámetros de puntero.

• Cifrar paquetes y aplicarles una firma digital.

• Autenticacion y autorizacion. Transmisión a través de la red de información que identifica al sujeto que realiza la llamada.

En algunas implementaciones de RPC (.NET Remoting), los límites de los subsistemas son interfaces polimórficas abiertas y es posible escribir su propia implementación de casi todos los subsistemas enumerados. En otras implementaciones (DCE RPC en Windows) este no es el caso.

ver también

Concepto de llamada a procedimiento remoto (RPC)

La idea de una llamada a procedimiento remoto (RPC) es ampliar el mecanismo bien conocido y comprendido para transferir control y datos dentro de un programa que se ejecuta en una máquina para transferir control y datos a través de una red. Las herramientas de llamada a procedimientos remotos están diseñadas para facilitar la organización de la informática distribuida. La mayor eficiencia del uso de RPC se logra en aquellas aplicaciones en las que existe comunicación interactiva entre componentes remotos con tiempos de respuesta rápidos y una cantidad relativamente pequeña de datos transferidos. Estas aplicaciones se denominan orientadas a RPC.

Los rasgos característicos de la convocatoria de trámites locales son:

• Asimetría, es decir, una de las partes que interactúan es el iniciador;
• Sincronicidad, es decir, la ejecución del procedimiento que llama se suspende desde el momento en que se emite la solicitud y se reanuda solo después de que regresa el procedimiento llamado.

Implementar llamadas remotas es mucho más complicado que implementar llamadas a procedimientos locales. Para empezar, dado que los procedimientos llamados y llamados se ejecutan en máquinas diferentes, tienen diferentes espacios de direcciones, y esto crea problemas al pasar parámetros y resultados, especialmente si las máquinas no son idénticas. Dado que RPC no puede depender de la memoria compartida, esto significa que los parámetros de RPC no deben contener punteros a ubicaciones de memoria que no sean de pila y que los valores de los parámetros deben copiarse de una computadora a otra. La siguiente diferencia entre RPC y una llamada local es que necesariamente utiliza el sistema de comunicación subyacente, pero esto no debe ser explícitamente visible ni en la definición de los procedimientos ni en los procedimientos mismos. La lejanía introduce problemas adicionales. La ejecución del programa que llama y el procedimiento local llamado en la misma máquina se implementa dentro de un solo proceso. Pero la implementación de RPC implica al menos dos procesos: uno en cada máquina. Si uno de ellos falla, pueden surgir las siguientes situaciones: si el procedimiento de llamada falla, los procedimientos llamados remotamente quedarán “huérfanos”, y si los procedimientos remotos fallan, los procedimientos de llamada quedarán “padres huérfanos”, esperando en vano una respuesta de los procedimientos remotos.

Además, existen una serie de problemas asociados con la heterogeneidad de los lenguajes de programación y los entornos operativos: las estructuras de datos y las estructuras de llamadas a procedimientos admitidas en cualquier lenguaje de programación no lo son de la misma manera en todos los demás lenguajes.

Estos y algunos otros problemas se resuelven mediante la extendida tecnología RPC, que subyace a muchos sistemas operativos distribuidos. Operaciones básicas RPC

Para comprender cómo funciona RPC, primero consideremos realizar una llamada a un procedimiento local en una máquina típica que se ejecuta sin conexión. Sea esto, por ejemplo, una llamada al sistema.

contar=leer(fd, buf, nbytes);

donde fd es un número entero, buf es una matriz de caracteres y nbytes es un número entero.

Para realizar la llamada, el procedimiento de llamada inserta los parámetros en la pila en orden inverso (Figura 3.1). Después de ejecutar la llamada de lectura, coloca el valor de retorno en un registro, mueve la dirección de retorno y devuelve el control al procedimiento de llamada, que extrae los parámetros de la pila y los devuelve a su estado original. Tenga en cuenta que en el lenguaje C, los parámetros se pueden llamar por referencia (por nombre) o por valor (por valor). En relación con el procedimiento llamado, los parámetros de valor son variables locales inicializadas. El procedimiento llamado puede cambiarlos sin afectar los valores originales de estas variables en el procedimiento que llama.

Si se pasa un puntero a una variable al procedimiento llamado, cambiar el valor de esta variable por el procedimiento llamado implica cambiar el valor de esta variable para el procedimiento que llama. Este hecho es muy significativo para RPC.

También hay otro mecanismo de paso de parámetros que no se utiliza en C. Se llama llamada por copia/restauración, que requiere que la persona que llama copie las variables en la pila como valores y luego las copie nuevamente después de realizar la llamada a través del valores originales del procedimiento de llamada.

La decisión sobre qué mecanismo de paso de parámetros utilizar la toman los desarrolladores del lenguaje. A veces depende del tipo de datos que se transfieren. En C, por ejemplo, los números enteros y otros datos escalares siempre se pasan por valor y las matrices siempre se pasan por referencia.

Solicitud

Una parte importante de los instrumentos control remoto El sistema operativo Windows (Visor de eventos, Administrador de servidores, administración de impresión, listas de usuarios) utiliza DCE RPC como medio de comunicación a través de la red entre el servicio administrado y la aplicación de control de la interfaz de usuario. El soporte DCE RPC ha estado presente en Windows NT desde la primera versión 3.1. Los clientes DCE RPC también fueron admitidos en la línea ligera. sistemas operativos Windows 3.x/95/98/Me.

Las bibliotecas del sistema Windows que proporcionan dichas capacidades de control y sirven como capa base para aplicaciones de control de interfaz de usuario (netapi32.dll y en parte advapi32.dll) en realidad contienen código de cliente para las interfaces DCE RPC que realizan este control.

Esta decisión arquitectónica fue objeto de críticas activas contra Microsoft. Los procedimientos de clasificación genéricos presentes en DCE RPC son muy complejos y tienen un enorme potencial para explotar defectos en la red mediante el envío de un paquete DCE RPC deliberadamente mal formado. Una parte importante de los defectos seguridad de ventanas, descubiertos desde finales de los 90 hasta mediados de los 2000, eran precisamente errores en el código de clasificación DCE RPC.

Además de DCE RPC, Windows utiliza activamente la tecnología DCOM. Por ejemplo, se utiliza como medio de comunicación entre las herramientas de administración del servidor web IIS y el propio servidor que se administra. Una interfaz completamente funcional para comunicarse con el sistema de correo MS Exchange Server (MAPI) también se basa en DCOM.

La idea de llamar a procedimientos remotos (Llamada a Procedimiento Remoto - RPC) Consiste en extender el mecanismo bien conocido y comprendido para transferir control y datos dentro de un programa que se ejecuta en una máquina para transferir control y datos a través de una red. Las herramientas de llamada a procedimientos remotos están diseñadas para facilitar la organización de la informática distribuida.

La mayor eficiencia del uso de RPC se logra en aquellas aplicaciones en las que hay comunicación interactiva entre componentes remotos Con corto tiempo de respuesta Y cantidad relativamente pequeña de datos transmitidos.Estas aplicaciones se denominan orientadas a RPC.

Los rasgos característicos de la convocatoria de trámites locales son:

asimetría, es decir, una de las partes que interactúan es el iniciador;

sincronicidad, es decir, la ejecución del procedimiento que llama se suspende desde el momento en que se emite la solicitud y se reanuda sólo cuando regresa el procedimiento llamado.

Implementar llamadas remotas es mucho más complicado que implementar llamadas a procedimientos locales.

1. Comencemos con el hecho de que dado que los procedimientos que llaman y llamados se ejecutan en máquinas diferentes, tener diferentes espacios de direcciones, y esto crea Problemas al transferir parámetros y resultados, especialmente si las máquinas no son idénticas..

Dado que RPC no puede depender de la memoria compartida, esto significa que Los parámetros RPC no deben contener punteros a ubicaciones de memoria que no sean de pila. Así que lo que los valores de los parámetros deben copiarse de una computadora a otra.

2. La siguiente diferencia entre RPC y una llamada local es que utiliza necesariamente el sistema de comunicación subyacente, sin embargo esto no debe ser claramente visible ni en la definición de los procedimientos ni en los propios procedimientos .

La lejanía introduce problemas adicionales. Ejecutar el programa que llama y el procedimiento local llamado en la misma máquina implementado dentrosoltero proceso. Pero involucrado en la implementación de RPCal menos dos procesos - uno en cada coche. Si uno de ellos falla, pueden ocurrir las siguientes situaciones:

Si el procedimiento de llamada falla, los procedimientos llamados remotamente quedarán "huérfanos" y

Si los procedimientos remotos finalizan de forma anormal, los procedimientos que llaman se convertirán en "padres indigentes" y esperarán una respuesta de los procedimientos remotos en vano.

Además, hay una serie de problemas asociados con la heterogeneidad de los lenguajes de programación y los entornos operativos : Las estructuras de datos y las estructuras de llamadas a procedimientos admitidas en cualquier lenguaje de programación no lo son de la misma manera en todos los demás lenguajes.

Estos y algunos otros problemas se resuelven mediante la extendida tecnología RPC, que subyace a muchos sistemas operativos distribuidos.

La idea detrás de RPC es hacer que una llamada a un procedimiento remoto se parezca lo más posible a una llamada a un procedimiento local. En otras palabras, haga que RPC sea transparente: el procedimiento que llama no necesita saber que el procedimiento llamado está en otra máquina, y viceversa.

RPC logra la transparencia de la siguiente manera. Cuando el procedimiento llamado es realmente remoto, se coloca en la biblioteca otra versión del procedimiento, denominada código auxiliar de cliente, en lugar del procedimiento local. Al igual que el procedimiento original, el stub se llama usando una secuencia de llamada (como en la Figura 3.1) y se produce una interrupción al acceder al kernel. Sólo que, a diferencia del procedimiento original, no coloca parámetros en registros y no solicita datos del kernel; en cambio, genera un mensaje para ser enviado al kernel de la máquina remota..

Arroz. 3.2. Llamada a procedimiento remoto

El propósito de este artículo es discutir la terminología. El artículo no trata sobre cómo y por qué, sino sólo sobre el uso de la terminología. El artículo refleja la opinión del autor y no pretende ser científico.

Introducción

Si trabajas en programación sistemas distribuidos o en integración de sistemas, entonces la mayor parte de lo que se presenta aquí no es nuevo para usted.

El problema surge cuando personas que usan diferentes tecnologías se encuentran y cuando esas personas comienzan a tener conversaciones técnicas. En este caso, a menudo surgen malentendidos mutuos debido a la terminología. Aquí intentaré reunir las terminologías utilizadas en diferentes contextos.

Terminología

No existe una terminología ni una clasificación claras en esta área. La terminología utilizada a continuación es un reflejo del modelo del autor, es decir, es estrictamente subjetiva. Cualquier crítica y discusión son bienvenidas.

He dividido la terminología en tres áreas: RPC (llamada a procedimiento remoto), mensajería y REST. Estas áreas tienen raíces históricas.

RPC

RPC tecnologías: las tecnologías más antiguas. Los representantes más destacados de RPC son: CORBA Y DCOM.

En aquella época era principalmente necesario conectar sistemas de forma rápida y relativamente fiable. redes locales. La idea principal detrás de RPC era hacer que llamar a sistemas remotos fuera muy parecido a llamar a funciones dentro de un programa. Toda la mecánica de las llamadas remotas estaba oculta al programador. Al menos intentaron ocultarlo. En muchos casos, los programadores se vieron obligados a trabajar en un nivel más profundo, donde aparecieron los términos marshaling ( ordenar) Y desmantelando(¿Cómo es eso en ruso?), que esencialmente significaba serialización. Las llamadas a funciones normales dentro de los procesos se manejaban al final de la persona que llama en Apoderado, y en el lado del sistema que realiza la función, en Despachador. Idealmente, ni el sistema de llamadas ni el sistema de procesamiento se ocuparían de las complejidades de la transferencia de datos entre sistemas. Todas estas sutilezas se concentraron en el paquete Proxy - Dispatcher, cuyo código se generó automáticamente.

Por lo tanto, no notará, no debería notar, ninguna diferencia entre llamar a una función local y llamar a una función remota.
Ahora hay una especie de renacimiento de RPC, cuyos representantes más destacados son: Google ProtoBuf, Thrift, Avro.

Mensajería

Con el tiempo, resultó que el intento de proteger al programador del hecho de que la función llamada aún difiere de la local no condujo a resultado deseado. Los detalles de implementación y las diferencias fundamentales entre los sistemas distribuidos eran demasiado grandes para resolverlos utilizando código Proxy generado automáticamente. Poco a poco, se comprendió que el hecho de que los sistemas estén conectados por un entorno poco fiable, lento y de baja velocidad debe reflejarse explícitamente en el código del programa.

Han aparecido tecnologías servicios web. empezamos a hablar ABC: Dirección, Vinculación, Contrato. No está del todo claro por qué aparecieron los contratos, que son esencialmente sobres para argumentos de entrada. Los contratos suelen complicar el modelo general en lugar de simplificarlo. Pero... no importa.

Ahora el programador creó explícitamente servicio(Servicio) o cliente(Cliente) llamando al servicio. El servicio consistió en un conjunto operaciones (Operación), cada uno de los cuales tomó en la entrada pedido(Pedido) y emitido respuesta(Respuesta). Cliente explícitamente enviado(Enviado) solicitud, el servicio recibido explícitamente ( Recibir) y le respondió (Enviado), enviando la respuesta. El cliente recibió respuesta y la llamada finalizó.

Al igual que en RPC, había un Proxy y un Dispatcher ejecutándose en alguna parte. Y como antes, su código se generaba automáticamente y el programador no necesitaba entenderlo. A menos que el cliente haya utilizado explícitamente clases de Proxy.

Las solicitudes y respuestas se convierten explícitamente a un formato destinado a la transmisión por cable. La mayoría de las veces se trata de una matriz de bytes. La transformación se llama Publicación por entregas Y Deserialización y a veces se esconde en el código Proxy.
La culminación de la mensajería se manifestó en el surgimiento del paradigma ESB (autobús de servicio empresarial). Nadie puede explicar realmente qué es, pero todos están de acuerdo en que los datos se mueven a través del ESB en forma de mensajes.

DESCANSAR

En la lucha constante con la complejidad del código, los programadores dieron el siguiente paso y crearon DESCANSAR.

El principio fundamental de REST es que las operaciones de funciones están muy limitadas y solo se deja un conjunto de operaciones. CRUD: Crear - Leer - Actualizar - Eliminar. En este modelo, todas las operaciones siempre se aplican a algunos datos. Las operaciones disponibles en CRUD son suficientes para la mayoría de las aplicaciones. Dado que las tecnologías REST en la mayoría de los casos implican el uso del protocolo HTTP, los comandos CRUD se reflejaron en los comandos. HTTP (Correo - Conseguir - Poner - Borrar) . Se afirma constantemente que REST no está necesariamente vinculado a HTTP. Pero en la práctica, se utiliza ampliamente la reflexión de las firmas de operación en la sintaxis de los comandos HTTP. Por ejemplo, llamando a la función

EntityAddress ReadEntityAddress (cadena parámetro1, cadena parámetro2)

Expresado así:

OBTENER: dirección de entidad?param1=valor1¶m2=valor2

Conclusión

Antes de comenzar una discusión sobre sistemas distribuidos o integración, defina la terminología. Si Proxy siempre significará lo mismo en diferentes contextos, entonces, por ejemplo, solicitud significará poco en términos de RPC, y la clasificación causará confusión cuando se hable de tecnologías REST.

Después de reiniciar la computadora el servicio no se inició" Llamada a procedimiento remoto (RPC)". Mucho depende de este servicio. Como resultado, la recuperación del sistema, el entorno de red, el sonido, el instalador de Windows no funcionan, la consola de administración (MMC) casi no funciona, las ventanas abiertas no se muestran en la barra de tareas, etc. etc. Un intento de iniciar manualmente da como resultado el error " No se puede iniciar...(RPC) en xxxComp. Error 5: Acceso denegado"El antivirus no encontró nada. Dos días de investigación y el ordenador volvió a la vida.

Según la recomendación de Microsoft, lo primero que intenté fue buscar y eliminar la clave de registro. . No lo tenía, quizás debido a algunas actualizaciones instaladas.

A continuación, se intenta restaurar los parámetros del servicio en el registro. Dado que regedit.exe era de solo lectura/eliminación (otro efecto secundario), no fue posible realizar cambios. Sí, no eran necesarios, porque... todo estaba bien. Debe tener un aspecto como este:

Editor del Registro de Windows Versión 5.00 "Descripción"="Proporciona mapeo de puntos finales y otros servicios RPC." "DisplayName"="Llamada a procedimiento remoto (RPC)" "ErrorControl"=dword:00000001 "Group"="Infraestructura 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 "NombreObjeto"="NT AUTHORITY\\NetworkService" "Inicio"=dword:00000002 "Tipo"=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 "Seguridad"=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,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,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

Valor del parámetro comenzar puede variar. Aún puedes cambiar el registro, pero necesitas arrancar desde Comandante MS ERD.

Simplemente describiré los siguientes pasos punto por punto. La idea general es que es necesario reemplazar los archivos por otros que se sepa que funcionan. Se pueden tomar de otra máquina o de una distribución de Windows (como hice yo).

• Inicie la consola (Inicio > Ejecutar: cmd)
• cdz:\i386(Distribución de Windows allí)
• expandir explorer.ex_ %TEMP%\explorer.exe
• expandir svchost.ex_ %TEMP%\svchost.exe
• Inicie el Administrador de tareas (Ctrl+Shift+Esc)
• Detener el proceso exlporer.exe
• copiar %TEMP%\explorer.exe %SYSTEMROOT% /y
• Detenga todos los procesos de svchost.exe. ¡Atención! Después de esto, tendrá 60 segundos hasta que la máquina se reinicie.
• copiar %TEMP%\svchost.exe %systemroot%\system32 /y

Esta finta tampoco produjo resultados. Otra opción: ejecutar un análisis de todos los protegidos. archivos del sistema con reemplazo versiones incorrectas correcto. En la consola ejecuta:

No ayudó... Entonces, un movimiento completamente brutal es restaurar la configuración de seguridad. De nuevo en la consola:

Después de reiniciar la computadora comenzó a funcionar. servicios basicos comenzó. Apareció un nuevo problema (o tal vez estuvo ahí desde el principio): al menos el Administrador de administración de discos y el instalador de Windows no se iniciaron en mi cuenta. Acceso denegado. Puede restaurar los derechos de acceso al disco del sistema a los valores "predeterminados" a través de la consola:

Luego deberá definir manualmente los derechos para cada cuenta. o recrearlos, lo que sea más fácil.

En mi caso, simplemente asigné los mismos derechos a todo el disco del sistema, usando el acceso al archivo . Agregué mi cuenta de dominio al estándar con todos los derechos sobre el disco. Quizás esto sea incorrecto desde el punto de vista de la seguridad, pero no tengo tiempo para profundizar en cada directorio por separado.

Que mas se podria hacer

Mientras la computadora estaba enferma, esto no estaba en el registro:

"ActiveService"="RpcSs"

Quizás la adición manual cambiaría de alguna manera la situación.

Intenta iniciar manualmente el servicio, por ejemplo mediante el comando " rcpss de inicio neto"terminó en error" Error 5: acceso denegado". Supongo que el acceso está denegado porque el servicio debe iniciarse con la cuenta del sistema: "NT AUTHORITY". Existe el siguiente parámetro en el registro:

"ObjectName"="NT AUTHORITY\\NetworkService"

Intentaría ingresar a la cuenta de administrador aquí e iniciar el servicio nuevamente. Pero esto es sólo una idea que no estuvo a la altura de su implementación.

Otra opción: utilizar el exploit KiTrap0D para obtener una consola con derechos de sistema. Este exploit fue escrito en . En realidad un binario. Pero tengo actualizaciones de Windows, por lo que parece que este exploit ya no funciona.

Materiales relacionados: