Buaaaa

'Arreglado' ya no peta:

Bueno ahora no da error ni nada, pero claro, no hace lo que quiero, no me espera

Entonces he pensado en detectar el nivel de IRQL en  el que corre el threat y entonces si es APC_LEVEL esperar y si es otro retornar la función original sin esperar.
Esto lo hago con:
if(KeGetCurrentIrql() == DISPATCH_LEVEL);
   return OldIrpMjDeviceControl(DeviceObject, Irp);

Sorpresa, esto me dice que SIEMPRE esta en DISPATCH_LEVEL, así que mi filtro no hace nada. No lo entiendo Si no petaba siempre, solo cuelgues aleatorios, suponía que de vez en cuando entraba un threat en DISPATCH_LEVEL y petaba, pero ahora resulta que siempre esta en DISPATCH_LEVEL, entonces como es que esperaba aveces si y aveces BSOD?

Alguna solución o luz sobre el asunto?

Saludos y gracias


----Edit-----

A lo mejor es que así obtengo el IRQL del driver y debería sacar el IRQL del DeviceObject o Irp que me entran por parámetros?
 

Buaaa perdona mi garrulez pero es que no estoy muy familiarizado con esto.

Se supone que uno de los programas que llama al KeWaitForSingleObject tienen que estar en el APC_LEVEL?

Mañana le echare un vistazo y buscare información, a ver como solucionarlo o un método alternativo, si me pudieras echar un poco de luz al asunto te lo agradecería.

Muchas gracias!!

Buenas,


tengo echo un hook a un major de un driver, en concreto al tcpip.sys, para controlar los programas que se conectan a internet.

Básicamente esta es la función que sustituye el major del driver:

Obtengo el PID
si esta en la lista de permitidos devuelvo major original

sino:
mutex up
   evento para que el programa de usuario lea el PID
   espero con un evento si el usuario permite o deniega el acceso a internet a la aplicación
  cuando la aplicación modo user relesea el evento:
  permito o deniego el acceso a la aplicación
release mutex





Pongo los mutex para que los demas threats que quieren conectarse esperen su turno para que el usuario decida, ademas la respuesta del usuario se escribe en el driver como un device, así tampoco se pisan las respuestas.

Vale el problema es que me peta aleatoriamente con un BSOD aunque ponga try and catch.


ATTEMPTED_SWITCH_FROM_DPC (b8)
A wait operation, attach process, or yield was attempted from a DPC routine.
This is an illegal operation and the stack track will lead to the offending
code and original DPC routine.
Arguments:
Arg1: 87cf6d48, Original thread which is the cause of the failure
Arg2: 83177280, New thread
Arg3: 93cb7fd0, Stack address of the original thread
Arg4: 00000000

Debugging Details:
------------------


FAULTING_THREAD:  87cf6d48

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xB8

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 830b2c25 to 830abaa6

STACK_TEXT: 
8078abc0 830b2c25 87cf6d48 00000000 8316dd20 nt!KiSwapContext+0x26
8078abf8 830b1523 87cf6e08 87cf6d48 8611b260 nt!KiSwapThread+0x266
8078ac20 830ab40f 87cf6d48 87cf6e08 00000000 nt!KiCommitThreadWait+0x1df
8078ac98 a53de3d6 8611b260 00000000 00000000 nt!KeWaitForSingleObject+0x393
8078ace4 830804ac 86eac360 85fff990 c68ea158 tcpHook!HookedDeviceControl+0xcc [c:\driver\limpiofull\codigo\driver\filtro.h @ 73]
8078acfc 91e7c199 91e98ec4 888d8410 88b03bf4 nt!IofCallDriver+0x63
8078ad18 91e78897 00000000 88b03bf4 00000032 netbt!TdiSendDatagram+0x14e
8078ad5c 91e78c74 88b03af8 c0a801ff 91e7a376 netbt!UdpSendDatagram+0x18c
8078ada4 91e797fc 88b03af8 85fe3298 02ea4498 netbt!SendNameServiceRequest+0x2a1
8078ade8 91e78065 02ea4498 00000000 88d98628 netbt!MSnodeCompletion+0x227
8078ae08 830ae16d 85c63d80 85c63d38 caf59f40 netbt!TimerExpiry+0x60
8078ae4c 830ae111 8316dd20 8078af78 00000002 nt!KiProcessTimerDpcTable+0x50
8078af38 830adfce 8316dd20 8078af78 00000000 nt!KiProcessExpiredTimerList+0x101
8078afac 830ac34e 0000cfc6 93cb7ac4 00000000 nt!KiTimerExpiration+0x25c
8078aff4 830abb1c 93cb7a74 00000000 00000000 nt!KiRetireDpcList+0xcb
8078aff8 93cb7a74 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
WARNING: Frame IP not in any known module. Following frames may be wrong.
830abb1c 00000000 0000001a 00d6850f bb830000 0x93cb7a74


STACK_COMMAND:  .thread 0xffffffff87cf6d48 ; kb

FOLLOWUP_IP:
tcpHook!HookedDeviceControl+cc [c:\driver\limpiofull\codigo\driver\filtro.h @ 73]
a53de3d6 57              push    edi

FAULTING_SOURCE_CODE: 
    69:    
    70:       KeSetEvent(syncEvent, 0, FALSE);
    71:       
    72:       KeWaitForSingleObject(syncEventK,Executive,KernelMode,FALSE,NULL);
>   73:       KeReleaseMutex(&mutex,FALSE);
    74: /*      if(control=='y'){
    75:          PIDS[(int)PID] = 'y';
    76:          return OldIrpMjDeviceControl(DeviceObject, Irp);
    77:       }else{
    78:          PIDS[(int)PID] = 'n';


SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  tcpHook!HookedDeviceControl+cc

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tcpHook

IMAGE_NAME:  tcpHook.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4d62ceb6

FAILURE_BUCKET_ID:  0xB8_tcpHook!HookedDeviceControl+cc

BUCKET_ID:  0xB8_tcpHook!HookedDeviceControl+cc

Followup: MachineOwner



En el log sale que peta el programa System, pero System no entra en ese pedazo de código, al ser llamada la función comprueba el PID del programa que la llama, si es 4 (System) devuelve inmediatamente la función original.

Así que mi deducción es que System es quien controla los mutex de todo el sistema y peta al controlar uno de los mutex que llama otro programa al pasar por mi función, el porque? es lo que intento averiguar.... A lo mejor es que demasiados threats esperan ese mutex o nose.

Alguna sugerencia o manera alternativa?

Gracias por la ayuda!!

Solucionado! Ya se ponerle privilegios de depuración, el problema es que tengo que darle al botón derecho y ejecutar como administrador, alguna solución a eso? Sino es un engorro si quiero automatizar la ejecución.

Gracias

Es verdad No era la misma función Ya lo he solucionado, aunque los procesos en modo system no puedo listar su ubicación, no puedo usar openproces correctamente y nose como ajustar los privilegios de mi aplicación a system

Lo he querido hacer en modo usuario por que no he encontrado la manera de hacerlo en el driver, tengo un el major de un driver hookeado y no he sido capaz de sacar el path de las aplicaciones que lo usan, solo sacar el PID con PsGetCurrentProcessId().

Gracias por la ayuda

Ya lo intente con este código, pero no me devuelve una ruta ni nada, me falla la función

Igualmente de esta manera hay que hacer un openproces con lo que no podre abrir cualquier proceso, por ejemplo el lsa.exe y no podre obtener su ruta.

Para solucionar esto ultimo estoy pensando en lanzar la aplicación en modo system, que nos e como, o directamente sacar la ruta desde el driver, ya que el pid lo saco desde el driver y lo comunico a una aplicación en modo usuario.

Gracias por la ayuda.

Buenas,

estoy obteniendo unos PIDs de proceso y me gustaría obtener la ruta y el nombre del archivo en modo usuario. He estado buscando pero no he visto una API que lo haga directo, alguien conoce alguna? O tendré que recorrer la lista de procesos buscando el proceso que coincida con el PID y buscarme la vida?


Gracias

Muchas gracias! He estado leyendo y codeando y todo ok

MI idea es que el modo kernel envié información al modo usuario y entonces se quede bloqueado asta recibir la respuesta del modo user.

He buscado como crear eventos pero o no se buscarlo o no hay nada.
Alguna idea o cacho de codigo?

Felices fiestas!!

Estoy liado con la comunicación entre modo kernel y user 

Tal como esta en el ejemplo puedes dar una orden desde modo user y al acabar la operación en el kernel devolver un resultado ya que segun creo la funcion:
DeviceIoControl(hDevice,(DWORD)Escribe,iBuffer,(DWORD)sizeof(iBuffer),(LPVOID)oBuffer,(DWORD)sizeof(oBuffer),&a,NULL)==true)

es bloqueante y espera a que desde el kernel se envié una repuesta.

Pero yo soy un caprichoso y me gustaría al revés, que el kernel enviara un int y se quedara esperando la respuesta del modo usuario, otro int. Pero claro creo que con el DeviceIoControl no es posible.

A alguien se le ocurre algo?¿