|
|
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 ... 76 77 [78] 79 80 ... 205
1926
« en: Domingo 9 de Septiembre de 2007, 23:48 »
no probé eso, sólo estube usando las técnicas comunes, por ejemplo fijate en la base esa que puse en un post mio en la sección vc++, eso es lo usado.. pero me podrías explicar mejor esto.. Esa es una tecnica muy comun y muy simple aunque probablemente no tan simple como es normalmente por el hook sobre NtWriteVirtualMemory. El chiste es crear el proceso (CreateProcess con el flag CREATE_SUSPENDED) con esto logramos que no arranque el proceso hasta que hagamos ResumeThread sobre el hilo principal. Antes de ese momento ya existe el proceso, esta mappeado en memoria y podemos hacer bastantes cosas. Una forma que en teoria podria funcionar es: A. Ejecutamos de forma suspendida B. Mappeamos una seccion de memoria compartida C. Escribimos codigo que cargue una DLL en esa seccion D. Encolamos un APC en el hilo principal E. Resumimos el hilo principal Esto hara que se ejecute el APC y cargue una DLL, objetivo cumplido. En cuanto a la base ya la miraras (vos) cuando logres inyectar una DLL con un misero MessageBox en el proceso, sino sos capaz de hacerlo no vale la pena desarrollar la DLL.aparte volviendo al tema del driver entonces estamos descartando esa posibilidad.. ¿? Hasta ahora no hay ninguna solucion propuesta para implementar desde modo Kernel (driver). Y yo descartaria hacer un driver sin tener ninguna experiencia al respecto y sin haber agotado todas las posibilidades desde modo Usuario.
1927
« en: Domingo 9 de Septiembre de 2007, 21:03 »
Entonces busca informacion sobre sockets.
1928
« en: Domingo 9 de Septiembre de 2007, 19:35 »
¿Como pensas analizar paquetes que llegan a otras placas de red y no pasan por la tuya?
1929
« en: Domingo 9 de Septiembre de 2007, 09:29 »
Cuando los mensajes se convierten en un rifi-rafe y cruce de mensajes entre 2 o 3 usuarios, creo que es llegado la hora de dejar de escribir en el foro dichos mensajes y hacerlos por privado... ha quedado clara la postura de ambos, no es necesario esplayarse más, la gente no es tonta y sabe sacar sus conslusiones entre lo que se dice y lo que se quiere decir....
Mi opinión es casi idéntica a la primera que se vierte tras el que abre el hilo... Por supuesto nada mejor que escribir este tipo de mensajes meses despues del fin de esta conversacion ...
1930
« en: Domingo 9 de Septiembre de 2007, 09:27 »
5) tu driver restaura la dirección original del api que guardo primero
Eso es lo que segun vos produce el BSOD cuando usas ese programa, esa solucion no sirve o ya estaba propuesta.
De cualquier manera:
¿Probaste a crear el proceso suspendido, modificar lo que quieras y despues resumir el hilo principal? Se me ocurren formas de conseguir inyectar codigo en el proceso ya en ejecucion pero es totalmente al pedo si podes hacer lo que acabo de decir.
Y todavia quedo en el tintero:
Decis que si deshookeas da BSOD, postea el minidump o analizalo, puede ser que ese programa se mande una cagada o que el anticheat lo detecte.
1931
« en: Sábado 8 de Septiembre de 2007, 23:08 »
A ver en este caso hookear es cambiar el valor de una entrada en una estructura. Si hookeas primero despues viene el otro driver, reemplaza tu valor y sigue interceptando. Como ellos son llamados primero pueden filtrar y devolver error antes de que llegue a tu codigo ...
Decis que si deshookeas da BSOD, postea el minidump o analizalo, puede ser que ese programa se mande una cagada o que el anticheat lo detecte.
Otra cosa ... ¿Probaste a crear el proceso suspendido, modificar lo que quieras y despues resumir el hilo principal? Se me ocurren formas de conseguir inyectar codigo en el proceso ya en ejecucion pero es totalmente al pedo si podes hacer lo que acabo de decir.
1932
« en: Sábado 8 de Septiembre de 2007, 19:35 »
Si hookeas vos primero entonces ellos van a seguir siendo llamados y vas a tener el mismo problema ... hay herramientas que permiten "deshookear" (en este caso no es mas que restaurar el valor original en la entrada correspondiente de la SDT). Tambien podrias escribir ese codigo ...
Pero no me mostraste todos los servicios hookeados, por ahora con los que vi todavia se puede inyectar codigo ...
1933
« en: Sábado 8 de Septiembre de 2007, 09:50 »
Existen ciertas librerias estandar, es decir que las verciones de c++ las contienen, por ejemplo la conio.h, stdio.h, etc.... y si buscan una en específico ps sólo basta con checar la sección help e ir a topic search y estan funciones y de mas cosas en orden alfabético..... bueno, almenos esto me funciona a mi, que tengo la verción 3.0 de c++ =D... conio.h NO es standard y no hay una version 3.0 de C++, esa es la version (arcaica y obsoleta) del compilador Turbo C++.
1934
« en: Sábado 8 de Septiembre de 2007, 09:44 »
Bueno, eso es ilegal para empezar.
Primero y principal antes de intentar hacer un driver averigua exactamente que metodo de interceptacion usan (detouring, sdt, etc) y que funciones interceptan. Una vez sepas esos datos podras buscar mas informacion, usar herramientas existentes o desarrollar algo.
1935
« en: Sábado 8 de Septiembre de 2007, 08:16 »
De nadas 
1936
« en: Sábado 8 de Septiembre de 2007, 01:24 »
1937
« en: Sábado 8 de Septiembre de 2007, 00:31 »
No encuentra esa funcion (HookClient que llamas desde newGetProcAddress), tal vez te falta compilar y enlazar el codigo objeto de algun fuente ...
1938
« en: Sábado 8 de Septiembre de 2007, 00:27 »
Se puede hacer en cualquiera de los dos lenguajes, busca informacion sobre Rootkits. Te aclaro que esto no tiene ningun futuro desde hace rato, el PatchGuard tira el S.O. abajo en cuanto detecta alguna discrepancia ... mejor investiga sobre las funciones de callback que podes registrar y usando un poco la creatividad podes reemplazar casi todos los hooks que ademas son poco seguros.
A menos que tengas vasta experiencia en modo Kernel te recomiendo que primero investigues mucho al respecto.
1939
« en: Viernes 7 de Septiembre de 2007, 15:40 »
Muy güeno ese RadicalEd 
1940
« en: Jueves 6 de Septiembre de 2007, 19:45 »
Podes crear un proyecto o usar el compilador directamente desde la linea de comandos, el binario del mismo es el cl.exe y usando como modificador /? te muestra la ayuda.
1941
« en: Jueves 6 de Septiembre de 2007, 12:55 »
NO se hacen tareas.
1942
« en: Jueves 6 de Septiembre de 2007, 11:57 »
¿Que tipo de librerias? Podes buscar archivos .h y .lib por ejemplo ...
1943
« en: Lunes 3 de Septiembre de 2007, 23:09 »
De nadas Y la verdad es que no suelo recomendar re-instalar pero en el caso de no tener un Kernel de original 
1944
« en: Lunes 3 de Septiembre de 2007, 20:13 »
Bueno, en serio, efectivamente, tengo este ntkrnlpa.exe-->Doble click-->Verify: "(Unable to verify)"
No se puede verificar. Jeje, tener el PAE no es problema pero que no se pueda verificar significa que no es una version confiable, es un ejecutable modificado y no un original de Microsoft. Por eso no podemos conseguir los simbolos ni analizar correctamente el minidump.
1945
« en: Lunes 3 de Septiembre de 2007, 19:34 »
Aunque poco probable no es imposible, efectivamente  hace un tiempo instalé un paquete que cambia el aspecto de Windows XP "Vista Transformation Pack 6.0". Lo dudo, aunque lo estoy bajando en un zip para ver que trae. PD: En estas instancias, solamente por curiosidad...
ntoskrnl.exe no me figura en la lista del process explorer. ¿Hay que agregarlo de alguna manera? No tenes Kernel  Seguramente tengas el ntkrnlpa.exe que es el que se usa con el PAE activado.
1946
« en: Lunes 3 de Septiembre de 2007, 19:25 »
¿Otra vez con los trucos para juegos?
Sinceramente diste muchas vueltas y poca informacion tangible, sino queres subir el ejecutable copia lo que devuelve el WinDbg usando lm, !dh sobre los modulos en cuestion y u sobre el entry point.
¿Funciona en algun lado el programa? Repito: No es lo logico tener que modificar el PE a mano para solucionar este problema. Y si realmente el problema es que una seccion del PE esta en read-only lo que no funciona es el "hook" ese, pero NUNCA funciono, cosa que puede ser ya que entre la direccion con el nombre de la DLL y la otra hay muy poca distancia ...
1947
« en: Lunes 3 de Septiembre de 2007, 16:42 »
Como te decia no puedo bajar los simbolos de tu Kernel. Puede haber una serie de razones, que tengas un Kernel modificado (lo suelen hacer para cambiar la imagen de inicio de Windows por ejemplo, un Rootkit aunque es poco probable tambien), una version que sea un patch en particular para el cual no haya simbolos o que este fallando el servidor y que con symcheck si lo logres conseguirlo. Para probar eso solo tenes que abrir el cmd, ir al mismo directorio donde esta WinDbg.exe y poner lo que pusiste en el WinDbg:
symchk /r c:\windows\system32\ntoskrnl.exe
Si asi y todo no funciona proba a subir el Kernel ... fijate con el Process Explorer si te verifica el ejecutable. Vas al proceso System con la ventana de abajo como View Dlls, le das doble click a Ntosrknl.exe y despues a Verify.
1948
« en: Domingo 2 de Septiembre de 2007, 20:26 »
symchk es un ejecutable aparte, no un comando del WinDbg.
Primero te diria que probaras con el WinDbg asi:
.symfix c:\symbols
.reload
.reload /f ntoskrnl.exe
Si eso no funciona proba con el symchk.exe (esta en el mismo directorio que el WinDbg).
1949
« en: Domingo 2 de Septiembre de 2007, 09:02 »
No es lo logico tener que modificar el PE a mano para solucionar este problema ... ¿De donde salio ese codigo y que pretende hacer?
1950
« en: Domingo 2 de Septiembre de 2007, 02:21 »
Podes usar el Visual Studio pero lo ideal es usar el WinDbg (busca Debugging tools for Windows, son gratis). De cualquier manera estos archivos son utiles solo si podemos obtener los simbolos del Kernel y por lo que veo no es posible hacerlo desde el servidor de Microsoft mediante el minidump que adjuntaste ... tal vez si adjuntas tu Kernel (ntoskrnl.exe - imagino que no es modificado -) pueda conseguirlos.
Páginas: 1 ... 76 77 [78] 79 80 ... 205
|
|
|
Mostrar Mensajes
