Título: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: Eleкtro en 4 Julio 2015, 18:31 pm INTRODUCCIÓN Buenas!. La forma tradicional de capturar las pulsaciones del teclado es mediante un hook del teclado, sin embargo, esta técnica está deprecada en .Net, ya que existe una forma alternativa o "moderna" que aporta bastantes mejoras (sobre todo mejoras de rendimiento), RawInput (el cual también sirve para sustituir a un LL-Hook del mouse): ➢ About Raw Input (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645543%28v=vs.85%29.aspx) Citar The raw input model is different from the original Windows input model for the keyboard and mouse. In the original input model, an application receives device-independent input in the form of messages that are sent or posted to its windows, such as WM_CHAR, WM_MOUSEMOVE, and WM_APPCOMMAND. In contrast, for raw input an application must register the devices it wants to get data from. Also, the application gets the raw input through the WM_INPUT message. There are several advantages to the raw input model: An application does not have to detect or open the input device. An application gets the data directly from the device, and processes the data for its needs. An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices. An application manages the data traffic by specifying data from a collection of devices or only specific device types. HID devices can be used as they become available in the marketplace, without waiting for new message types or an updated OS to have new commands in WM_APPCOMMAND. Siempre tuve curiosidad por RawInput pero nunca me animé a implementar este modelo ya que sabía que iba a ser una auténtica pesadilla de P/Invoking, pero al final la curiosidad pudo conmigo, y tras analizar decenas de ejemplos y semi-ejemplos en C#, acabé acumulando suficiente información para desarrollar el core de un keylogger para uso genérico en VB.Net. DESCRIPCIÓN Esto NO es un programa, es un algoritmo o código que encapsula los datos y las definiciones de la API de Windows de los miembros de RawInput, junto a todo lo demás adicional y necesario, exponiendo sus funcionalidades a través de una Class, con propiedades, y eventos. Se puede decir que es la base o el core para poder desarrollar la UI de un KeyLogger, ya que usando esta Class solamente sería necesario diseñar la UI y/o adaptar este código si fuese necesario según las necesidades del programador por ejemplo para monitorizar las ventana que tiene el foco activado, o la interpretación textual de las teclas del sistema, etc... Hay varias cosas que perfeccionar y refactorizar en el código, no comparto este código cómo si fuese el mejor y más completo algoritmo del mundo, me he tomado la molestia de decorar bastante este post por que creo que el código cómo ejemplo está muy bien ...ha sido bastante laborioso y por ese motivo se merece una mención especial de esta forma (por mi parte), pero simplemente comparto el código para mostrarles una manera curiosa, distina y mejor, una alternativa "moderna" a la deprecada técnica de SetWindowsHookEx + CallNextHookEx + UnhookWindowsHookEx para llevar a cabo la misma tarea. CARACTERÍSTICAS
DEMOSTRACIÓN A la derecha está lo que escribo en un editor de texto, a la izquierda está lo que intercepta el keylogger y la interpretación de las teclas del sistema. (http://i.imgur.com/ajv4FI8.gif) El código que he utilizado para desarrollar el ejemplo: Código
DIAGRAMA DE CLASS (http://i.imgur.com/T6UgFTR.png)v CÓDIGO FUENTE http://pastebin.com/u7uKf8ge Espero que les haya gustado. Si encuentran cualquier bug por favor coméntenlo aquí. Saludos! Título: Re: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: DarK_FirefoX en 4 Julio 2015, 19:22 pm Esto está genial, muy buen trabajo (como siempre), le estoy echando un vistazo, si tengo alguna duda pregunto.
Salu2s Título: Re: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: someRandomCode en 31 Agosto 2015, 01:25 am Elektro, has visto el tema de los Detours?
La verdad que hasta ahora lo que venia haciendo despues de investigar y tratar de implementar muchas cosas es cargar una DLL desde un recurso previo haberla descifrado.. Me voy a poner a leer sobre RawInputs a ver que onda.. Lamentablemente lo unico que encuentro es para gamepads, lectores de codigo de barras, etc.. Mi lenguaje de eleccion es C/C++ con Qt como framework.. Tenes algun enlace que me puedas compartir? Título: Re: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: Eleкtro en 31 Agosto 2015, 10:20 am Elektro, has visto el tema de los Detours? ¿Te refieres a Microsoft Detours?, tengo entendido que ese producto es para el API-Hooking, de todas formas nunca he usado Detours ni me lo he planteado (al requerir hacer wrappers de su librería) ya que en .Net se vuelve innecesaria su utilización al existir algunas alternativas cómo EasyHook o Nektra Deviare, siendo esta última, Deviare, la mejor opción. Mi lenguaje de eleccion es C/C++ con Qt como framework.. Tenes algun enlace que me puedas compartir? No, pero esto son ejemplos para el teclado en Visual C++ que imagino te podrán servir de mejor ayuda: ➢ Minimal Key Logger Using RAWINPUT (http://www.codeproject.com/Articles/297312/Minimal-Key-Logger-using-RAWINPUT) ➢ Combining Raw Input and keyboard Hook to selectively block input from multiple keyboards (http://www.codeproject.com/Articles/716591/Combining-Raw-Input-and-keyboard-Hook-to-selective) saludos Título: Re: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: someRandomCode en 31 Agosto 2015, 13:43 pm Estuve leyendo sobre GetRawInputData, y hay que establecer el parseo de mensajes en WM_INPUT, si hay alguna ventana privilegiada en el sistema puede no funcionar verdad? Dado que el parseo de mensajes tanto como el de eventos sobre las coordenadas o durante la ejecucion de algo con privilegios en las ultimas versiones de Windows siempre me ha dado problemas consulto :P
Parece como que dispararia varias alarmas a nivel de sistema tambien.. Has hecho alguna prueba de concepto como para probar? Título: Re: [SOURCE] Algoritmo KeyLogger (RawInput) Publicado por: Eleкtro en 5 Septiembre 2015, 17:38 pm Estuve leyendo sobre GetRawInputData, y hay que establecer el parseo de mensajes en WM_INPUT, si hay alguna ventana privilegiada en el sistema puede no funcionar verdad? Dado que el parseo de mensajes tanto como el de eventos sobre las coordenadas o durante la ejecucion de algo con privilegios en las ultimas versiones de Windows siempre me ha dado problemas consulto :P Parece como que dispararia varias alarmas a nivel de sistema tambien.. Has hecho alguna prueba de concepto como para probar? La documentación oficial en MSDN explica poquito y me deja algunas cosas con interrogantes, pero de todas formas el mensaje de ventana WM_INPUT es posteado en la cola de mensajes de la o las aplicaciones que se hayan registrado con RegisterRawInputDevices, particularmente del thread desde el que se haya registrado (normalmente el thread de la UI, ya que se necesita un HWND para la estructura RAWINPUTDEVICE), por ende, en principio creo que no tendría por qué dar problema alguno ya que teorica o supuestamente el mensaje le llegará a todas las ventanas que cumplan ese requisito, sean privilegiadas o no, sin embargo, quizás tambien pueda depender de otros factores (limitaciones, errores humanos, u otras cosas secundarias a tener en cuenta), ya que por ejemplo, con el tipo de hooking convencional, es decir, el uso de LowLevelKeyboardProc y LowLevelMouseProc, hay que tener mucho cuidado con el parámetro nCode que se devuelva tras procesar los mensajes, ya que si no se hace correctamente, entonces podría provocar un conflicto en el sistema que acabaría "bloqueando" el mensaje para el resto de aplicaciones, las cuales no podría procesarlo (durante el tiempo de vida de la app o thread, no es algo permanente claro está), tal vez eso sea lo que hayas podido experimentar en el pasado con los hooks, ya que al menos yo pasé por eso mismo cuando empecé a trastear con los windows_messages para un ll-hook del mouse, o tal vez te refieras a otro tipo de conflicto ?. Sobre las pruebas, hombre, no voy a compartir algo sin comprobar que funciona lo que hice xD, pero fueron pruebas de uso básico o digamos "ético", quiero decir, no con seguridad de terceros implementada en el S.O, ni tampoco UAC ni nada, ni con otras aplicaciones en segundo plano registradas con RAWINPUT, pero ya digo, que en pricnipio no debería dar problemas... Si descubres algo, un conflicto o lo que sea que se pueda mejorar, házmelo saber. saludos! |