osx - vacuna - La mejor forma de inyectar funcionalidad en un binario
remedios caseros para aliviar el dolor de las vacunas en bebes (6)
Problema interesante. Si lo entiendo correctamente, le gustaría agregar la capacidad de llamar remotamente funciones en un ejecutable en ejecución.
Si realmente no necesita toda la aplicación, es posible que pueda quitar la función principal y convertirla en un archivo de biblioteca con el que pueda establecer un vínculo. Depende de usted averiguar cómo asegurarse de que se produzca toda la inicialización requerida.
Otro enfoque podría ser actuar como un virus. Inyecte una función que maneja las llamadas remotas, probablemente en otro hilo. Tendrá que iniciar este hilo al inyectar un código en la función principal o en cualquier otro lugar que sea apropiado. Lo más probable es que se encuentre con problemas importantes con la inicialización, la seguridad del hilo y / o el mantenimiento del estado del programa correcto.
La mejor opción, si está disponible, es conseguir que el proveedor de su aplicación exponga una API de complemento que le permita hacer esto de manera limpia y confiable de manera compatible.
Si vas con cualquiera de las dos rutas, será lento y frágil, pero aprenderás mucho en el proceso.
Cuál sería la mejor forma de insertar la funcionalidad en una aplicación binaria (3d party, fuente cerrada).
La aplicación de destino está en OSX y parece que se compiló usando gcc 3+. Puedo ver la lista de funciones implementadas en el binario y he depurado y aislado una función particular a la que me gustaría llamar de forma remota.
Específicamente, me gustaría llamar a esta función, llamémosla void zoomByFactor(x,y) - cuando recibo ciertos datos de un HIDevice complejo.
Puedo modificar o inyectar instrucciones fácilmente en el archivo binario mismo (es decir, no es necesario que el parche se produzca solo en la RAM).
¿Qué recomendarías como una forma de "hacer bien" esto?
Editar:
De hecho, necesito una aplicación completa. Entonces no puedo abandonarlo y usar una biblioteca. (Para aquellos que necesitan una explicación ética: esta es una pieza patentada de software CAD cuyo sitio web de la compañía no se ha actualizado desde 2006. He pagado este producto (bastante dinero por lo que realmente es) y tengo un proyecto datos que no puedo migrar fácilmente. El producto me queda bien tal como está, pero quiero usar un nuevo HID que obtuve recientemente. He examinado las partes internas de la aplicación, y estoy bastante seguro que puedo llamar a la función correcta con los datos relevantes y hacer que funcione correctamente).
Esto es lo que he hecho hasta ahora, y es bastante gheto.
Ya he modificado partes de la aplicación a través de este proceso:
xxd -g 0 binary > binary.hex cat binary.hex | awk ''substitute work'' > modified.hex xxd -r modified.hex > newbinary chmod 777 newbinary
Estoy haciendo este tipo de salto a través de aros porque el binario es casi 100 megas de gran tamaño.
El motivo de lo que estoy pensando es que saltaría en alguna parte del ciclo principal de la aplicación, lanzaría un hilo y regresaría a la función principal.
Ahora, las preguntas son: ¿dónde puedo insertar el nuevo código? ¿Necesito modificar las tablas de símbolos? alternativamente, ¿cómo podría hacer una carga de dylib automáticamente para que el único "pirateo" que tengo que hacer sea insertar una llamada a un dylib cargado normalmente en la función principal?
Para aquellos interesados en lo que terminé haciendo, aquí hay un resumen:
He visto varias posibilidades. Caen en el parche de tiempo de ejecución y en el parche de archivos binarios estáticos.
En lo que respecta al parcheo de archivos, esencialmente probé dos enfoques:
modificando el ensamblaje en los segmentos de código (__TEXT) del binario.
modificando los comandos de carga en el encabezado mach.
El primer método requiere espacio libre o métodos que puede sobrescribir. También sufre de mantenibilidad extremadamente pobre. Cualquier binario nuevo requerirá un parche manual una vez más, especialmente si su código fuente ha cambiado ligeramente.
El segundo método fue intentar agregar una entrada LC_ LOAD_ DYLIB en el encabezado mach. No hay muchos editores mach-o, por lo que es peludo, pero en realidad modifiqué las estructuras para que mi entrada fuera visible por otool -l . Sin embargo, esto en realidad no funcionó ya que había una dyld: bad external relocation length en tiempo de ejecución. Supongo que necesito rebuscar en las tablas de importación, etc. Y esto es demasiado esfuerzo para hacerlo bien sin un editor.
La segunda ruta era inyectar código en tiempo de ejecución. No hay mucho por hacer esto. Incluso para aplicaciones sobre las que tienes control (es decir, una aplicación secundaria que ejecutas). Quizás haya una forma de fork() y lanzar el proceso de inicialización, pero nunca voy a eso.
Hay SIMBL, pero esto requiere que su aplicación sea Cocoa porque SIMBL se posará como un InputManager de todo el sistema y cargará paquetes selectivamente. Desestimé esto porque mi aplicación no era Cocoa, y además, no me gustan las cosas de todo el sistema.
El siguiente paso fue mach_inject y el proyecto mach_star. También hay un proyecto más nuevo llamado PlugSuit alojado en google que parece ser nada más que un delgado envoltorio alrededor de mach_inject.
Mach_inject proporciona una API para hacer lo que su nombre implica. Sí encontré un problema en el código. En 10.5.4, el método mmap en el archivo mach_inject.c requiere que exista un MAP_ SHARED or''d con MAP_READ o de lo contrario el mmap fallará.
Aparte de eso, todo funciona realmente como se anuncia. Terminé usando mach_ inject_ bundle para hacer lo que tenía la intención de hacer con la adición estática de un DYLIB al encabezado mach: concretamente el lanzamiento de un nuevo hilo en el módulo init que hace su negocio sucio.
De todos modos, he hecho esto una wiki. Siéntase libre de agregar, corregir o actualizar la información. Prácticamente no hay información disponible sobre este tipo de trabajo en OSX. Más información es mejor.
En Windows, esto es simple de hacer, en realidad está muy extendido y se conoce como inyección DLL / código.
Existe un SDK comercial para OSX que permite hacer esto: Application Enhancer (gratuito para uso no comercial).
Recientemente tomé una puñalada de inyección / anulación utilizando las fuentes mach_star . Terminé escribiendo un tutorial para él, ya que la documentación para este material siempre es muy incompleta y, a menudo, desactualizada.
http://soundly.me/osx-injection-override-tutorial-hello-world/
En las versiones de Mac OS X anteriores a 10.5, harías esto con una extensión de Administrador de entrada. El Administrador de entrada estaba destinado a manejar cosas como la entrada para idiomas no romances, donde la extensión podría abrir una ventana para ingresar los glifos apropiados y luego pasar el texto completo a la aplicación. La aplicación solo necesitaba asegurarse de que era Unicode-clean, y no tenía que preocuparse por los detalles exactos de cada idioma y región.
El Administrador de entrada fue abusado salvajemente para parchar todo tipo de funcionalidades no relacionadas en las aplicaciones, y con frecuencia desestabilizó la aplicación. También se estaba convirtiendo en un vector de ataque para troyanos, como "Oompa-Loompa". MacOS 10.5 restringe las restricciones en los Administradores de Entrada: no los ejecutará en un proceso propiedad de root o wheel, ni en un proceso que haya modificado su uid. Lo que es más importante, 10.5 no cargará un administrador de entrada en un proceso de 64 bits y ha indicado que incluso el uso de 32 bits no es compatible y se eliminará en una versión futura.
Entonces, si puedes vivir con las restricciones, un administrador de entrada puede hacer lo que quieras. Es casi seguro que las próximas versiones de MacOS presenten otra forma (más segura, más limitada) de hacerlo, ya que la funcionalidad realmente es necesaria para el soporte de entrada de idiomas.
Creo que también puedes usar el método DYLD_INSERT_LIBRARIES .
Esta publicación también está relacionada con lo que estabas tratando de hacer;