El principio de la inyección de la memoria entre procesos de Windows CE

Recientemente, debido a las necesidades de programación, llevé a cabo investigaciones sobre la capa de memoria WincowsCE debido a la menor documentación interna que se encuentra en esta zona, por lo que el estudio terminó en ocasión de la formación de este ejemplo Los documentos, con la esperanza de lanzar ladrillos para atraer el jade, consiguen la corrección de otros maestros.

En primer lugar, un requisito previo para la ejecución de programas

Debido a que Windows Forms sistema de mensajería se entrega siempre a la forma designada una función de mensaje de proceso en particular. Así que la parte formulario de mensajes de otros procesos en el proceso local (su aplicación) debe ser implementado en dos partes:

1, de conexión en código del formulario en el espacio de direcciones del proceso de destino Entra

2. Ejecute este código y reciba el mensaje del formulario de proceso de destino.

Estos dos pasos parecen simples, pero son más difíciles de implementar. Debido a que los dispositivos móviles Windows CE como sistema operativo embebido, y Windows 98/2000 /XP y otros sistemas operativos de escritorio tienen grandes diferencias en el núcleo del concepto de diseño y apoyan la API. Esto conduce directamente al sistema de escritorio convencional que usa inyección de gancho de mouse global /inyección de hilo remoto y otros métodos en el CE son completamente inviables. Pero la buena noticia es, depurador remoto remotexxx tales como herramientas de desarrollo de Microsoft me hace consciente de este objetivo no es una tarea imposible, ya que Microsoft puede hacer, es decir, dentro de la CE debe tener un conjunto completo de la memoria entre procesos Mecanismo de acceso /inyección de código.

En segundo lugar, los principios básicos de la ejecución de los programas

Después de dos días de búsqueda de Google en Internet me encontré con una función API interesante que no está declarado en la documentación de Microsoft: PerformCallBack4, la función legendaria Puede ejecutar una función en el proceso especificado en su propia aplicación, ¡Muy bien! Esto parece ser exactamente lo que necesito. ! A pesar de los rumores en línea también wm5 esta función no está soportada, de hecho demostrado que este rumor sólo informa

PerformCallBack4 función definida por:
[DllImport (" coredll.dll ")] pública uint extern estático PerformCallBack4 (ref CallBackInfo CallBackInfo, IntPtr ni_pVoid1, IntPtr ni_pVoid2, IntPtr ni_pVoid3);

en el que la función de estructura CallBackInfo parámetro se define:
[StructLayout (LayoutKind.Sequential)] público struct CallBackInfo {IntPtr público hProc; //proceso de destino remoto IntPtr pública PFN; IntPtr pública pvArg0 //puntero a una dirección de función de proceso de destino remoto; //primer parámetro de la función requerida} //estructura final

el ni_pVoid1 PerformCallback4 de, ni_pVoid2, ni_pVoid3 realizan otras funciones para los tres parámetros pasados ​​al proceso de destino remoto.

A medida que el código en el espacio de memoria del proceso de destino, podemos utilizar una función en el diseño, la fabricación:

1, con el fin de ahorrar el uso de memoria, biblioteca de vínculos dinámicos CE todo el programa de llamada ( DLL) se asignan a la misma dirección de memoria.

2, el diseño de memoria de la CE en la delineación de una posición de memoria de slot0, esta posición de memoria está ocupada por el proceso de ejecución, cada segmento de tiempo concreto, sólo un proceso puede ocupar este recuerdo El espacio Cuando sea necesario para llevar a cabo un proceso, el sistema no ejecuta directamente ubicaciones de memoria de código que un proceso, pero el proceso de ejecución de la posición de memoria copia el código para producir una copia de slot0 realizado. Ese proceso en la aplicación del proceso de la memoria tendrá que realizar dos versiones completamente diferente del código: el código existe en la memoria en sí se encuentra en proceso de slot0 código y los procesos se están ejecutando.

En esta función, se puede concluir: si el proceso de carga A por la función Prueba.dll LoadLibrary, y el proceso B también está cargado por la misma función Prueba.dll LoadLibrary, todas las funciones en el proceso A Prueba.dll Cuando se ejecuta en el proceso B, se obtiene la misma dirección en relación con el código de ejecución del proceso en slot0.

3, en CE, el sistema de memoria se divide en 33 ranuras, reservado para slot0 proceso que está siendo ejecutado, entonces cuando el proceso comienza de todo el código en una ranura (slot0 excepto que el En el notorio sistema CE, la memoria solo puede tener un máximo de 32 restricciones de ejecución de programas. Cuando la ejecución del proceso, cada acceso de memoria de espacio de direcciones por defecto de la aplicación sólo se puede acceder al espacio de direcciones de memoria de la ranura de memoria slot0 y el proceso es en. Pero para que el controlador de dispositivo puede acceder a los datos a otras aplicaciones que necesitan, CE proporciona dos funciones para romper este límite, SetKmode y SetProcPermission, la función SetKmode indica al sistema si los procesos que se están ejecutando en modo kernel necesita ser realizado; La función SetProcPermission puede aceptar una máscara de bits, cada bit de código tiene un control de acceso a la ranura, y 1 representa el contenido de la memoria que puede acceder a la ranura. 0 significa que no se puede acceder al contenido de la memoria de la ranura. Estas dos funciones son útiles en msdn, consulte la documentación para msdn.