La dirección fija está ocupada en .NET

OpenSSL compatible con FIPS tiene una limitación: debe cargar libeay32.dll en una dirección fija y, si se carga en cualquier otra dirección, falla la verificación de inicialización, por lo que no se puede usar en el modo FIPS.

Así que elegimos la dirección de acuerdo con la recomendación de Microsoft y en algunas máquinas que la dirección de vez en cuando está ocupada por otras bibliotecas, como MSVCR120_CLR0400.dll o mscorlib.ni.dll o clr.dll , obtienes el punto.

¿Hay alguna forma de verificar si se toma alguna dirección fija + longitud y pedirle al sistema operativo que me libere esa parte de la memoria, como volver a basar esas DLL a otras partes de la memoria o algo así?

Actualizar:

He recostackdo información de 20 dispositivos con ListDLLs y hay algún patrón en el que se carga, pero está lejos de estar bien definido. Así que hice algunos cálculos, encontré la brecha más grande, donde no se cargó nada en esos 20 registros que tenía, cambié la dirección base de libeay32 a un lugar en esa brecha (la brecha era ~ 6 veces más grande que dll, así que elegí ~ medio) y aún después de un par de bashs, la aplicación logró cargar algo en ese espacio antes de libeay32 (para ser específico – clrjit.dll, tiene una dirección base de 0x10000000, que creo que es la predeterminada), aunque en la aplicación bash cargar libeay32 tan pronto como sea posible.

¿Por qué no combinas los consejos dados?

  • Use /INCLUDE con un símbolo de libeay.dll cuando vincule su progtwig para forzar una dependencia estática en esa biblioteca.
  • Compile libeay32.dll con /FIXED para que no pueda ser reubicado.

Por lo tanto, se carga al cargar el archivo ejecutable, antes de que se ejecute cualquier código administrado, no dinámicamente más tarde, por lo que todas las dlls reubicables aún no están allí y no pueden interferir.