Editar recursos de un archivo DLL

[FJDA]

hola
Tengo un crack de un programa con un dll. Tiene dentro unas imágenes de recursos que se acoplan al programa crackeado que no me gustan, así que decidí editar los recursos y eliminar o reemplazar las imágenes por las verdaderas del programa original. Lo edité con ResourceHacker, PE Explorer, Visual Studio C++.

Cuando lo edito el crack no funciona y me da error. Hice una prueba extraje la imagen de recurso y luego la volví a poner tal cual estaba. Idioma, ID todo igual, pero igualmente el crack me daba error. De alguna manera detecta que ha sido editado y lo rechaza, ya que el DLL es usado por un EXE. Probaré de editarlo mediante hexadecimal pero no podré colocar la imagen que yo quiera, solo para ver que pasa. También probé el abrirlo con 7-zip, pero no se permite la edición.

No se si habrá algún programa o alguna manera para editarlo y que no ocurra esto.

[tincopasan]

lo más probable es que tenga un chequeo de integridad del archivo(crc) te toca debugear para encontrar dicho punto.

[Serapis]

hola
Tengo un crack de un programa con un dll. Tiene dentro unas imágenes de recursos que se acoplan al programa crackeado que no me gustan, así que decidí editar los recursos y eliminar o reemplazar las imágenes por las verdaderas del programa original. Lo edité con ResourceHacker, PE Explorer, Visual Studio C++.

Cuando lo edito el crack no funciona y me da error. Hice una prueba extraje la imagen de recurso y luego la volví a poner tal cual estaba. Idioma, ID todo igual, pero igualmente el crack me daba error. De alguna manera detecta que ha sido editado y lo rechaza, ya que el DLL es usado por un EXE.

Cuando editas una dll que usa un programa y que está registrada (en el registor del sistema), cuando el ejecutable tratade cargar dicho ejecutable se localiza mediante su CLSID, como quiera que dicho valor habrá cambiado con tu modificación 'entenderá' que se trata de una version distinta.

Prueba primero a localizar en el registro la dll y haz copia de la rama/s que la contengan (junto con la dll original), luego registra la dll modificada, se creará un CLSID distinto del previo...
Si el programa instancia la dll por su servidor.nombre (late binding), seguirá teniendo acceso a ella, pero si el programa mantiene referencia a su CLSID (early binding), no funcionará, en cuyo caso tendrías que cambiar (también) en el programa... el CLSID, que referencia la dll (en todas las partes que apareciere), por el nuevo que arroja tras el registro después de editarla.

Otra cosa es que tras las modificaciones, tengas que usarlas en tus programas, simplemente registras la dll, y tu programa la instancia, no importa el CLSID que tenga ahora, porque es el que tu programa tomará... en este caso conviene además cambiar nombres, para evitar que una versión modificada (para uso personal y propio), no malogre el acceso y uso a la misma dll (la original sin modificar), que pueda necesitar uno o más programas del sistema.

[MCKSys Argentina]

Cuando editas una dll que usa un programa y que está registrada (en el registor del sistema), cuando el ejecutable tratade cargar dicho ejecutable se localiza mediante su CLSID, como quiera que dicho valor habrá cambiado con tu modificación 'entenderá' que se trata de una version distinta.

Prueba primero a localizar en el registro la dll y haz copia de la rama/s que la contengan (junto con la dll original), luego registra la dll modificada, se creará un CLSID distinto del previo...
Si el programa instancia la dll por su servidor.nombre (late binding), seguirá teniendo acceso a ella, pero si el programa mantiene referencia a su CLSID (early binding), no funcionará, en cuyo caso tendrías que cambiar (también) en el programa... el CLSID, que referencia la dll (en todas las partes que apareciere), por el nuevo que arroja tras el registro después de editarla.

Otra cosa es que tras las modificaciones, tengas que usarlas en tus programas, simplemente registras la dll, y tu programa la instancia, no importa el CLSID que tenga ahora, porque es el que tu programa tomará... en este caso conviene además cambiar nombres, para evitar que una versión modificada (para uso personal y propio), no malogre el acceso y uso a la misma dll (la original sin modificar), que pueda necesitar uno o más programas del sistema.

Pero eso es sólo en los casos en que se usa COM/ActiveX. Las DLLs en gral. no tienen un CLSID asociado (o, al menos, no conozco eso en Windows).

Si creas una DLL simple (Tipo "hola mundo") sólo tendrás una librería que importe las funciones para mostrar el mensaje y no mucho más...

Lo más probable es que sea lo que dice tincopasan: el crack calcula un hash de la DLL y si no coincide no funciona (tocar cualquier byte haría que cambie y lograr una colisión de hash dependería del tipo de hash usado. MD5 puede colisionarse en segundos/minutos).

Saludos!

[Serapis]

En efecto... las dll tipo API, es como bien señala Tincopasan y tú mismo...

Me faltó señalar que '...la otra situación que puede darse con las dll...' que omití precisamente porque ya había respuesta dada, aunque al escribir el mensaje me pareció que era como mucho deducible, ahora al releerme no me parece tan obvio, así que gracias por añadir la diferenciación para impedir que induzca a cierta ambigüedad.

[FJDA]

Habéis mencionado que no tiene un CLSID asociado  pues no, de hecho el DLL de crack en cuestión no es el original que se instala con el crack justamente. Rastreando la actividad del setup descubrí que instala una versión más vieja y luego la actualiza (offline) reemplazando justamente dicho DLL, todo desde un PC controlado. Luego instalé el crack manualmente pero al ser una versión DLL más antigua no servía para crackear el programa "víctima" aunque se ejecutaba pero la licencia no era válida. Después manualmente copié y reemplacé por al versión más nueva y entonces si que valida la licencia. Ambos DLLs  son distintos en tamaño, no son el mismo y sin embargo ambos funcionan. Así que da la impresión que sea lo de la integridad CRC SHA pero el SH1 de ambos son distinto 

[Serapis]

Las situaciones explicadas son los casos hipotéticos más comunes que uno se va a encontrar. El caso concreto exacto que a tí se te presente, pués será eso, el caso concreto que tienes entre manos.
Comprenderás que sin más datos que una pintoresca explicación no pueda hacerse otra cosa que dilucidar las posibles causas más frecuentes. Que por supuesto no tiene por qué coincidir con tu caso o el de otra persona.

Diferentes versiones de dlls, tipo API, funcionarán correctamente siempre que la firma de las funciones (que se invoquen) coincidan (con compatibles). Todavía un programa puede molestarse en asegurarse por tener una versión específica, o solo limitarlo a que sea mayor o menor de x versión... son casos menos frecuentes, que suelen remitirse a dlls que son nativas del propio programa (posteriores versiones tienen cambios incompatibles mientras mantienen el mismo nombre para la dll) o bien porque parten de una versión nueva de un programa antiguo que funciona con una configuración antigua (que solo funcione con versiones específicas de dichas dlls).

Incluso habrá revisiones que un porgrama puede hacer sin llegar a verificar un hash completamente (que será más o menos costos en tiempo), y solo se moleste en verificar (por ejemplo) la fecha, versión, tamaño, o ciertos bytes dentro de la librería ...y además puede mantener esa verificación para varias versiones de dlls que acepte (no solo para 1 fichero).

En fin es cuestión de lo que el programador haya ingeniado... descubrir el modo exacto con que proceda un programa solo puede descubrise metiéndose con el programa y las dll en cuestión, no por un par de párrafos escritos. Pero las ideas vertidas, te dan para no quedarte estancado si no se te ocurren opciones (que supongo es la razón por la que abriste el hilo), revisar e ir descartando opciones hasta dar con el problema exacto...

[apuromafo CLS]

ideas:
+error de crc
+la sección del recurso solapó a otra sección
+la sección de recurso solapó a la iat (daría error hasta que no se ejecuta)
+parchas lugares que son solapados con relocation (en x64dbg salen los parches de color azul por ejemplo en este tipo de casos)
+ error de rebasing o guardas en un momento donde hay información inicializada (que debería estar en 0 en condición inicial).

sugerencias de edición de dll, ? es mejor parchar como inline/runtime, y vayas testeando que tal... (sugerencias detour..inline u otro)
Saludos cordiales.
Apuromafo