Ver Mensaje Individual
  #10  
Antiguo 09-07-2007
Avatar de cHackAll
[cHackAll] cHackAll is offline
Baneado?
 
Registrado: oct 2006
Posts: 2.159
Reputación: 20
cHackAll Va por buen camino
Cool super!

En realidad l30, concuerdo con seoane y dec; este ejemplo esta muy bueno... un saludo al autor ¿? !!!

Te explico de la forma más digerible lo que hace para lo utilices; Todos los procesos tienen una copia en su contexto de las librerías que utiliza, por tal motivo la solución del hilo que iniciaste esta dada por el reemplazo de la API CreateProcess en todos los procesos habidos y por haber. El autor del anterior ejemplo se valió ingeniosamente de la API SetWindowsHookEx para cargarse en todos los procesos que manejen mensajes, de ésta forma casi todos los procesos cargan indirectamente dicha librería... cargada la librería, reemplaza los 32 bits que apuntan a la llamada de la API CreateProcess para parámetros ansi y unicode. Este es el motivo por el que cuando uno corre una consola (cmd.exe), y en ésta ejecuta el chkdsk, no aparece en la aplicación de prueba, la misma eventualidad es apreciable cuando uno crea una aplicación en Delphi que no procesa mensajes.

y bueno como la implementas? sencillo, en la unidad HookCrPr.pas, añade tu línea de comprobación de hash antes de procesar las antiguas APIs por ejemplo:

Código Delphi [-]
...
function NewCreateProcessA(lpApplicationName: PChar; lpCommandLine: PChar;
  lpProcessAttributes, lpThreadAttributes: PSecurityAttributes;
  bInheritHandles: BOOL; dwCreationFlags: DWORD; lpEnvironment: Pointer;
  lpCurrentDirectory: PChar; const lpStartupInfo: TStartupInfo;
  var lpProcessInformation: TProcessInformation): BOOL; stdcall;
var i: Integer;
begin
 if not Allowed(lpCommandLine) then // en el otro hilo induje que utilizabas una función como ésta.
  Result := False
 else 
  Result := OldCreateProcessA(lpApplicationName, lpCommandLine,
    lpProcessAttributes, lpThreadAttributes, bInheritHandles, dwCreationFlags,
    lpEnvironment, lpCurrentDirectory, lpStartupInfo, lpProcessInformation);
// las restantes lineas hasta las puedes obviar por ser una aplicacion "a medida"
end;
...

// Espero que el autor esté de acuerdo con la modificación de su unidad.

Para que dicha librería funcione en los casos excepcionales comentados anteriormente aconsejo modifiques el tipo de hook en Hook.dpr (WH_MOUSE por ejemplo), pero no creo que sea la solución más efectiva para incluir dichos casos. Personalmente lo que yo haría es listar todos los procesos eventualmente como te mostre en tu anterior hilo, y reemplazar la entrada de llamada de la API en cada uno de éstos al ser necesario, mejor aún; dicho reemplazo solo debe hacerse la primera vez, luego al correr un proceso (puesto que "tu" lo corres), debes reemplazarlas entradas del nuevo procesos creado.

TODOS las llamadas de creacion de procesos (CreateProcess, WinExec y ShellExecute*) llaman en algún momento a la API CreateProcessInternal; GüinDOS trabaja internamente con unicode así que la API que debes reemplazar es la CreateProcessInternalW. ShellExecute llama a una serie de funciones para dar soporte a la función en si, la funcion en la que me quedé en el proceso de debugging es la ShellExecuteExW, sin embargo puedo asegurar que acaba en las "manos" de CreateProcessInternalW.

PD: Claro que llevando el proceso de debugging más a fondo podríamos obtener algo como ésto:

ntdll.dll!_ZwCreateProcessEx@36()
kernel32.dll!CreateProcessInternalW()
advapi32.dll!CreateProcessAsUserW()
wlnotify.dll!ProcessExecRequest()
wlnotify.dll!ExecServerThread()
kernel32.dll!BaseThreadStart()


y pasar por NtCreateProcessEx, pero mientras más nos acercamos al kernel aumentamos el riesgo de nuestra aplicacion, y necesitamos un conocimiento de "bajo nivel" no muy bien documentado. Revisa ésto; tambien en otros foros comentan que la API que debemos reemplazar es NtCreateProcessEx, pero eso ya lo dejo a tu propio análisis.

Suerte!
Responder Con Cita