Mensajes

Sí que se puede hacer... de hecho yo he hecho algunos cracks modificando el código y llevándolo hacia donde yo he querido..

Tú puedes hacer los injertos, sabiendo donde los haces y por supuesto, restaurando todo tal cual (por ej. para los registros puedes guardarlos con un pushad y recuperarlos con un popad). El problema que yo siempre me encontrado en VB, es que como todo depende de MSVBVM60.dll pues no es tan sencillo programar en ensamblador, ya que a la hora por ejemplo de encontrar un handle de un determinado control no es tan sencillo, no sé si me entiendes.. pero por poderse hacer, puedes hacer lo que quieras.

Por ejemplo si tú quieres enviar un mensaje a un textbox en un programa ya compilado, sabes que puedes utilizar el API SendMessage... pero... y aquí viene también la dificultad o lo haces como lo hace un programa en VB o lo intentas hacer llamando a la función SendMessage directamente como lo harías en ensamblador, pero de esta segunda forma ya tienes que tener la dirección de sendmessage que puedes conseguir con GetProcAddress ect...

Hay otras opciones y es que si copias la dll MSVBVM60 y la modificas y la pones en el directorio del programa, el programa abrirá primeramente la de tu directorio (esto lo explicó Ricardo en tu tute muy bueno), no la system32.
Puedes si quieres modificar la librería y luego unir todo en uno con el Molebox.

Mira esto es complejo y más modificar programas en VB. Dí qué quieres hacer exactamente y le echamos un vistazo.

Ya me huelo algún troyano.... jeje

PD. Modificar el código de un programa en VB ya compilado es algo que me apasiona... si es alguna cosa secreta que estás haciendo (jeje) mándame un privado.

Acabo de probar varios OCX y no los carga antes del evento Initialize, lo acabo de comprobar con el debugger.. es decir, que lo que he puesto en Initialize se ejecuta antes de que cargue los ocx.

No he probado todavía con el control winsock, pero he hecho la prueba con varios ocx comerciales y siempre he visto que los carga (sólo los ocx) después del evento Initialize.

Pero si va a utilizar el solamente el control winsock, pienso que lo mejor que puede hacer es lo que dices tú: usar los módulos csocketmaster...

Yo he hecho ese ejemplo porque nhaalclkiemr dijo al principio:
"Lo k me gustaría es k en caso de error se saliera y punto sin mostrar nada"

Efectivamente, como dices wACtOr, también se puede emular ese ocx. Además hay muchos código fuente de ocx que puedes incorporar. Estoy de acuerdo en que si se puede emular el ocx mejor que mejor, pero vamos, yo le entendí que si no existe el ocx que el programa finalizara.

un saludo

He encontrado esta forma para los OCX.
Yo lo he hecho como ejemplo simple para saber si el OCX está en el directorio del programa. Tú ya lo haces a tu manera..

Código [Seleccionar] Expandir

Private Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)
Private Declare Function GetExitCodeProcess Lib "kernel32" (ByVal hProcess As Long, lpExitCode As Long) As Long
Private Declare Function GetCurrentProcess Lib "kernel32" () As Long

Private Sub Form_Initialize()
Dim archivo As String
archivo = "C:\VBbotones.ocx"
If Dir(archivo) = "" Then
    MsgBox "El ocx no existe y ahora va a finalizar el programa"
    ExitProcess GetExitCodeProcess(GetCurrentProcess, 0)
End If
End Sub

Espero te sirva

Lo he estado mirando y me parece interesante por este motivo:
los bytes que añades están "medio escondidos", me explico:

Si realmente se quisiera hacer bien la aplicación, para poder utilizar esos bytes tendrías que modificar el PEheader, pero en tu caso solamente los añades al final y como la última sección en el PEheader ya tiene un size, pues realmente esos bytes aparecen "medio escondidos"...

me ha parecido interesante,  me lo guardo y gracias por el source.

Estoy echando un vistazo...

Acabo de comprobar que carga los OCX (o por lo menos en mi caso) después de llegar al OEP.
El mensaje que sale es un MessageBeep..
Voy a mirarlo bien y a ver si se pudiera hacer desde VB, para no modificarlo con ensamblador..

Un saludo

El problema es que las librerías las carga el programa antes de llegar al OEP, para entenderlo: antes de ejecutar tu código fuente.
Esa información, no me quiero meter mucho en el tema, está guardada en el PE header y el programa carga las librerías que necesite y además tiene puestas ahí las que necesita..
Por ej. en el caso de VB necesita la MSVBVM60.dll y la carga lógicamente antes de llegar al OEP.

Me parece un tema interesante...

Una cosa que se me ocurre que puedes hacer y te funcionará es modificar la IMAGE IMPORT DESCRIPTOR (para que entiendas esta zona a grandes rasgos: dice qué librerías se van a cargar al comienzo del programa), y dejar lo indispensable para que funcione y después a partir del OEP, pues cargar las otras librerías con LoadLibrary y ya sabes si están o no.
Con esto tienes un problema si quieres hacerlo en VB: que VB para funcionar necesita obligatoriamente su librería: MSVBM60.dll y por este motivo no te dejará hacer nada sin ella. Modificando un programa en VB con ensamblador yo creo (sería cuestión de intentarlo) que sí sabría hacer lo que dices. De todos modos me surge la duda de si por ejemplo quito la librería de VB, si luego al hacer LoadLibrary se cargarán correctamente todas sus funciones con las direcciones correctas... no sé tal vez tenga su complicación.
Si sabes ensamblador te puedo orientar...

PD. Esto q acabo de explicar es mi idea, tal vez he pasado por alto algo elemental... quién sabe...

Un saludo

[Descarga SEH por karmany]

He hecho un tute sobre excepciones recopilando toda la información que pude.
Pienso que ha quedado muy interesante y completo.
Quería compartirlo con ustedes:

Descarga SEH por karmany

Espero que os guste. Pienso que es un tute para gente con conocimientos avanzados.
Un saludo.

PD. No ejecutar el SEH.exe ya que está hecho así a propósito y ejecuta un bucle infinito. Para más info, leer el tutorial que está explicado todo al detalle.

Muchisimas gracias a el-brujo por subirlo a este host.

Le he echado un vistazo y efectivamente sale un error al final del video.
Prueba a sustituir los archivos del directorio que son la mayoría dll a ver qué ocurre.

Yo estoy investigando el .exe original comparando con el que me has pasado...

Bueno, yo sí que le he echado un vistazo.

-Supongo que el error que tendrás será como el mío: lo ejecutas y te sale una nag con una dirección a Securom...

Antes de responder me he intentado informar todo lo posible sobre la protección Securom, ver solución de tutes y echar un vistazo al programa Horsed y la verdad que es curioso:
-Da error con Daemon Tools en su última versión que además tiene para emular Securom.
-He visto que el programa va descifrando(bien) ciertas partes de código que después utiliza y el error sale en una ventana (API DialogBoxIndirectParamA) y sin llegar al OEP (o eso es lo que he visto yo).
Detecta los breakpoints y he intentado hacerlo correr bien desde el debugger y de momento tampoco he encontrado forma.

-El principal problema que le veo es no tener el CD original, ya que es muy probable que el programa utilice datos del CD original para descifrar alguna parte. Por ejemplo, pensando que la zona del OEP podría estar sobre 401000, si vas a esa zona está totalmente cifrada y además cuando sale la nag de aviso esa parte no se descifra aún. Tal vez el problema pueda venir por ahí - pero no lo sé.
-Si se pudiera llegar al OEP sólo sería cuestión de arreglar la IAT y ciertos saltos a funciones que suelen quedar mal. Pero esto sería cuestión de tiempo.
Sin embargo, al no tener el CD original, pues es muy difícil saber qué datos son los que hacen falta. Porque con el CD original se llega al OEP se dumpea se arregla todo y ya está el crack.

Voy a seguir un poco investigando ya que no me para en determinadas API's que debería parar...

PD. De todos modos si tienes el crack en inglés que dices, sustituye el .exe por el crack porque el juego se suele guardar en los otros archivos, y te saldrá en castellano.