|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - Eternal Idol
Páginas: 1 ... 64 65 [66] 67 68 ... 205
1626
« en: Viernes 14 de Diciembre de 2007, 16:14 »
De nada, me alegro de haber podido ayudar una vez mas en el foro.
1627
« en: Viernes 14 de Diciembre de 2007, 13:51 »
El autorun es un archivo de Windows. Me parece que necesitas El Torito.
1628
« en: Viernes 14 de Diciembre de 2007, 09:32 »
Esto ya se pregunto muchas veces, usa el buscador.
Windows: VC++. GNU/Linux: gcc.
1629
« en: Jueves 13 de Diciembre de 2007, 18:12 »
Jajaja, ya se, solamente decía que al tener 16 años, se tiene que poner a estudiar mas lenguajes porque es muy poco, y la verdad es que no va mal, pero necesita mas a esa edad, y la comprensión, la tengo, solamente que no se vio en ese post Con 3 lenguajes (assembly, C y C++) tenes para hacer practicamente cualquier cosa. Mejor entonces si la tenes Una pregunta: Ustedes cuantos años me dan? me creen que tengo 13 años? porque hay mucha gente que me dice que cree que soy mas grande, y me dicen que es por mi forma de escribir/hablar y por mis conocimientos... Así que posteen, me creen? xD ¿Con dos mensajes escritos aca? No tengo la menor idea.
1630
« en: Miércoles 12 de Diciembre de 2007, 23:36 »
De nadas, ahora revisa todo tu codigo teniendo en cuenta el ambito de las variables
1631
« en: Miércoles 12 de Diciembre de 2007, 22:25 »
1632
« en: Miércoles 12 de Diciembre de 2007, 22:22 »
Tiene todo el sentido del mundo, lo que se llama es el destructor de los objetos locales que estan en la pila, en cuanto se acaba el constructor su ambito desaparece y por tanto se llama al destructor correspondiente (SocketServer/SocketClient). Lo que tenes que cambiar es el constructor mismo (L2cap::L2cap) como te dije antes.
La ultima parte de mi mensaje anterior explicaba la diferencia en los errores con y sin esa linea bizarra.
1633
« en: Miércoles 12 de Diciembre de 2007, 18:52 »
Tenes que arreglar ese constructor ... usa new para los objetos y no te olvides del delete correspondiente.
La diferencia es que se llama al operator = de la clase Socket y eso entre otras cosas aumenta la variable de las referencias (cuando no lo haces al ejecutarse el destructor y quedar sin referencias tambien se ejecuta End que llama a WSACleanup).
1634
« en: Miércoles 12 de Diciembre de 2007, 00:11 »
No quiero ser pesado, ya me entere de que hay que usar la api nativa. Me olvidare de la api de nivel usuario y ya esta. Ya te comente lo que era la API nativa, si la usas es en un programa NORMAL desde modo Usuario. Esa manera de pasar a modo Kernel no es mas que un hack horroroso que no deberias usar jamas para nada que no sea probar que funciona. Ya se que el WinDbg debuggea en modo kernel, pero me referia a que tiene una interfaz muy fea. Sabes si existe alguna interfaz decente ? porque me bajé una de crackslatinos y ayuda pero no mucho. No conozco, siempre uso esa y es asi de chota como la ves pero es funcional y permite depurar tanto en modo Usuario como en modo Kernel. Aparte de esto, algun consejo ? Si queres trabajar en modo Kernel mejor empeza por conseguir el WDK y un par de libros sobre Windows y WDM. Aprende a escribir tu primer modulo de modo Kernel en assembly y despues usa C/C++.
1635
« en: Martes 11 de Diciembre de 2007, 23:56 »
Tanto sentido como _escuchando = true; en la primera linea del constructor de L2cap pero es TU codigo. Todo ese constructor es erroneo ... No se donde habras sacada esto: *(s) = sb; //Con esto hemos anclado el contenido del puntero y ya no se borra al salir del Constructor
En cuanto termina ese constructor se llama al destructor de in o sb segun corresponda ...
1636
« en: Martes 11 de Diciembre de 2007, 23:25 »
El WinDbg permite depurar en modo Usuario y modo Kernel, el OllyDbg no asi que no hay punto de comparacion.
¿Y cual es la razon para hacer en modo Kernel lo que en modo Usuario? No tiene sentido ...
La API nativa de XP es la NTDLL.dll - una libreria dinamica comun y corriente de modo Usuario - que en su mayoria de funciones solo transforma unos parametros y pasa a modo Kernel.
La DLL - Kernel32 - ya esta cargada en tu proceso y GetStdHandle es ejecutada correctamente, si llamaras antes desde modo Usuario a esa funcion - WriteConsoleA - como te dije no daria una excepcion al no tener que resolver el page-fault el Kernel - cuando lo hace vuelve a modo Usuario -.
En modo Kernel hay que usar las funciones ofrecidas por el Kernel y no por la API de Windows de modo Usuario.
1637
« en: Martes 11 de Diciembre de 2007, 22:42 »
Me traiciono la memoria evidentemente, hubiera jurado que PhysicaMemory estaba vedado en XP pero veo que es de 2003 Server en adelante. Al codigo le faltaba la parte en la cual llamaba a la funcion aunque la encontre rapidamente en Internet. ¿Cual es la razon por la cual pensas que tiene algun sentido llamar a una funcion de modo Usuario desde modo Kernel? La amplia mayoria de ellas intentan pasar a modo Kernel justamente. GetStdHandle es una excepcion ya que usa el PEB (RTL_USER_PROCESS_PARAMETERS) para devolver esos valores. En fin, si se comporta tal como en mi maquina virtual la excepcion se produce por una razon muy simple, esa funcion no esta en memoria y el Kernel se encarga de manejar el page-fault (si lo depuraras verias como justo despues de la ejecucion de MmAccessFault si esta disponible el codigo de la funcion en memoria)  Si llamaras a WriteConsoleA antes no daria una excepcion aunque seguiria siendo inutil por supuesto. En modo Kernel hay que usar las funciones ofrecidas por el Kernel y no por la API de Windows de modo Usuario.
1638
« en: Martes 11 de Diciembre de 2007, 09:23 »
Siempre hace las comprobaciones en el ambito de cada proceso (cliente y servidor) no sirve de nada comparar entre ambos ya que al ser otro proceso su tabla de handles es completamente independiente.
En el cliente si socket() y send() usan un diferente s_ es logico que falle, comproba todos los puntos donde se podria cambiar este valor. Lo mejor es que lo depures, desde el momento en que s_ es asignado por socket() - donde tiene que ser valido - hasta el momento en que cambia. En el servidor se usa un socket para escuchar y despues hay otro para conexion aceptada y con ese se comunica.
1639
« en: Martes 11 de Diciembre de 2007, 08:11 »
Lo que querias hacer ya se habia entendido, sino queres mostrar lo que estas haciendo exactamente no hay problema pero no esperes que te ayude.
1640
« en: Martes 11 de Diciembre de 2007, 00:47 »
Bien, no se cierra. Se crea con la funcion socket(), buscala y comproba que su valor de retorno (se supone que se crea uno solo) sea exactamente el mismo que pasas a send() siempre (s_).
1641
« en: Martes 11 de Diciembre de 2007, 00:30 »
Si estas probando algo con el servidor por ahora olvidalo por completo, ejecutalo y no lo pruebes/depures, no tiene sentido. No se si encontraste algo ya que no se realmente que fue lo que hiciste. ¿Ya comprobaste los puntos donde se cierra el socket? No quiero repetir lo mismo 500 veces.
1642
« en: Lunes 10 de Diciembre de 2007, 23:52 »
Es probable, a mi me funciona, pero no se si comprobaste los puntos donde esos sockets se cierran. Si te dice que el socket no es valido es por una razon ... o es un numero totalmente al azar o ese socket fue cerrado con anterioridad.
1643
« en: Lunes 10 de Diciembre de 2007, 22:59 »
OK, NT 5.1 entonces.
¿Que fallo es poner un breakpoint? Depura en modo Kernel con el WinDbg entonces (necesitas otra maquina) o usa el SoftIce (obsoleto ya).
La logica es que no funcione nada de lo que estas haciendo, tendria que ver tu codigo y depurarlo como para decirte en que punto esta el problema exactamente.
1644
« en: Lunes 10 de Diciembre de 2007, 22:45 »
No se realmente donde encontraste el error. Yo lo depuro y esta correcto:
En main tenes un objeto llamado micapa de la clase L2cap cuya direccion en memoria es en mi caso 0x0012feec. Sigo la pila y llegamos a Openchannel_req donde se crea un objeto de tipo L2capChannel. En el constructor del mismo se recibe como tercer parametro un void * a cuyo valor en este caso tambien es 0x0012feec. Ese constructor llama a Wrapper_a_escribeEnSocket con un parametro void *pt2Object con el mismo valor de siempre, ahi mismo tenes un puntero a un objeto de la clase L2cap mediante un casting a la direccion de siempre. Con lo cual mySelf es lo mismo que &micapa del main. Eso llama a escribeEnSocket donde this ya es igual a &micapa/mySelf y SendBytes lo mismo. Por eso mismo me funciona perfectamente.
mySelf es un puntero a micapa y no necesitas cambiar ni asignar ningun valor en el, el socket es el mismo.
Depura (o usa alguna cadena para mostrar en pantalla) los puntos donde se crean, se cierran y se usan los sockets. Es la unica forma de comprender el problema realmente.
1645
« en: Lunes 10 de Diciembre de 2007, 22:21 »
¿Estas trabajando bajo 9x o NT? Desde el vamos en modo Kernel no existen esas funciones ... igual no se exactamente que estas haciendo.
De cualquier manera usa el WinDbg para depurarlo y analiza el dump generado si da un BSOD.
1646
« en: Lunes 10 de Diciembre de 2007, 21:13 »
Evitando que pueda interceptar, segun recuerdo esto usaba la SSDT y es muy facil de restaurar con el WinDbg, solo tenes que encontrar las direcciones (empezando por KeServiceDescriptorTable por supuesto). No voy a entrar a discutir como saltar X o Y proteccion, no me interesa en lo mas minimo.
1647
« en: Lunes 10 de Diciembre de 2007, 18:07 »
¿Cual es la razon por la cual DEBES mejorar ese codigo arcaico y obsoleto? Supongo que alguien te habra dicho exactamente que debes hacer ...
1648
« en: Lunes 10 de Diciembre de 2007, 14:44 »
Otra manera seria restringir el protocolo tal que el programa se pueda abrir pero sea inutil: http://en.wikipedia.org/wiki/Msn_messenger#ProtocolPD. Casi siempre hay alguna manera de saltar cualquier proteccion
1649
« en: Lunes 10 de Diciembre de 2007, 08:13 »
Deshabilitar la tecla de inicio, ctrl+alt+supr, ocultar el proceso ... llamalo como quieras.
1650
« en: Lunes 10 de Diciembre de 2007, 08:11 »
Páginas: 1 ... 64 65 [66] 67 68 ... 205
|
|
|