Posterior a mirar en diferentes repositorios y sitios de internet finalmente descubrimos la solución que te mostramos pronto.
Solución:
Necesito encontrar el modo exe / dll que se construyó mirando sus encabezados.
Si por “encabezados” te refieres a secciones o recursos PE (¡los encabezados no te dirán nada y los programas generalmente no se envían con sus encabezados de desarrollo!), Esto es mas o menos posible, dentro de unos límites y de forma poco fiable. De lo contrario, este es un esfuerzo completamente imposible a menos que usted mismo haya escrito el programa.
Generalmente, es difícil hacer tal cosa de una manera confiable, más aún porque la “compilación de depuración” es una simplificación de Microsoft Visual Studio que no existe como tal en la mayoría de los compiladores. Por ejemplo, con GCC está perfectamente permitido tener un construcción optimizada que, sin embargo, contiene símbolos de depuración. Incluso es posible activar y desactivar optimizaciones con #pragma (¡y cambiar el nivel de optimización e incluso la máquina de destino!) y así tener funciones optimizadas (o grupos de funciones) en una compilación no optimizada, y viceversa.
La presencia de símbolos de depuración es su mejor conjetura para un programa que no escribió. No es posible (no de manera realista, de una manera simple y automatizada, de todos modos) saber a partir de un binario generado si ha sido optimizado o no.
Las secciones .debug$S y .debug$T contienen símbolos de depuración y tipos de depuración, respectivamente. Hay algunas otras secciones que comienzan con .debug también, pero están obsoletos. Un programa que se ha creado en “modo de depuración” y que no se ha eliminado posteriormente contendrá algunas o todas estas secciones.
Si utiliza C ++ sin herramientas externas, querrá omitir el código auxiliar “MZ” de DOS y el encabezado PE. Después de esto, vienen los encabezados de sección, que puede analizar. La documentación completa del formato de archivo se puede descargar aquí.
Lo más probable es que lea el archivo y realice una string partido para .debug será igual de bueno.
De manera similar, puede mirar VERSIONINFO o el archivo de manifiesto (también permiten especificar si un programa es una compilación de depuración), pero estos no son obligatorios. Puedes escribir casi todo lo que quieras en estos. En la medida, son incluso menos confiables que buscar símbolos de depuración.
Otra sugerencia, de nuevo poco fiable, sería comprobar con qué versiones de las bibliotecas del sistema estaba vinculado un programa. Si es la versión de depuración, es probable que sea una compilación de depuración. Sin embargo, uno podría hacer una versión de lanzamiento y aún enlazar con bibliotecas de depuración, nada puede evitar que lo haga.
La siguiente mejor suposición sería la ausencia de llamadas al CRT. assert función (que podrías hacer con una simple string partido), ya que el assert macro (del que normalmente se llama) se elimina por completo en una compilación con NDEBUG definido. Sin uso de ese símbolo, no string presente en el binario.
Desafortunadamente, un programa que no tiene cualquier afirmación se identificaría falsamente como “versión de lanzamiento” independientemente de su versión real, y es completamente posible redefinir la assert macro hacer algo completamente diferente (como printf un texto y continuar). Y por último, no sabes si algunos static La biblioteca de terceros con la que se vincula (que obviamente ya ha pasado el preprocesador) contiene llamadas a assert que no conoces.
Si desea comprobar un programa que ha escrito usted mismo, puede aprovechar el hecho de que el optimizador eliminará por completo las cosas que probablemente sean inalcanzables o no se utilicen. Puede tomar 2-3 intentos para hacerlo bien, pero básicamente debería ser tan simple como definir una variable (o una función exportada si su compilador / enlazador no exporta símbolos que no se usan) y escribir dos o tres valores mágicos desde una ubicación de programa que no es accesible. Un compilador de optimización al menos colapsará esos varios movimientos redundantes en uno, o más probablemente los eliminará por completo.
Entonces puedes hacer un binario string busca los valores mágicos. Si no están presentes, es una compilación optimizada.
La pregunta es muy buena y, como ya se ha dicho, no existen indicadores obvios (únicos) reales que indiquen si una imagen está depurada o publicada.
Como se explica aquí y aquí, la presencia de un directorio de depuración NO es un indicador de si se ha creado o no una imagen en el modo de lanzamiento. Es muy común que imágenes publicadas están construidos con soporte de depuración. De hecho, casi TODOS los archivos de imagen del sistema operativo Windows se crean con soporte de depuración (de lo contrario, NO habría posibilidad de vincular estas imágenes publicadas con los archivos de símbolos del servidor de símbolos de Microsoft). ¡Aunque estas imágenes son imágenes de lanzamiento!
Incluso la presencia de la sección .debug (en realidad, los nombres de las secciones NO juegan un papel en la especificación PE, el nombre de una sección se puede cambiar y configurar como desee, ¡al cargador no le importa!) NO es una indicador de lanzamiento frente a imagen de depuración.
Al final de todo puedes encontrar los comentarios de otros programadores, tú igualmente tienes la opción de dejar el tuyo si te gusta.