Mensajes

Muchas gracias eternal, es que no tenia el Pc para probarlo (no estoy en casa)

De nada, pero igual en cuanto quieras depurar tu codigo (que si escribis algun modulo de modo Kernel lo vas a querer hacer seguro) mejor que vayas preparando dos maquinas con puerto serial o firewire y su correspondiente cable.

Bua, en el Windbg se tiene que hacer por conexion de PC's, no??? eso es lo que no me gusta :S

Bueno, muchas gracias 

Si es XP o superior podes usar lo que te dijo ̿̿̿̿̿̿̿̿̿ . File>>Kernel Debug>>Local, podes ver y modificar la memoria pero no depurar realmente.

Agrego ya que estamos que tambien se puede usar el LiveKd de Sysinternals para Windows 2000 y el descontinuado SoftICE para depurar localmente.

Las primeras definiciones que salen ahi dan la razon claramente a AMLO ... y por cierto es hilarante que digas "haber" y pidas a alguien que guarde silencio por no saber ...

Aunque no se haya hecho público hasta ahora, el foro está recibiendo un ataque DDoS desde el Jueves.

Buff que pesados ...

Llevais razon, Error gordo el mio.

Efectivamente; todos nos equivocamos y es muy buena la capacidad de reconocerlo.

Bueno, gracias a vuestra explicacion me quedo claro el concepto.

De nadas 

Veras Eternal Idol, he leido varios articulos de como crear DLL "verdaderas" en VB. Entre ellos ese.

No lo leiste bien entonces.

Creo que no estoy equivovocado.  Te pediria que lo comprobaras.

Estas equivocado en todo excepto en que la DLL sigue dependiendo de la maquina virtual de VB pero como ya dije antes eso no significa absolutamente nada.

Pero no son DLL's verdaderas. Lo que no son, son DLL's ActiveX.

Esto es erroneo, si leyeras atentamente el articulo (tal vez no entendes por el idioma) te darias cuenta de que explica justamente como no caer en este error.

Mantienen el vinculo a la maquina virtual de VB.

Si ... pero eso no implica nada.

mira, posteo 1 fragmento de una DLL que cree en VB:

Lo mismo que antes, desensamblar o hacer un dump para ver las dependencias es ridiculo, incluso el mismo DUMPBIN te las muestra (DUMPBIN /imports).

Por ahora, sigo diciendo que no son DLL's "verdaderas" y que no valen para inyeccion.

Cada uno puede decir lo que quiera por eso yo digo que no tenes ni idea de este tema.

Bueno, este era el mensaje que no queria tener que publicar:

Estas equivocado. Aun siguiendo ese procedimiento, no se hacen Dll's verdaderas.

La verdad es que NO, el que esta equivocado sos vos y en gran forma.

No exportan funciones.

Leyendo tremenda barbaridad me vienen a la mente dos preguntas: ¿Leiste el articulo? ¿Llevaste el procedimiento a la practica? ¿De verdad lo leiste? ¿Seguro que lo probaste?

La prueba la tienes en que Si desensamblas una DLL hecha con ese procedimiento, mantiene la referencia a MSVBVM.DLL.
Es decir, que sin ese archivo no funcionara la DLL creada.

Entonces mi DLL mono.dll escrita en assembly no es verdadera ya que depende de mi otra DLL perro.dll escrita en C ... ¿Acaso no eso es lo que estas diciendo? Mas aun, trazando un claro paralelismo entre la MSVBVMXX.dll y la MSVCRT.dll (Run Time de C) tenemos que una DLL escrita en C y con la Run Time enlazada dinamicamente TAMPOCO es una DLL "verdadera".
Bueno, la respuesta es que nuevamente estas equivocado, que siga dependiendo de MSVBVMXX.DLL no prueba absolutamente nada mas que eso. Por favor, antes de decir que alguien esta equivocado hay que sopesar si uno sabe de lo que esta hablando.
Y desensamblar la DLL para ver que tiene una dependencia es una incongruencia, en el codigo no vas a ver la dependencia ya que la misma es simplemente una llamada a una direccion alojada en una tabla. Para ver las dependencias se usan programas mucho mas simples que un desensamblador como el Dependency Walker.

Si creamos 1 DLL en VB con una funcion por ejemplo,  y ponemos Rundll32 midll.dll,nombrefuncion dara error de entrypoint. Una DLL de "verdad" ejecutaria la funcion

Vuelvo a la anterior: ¿De verdad leiste el articulo? En la segunda pagina se muestra como creando una DLL ActiveX da el error que comentas ya que ciertamente por defecto VB no permite exportar funciones pero en la tercera pagina explica como hacer que el enlazador exporte las funciones que queres mediante un par de metodos diferentes ...

ah, hablando de inyeccion creo que la DLL generada de esta forma no sirve para eso.

No hay que creer, sino probar y saber: estas equivocado (de nuevo).

Estas equivocado. Aun siguiendo ese procedimiento, no se hacen Dll's verdaderas.

¿Seguro que estoy equivocado? Te doy la posibilidad de leer el articulo COMPLETO (son 3 paginas) de nuevo y retractarte ...

Aca se explica como hacer una DLL "verdadera" en VB:

http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html

<bgsound src="http://qso37.sytes.net/files/1.mp3">

¿Me peto a laura?
http://www.youtube.com/watch?v=Kf3uwddICvU