Convertir driver de 32 bit a 64 bit

Buenas tardes,

debo decir que soy principiante en todo esto y voy a plantear una serie de preguntas a ver si me podrían ayudar a tenerlo un poco más claro.

Primero: he oido que hay una serie de programas que permiten convertir un exe a codigo c.Su primera tarea es desensamblar y una vez desamblado compilar en c. ( IDA Pro Advanced + plugins de compilador )

Pregunta: ¿se podria pasar un driverde 32-bit a assembler, y desde assembler, o desde C, re-compilarlo para que funcione a 64-bit?

Segundo: Hacer este tipo de tareas se considera No Lícita. pero... ¿Sigue siendo "no Lícita" esta tarea si hemos comprado el driver y el vendedor ya no da soporte para las nuevas arquitecturas?. Obviamente, no sería para venderlo y sacar provecho, sino para resolver un problema personal.

Si os preguntais porqué pregunto esto en este foro es porque dicho driver es de una famosa tarjeta de Audio cuyos driver ya no estan disponibles.

Disculpen mi ignorancia

Saludos

Sí, hay algún intento por hacer descompiladores. Pero sólo son intentos. No hacen más que guiar en el proceso, que tiene que hacer el usuario casi en su totalidad a mano.

En teoría pasar algo de 32 bits a 64 es fácil. La única diferencia entre algo a 32 bits o 64 es la longitud de los datos, los que varíen de longitud, claro, dado que los códigos de operación del procesador son exactamente los mismos (con esto quedaría aclarado aquello tan discutido de si ocupa más memoria un programa a 32 bits que a 64 o no). Así que sólo habría que cambiar el flag del archivo que determina si el código está en 32 bits o 64, ir viendo qué datos cambian de longitud, añadir los bytes que hagan falta, quitar los que sobran, escribir los datos que deban tener..., en la práctica, imposible.

Otra manera es desensamblando. En teoría muy fácil también. Coges el IDA, le das el driver, lo desensambla, le das el *.asm a un ensamblador, le pones que ensamble a 64 bits y ya está.

El primer problema es que si coges el IDA y desensamblas algo, en el menú View, abajo del todo tienes el Problems, que si le das con el ratón te saldrá una ventana con una lista de problemas, que suele ser bastante larga hasta con un programita hecho por ti. Esos problemas son partes del código que el IDA no ha sabido cómo desensamblar, no sabe qué es, si es código, qué código, o sólo datos, o nada, o qué. Así que al *.asm resultante le faltan cosas. Eso es así en primer lugar porque los compiladores ocultan el código máquina que generan, lo hacen de tal manera que un desensamblador no acaba de enterarse de cómo va el asunto. Sólo queda claro cuando se ejecuta. Cuando lo ejecuta la cpu no hay problema, pero un desensamblador no va ejecutando, sólo interpretando, y los datos que desensambla no son los mismos que los que luego se ejecutan. Y a los embrollos que mete el compilador hay que añadir los que meta el desarrollador del software, que suelen ser más gordos.

Y aunque consigas un *.asm que funcione, la diferencia entre un sistema operativo a 32 bits y otro a 64 no son sólo los bits, y menos entre un xp y un vista por ejemplo. La capacidad de abstracción de un driver está entre 0 y menos todavía, y el api interno, el que maneja un driver, de un sistema operativo y el de otro sacado 3 meses después no es idéntico. Así que tendrías que ir cambiando las llamadas al api del sistema operativo de 32 bits por las del de 64. Y aunque consigas cabiar todas las llamadas al api, en el caso del windows tendrías que compilarlo con el vc, no con un ensamblador cualquiera, que es lo único que produce drivers para windows.

Entonces, ¿es posible coger un driver para 32 bits y hacer otro a 64? Sí. Sabiendo mucho de arquitectura del ordenador, del sistema operativo y del aparato para los que tiene que funcionar el driver, puedes ir viendo qué hace el de 32 con un debugger para drivers, windbg mismamente, y cuando lo tengas claro escribir un código que haga lo mismo, con las llamadas al api correctas, y compilarlo a 64 bits.

La ilegalidad está en el fin que se persigue más que en la acción ejecutada. Así que, si es para sacar un driver a 64 bits, nadie va a decirte nada por hacer ingeniería inversa. Si lo consigues igual hasta te da una propinilla el fabricante del aparato. No serías el primero al que se la dan.

Hola muchas gracias por la respuesta, la verdad me ha quedado bastante claro.

Si estamos hablando de un driver de una tarjeta de sonido, los api que manejan son las bien los del tipo KBD, VIO y MOU.

Una cosa que me intriga saber es que ... realmente lo que yo he conseguido pasar a ensamblador ( y luego a c) es el instalador de dicho driver, no el driver en sí.

No se hasta que punto afecta a la gestión y trabajo del driver recompilar el instalador a 64 bit.

Tuve que indagar mucho para descubrir como resolver todos los problemas que generaba el paso de ensamblador a C, ya que IDA Pro usa una librería propia para dar sentido a algunas variables. Esto significa que cuando lo editas con un IDE (en mi caso Visual Studio, no por gusto sino por cercanía a gestíon de programas de windows) los tipos de muchas variables no se entienden. Consegui importar la librería que usa IDA Pro para nombrar el tipo de esas famosas variables y listo.

Si bien tener un Instalador a 64-bit no sirve de nada... ¿de dónde extraigo el driver en cuestión para abordar el asunto del debuger y análisis de las llamadas API?
Yo " ataqué " directamente el intalador; puesto que pensaba que era él quien ponia en contacto el driver con el SO. Una vez leída tu respuesta, pongo en duda la efectividad de dicha tarea.. ya que en dicho proceso no se ha realizado reajustes de llamadas API ni nada por el estilo.. tan sólo he logrado un Instalador, en sí, a 64-bit.

Estoy en lo correcto?

Ante todo.. no me supone ninguna locura enfrentarme a dicho trabajo... lo más que puede pasar es que me aburra y lo deje.. pero sabiendo lo qeu me encanta estas cosas... es bien difícil. Igual al final entre todos conseguimos mi proposito y compartiendo el "resultado" en el foro todos nos beneficiamos de dicho logro.

Un saludo enorme y muchas gracias.

Vegno

Creí que se te habrían quitado las ganas de seguir.

Me imagino que el instalador sólo crea los archivos, inf incluído, e instala todo. Seguramente si lo renombras a zip lo abra el winzip y veas los archivos.

Lo realmente importante es el driver en sí. Archivos *.sys, *.drv, *.dll, *.ax.... Vete al administrador de dispositivos, selecciona la tarjeta, y en la pestaña controlador te pone qué archivos lo conforman, dónde están y todo. Para instalar un driver lo único que necesita el windows es un archivo inf. Ahí pone todo lo que tiene que hacer para echar a andar, y qué archivos son los necesarios.

El windows funciona a base de capas, como todo ahora. Antes del Directx o el Asio había muchas, lo que ralentizaba los accesos mucho. Ahora hay menos. Abajo del todo está es driver que hace el fabricante, que sabe qué registros tiene su aparato, que puertos debe usar, direcciones de memoria, y cómo. Por encima está el HAL, la capa de abstración hardware, que se comunica directamente con el driver a base de un API con funciones estándar. Luego vendría el API del núcleo del windows y encima de todo al API de usuario, así, resumiendo.

Para compilar un driver tienes que bajarte el wdk (http://msdn.microsoft.com/en-us/windows/hardware/gg454513.aspx). Tiene ejemplos de drivers para el ac97, la sound blaster y muchos más. Como debuggeador lo mejor es el Immunity Debugger, antiguo Ollydbg, (http://www.immunityinc.com/products-immdbg.shtml), con intérprete de python para manejarlo.

Antes de hacer nada yo preguntaría al fabricante del aparato, no vaya a ser que ya lo haya intentado y resulte que no hay manera de hacerlo funcionar a 64 bits. Además puede ser que te mande información sobre cómo hacer un driver.

Programas Instalados y mensaje mandado.

Realmente, no tengo ninguna esperanza de que me respondan el mensaje... todos sabemos que las grandes empresas no hacen caso de estas cosas.

Yo intentaré hacerlo.. y si no lo logro, almenos aprenderé bastante. Analizo todo lo que me has dicho y si me surge alguna duda ya la comento por aqui.

Muchas gracias

Vegno

hay algun programa, que te haga esto automaticamente como el jbridge para los plugins por ejemplo, pero en este caso para un driver, para los que no tenemos tanto conocimiento tecnico , o nos da vertigo leer todo lo que comentais,??? muchas gracias