Mensajes

Una breve acotacion: el parent no es 100% confiable ya que los PIDs se reciclan.

ahora yo tengo una duda con respecto a esto de los procesos:

con el codigo anterior, si quisiera saber el numero de identificacion que se le asigna a cada proceso, como lo sabria?

En la estructura PROCESSENTRY32 hay un campo llamado th32ProcessID.

http://www.kriptopolis.org/jaqueando-vista

Lo lei hace dias y no me acordaba de donde 

Tiene un año eh 

Como decia, una empresa no pude darse el lujo de desactivar o eludir el PatchGuard (que por supuesto es posible), la estabilidad en sus productos es una de las cosas mas importantes. Para hacer malware no hay problema ...

hombre pesima jeje, yo diria sencilla y efectiva.

Si hablamos de un software comercial que va a salir a la calle es una solucion pesima y tarde o temprano se paga.

hombre yo lo mas parecido que he leido de hacer "sin hooks" es esto (lo entrecomillo por la forma de hacerlo que viene siendo lo mismo) decia algo asi como establecer un marco SEH y cambiar un byte de la direccion a hookear al ejecutar ese codigo genera una excepcion y va a  rutina donde ejecutas lo que tengas que hacer. mas o menos era asi ahora no voy a poner aqui todo el texto, es mas en gamedeception en el foro esta, pero esto yo lo veo hacer lo mismo pero mas raro.

Como bien decis es otro tipo de hooking, tambien se puede aprovechar el "HotPatching" (mov edi, edi) que es mucho mas limpio y esta pensado (casi) para eso.

tu dices que hay alternativas documentdas,podrias dar mas informacion? no hace falta pegar un tocho con explicar la base despues ya se busca  documentacion.

A lo sumo pegaria un enlace  Las alternativas dependen del campo, por ejemplo hookear (con cualquier metodo, SSDT, detours, etc) NtCreateFile es una estupidez cuando podemos crear un driver de tipo filtro para el filesystem. Con uno de estos podemos registrar un callback para la creacion de una sección (si, podemos bloquear jecutables asi - procesos, dlls, drivers).

Para trafico de red podemos hacer un Intermediate Driver de NDIS, para el registro hay callbacks en cantidad, para procesos, hilos y modulos tambien hay callbacks.
Y para NT 6.1 (antes tambien queria decir 6.1 y no 6.2, ups) hasta va a haber un callback para *OpenProcess 

Filter drivers vs hooking y mas generico en realidad.

Windows Vista Security: An Introduction to Kernel Patch Protection Introduccion al problema y algunas alternativas existentes.

respecto a esto, no ngo ni idea pq noe leido nada, pero porcasualidad si di con un tema que explicaban algo de eso y creo q dijeron que si se podia, de otra forma pero llegaban a lo que se queria.

repito no recuerdo dnd lo vi y no se que tendra de cierto.

Poder se puede pero Windows tira abajo el sistema (PatchGuard). Es cierto que se puede burlar (aunque cada vez que lo hagas y Microsoft se entere cerrara esa forma) pero un software comercial no se puede dar ese lujo. Microsoft ahora esta agregando muchos callbacks aunque un poco tarde (para NT 6.2) y algunos ya existen (registro, procesos, modulos, hilos, etc).

De cualquier manera casi todo se puede hacer sin hooks y es una practica de programacion pesima cuando existen alternativas documentadas ...

Con driver de verdad te refieres a un driver firmado????

No, me referia al concepto primigenio de device driver (controlador de dispositivo) y a que en estos tiempos un driver WDM por ejemplo tiene que especificar una rutina de descarga (DriverUnload en PDRIVER_OBJECT).

Ok, asi que no hay posibilidad de que el driver se "termine" el mismo, no??

Bueno, no hace falta 

Gracias Eternal 

Un driver de verdad lo mas probable es que si pero un modulo de modo Kernel de este tipo es dificil que tenga rutina de descarga. Igual como te dijeron antes con cortar todos los puntos donde intercepta la funcionalidad que queres ... da lo mismo que siga cargado. Otra cosa, en 64 bits hay que olvidarse de los hooks (al menos el software comercial).

Documentacion WDK (Windows Driver Kit).

Por lo general las estructuras se suelen declarar asi en el DDK:

Código [Seleccionar] Expandir


typedef struct _NOMBRE
{
  //campos
} NOMBRE, *PNOMBRE;


Por cierto eternal, el IoDeleteDriver, que le tengo que pasar para terminar el proceso de mi driver??? el PEPROCESS??

Eso lo unico que hace es dereferenciar un PDRIVER_OBJECT y no esta documentado,  no te lo recomiendo para nada. Un driver no tiene un proceso, se ejecuta en un hilo bajo el contexto de un proceso no determinado.

En google no me sale eso  ademas, en otros codigos vi que utilizaban el IoDeleteSymbolicLink, pero tampoco se que pasarle....

A IoDeleteSymbolicLink se le pasa un PUNICODE_STRING, basicamente una cadena que hace de enlace con un driver para comunicarse desde modo Usuario.

[3Ch]

Por cierto IoGetCurrentProcess no devuelve un PID sino un PEPROCESS que siempre va a ser el de SYSTEM (DriverEntry se ejecuta siempre bajo el contexto de un hilo del sistema). PID = PsGetCurrentProcessId.

Una tecnica que se usa normalmente es apoyarse en NTDLL.dll - especialmente para las funciones que no estan exportadas - donde hay stubs que pasan a modo Kernel con el numero del servicio correspondiente, ej.:

ntdll!ZwCreateFile:
77f3f414 b83c000000      mov     eax,3Ch << numero del servicio
77f3f419 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)
77f3f41e ff12            call    dword ptr [edx]
77f3f420 c22c00          ret     2Ch

Otra cosa, las funciones esas son las Nt* no Zw*. En modo Usuario no hay diferencia (una es alias de la otra) pero en modo Kernel no es lo mismo.

http://www.osronline.com/article.cfm?article=257
http://www.osronline.com/login.cfm?prompt=ntInsider&id=266