2011-09-11 17 views
5

Después de volver a basar el programa principal en su propia base de imágenes.C++ Cómo controlar la base de la imagen de LoadLibrary API

¿Cómo garantizar que el archivo DLL que se carga se cargará en 0x400000

dllImageBase = LoadLibrary("test.dll"); 
printf("imagebase = 0x%x", dllImageBase); 

Siempre me 0x460000 en lugar de 0x400000

necesito mi primera instrucción DLL que empezar desde 0x401000, que solía comenzará a 0x600000 antes rebase

Comando de enlazador a rebasar es

#pragma comment(linker, "/BASE:8000000") 

Entonces, 0x400000 es actualmente gratis, pero no lo usa de manera predeterminada ... así que de cualquier forma puedo controlarlo, donde debería reubicarse. Algunos WIN32API tal vez?

+0

¿Cómo se puede saber que '0x400000' es gratis? Algún otro DLL podría estar allí. –

+0

Miré el mapa de memoria y el encabezado .code/PE de mi programa comienza en '0x8000000' .. y antes de' 0x3300000' que es solo sortbls.nls y cada vez es más y más bajo, nada realmente está usando '0x4000000'. Pero lo que dices en algún lugar en el futuro se romperá por algún extraño accidente, sí? eso es si me explico cómo configurar demasiado 0x4000000. Luego, de nuevo, si de alguna manera descubro cómo controlar esto, nunca volverán a cargar allí. – SSpoke

+0

No conozco ninguna forma de controlar eso. Si su código depende de una DLL particular que vive en una dirección particular, está roto. Tan simple como eso (p. Ej., X64 Windows específicamente intenta aleatorizar las direcciones en las que se cargan varias DLL como medida de seguridad). –

Respuesta

5

Va a tener que deshabilitar la aleatorización de diseño del espacio de direcciones para cargar el archivo DLL donde lo desee. Una función diseñada para evitar lo que intenta hacer./Opción del vinculador DYNAMICBASE. Cargando en 0x400000 funcionó cuando lo probé.

+0

lol warning LNK4044: opción no reconocida "DYNAMICBASE: NO"; ignorado, supongo que mi compilador está desactualizado – SSpoke

2

Nunca confíe en una carga DLL en una base específica. Si puede forzar DLL para cargar en una base específica, entonces está abriendo un potencial agujero de seguridad.

Si tiene un archivo de mapa, sabe cuál es el desplazamiento de una función determinada. Por lo tanto, puede usar GetProcAddress para determinar cuál es la dirección base de la DLL. Esta es una forma mucho más segura de trabajar, incluso si eso significa que la actualización de su DLL rompe el código que carga la DLL.

+0

El código de ensamblaje usa matemática para generar el siguiente desplazamiento de llamada que está codificado en esa dirección base específica. Sé que es bastante extraño ver esto, pero nunca se supuso que se llamara como una función dll en primer lugar – SSpoke

+0

@SSpoke: Bueno, si no puedes resolver la dirección base usando un truco como sugiero arriba, entonces tienes no hay más remedio que utilizar la solución de Hans Passant. Solo tenga en cuenta que nada garantiza que una versión posterior de Windows no rompa su código. Una solución diferente es definitivamente la mejor manera de avanzar. Aunque no estoy del todo seguro de qué es exactamente lo que intentas hacer, me parece que podrías usar cualquier dirección base que elijas. – Goz

+0

Ojalá Goz también, pero estoy realizando un gran programa de ingeniería inversa con 128 funciones, la mejor solución sería convertir todo ese ensamblaje en código C o al menos en línea, pero quiero una salida perezosa por ahora, así que convertí el exe a un dll eliminado es main() y lo reemplazó con un dllmain por lo que puede cargar con éxito como dll ahora – SSpoke

Cuestiones relacionadas