Cómo ocultar información para que no se vea en un ejecutable

[carlos gonzalez]

Hola amigos tengo una duda ojala alguien de ustedes me pueda ayudar, es algo urgente y delicado para mi trabajo.
Tengo en mi trabajo muchas aplicaciones muy estables desarrolladas en Delphi 7, manejamos dbexpress para las conexiones a la base de datos. No me había dado cuenta que si intentamos abrir el exe desde un block de notas muestra todos los datos de la conexión, servidor, usuario y password. Existe alguna forma de ocultar o encriptar esta información de modo que no sea visible y no ponga en riesgo la seguridad de la empresa.

Ejemplo de una parte de datos que me muestra al abrir el exe con el bloc de notas

	bvLoweredTabOrder TLabelLabel3Left
TopWidth1Height
Caption	Database:  TLabelDatabaseNameLeft[TopWidthHeight
  TBevelBevelLeftTopWidthþ Height	Shape	bsTopLine  TPanelPanel1LeftTopWidthý HeightAAlignalBottom
BevelOuterbvNoneTabOrder  TLabelLabel1LeftTopWidth8Height
Caption&User Name:FocusControlUserName  TLabelLabel2LeftTop$Width1Height
Caption
&Password:FocusControlPassword  TEditUserNameLeftVTopWidth™ Height	MaxLengthTabOrder   TEditPasswordLeftVTop!Width™ Height	MaxLengthPasswordChar*TabOrder     TPF0TMDataMDataOldCreateOrderOnCreateDataModuleCreateLeftITopfHeight¸Width÷ TSQLConnectionSQLConnection1ConnectionNamePOWER6
DriverNameCA400
GetDriverFuncgetSQLDriverCA400LibraryNamedbexpca400.dllLoginPromptParams.StringsDriverName=CA400Database=168.1.1.50User_Name=usersisPassword=Ori147HServerCharSet=ErrorResourceFile=LocaleCode=0000BlobSize=-1
RowsetSize=-1	RoleName=CA400 TransIsolation=DirtyReadCommitRetain=TrueAutoCommit=TrueCustom String=/trace=0Connection Timeout=-1Trim Char=True 	VendorLib	cwbdb.dllLeft Top  TSimpleDataSetSDSCp11pfGrados
Aggregates 
ConnectionSQLConnection1DataSet.CommandText

Su amigo Charless

[Casimiro Notevi]

Lo más simple y rápido, ahora mismo, es usar algo como UPX o similar.

[mamcx]

Ya que usas Sql Server, es mejor que uses "Seguridad Integrada":

http://www.connectionstrings.com/sql-server-2012/

Eso hace que la autenticacion pase por el OS. Es mas seguro. El uso de usuario/clave es desaconsejado para la mayoria de los casos y solo se usa para acceder a BD remotas por fuera del dominio/maquina

[[AgustinOrtu]]

Eso pasa porque esta todo en tiempo de diseño en tu componente connection

Lo mejor que podes hacer es asignar la ConnectionString en runtime, pasando los credenciales como string literales; no los almacenes como constantes o recursos

[orodriguezca]

Empezado por mamcx

Ya que usas Sql Server, es mejor que uses "Seguridad Integrada":

Por la librería de conexión "dbexpca400.dll" pensaría que se está conectando a un IBM ISeries (AS400). Si es así en este caso no aplica la "Seguridad Integrada".

[carlos gonzalez]

Es correcto la base de datos que manejamos es DBD2 DEL AS/400

[look]

No sera mejor indagar en temas de ofuscacion?, o sera algo asi como que exe tambien se va en debug y no release?

Saludos!

[mamcx]

En tal caso, la opcion mas recomendada es poner los datos en una ubicacion aparte y leerlo de forma dinamica. Puede ser un archivo que se le aplique los permisos adecuados, o usar mucho mejor el api:

https://msdn.microsoft.com/en-us/library/ms995355.aspx

Y esto en delphi:
https://stackoverflow.com/questions/...ord-in-windows

Esto entonces plantea como alimentar la primera vez esa info. La idea es que puedes por ejemplo pasarlo en un archivo, guardarlo de forma segura en el keylocker y borrar el archivo.

[Neftali [Germán.Estévez]]

Yo habitualmente para temas de password, los añado al código (no al DFM) con una encriptación sencilla o en algún fichero de configuración con técnica similar.
Y en tiempo de ejecución se asignan esos parámetros.

[pacopenin]

Una posible solución de efectos inmediatos podría ser cargar los valores que se desean ocultar llamando a funciones que devuelvan esos valores.

Hace tiempo nos piratearon un programa mediante un debugger. Generábamos la clave de registro y era almacenaba en una variable, luego la comparaba con la que tenía asignada la instalación del programa. Al asignarla a una variable, dicha clave se veía mediante el debuger. Cambiamos a devolverla mediante una función y ya no aparecía en toda la traza. Es algo sencillo y funciona.

[Neftali [Germán.Estévez]]

Empezado por pacopenin

Hace tiempo nos piratearon un programa mediante un debugger. Generábamos la clave de registro y era almacenaba en una variable, luego la comparaba con la que tenía asignada la instalación del programa. Al asignarla a una variable, dicha clave se veía mediante el debuger. Cambiamos a devolverla mediante una función y ya no aparecía en toda la traza. Es algo sencillo y funciona.

Si se entra en temas de debuggers (OllyDbg es el más utilizado) la cosa se complica y hay que entrar "en otro nivel".
Hay que tener en cuenta mensajes de error, mensajes al usuario, nombre que se definen en las funciones, nombres que se definen a las constantes/variables, y bastantes cosas más.
Normalmente lo primero que se hace es atacar al valor de una variable o constante (como comenta pacopenin), pero también al momento de la comparación. Es decir, que por muy complicada que sea la forma de almacenar la clave o de calcularla, al final lo normal es hacer un... "si este valor es igual a este" o "si son diferentes" dejo ejecutar o no (el registro es correcto o no).
Y a ese punto es al que se ataca. Modificando un JZ por un JNZ o JE por JNE, lo que se consigue es "negar" la comparación, por lo tanto, cualquier clave incorrecta pasa a devolver correcta (excepto la buena ).

Es un ejemplo, pero si alguien que sepa utilizar un debugger está pirateando nuestro programa, las técnicas y las estrategias para protegerlo o al menos para ponérselo más difícil son diferentes.