6 replies to this topic

[escafandra]

Me vi en la necesidad de tener que localizar los datos que exporta un archivo ejecutable en tiempo de ejecución, así que el mejor método es caminar por el formato PE y este es un ejemplo válido para todos los Windows NT:

cpp

//---------------------------------------------------------------------------
PIMAGE_EXPORT_DIRECTORY ImageExportDirectory(HMODULE hModule)
{
  DWORD VirtualAddress_idata = ((DWORD)hModule + *(DWORD*)((DWORD)hModule + 0x3C) + 0x78);
  return PIMAGE_EXPORT_DIRECTORY((DWORD)hModule + *(DWORD*)VirtualAddress_idata);
}
 
//-----------------------------------------------------------------------------
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);
}

Saludos.

[egostar]

Hola amigo

Dejame entender la situación, quieres decir que este proceso es algo como un sniffer ?

Salud OS

[escafandra]

Dejame entender la situación, quieres decir que este proceso es algo como un sniffer ?

Bueno, olfatear, olfatea pero se trata de averiguar los datos que exporta un archivo ejecutable. Tanto una dll como un archivo.exe tienen una cabecera con un formato perfectamente definido y estandarizado para varios S.O. Es el formato PE. En él, los programas pueden exponer a otros, las funciones y datos que exportan, el caso de las librerías dll es el ejemplo mas claro. También tiene la información de lo que se importa, de la sección de recursos, el punto de entrada del ejecutable y un montón de cosas que pueden resultar muy útiles y que generalmente nos son transparentes.

Es el S.O. el que interpreta el PE y es absolutamente necesario para la carga y ejecución del ejecutable y lo hace compatible para las diferentes versiones del S.O.

El ejemplo muestra una pequeña parte de lo que se puede extraer del análisis del PE de un ejecutable. Distintas herramientas pueden dar esa información. El ejemplo trata de conseguirlo en tiempo de ejecución.

Saludos.

[egostar]

Ah vaya, pues si que es muy interesante el asunto, siempre me agrada ver tu code aunque no comprenda de inicio todo lo que haces. Algún día lo entenderé, lo prometo

Salud OS

[seoane]

Lo que es mas difícil de averiguar es que librerias importa el programa forma dinámica (usando las funciones LoadLibrary y GetModuleHandle).

Por ejemplo, cuando aquí intento interceptar las comunicaciones de un proceso, busco en la misma tabla que tu (o eso creo  ) las funciones para enviar y recibir. Sin embargo me funciona en programas como firefox, pero en el opera no, y me temo que es porque este carga las funciones de forma dinámica.

[Wilson]

Ah vaya, pues si que es muy interesante el asunto, siempre me agrada ver tu code aunque no comprenda de inicio todo lo que haces. Algún día lo entenderé, lo prometo

Salud OS

Gracias a los maestros por sus valiosos aportes, Egostar me uno a tu promesa...

saludos

[escafandra]

Lo que es mas difícil de averiguar es que librerias importa el programa forma dinámica (usando las funciones LoadLibrary y GetModuleHandle).

Por ejemplo, cuando aquí intento interceptar las comunicaciones de un proceso, busco en la misma tabla que tu (o eso creo  ) las funciones para enviar y recibir. Sin embargo me funciona en programas como firefox, pero en el opera no, y me temo que es porque este carga las funciones de forma dinámica.

Ciertamente del PE se pueden extraer los datos importados, pero esta vez es de la sección .idata del PE. En mi ejemplo se investigan los datos exportados (sección .edata del PE).

Tu ejemplo, seoane es una magnífica forma de realizar un Hook a una API en la IAT (tabla de importación de direcciones) donde se encuentran los punteros de las APIs importadas por el ejecutable. Con la API ImageDirectoryEntryToData alcanzamos el directorio de datos importados, uno por cada módulo importado. Esa API, en caso de necesitar un nivel mas bajo en la implementación, puede ser sustituida por:

cpp

PIMAGE_IMPORT_DESCRIPTOR GetImageImportDescriptor(HMODULE hModule)
{
   // Encuentra y devuelve el directorio de sección .idata para un modulo dado.
 
   DWORD VirtualAddress_idata = ((DWORD)hModule + *(DWORD*)((DWORD)hModule + 0x3C) + 0x80);
   return PIMAGE_IMPORT_DESCRIPTOR((DWORD)hModule + *(DWORD*)VirtualAddress_idata);
}

Efectivamente, si un proceso importa una API en tiempo de ejecución, no puede ser hookeada con esta técnica. Ese es el efecto buscado en esta solución en modo kernel. Para poder hookear esas APIs importadas en tiempo de ejecución, se debe usar la técnica de sobreescribir sus primeros bytes para provocar un salto a nuestro código. Ese salto se podría también sobreescribir en un salto de la misma API. Esta segunda técnica es válida para cualquier API, importada en tiempo de compilación o se ejecución, así, no hace falta averiguar que librerías importa el programa forma dinámica, no nos importa .

De cualquier forma, el PE esconde secretos muy valiosos para los curiosos. 

Saludos.