ctrl+alt+supr como las capturo?

[patorecalde]

Estimados, como les va quisiera que cuando este corriendo mi aplicacion y se precionara esta secuencia de letras (ctrl+alt+supr) se grabe en un archivo de mi disco,una linea con el texto 'Se presiono ....' lo unico que me queda es, como se o como hago para capturar esa secuencia de teclas?
Gracias desde ya, un abrazo

[[seoane]]

Pues supongo que estamos hablando de Windows XP, si es así, la respuesta corta es que no puedes, al menos el tema se ha tratado varias veces por aquí y nadie a encontrado una buena solución.

Eso se debe a que el propio windows protege con especial cuidado esa combinación de teclas. Pero, al menos en Windows XP, al pulsar esa combinación de teclas windows se limita a ejecutar el siguiente programa:

C:\WINDOWS\system32\taskmgr.exe

Por lo que una solución un poco chapuza, es cambiarle el nombre a ese programa y cambiarlo por el nuestro. Así al pulsar Ctrl+Alt+Supr se ejecutaría nuestro programa, y nuestro programa se encargaría de ejecutar el verdadero programa. Para el usuario el proceso seria completamente transparente.

[roman]

Pero el administrador de tareas aparece al presionar Ctrl+Alt+Supr si en "Cuentas de Usuario" en el panel de control, se habilita la opción "Usar la pantalla de bienvenida"; pero en caso contrario aparece el cuadro de diálogo de "Seguridad de Windows", desde donde se puede escoger el administrado de tareas. De forma que no sé si baste con la técnica que describes.

// Saludos

[[seoane]]

Ahora si que me perdí roman, yo en Windows XP cuando tecleo Ctrl+Alt+Sup me salta el Administrador de Tareas. ¿No estarás hablando de Windows 2000 en vez de XP?

De todas formas ya dije que es un método chapuza, una simple actualización de windows podría dar al traste con todo. Se podrían implementar soluciones mas complicadas, ahora mismo se me ocurre alguna con una dll, pero yo creo que es complicarse demasiado. Seguro que sabiendo el objetivo que se quiere conseguir, exista un método mejor.

[roman]

Pue sí, en mi caso también cuando tecleo ctrl+alr+supr en windows xp sale el administrador de tareas, pero eso es porque tengo marcada la opción que mencioné. Desmárcala y dime qué pasa.

En cuanto a si es demasiado complicada, puede ser, pero si lo haces habrás resuleto la pregunta del siglo así que yo creo que sí vale la pena

// Saludos

[patorecalde]

ok, voy a analizarlo con esto que me dicen y veo como manejo el tema, gracias.

[[seoane]]

Empezado por roman

En cuanto a si es demasiado complicada, puede ser, pero si lo haces habrás resuleto la pregunta del siglo así que yo creo que sí vale la pena

No se si el problema del siglo, pero la cosa esta complicada.

La cosa funciona así, cuando se pulsa Ctrl+Alt+Sup windows manda el mensaje WM_HOTKEY a una ventana del proceso winlogon.exe. Pues bien, hasta ahora he conseguido estar en el mismo desktop que esa ventana, e incluso puedo provocar el evento enviando el mensaje WM_HOTKEY desde mi aplicación. Pero la cosa se complica si lo que queremos es interceptar el mensaje, pensé en utilizar un hook pero por algún motivo no funciona, y la otra posibilidad es la inyección de código en el proceso winlogon.exe, pero a parte de lo peligroso que puede resultar, no me parece una solución muy elegante ...

Bueno, aquí pongo mis pasos:

Primero creamos un servicio, esto es necesario porque necesitamos ejecutarnos bajo la cuenta system para acceder al mismo desktop que el programa winlogon.exe, que es el que controla todo esto.

Código Delphi [-]
// Este es el evento OnExecute del TService
procedure TsvcMain.ServiceExecute(Sender: TService);
var
  OldStation: HWINSTA;
  OldDesktop: HDesk;
  Station: HWINSTA;
  DeskTop: HDesk;
begin
  // Guardamos los valores anteriores
  Oldstation:= GetProcessWindowStation();
  OldDesktop:= GetThreadDesktop(GetCurrentThreadId);
  Station:= OpenWindowStation('winsta0', FALSE, MAXIMUM_ALLOWED);
  if Station <> 0 then
  begin
    if SetProcessWindowStation(Station) then
    begin
      Desktop:= OpenDesktop('Winlogon', 0, FALSE, MAXIMUM_ALLOWED);
      if Desktop <> 0 then
      begin
        if SetThreadDesktop(Desktop) then
        begin
          // Ahora estamos detro del mismo desktop que winlogon.exe

          // Para probar podemos mandar el mensaje WM_HOTKEY
         PostMessage(HWND_BROADCAST,WM_HOTKEY,0,
             MAKELPARAM(MOD_ALT or MOD_CONTROL,VK_DELETE));

          // Una vez terminamos volvemos todo a su lugar
          SetThreadDesktop(OldDesktop)
        end;
        CloseDesktop(Desktop);
      end;
      SetProcessWindowStation(OldStation);
    end;
    CloseWindowStation(Station);
  end;
end;

Ahora utilizo la función SetWindowsHookEx con el parámetro WH_CALLWNDPROC, pero aunque no devuelve ningún error tampoco parece funcionar. Esta era la manera mas "elegante" que se me ocurría para inyectar código en el programa "winlogon.exe", pero parece que no funciona ... y la verdad ya me esta aburriendo el tema

¿A alguien se le ocurre algo diferente?

[[ArdiIIa]]

Os pongo un ejemplo de como:......
Este como lanza el notepad e inyecta el contenido de la función main en él...
y esta función lo que hace es leer la cola de mensajes....
A partir de aquí la imaginación es libre....

Código Delphi [-]
program Inyector_Proceso;

{$IMAGEBASE $13140000}

uses
  Windows,SysUtils,Messages;

const
CM_MANDA_TECLA  = WM_USER + $1000;
CM_MANDA_SHOW   = WM_USER + $1001;


function Main(dwEntryPoint: Pointer): longword; stdcall;
Var Zeta : String;
Msg : TMsg;
     Procedure M_Tecla;
     Begin
      MessageBox(0, 'Esto Funciona de Maravilla, MARAVILLOSAMENTE', 'M_Tecla', 0);
     End;

     Procedure M_Show;
     Begin
     Zeta := 'Esto Form ha sido llamado mediante el envio de un mensaje y cerramos el proceso';
     MessageBox(0, PChar(Zeta), 'M_Show', 0);
     End;
begin
  //si en vez de ExitThread, ponemos ExitProcess, no solo nos descargaria el archivo
  //si no que también terminaría el proceso en el que estamos inyectados


    while GetMessage(Msg,0,0,0) do
    begin
    Case MSg.message Of
    CM_MANDA_SHOW:
        M_Show;
    CM_MANDA_TECLA:
        Begin
        M_Tecla;
        ExitProcess(0);
        End;
    End; //Case
    End; //While
//  ExitThread(0);
  ExitProcess(0);
  Result := 0;
  //PostThreadMessage
end;

procedure Inject(ProcessHandle: longword; EntryPoint: pointer);
var
  Module, NewModule: Pointer;
  Size, BytesWritten, TID: longword;
begin
  Module := Pointer(GetModuleHandle(nil));
  Size := PImageOptionalHeader(Pointer(integer(Module) + PImageDosHeader(Module)._lfanew + SizeOf(dword) + SizeOf(TImageFileHeader))).SizeOfImage;
  VirtualFreeEx(ProcessHandle, Module, 0, MEM_RELEASE);
  NewModule := VirtualAllocEx(ProcessHandle, Module, Size, MEM_COMMIT or MEM_RESERVE, PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(ProcessHandle, NewModule, Module, Size, BytesWritten);
  CreateRemoteThread(ProcessHandle, nil, 0, EntryPoint, Module, 0, TID);
  Sleep(2000);
  MessageBox(0, 'Mando Mensaje CM_MANDA_SHOW', 'Inject', 0);
  PostThreadMessage(TID,CM_MANDA_SHOW,0,0);
  Sleep(5000);
  PostThreadMessage(TID,CM_MANDA_TECLA,0,0);
end;

var
  ProcessHandle, PID: longword;
  StartupInfo: TStartupInfo;
  ProcessInfo: TProcessInformation;

begin

  CreateProcess(nil, 'notepad', nil, nil, False, 0, nil, nil, StartupInfo, ProcessInfo);

  Sleep(500);

  GetWindowThreadProcessId(FindWindow('Notepad', nil), @PID);
  ProcessHandle := OpenProcess(PROCESS_ALL_ACCESS, False, PID);
  Inject(ProcessHandle, @Main);
  CloseHandle(ProcessHandle);

end.

[[seoane]]

Caramba Ardilla, muy interesante tu código, le has hechado un vistazo a este otro hilo:

http://www.clubdelphi.com/foros/showthread.php?t=37902

O de forma mas ludica:
http://www.clubdelphi.com/foros/showthread.php?t=38132

A veces es difícil no hacer maldades, ... es tan tentador

[roman]

Este es uno de esos código que yo jamás entenderé, no sé, creo que hay un sector neuronal que me hace falta . Vamos, ni siquiera entiendo qué se supone que hace. Ejecuto el programa y se abre el bloc de notas, luego unos mensajes y se cierra el bloc de notas. Aún así un par de preguntas:

¿Para qué es la directiva IMAGEBASE?
¿Se puede hacer lo mismo (cualquier cosa que esto sea) si el proceso no lo iniciamos nosotros mismos?

// Saludos

[[seoane]]

Roman, el programa no es tan difícil de entender, al menos los conceptos básicos. Primero escribimos en la memoria del proceso a "atacar" la función a inyectar, después ejecutamos el código inyectado.

¿Para que sirve IMAGEBASE? para indicar a partir de que posición de memoria se cargara nuestro programa. ¿Para que la utilizamos aquí? pues necesitamos que nuestro código este lo suficientemente alto en la memoria para que no interfiera con el propio código del notepad.

¿Se puede hacer con cualquier proceso? En principio si, siempre que dispongamos de su handle, y de los permisos necesarios. En cualquier caso es necesario tener un conocimiento detallado del proceso donde nos vamos a inyectar, hay que recordar que estamos manipulando la memoria de un proceso no podemos entrar como un elefante en una cristalería

De todas formas creo que el nuevo vista implementa protecciones contra esto, si alguien tiene el vista que lo pruebe haber que pasa.

[[ArdiIIa]]

Empezado por seoane

¿Se puede hacer con cualquier proceso? En principio si, siempre que dispongamos de su handle, y de los permisos necesarios. En cualquier caso es necesario tener un conocimiento detallado del proceso donde nos vamos a inyectar, hay que recordar que estamos manipulando la memoria de un proceso no podemos entrar como un elefante en una cristalería

Los hilos que mi citabas no los había visto, de hecho estuve buscando hilos sobre inyección de procesos.. y me encontré con esto:

Empezado por seoane

Esta era la manera mas "elegante" que se me ocurría para inyectar código en el programa "winlogon.exe", pero parece que no funciona ... y la verdad ya me esta aburriendo el tema

¿A alguien se le ocurre algo diferente?

Por eso la respuesta....

A grandes rasgos te comentaré que lo he probado con resultados satisfactorios en procesos tales como el "explorer.exe" que es vital o mejor dicho es la Shell de windows y por lo que es asumible que siempre estará ahí, y por supuesto lo "inyectado" no tiene nada que ver con el código de la referencia anterior.

Empezado por seoane

De todas formas creo que el nuevo vista implementa protecciones contra esto, si alguien tiene el vista que lo pruebe haber que pasa.

Tiempo al tiempo....

[roman]

Empezado por seoane

Roman, el programa no es tan difícil de entender, al menos los conceptos básicos. Primero escribimos en la memoria del proceso a "atacar" la función a inyectar, después ejecutamos el código inyectado.

Mmmm... Leo lo que dices, reconozco las palabras, pero no entiendo nada. ¿No podrías detallar un poco indicando las partes del codigo que hacen eso que tú dices?

Empezado por seoane

¿Para que sirve IMAGEBASE? para indicar a partir de que posición de memoria se cargara nuestro programa. ¿Para que la utilizamos aquí? pues necesitamos que nuestro código este lo suficientemente alto en la memoria para que no interfiera con el propio código del notepad.

Ok. Suena razonable. Mmm.. ¿qué pasaría si no lo ponemos? ¿Cómo es que podría interferir? ¿Acaso windows puede asignar el mismo pedazo de memoria a dos procesos?

Otra cosa: el código que escribiste en el hilo del engaño de memoria, ¿tiene algo que ver con esto? A primera vista se me hace más digerible. No es que lo entienda, pero como que me lo creo más fácilmente. Pero parecieran dos cosas totalmente distintas. ¿Podrías aclarar?

Por cierto, ese hilo apenas hoy lo veo. Realmente está muy interesante. Me gustó.

// Saludos

[[ArdiIIa]]

A ver roman si en pocas palabras de lo hago un poco legible....
La función main, es el trozo de código que será inyectado, en él podrás introducir cualquier cosa que se te ocurra... Procedures... etc.. en este caso no hace nada en especial, sino que únicamente se pone a recibir mensajes y procesarlos...

El procedimiento inject será el encargado de:

• Calcular la memoria necesaria para el proceso a inyectar
• Reservar esa memoria atendiendo a los parámetros (PAGE_EXECUTE_READWRITE)....
• Escribir en la memoria reservada el proceso (función main)
• Y finamlente lanzar el proceso.

Adicionalmente en ese mismo proceso, lo que hace es esperar un poquito y mandar un par de mensajes de prueba al proceso YA inyectado. En este punto te aclaro que no tendría mucho sentido, y que lo he puesto a modo de ejemplo, sin embargo si es otra aplicación la que coge los parámetros de ubicación del proceso; esa otra aplicación debería ser la encargada de mandar los mensajes al proceso inyectado.
Por último y también a modo de ejemplo el programa en su ejecución lo que hace es...

• Lanzar el Notepad
• Buscar el handle del proceso
• Y finamente inyecta el proceso.

Es obvio que si lo que queremos es un proceso tal como el "explorer.exe, winlogon.exe" o similar, no hemos de lanzar nada, sino simplemente buscar ahí e inyectar.

Ok. Suena razonable. Mmm.. ¿qué pasaría si no lo ponemos? ¿Cómo es que podría interferir? ¿Acaso windows puede asignar el mismo pedazo de memoria a dos procesos?

$IMAGEBASE controla la dirección de la carga por defecto del objeto cargado, pero de hecho, señalo que el proceso de inyección busca y reserva memoria (ver VirtualAllocEx) para el proceso a inyectar, por lo cual entiendo que no hay ninguna interferencia. Es mas si se anula esa directiva, el programa funcionaría igualmente, lo que ocurre, es que precisamente este método está basado en la inyección de una DLL y en ese caso, realmente si que resultaría necesaria.

Espero aclararte algo roman.

[[seoane]]

Empezado por roman

Otra cosa: el código que escribiste en el hilo del engaño de memoria, ¿tiene algo que ver con esto? A primera vista se me hace más digerible. No es que lo entienda, pero como que me lo creo más fácilmente. Pero parecieran dos cosas totalmente distintas. ¿Podrías aclarar?

En ambos casos se trata de inyectar codigo ajeno dentro de un proceso. El metodo de Ardilla es mas directo, tambien mas complejo, y depende en gran medida de las permisos. Mi metodo es menos directo, deja que windows haga el trabajo. Cuando implementamos un hook en una dll (no un LL como los de tu unit), windows se encarga de inyectarlo en los demas procesos que comparten escritorio con el que crea el hook. Asi una vez tenemos cargada la dll en el proceso a "atacar" podemos hacer lo que queramos dentro de el.

Un ejemplo tipico en ambos casos, es hacer "subclassing". Es decir sustituir el bucle de mensajes de una ventana por uno diferente, esto es lo que hago yo en mis 2 ejemlos. Otra cosa muy interesante que se peude hacer es un hook de las APIs, que consiste en sustituir el codigo de algunas funcicones de la API que estan cargadas en memoria por codigo propio, esto ultimo es lo que hacen los famosos rootkits, y la verdad a mi ya se me hace un poco complejo

[roman]

Empezado por ArdiIIa

Espero aclararte algo roman.

Hola, muchas gracias. Ahora tengo un panorama general más claro aunque desde luego tengo que meterme en cada detalle. Para empezar, ¿en qué parte del SDK puedo encontrar información acerca del FileHeader, DosHeader, OptionalHeader, etc.?

Ahora bien, lo del IMAGEBASE sigue sin quedarme claro. Tal como dices, el programa funciona aún sin él, pero entonces ¿por qué es necesario si se tratase de una dll? ¿No vale el mismo proceso del VirtualAlloc?

Empezado por seoane

Un ejemplo tipico en ambos casos, es hacer "subclassing"

A ver, tratar de liarme con ambas técnicas al mismo tiempo va a estar de locos pero vamos allá. Según creo recordar, en los tiempos del windows de 16 bits, el subclassing era tan sencillo como hacer un

Código Delphi [-]
SetWindowLong(hWnd, GWL_WNDPROC, LongInt(@WindowProc))

con lo que sustituíamos el procedimiento de ventana de la ventana hWnd con el nuestro WindowProc. Al llegar los 32 bits, también llegó esto:

Empezado por SDK de Windows

The SetWindowLong function fails if the window specified by the hWnd parameter does not belong to the same process as the calling thread.

con lo cual se anulaba la diversión. Sin embargo veo que usas esto mismo en tu código (de ahí copié la línea de código anterior )

Entonces, inyectamos el código en el otro proceso precisamente para ser parte de él y poder hacer el subclassing. ¿Es esto correcto o nada que ver?

Otra cosa: ¿una dll siempre se inyecta? Es decir, cuando un proceso ejecuta código de una dll, ¿Windows mapea ese código dentro del espacio del proceso?

Muchas gracias a ambos.

pd: Entonces, ¿la técnica de ArdiIIa ya nos permitiría inyectar a WinLogon e interceptar el famoso Ctrl+Alt+Supr?

// Saludos

[[seoane]]

Empezado por roman

Entonces, inyectamos el código en el otro proceso precisamente para ser parte de él y poder hacer el subclassing. ¿Es esto correcto o nada que ver?

Exacto, inyectamos el codigo precisamente para poder hacer subclassing.

Empezado por roman

Otra cosa: ¿una dll siempre se inyecta? Es decir, cuando un proceso ejecuta código de una dll, ¿Windows mapea ese código dentro del espacio del proceso?

Pues si, para llamar a una funcion de una dll primero hay cargar esa dll dentro de la memoria del proceso. Utilizando, por ejemplo, ProcessExplorer de Sysinternal puedes ver la cantidad de librerias que tiene cargado cada proceso. Y en el caso de los hook, puedes ver como la libreria que contiene el hook aparece ahi con las demas.

Empezado por roman

pd: Entonces, ¿la técnica de ArdiIIa ya nos permitiría inyectar a WinLogon e interceptar el famoso Ctrl+Alt+Supr?

Pues si, pero como ya he dicho antes esta tecnica me resulta un poco compleja, pero si Ardilla se ve con ganas ... La prueba de que la inyeccion de codigo funciona para interceptar el Ctr+Alt+Supr es que hay varios programas que lo consiguen de esta forma, en codeproject creo que hay algun ejemplo.

PD: No sabia roman que te interesaba el tema. Pense que era el unico por aqui que lo encontraba entretenido, pero ya veo que Ardilla y tu tambien le encontrais interesante.

[roman]

Empezado por seoane

La prueba de que la inyeccion de codigo funciona para interceptar el Ctr+Alt+Supr es que hay varios programas que lo consiguen de esta forma, en codeproject creo que hay algun ejemplo.

Pues no sé. Si tienes una referencia específica me gustaría verla porque siempre que he buscado acerca del Ctrl+Alt+Supr termino con GINA.

El tema es, desde luego, interesante, pero nunca me he metido a profundidad en las entrañas de Windows. El primer ejemplo que citaste aquí, lo vi pero no me metí a estudiarlo, pero con el segundo, que apenas hoy (ayer) ví, la cosa cambia porque, como dices, es más divertido

// Saludos

[[seoane]]

Empezado por roman

Pues no sé. Si tienes una referencia específica me gustaría verla porque siempre que he buscado acerca del Ctrl+Alt+Supr termino con GINA.

Por ejemplo este http://www.codeproject.com/win32/AntonioWinLock.asp

Código Delphi [-]
El primer ejemplo que citaste aquí, lo vi pero no me metí a estudiarlo, pero con el segundo, que apenas hoy (ayer) ví, la cosa cambia porque, como dices, es más divertido

Y seguro que podemos buscarle otras utilidades igual de divertidas

[roman]

Increible. Ese artículo ya lo había visto hace como medio año. Seguramente como no tenía ni la más remota idea de la inyección ni cómo hacerla, mi mente lo bloqueó Pues apenas tenga tiempo ya me veo estudiando su código.

// Saludos