[win32] Cercare simboli nel contesto corrente

[ilsensine]

Sotto linux, posso usare dlopen (l'equivalente di LoadLibrary), oltre che per caricare dinamicamente librerie, anche per avere un riferimento al contesto corrente di esecuzione (il processo corrente). Quindi con dlsym (equivalente di GetProcAddress) posso cercare se una certa funzione è presente nel contesto corrente, e di ottenerne l'indirizzo. E' possibile usare una tecnica simile sotto windows?
Inoltre, esiste un equivalente windows di LD_PRELOAD?

[71104]

Originariamente inviato da ilsensine

Sotto linux, posso usare dlopen (l'equivalente di LoadLibrary), oltre che per caricare dinamicamente librerie, anche per avere un riferimento al contesto corrente di esecuzione (il processo corrente). Quindi con dlsym (equivalente di GetProcAddress) posso cercare se una certa funzione è presente nel contesto corrente, e di ottenerne l'indirizzo. E' possibile usare una tecnica simile sotto windows?

non ho mica capito il punto della domanda...
le funzioni API le hai nominate tu stesso, LoadLibrary e GetProcAddress; la loro accoppiata è un uso naturalissimo e anche abbastanza frequente che permette di ottenere in runtime l'indirizzo di una funzione esportata da un altro modulo eseguibile: con LoadLibrary ti assicuri che il modulo sia caricato (ovviamente non viene caricato due volte se è già caricato) e ne ricavi uno pseudo-handle; poi passi lo pseudo-handle alla GetProcAddress assieme al nome del simbolo di cui vuoi sapere l'indirizzo, e hai fatto.

A dire il vero non ho mai provato a passare a GetProcAddress nomi di variabili anziché di funzioni ma non dovrebbe esserci nessun problema: il formato Portable Executable non permette neanche di distinguere tra l'uno e l'altro tipo di simboli; nella Import Address Table ci trovi sostanzialmente solo un nome (o un id numerico) e un RVA (Relative Virtual Address, cioè un offset relativo all'indirizzo base del modulo eseguibile).

Inoltre, esiste un equivalente windows di LD_PRELOAD?

non sapevo a cosa servisse e ho fatto una ricerca: http://www.die.net/doc/linux/man/man8/ld-linux.8.html
ma non ho capito bene che implicazioni ha... dice che viene utilizzato per sovrascrivere selettivamente funzioni in altre librerie dinamiche.
mi pare di aver capito che l'eseguibile principale, linkandosi prima a determinate librerie che ad altre, finisce per chiamare le funzioni a cui è stato linkato la prima volta; se ci sono funzioni omonime nelle librerie caricate dopo non le chiama.

se è così in Windows non v'è nulla del genere: il concetto di binding ad un simbolo importato da un altro modulo è un concetto che implica anche il modulo da cui proviene quel simbolo. se due moduli caricati nello stesso processo esportano due simboli omonimi, qualsiasi altro modulo eseguibile può teoricamente usarli tutti e due.

ovviamente da codice C però ne userai uno solo: dipende se il tuo programma è stato linkato col .lib dell'uno o dell'altro modulo. a quel punto diventa una questione di mettersi in pace con se stessi: vuoi usare il simbolo proveniente da questa o quella DLL?

o altrimenti ne usi uno solo e l'altro lo usi tramite linking esplicito (cioè con GetProcAddress).

[71104]

faccio un altro post per fare un po' di chiarezza sulla situazione.

nella programmazione Win32 ci sono ben tre tipi di linking. una porzione di codice di terze parti può essere stata compilata come una libreria statica che potrai fondere direttamente nel tuo programma, e allora si parla di linking statico. altrimenti può essere stata compilata sotto forma di un eseguibile* a se stante quale può essere una DLL, ed in tal caso dovrai effettuare una delle due possibili forme di linking dinamico: implicito o esplicito.

* eseguibile ma non "lanciabile", visto che è una DLL

procedure tipica di linking implicito: chi ha scritto la DLL ha anche rilasciato ai programmatori che la useranno un header che dichiara i prototipi di tutte le funzioni esportate dalla DLL; ed eventualmente se esporta pure variabili allora dichiara anche quelle. tali dichiarazioni sono particolari: sono precedute da qualche keyword specifica del compilatore che gli fa capire che il simbolo sta in una DLL e che quindi per effettuarne il linking deve cercarne le informazioni in un certo file .lib associato alla DLL e rilasciato dall'autore della stessa. il compilatore Microsoft utilizza per questo scopo la keyword __declspec(dllimport). a questo punto tu dal programma includi l'header, chiami quella funzione, o usi quella variabile, e il resto vien da se'.

procedura invece di linking esplicito: LoadLibrary/GetProcAddress.

nota: praticamente tutte le API Win32 sono accessibili tramite linking implicito grazie alle dichiarazioni presenti nei vari headers del Platform SDK. non serve che stai ad impazzire per includere di ogni set di funzioni il rispettivo header, basta che includi windows.h e ce le hai tutte. le rarissime funzioni che Microsoft non dichiara negli headers, ma dice di importare tramite GetProcAddress, sono o funzioni vecchie e deprecate, tenute per retrocompatibilità, o internals di Windows (ne ho vista qualcuna di quelle native, prefisso Zw o Nt).

[ilsensine]

Originariamente inviato da 71104

non ho mica capito il punto della domanda...

Esempio. Sotto linux posso fare (sotto opportune condizioni di compilazione):

#include <dlfcn.h>

void ciao()
{
// ...
}

int main()
{
  void *h = dlopen(NULL, RTLD_LAZY);
  void *addr = dlsym(h, "ciao");
  void (*proc)() = (void(*)()) addr;
  proc(); // chiama ciao()
  dlclose(h);
  return 0;
}

Ti tralascio il perché mi serve. Capirai che è una situazione molto particolare.
Su windows posso fare qualcosa di simile?

non sapevo a cosa servisse e ho fatto una ricerca: http://www.die.net/doc/linux/man/man8/ld-linux.8.html
ma non ho capito bene che implicazioni ha... dice che viene utilizzato per sovrascrivere selettivamente funzioni in altre librerie dinamiche.

Non solo, serve per molte altre cose.

se è così in Windows non v'è nulla del genere: il concetto di binding ad un simbolo importato da un altro modulo è un concetto che implica anche il modulo da cui proviene quel simbolo. se due moduli caricati nello stesso processo esportano due simboli omonimi, qualsiasi altro modulo eseguibile può teoricamente usarli tutti e due.

Non è quello che mi serve, non devo sovrascrivere un simbolo.

[71104]

Originariamente inviato da ilsensine

Esempio. Sotto linux posso fare (sotto opportune condizioni di compilazione):

#include <dlfcn.h>

void ciao()
{
// ...
}

int main()
{
  void *h = dlopen(NULL, RTLD_LAZY);
  void *addr = dlsym(h, "ciao");
  void (*proc)() = (void(*)()) addr;
  proc(); // chiama ciao()
  dlclose(h);
  return 0;
}

Ti tralascio il perché mi serve. Capirai che è una situazione molto particolare.
Su windows posso fare qualcosa di simile?

il flag RTLD_LAZY ricorda molto il delay-load, che però su Windows è una pratica legata al linking implicito, non esplicito. comunque il punto non mi sembra quello: se ho capito bene vuoi semplicemente ottenere l'indirizzo di una funzione del tuo stesso eseguibile. beh non vedo cosa lo vieti... esporta la funzione con __declspec(dllexport):

__declspec(dllexport) void ciao();

void ciao() {
	. . .
}

così farai in modo che il linker ne metta nome e indirizzo nella Export Address Table. dopodiché ne puoi ottenere l'indirizzo passando a GetProcAddress il nome e l'HMODULE del tuo modulo. se il tuo modulo è l'eseguibile principale (quello da cui è stato creato il processo, l'exe insomma) allora l'HMODULE è semplicemente quello che ti entra al parametro hInstance della WinMain (HINSTANCE e HMODULE in Win32 sono esattamente la stessa cosa), e che puoi ottenere anche passando NULL a GetModuleHandle.

[ilsensine]

Originariamente inviato da 71104

il flag RTLD_LAZY ricorda molto il delay-load, che però su Windows è una pratica legata al linking implicito, non esplicito. comunque il punto non mi sembra quello: se ho capito bene vuoi semplicemente ottenere l'indirizzo di una funzione del tuo stesso eseguibile. beh non vedo cosa lo vieti... esporta la funzione con __declspec(dllexport):

__declspec(dllexport) void ciao();

void ciao() {
	. . .
}

così farai in modo che il linker ne metta nome e indirizzo nella Export Address Table. dopodiché ne puoi ottenere l'indirizzo passando a GetProcAddress il nome e l'HMODULE del tuo modulo. se il tuo modulo è l'eseguibile principale (quello da cui è stato creato il processo, l'exe insomma) allora l'HMODULE è semplicemente quello che ti entra al parametro hInstance della WinMain (HINSTANCE e HMODULE in Win32 sono esattamente la stessa cosa), e che puoi ottenere anche passando NULL a GetModuleHandle.

Ok torna. Ora supponi che la funzione che cerco sia in una dll linkata al programma: funziona ancora chiamando la GetProcAddress con l'handle ritornato da GetModuleHandle(NULL)?

[71104]

Originariamente inviato da ilsensine

Ok torna. Ora supponi che la funzione che cerco sia in una dll linkata al programma: funziona ancora chiamando la GetProcAddress con l'handle ritornato da GetModuleHandle(NULL)?

eh, no: alla GetProcAddress devi passare l'HMODULE del modulo in cui si trova il simbolo che cerchi perché ciascun modulo ha la sua EAT. l'handle di un modulo, a volte espresso come HMODULE e a volte come HINSTANCE, altro non è che il base address a cui è stato mappato il modulo nello spazio di indirizzamento del processo corrente. per gli eseguibili infatti è sempre 0x00400000 a meno che non lo cambi dalla command line del linker.

se ti trovi in una DLL il tuo entry point è la DllMain, anziché WinMain. anche la DllMain ha un parametro HINSTANCE che ti dice il base address nel processo da dove ti viene chiamata (se una DLL viene caricata in N processi, la DllMain viene chiamata N volte). altrimenti se non hai una funzione DllMain devi passare a GetModuleHandle il nome della tua DLL sperando che l'utonto non te l'abbia cambiato

[ilsensine]

...e se volessi fare una cosa del genere?

#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>

void do_test()
{
  void *h = dlopen(NULL, RTLD_LAZY);
  void *addr = dlsym(h, "cos");
  double (*cos)(double) = (double(*)(double)) addr;
  printf("coseno di 0.5=%f\n", cos(0.5));
  dlclose(h);
}

int main()
{
  void *h = dlopen("libm.so", RTLD_LAZY|RTLD_GLOBAL);
  do_test();
  dlclose(h);
  return 0;
}

Nota che la funzione do_test mi funziona in tutti questi casi:
1 - ho caricato libm tramite dlopen(...., RTLD_GLOBAL), come nell'esempio che ho scritto
2 - ho linkato il programma a libm.so durante il linking
3 - ho eseguito il programma impostando LD_PRELOAD=libm.so
4 - il programma implementa internamente un simbolo "cos" ed è compilato con -rdynamic
Ok per 3 forse non c'è niente da fare su windows; 4 ho capito che funziona con il trucco che mi hai spiegato; per 1 e 2 ti viene in mente niente?

[71104]

ma libm.so contiene il simbolo cos oppure lo importa da qualche altra parte? perché nella prima ipotesi non capisco la logica del programma

si tratta di un programma che importa la funzione coseno prendendola da libm.so, il quale la prende a sua volta dal programma stesso?

comunque per quanto riguarda RTLD_GLOBAL... mi sono visto cosa fa nel man e mi pare che Windows non abbia nulla di simile: il binding dei simboli che vuoi importare avviene solo in base alla tua IAT, non quella di altri moduli; al massimo puoi fare in modo che una delle entries della EAT di un tuo modulo altro non sia che un redirect ad un simbolo esportato in realtà da un altro modulo (cosa che accade anche per alcune API di Windows la Rtl mi sembra), non so quanto c'entri con quello che devi fare tu.

invece per il punto 2 non mi pare ci sia nulla di atipico: forse (dimmi se ho capito bene) il fatto che a runtime carichi con dlopen uno shared object a cui ti eri già linkato in link time? in Windows nulla lo vieta: compili l'eseguibile in modo che utilizzi una certa DLL (ne importi dei simboli e li usi), e poi a runtime chiami LoadLibray su quella DLL. ciò che accade quando chiami LoadLibrary è che il kernel vede che la DLL ti è già stata mappata (non importa che la cosa sia avvenuta in maniera implicita alla creazione del processo), e quindi te ne restituisce semplicemente l'handle senza ricaricartela una seconda volta.

[ilsensine]

Originariamente inviato da 71104

ma libm.so contiene il simbolo cos oppure lo importa da qualche altra parte?

Nel caso specifico, contiene. Ma anche se importa da un altro .so, funziona ugualmente (l'altro .so viene caricato in catena se è linkato a libm).

perché nella prima ipotesi non capisco la logica del programma

...non devi capire

invece per il punto 2 non mi pare ci sia nulla di atipico: forse (dimmi se ho capito bene) il fatto che a runtime carichi con dlopen uno shared object a cui ti eri già linkato in link time? in Windows nulla lo vieta: compili l'eseguibile in modo che utilizzi una certa DLL (ne importi dei simboli e li usi), e poi a runtime chiami LoadLibray su quella DLL. ciò che accade quando chiami LoadLibrary è che il kernel vede che la DLL ti è già stata mappata (non importa che la cosa sia avvenuta in maniera implicita alla creazione del processo), e quindi te ne restituisce semplicemente l'handle senza ricaricartela una seconda volta.

No, la funzione do_test non sa nulla della provenienza del simbolo "cos". Non sa se è nell'eseguibile, in una sua libreria, o in una libreria caricata dinamicamente. A me serve trovare dei simboli nello spazio dell'applicazione, senza poter fare assunzioni su chi li fornisce.

Non c'è modo di enumerare i vari HMODULE delle dll correntemente caricate dall'applicazione? Un pò contorto, ma potrebbe essere una via...

[71104]

Originariamente inviato da ilsensine

No, la funzione do_test non sa nulla della provenienza del simbolo "cos". Non sa se è nell'eseguibile, in una sua libreria, o in una libreria caricata dinamicamente. A me serve trovare dei simboli nello spazio dell'applicazione, senza poter fare assunzioni su chi li fornisce.

òòòò finalmente sei stato chiaro
sicché è questo che vuoi fare.

Non c'è modo di enumerare i vari HMODULE delle dll correntemente caricate dall'applicazione? Un pò contorto, ma potrebbe essere una via...

per caricare un simbolo sicuramente presente nel processo senza sapere in quale modulo penso che quella sia l'unica via. per enumerare gli HMODULE devi usare le PSAPI, in particolare la funzione EnumProcessModules.

[ilsensine]

Grazie, provo con questa.

[71104]

mi sono scordato di dirti che ad EnumProcessModules al parametro HANDLE non c'è bisogno che gli passi un valore aperto da OpenProcess, puoi usare lo pseudohandle ritornato da GetCurrentProcess, che è come un HANDLE aperto con PROCESS_ALL_ACCESS, cioè con tutti i permessi possibili (significa che qualsiasi utente dall'interno di un processo con quel processo ci può fare quello che gli pare, compreso enumerarne i moduli; specifico perché in linea teorica OpenProcess può fallire anche se vuoi aprire il tuo processo).

[71104]

Originariamente inviato da ilsensine

Grazie

e di che, siamo pari

[ilsensine]

Originariamente inviato da 71104

mi sono scordato di dirti che ad EnumProcessModules al parametro HANDLE non c'è bisogno che gli passi un valore aperto da OpenProcess, puoi usare lo pseudohandle ritornato da GetCurrentProcess

Ci ero arrivato, mica programmo sotto windows

[71104]

Originariamente inviato da ilsensine

Ci ero arrivato, mica programmo sotto windows

sese come no
e poi non si sa mai, nella pagina di MSDN di EnumProcessModules c'era un link ad un esempio di codice intitolato ENUMERATING ALL MODULES FOR A PROCESS, e l'esempio usava OpenProcess

[ilsensine]

Ok funziona.
A proposito di LD_PRELOAD, questo funziona (solo per una dll):
http://www.deez.info/sengelha/code/win32-ldpreload/
un bell'esempio di "ODP"

(ODP = object-disoriented programming)

[ilsensine]

Originariamente inviato da ilsensine

Ok funziona.
A proposito di LD_PRELOAD, questo funziona (solo per una dll):
http://www.deez.info/sengelha/code/win32-ldpreload/

Mi è venuto in mente un metodo più pulito, dimmi se può funzionare...
Creo un processo "suspended"; apro le dll che devo aprire; con DuplicateHandle "duplico" gli handle delle dll che ho aperto nel nuovo processo, e quindi lo lancio...
che dici può funzionare o mi ritrovo Guglielmo Cancelli alla porta con un grosso randello?

[71104]

Originariamente inviato da ilsensine

Ok funziona.
A proposito di LD_PRELOAD, questo funziona (solo per una dll):
http://www.deez.info/sengelha/code/win32-ldpreload/
un bell'esempio di "ODP"

(ODP = object-disoriented programming)

ah vabbè che c'entra, se la mettiamo così allora possiamo anche scrivere un launcher che offre un'implementazione completa di LP_PRELOAD, e potremmo addirittura farlo in maniera pulita, cioè senza code injections. si potrebbe creare un eseguibile di ausilio con un base address diverso da 0x00400000 (in modo tale da evitare di causare sempre la rilocazione dell'eseguibile vero e proprio); il launcher lancia l'eseguibile di ausilio, apre con esso un qualche canale IPC (per esempio facendogli ereditare l'HANDLE di una pipe) e gli passa la lista delle DLL da precaricare e l'eseguibile finale da lanciare; l'eseguibile carica prima le DLL da precaricare, e poi carica (sempre con LoadLibrary!) l'eseguibile finale; sempre che io abbia capito bene il funzionamento di LD_PRELOAD. una volta fatto il caricamento apre gli headers PE dell'eseguibile finale, legge l'indirizzo dell'entry point, e lo chiama.

[71104]

Originariamente inviato da ilsensine

Mi è venuto in mente un metodo più pulito, dimmi se può funzionare...
Creo un processo "suspended"; apro le dll che devo aprire; con DuplicateHandle "duplico" gli handle delle dll che ho aperto nel nuovo processo, e quindi lo lancio...
che dici può funzionare o mi ritrovo Guglielmo Cancelli alla porta con un grosso randello?

DuplicateHandle duplica solamente gli handles di tipo HANDLE, cioè quelli che rappresentano kernel objects (anche detti securable objects, perché possono avere un descrittore di sicurezza).

HINSTANCE e HMODULE non rappresentano nessun kernel object, sono solo dei banali numeri da 4 byte castati ad HINSTANCE o HMODULE; sono i base address dei rispettivi moduli eseguibili, e affinché abbiano senso nel contesto di un processo arbitrario è sufficiente che siano accompagnati da un'indicazione circa il processo a cui si riferiscono.

per pignoleria: non è proprio vero che gli handles dei moduli siano solo numeri: kernel32.dll tiene al suo interno delle strutture a noi ignote tramite le quali implementa funzionalità come il reference counting dei singoli moduli, ma tutta roba user mode. te l'ho detto per farti presente che se tu in un processo allocassi un'area di memoria, ci scrivessi manualmente un'immagine PE valida/bindata/rilocata e tutto quanto, e utilizzassi il base address di quell'area castato ad HMODULE per passarlo a delle API Win32, quelle API potrebbero lanciarti un'eccezione. anche altre API che interpellano servizi del kernel non funzionrebbero perché il kernel non troverebbe nessun Section Object associato ai tuoi base address "inventati" (l'oggetto Section di un modulo sarebbe quello utilizzato per gestire la condivisione tra processi dell'immagine eseguibile: protezione Copy-On-Write ecc. è un oggetto che somiglia ad un file mapping).

edit - nota che l'HMODULE non è l'handle dell'oggetto Section