[C] Trovare il nome del file dal puntatore FILE

[uReverendo]

Ciao, avendo un puntatore ad una struttura FILE come è possibile recuperare il nome del file?
Ovviamente il file lo apre un'altro programma con la funzione fopen.

[ilsensine]

Fammi capire...il programma A apre un file, e il programma B deve capire (dal puntatore FILE * di A) di che file si tratta?

[andbin]

Ciao, avendo un puntatore ad una struttura FILE come è possibile recuperare il nome del file?
Ovviamente il file lo apre un'altro programma con la funzione fopen.No, non è possibile. La struttura FILE è una struttura "opaca" (cioè il programmatore non dovrebbe ficcarci dentro il naso ;) ) il cui contenuto, in termini di campi, può variare da piattaforma a piattaforma e -ciliegina sulla torta- non contiene alcuna informazione sul nome del file aperto.

[-fidel-]

Ciao, avendo un puntatore ad una struttura FILE come è possibile recuperare il nome del file?
Ovviamente il file lo apre un'altro programma con la funzione fopen.

Ti conviene che l'altro programma apra il file usando una struct ad hoc, in questo modo:


#define STRING_LENGHT 256

typedef struct FileStruct_t {
char filename[STRING_LENGTH];
FILE *fp;
} FileStruct;

...

FileStruct file;
strncpy(file.filename, "nome_del_file.ext", STRING_LENGTH);
file.fp = fopen(...);


In questomodo hai sia il puntatore che il nome del file. Non è possibile, se non erro, conoscere il nome del file dal puntatore restituito dalla fopen, per come è implementato il tutto.

[ilsensine]

No, non è possibile. La struttura FILE è una struttura "opaca" (cioè il programmatore non dovrebbe ficcarci dentro il naso ;) ) il cui contenuto, in termini di campi, può variare da piattaforma a piattaforma e -ciliegina sulla torta- non contiene alcuna informazione sul nome del file aperto.
No, ma si può ottenere in maniera indiretta. Purtroppo questo non è portabile e dipende dal s/o (ho una idea di come farlo su linux, ad esempio).

Se non ho capito male però, uReverendo parla di "un'altro programma", il che complica le cose...

[sottovento]

Ciao, avendo un puntatore ad una struttura FILE come è possibile recuperare il nome del file?
Ovviamente il file lo apre un'altro programma con la funzione fopen.


Sotto UNIX:
Utilizzando la fileno () ti puoi far ritornare il descrittore (come se avessi aperto il file con la open()). Dopo di che puoi usare la fstat() per ottenere l'i-node.

Il passaggio da i-node a nome file non dovrebbe essere difficile. E' piu' facile se conosci la directory in cui il file risiede, ovviamente.

Sotto Windows:
Mi piacerebbe proprio saperlo. Il processo di cui sopra non e' applicabile

Spero in nell'intervento di qualcuno piu' preparato, visto che e' un problema interessante (soprattutto in caso di debug di codice altrui che si dimentica di chiudere una risma di file...)

[ilsensine]

Sotto UNIX:
Utilizzando la fileno () ti puoi far ritornare il descrittore (come se avessi aperto il file con la open()). Dopo di che puoi usare la fstat() per ottenere l'i-node.

Passare dall'inode al filename non è possibile, in quanto un inode può essere collegato a più filename (hard link) o a nessuno (unlink-after-open).

[-fidel-]

In windows ci sarebbe la GetModuleFilename, credo funzioni anche con i file, ma comunque vuole un HANDLE come paramentro, non un puntatore di tipo FILE, per questo non l'ho proposta.

Per linux anch'io conosco un metodo, ma si basa appunto sulle tabelle del SO, quindi non è portabile...

[uReverendo]

Fammi capire...il programma A apre un file, e il programma B deve capire (dal puntatore FILE * di A) di che file si tratta?Esatto...
No, non è possibile. La struttura FILE è una struttura "opaca" (cioè il programmatore non dovrebbe ficcarci dentro il naso ) il cui contenuto, in termini di campi, può variare da piattaforma a piattaforma e -ciliegina sulla torta- non contiene alcuna informazione sul nome del file aperto. Grazie x la risposta. Ma passando il puntatore FILE a fread lui si che lo trova il file :D Inoltre c'è un'utility "handle" di Mark Russinovich che fa un lavoro simile (restituisce gli handle (con i rispettivi nomi) dei file aperti)

[ilsensine]

Esatto...
Grazie x la risposta. Ma passando il puntatore FILE a fread lui si che lo trova il file :D
No, trova l'handle del file, scritto in maniera opaca nella struct FILE.
E comunque, in generale, un programma non ci fa niente con il puntatore FILE * di un altro programma. Si può tentare di aggirare anche questo ostacolo, ma si entra ancor più nel complicato e s/o-dipendente.

[andbin]

No, ma si può ottenere in maniera indiretta. Purtroppo questo non è portabile e dipende dal s/o (ho una idea di come farlo su linux, ad esempio).Se parli del descrittore del file, è probabile che sia fattibile ma è da vedere come e su quale S.O. (non c'ho mai provato ;) ).
Su linux anche io avrei una idea, magari stupida: dato il descrittore e il PID, andare in /proc/<num PID>/fd e vedere a cosa corrisponde il link che ha il numero del descrittore.

[uReverendo]

Per chiarirci l'applicazione che apre il file non l'ho scritta io (le sto facendo un debug). Inoltre lavoro su win2000.

[ilsensine]

Se parli del descrittore del file, è probabile che sia fattibile ma è da vedere come e su quale S.O. (non c'ho mai provato ;) ).
Su linux anche io avrei una idea, magari stupida: dato il descrittore e il PID, andare in /proc/<num PID>/fd e vedere a cosa corrisponde il link che ha il numero del descrittore.
Esattamente. Un veloce readlink e hai fatto.

[ilsensine]

Per chiarirci l'applicazione che apre il file non l'ho scritta io (le sto facendo un debug). Inoltre lavoro su win2000.
Spero ti rendi conto che è una impresa titanica, se non hai i sorgenti del programma.

[sottovento]

Passare dall'inode al filename non è possibile, in quanto un inode può essere collegato a più filename (hard link) o a nessuno (unlink-after-open).

E' infatti questo la potenza degli i-node, no? Lo stesso file riferito da piu' filename. Volendo li si puo' trovare tutti

Purtroppo il problema e' da risolvere su win 2000, e su questa piattaforma mi sembra un problemone.

Buona notte a tutti
High Flying
Sottovento

[uReverendo]

Spero ti rendi conto che è una impresa titanica, se non hai i sorgenti del programma.Certo che lo so e collegare le strutture FILE ai nomi mi agevolerebbe parecchio. Ho provato ad aprire un paio di file e ad analizzare la struttura FILE di ognuno e ho notato che l'unico membro a variare è _file che dovrebbe identificare il file univocamente.

[ilsensine]

Forse puoi ricavarti gli HANDLE aperti dal processo...fidel?

[-fidel-]

Forse puoi ricavarti gli HANDLE aperti dal processo...fidel?

Se hai l'Handle al processo, basta usare la EnumProcesModules() di psapi.h (psapi.dll).
L'Handle al processo la si ricava facilmente, ad esempio con una EnumProcesses(), seguita da una OpenProcess()

EDIT: ancora meglio!! C'è una bella funzione che si chiama GetMappedFileName(). Basta passare come parametro l'Handle al processo in questione e l'indirizzo da verificare, e se questo si riferisce ad un file caricato dal processo (quindi già aperto), copia in un buffer (passato sempre come parametro) il nome del file.
La descrizione completa è qui ad esempio:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getmappedfilename.asp

[ilsensine]

EDIT: ancora meglio!! C'è una bella funzione che si chiama GetMappedFileName(). Basta passare come parametro l'Handle al processo in questione e l'indirizzo da verificare, e se questo si riferisce ad un file caricato dal processo (quindi già aperto), copia in un buffer (passato sempre come parametro) il nome del file.
La descrizione completa è qui ad esempio:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getmappedfilename.asp
No funziona solo con i file in mmap...

[-fidel-]

No funziona solo con i file in mmap...

...e comunque serve a poco, per un problema di fondo. Ho appena provato, ma la EnumProcessModules elenca, come sospettavo, solo le DLL caricate...
Purtroppo non elenca alcun handle riferito ad un file aperto...

Stavo pensando di usare i performance object, ma psapi fornisce le stesse funzionalità (per questo non li uso da secoli). Magari in quel modo si ricava qualcosa, ma dubito.

E' un grosso problema questo...

[cionci]

Obtaining a File Name From a File Handle

The following example obtains a file name from a file handle using a file mapping object. It uses the CreateFileMapping and MapViewOfFile functions to create the mapping. Next, it uses the GetMappedFileName function to obtain the file name. For remote files, it prints the device path received from this function. For local files, it converts the path to use a drive letter and prints this path. To test this code, create a main function that opens a file using CreateFile and passes the resulting handle to GetFileNameFromHandle.



#include <windows.h>
#include <stdio.h>
#include <tchar.h>
#include <string.h>
#include <psapi.h>

#define BUFSIZE 512

BOOL GetFileNameFromHandle(HANDLE hFile)
{
BOOL bSuccess = FALSE;
TCHAR pszFilename[MAX_PATH+1];
HANDLE hFileMap;

// Get the file size.
DWORD dwFileSizeHi = 0;
DWORD dwFileSizeLo = GetFileSize(hFile, &dwFileSizeHi);

if( dwFileSizeLo == 0 && dwFileSizeHi == 0 )
{
printf("Cannot map a file with a length of zero.\n");
return FALSE;
}

// Create a file mapping object.
hFileMap = CreateFileMapping(hFile,
NULL,
PAGE_READONLY,
0,
1,
NULL);

if (hFileMap)
{
// Create a file mapping to get the file name.
void* pMem = MapViewOfFile(hFileMap, FILE_MAP_READ, 0, 0, 1);

if (pMem)
{
if (GetMappedFileName (GetCurrentProcess(),
pMem,
pszFilename,
MAX_PATH))
{

// Translate path with device name to drive letters.
TCHAR szTemp[BUFSIZE];
szTemp[0] = '\0';

if (GetLogicalDriveStrings(BUFSIZE-1, szTemp))
{
TCHAR szName[MAX_PATH];
TCHAR szDrive[3] = TEXT(" :");
BOOL bFound = FALSE;
TCHAR* p = szTemp;

do
{
// Copy the drive letter to the template string
*szDrive = *p;

// Look up each device name
if (QueryDosDevice(szDrive, szName, BUFSIZE))
{
UINT uNameLen = _tcslen(szName);

if (uNameLen < MAX_PATH)
{
bFound = _tcsnicmp(pszFilename, szName,
uNameLen) == 0;

if (bFound)
{
// Reconstruct pszFilename using szTemp
// Replace device path with DOS path
TCHAR szTempFile[MAX_PATH];
_stprintf(szTempFile,
TEXT("%s%s"),
szDrive,
pszFilename+uNameLen);
_tcsncpy(pszFilename, szTempFile, MAX_PATH);
}
}
}

// Go to the next NULL character.
while (*p++);
} while (!bFound && *p); // end of string
}
}
bSuccess = TRUE;
UnmapViewOfFile(pMem);
}

CloseHandle(hFileMap);
}
printf("File name is %s\n", pszFilename);
return(bSuccess);
}


Preso dal Paltform SDK...
Purtroppo c'è un problema...bisogna avere l'handle :stordita:

[trallallero]

Preso dal Paltform SDK...
Purtroppo c'è un problema...bisogna avere l'handle :stordita:
e questo comunque risolverebbe solo su Windows.
M'avete incuriosito, problema interessante :D

[-fidel-]

Purtroppo c'è un problema...bisogna avere l'handle :stordita:

Già, alla fine è quello il problema, trovare il nome del file tramite l'handle è facile con la GetMappedFileName(), come esposto in precedenza. Io non riesco ad ottenere l'handle con la EnumProcessModules, ma solo le DLL caricate (e quindi i nomi files delle DLL). Il perché è facilmente deducibile (dato che l'handle al file si riferisce allo spaziodegli indirizzi del processo target, non del kernel, a differenza delle DLL).
Ho però pensato ad una strategia: iniettare il codice che fa la GetMappedFileName() nel processo. L'handle al file, in questo modo, sarà accessbile, dal momento che il nostro programma iniettato si troverà nello stesso spazio indirizzi dl progcesso target. Il valore dell'handle non è di solito un problema: il SO tende a restituire sempre lo stesso handle se apriamo lo stesso file in due chiamate successive del programma target. Quindi:
1) Lanciare il programma target e estrarre con un debugger l'handle interessato
2) Usare il valore di questo handle "hardcoded" nel nostro programma (nella GetMappedFileName()).
3) lanciamo di nuovo il programma target: con MOLTA probabilità, quando questo aprirà il file, l'handle al file sarà lo stesso del punto 1)
4) Iniettare il nostro codice nel programma target (fattibilissimo se il nostro programma risiede in una DLL).
5) Fatto :)

Appena ho tempo provo, ma credo funzioni senza problemi.

EDIT: nel caso specifico, il problema ulteriore è che non abbiamo neanche l'handle al file, ma un classico puntatore FILE*...

[trallallero]

Già, alla fine è quello il problema, trovare il nome del file tramite l'handle è facile con la GetMappedFileName(), come esposto in precedenza. Io non riesco ad ottenere l'handle con la EnumProcessModules, ma solo le DLL caricate (e quindi i nomi files delle DLL). Il perché è facilmente deducibile (dato che l'handle al file si riferisce allo spaziodegli indirizzi del processo target, non del kernel, a differenza delle DLL).
Ho però pensato ad una strategia: iniettare il codice che fa la GetMappedFileName() nel processo. L'handle al file, in questo modo, sarà accessbile, dal momento che il nostro programma iniettato si troverà nello stesso spazio indirizzi dl progcesso target. Il valore dell'handle non è di solito un problema: il SO tende a restituire sempre lo stesso handle se apriamo lo stesso file in due chiamate successive del programma target. Quindi:
1) Lanciare il programma target e estrarre con un debugger l'handle interessato
2) Usare il valore di questo handle "hardcoded" nel nostro programma (nella GetMappedFileName()).
3) lanciamo di nuovo il programma target: con MOLTA probabilità, quando questo aprirà il file, l'handle al file sarà lo stesso del punto 1)
4) Iniettare il nostro codice nel programma target (fattibilissimo se il nostro programma risiede in una DLL).
5) Fatto :)

Appena ho tempo provo, ma credo funzioni senza problemi.

EDIT: nel caso specifico, il problema ulteriore è che non abbiamo neanche l'handle al file, ma un classico puntatore FILE*...
ma se debuggi con VC non riesci a capire quello che fa sta benedetta GetMappedFileName() ?
mi ricordo che con il debugger, funzione stepin, si andava a finire in sorgente di windows PIENO di :Puke: goto

[cionci]

"Ever wondered which program has a particular file or directory open? Now you can find out. "
http://www.sysinternals.com/Utilities/Handle.html

[uReverendo]

Già, alla fine è quello il problema, trovare il nome del file tramite l'handle è facile con la GetMappedFileName(), come esposto in precedenza. Io non riesco ad ottenere l'handle con la EnumProcessModules, ma solo le DLL caricate (e quindi i nomi files delle DLL). Il perché è facilmente deducibile (dato che l'handle al file si riferisce allo spaziodegli indirizzi del processo target, non del kernel, a differenza delle DLL).
Ho però pensato ad una strategia: iniettare il codice che fa la GetMappedFileName() nel processo. L'handle al file, in questo modo, sarà accessbile, dal momento che il nostro programma iniettato si troverà nello stesso spazio indirizzi dl progcesso target. Il valore dell'handle non è di solito un problema: il SO tende a restituire sempre lo stesso handle se apriamo lo stesso file in due chiamate successive del programma target. Quindi:
1) Lanciare il programma target e estrarre con un debugger l'handle interessato
2) Usare il valore di questo handle "hardcoded" nel nostro programma (nella GetMappedFileName()).
3) lanciamo di nuovo il programma target: con MOLTA probabilità, quando questo aprirà il file, l'handle al file sarà lo stesso del punto 1)
4) Iniettare il nostro codice nel programma target (fattibilissimo se il nostro programma risiede in una DLL).
5) Fatto :)

Appena ho tempo provo, ma credo funzioni senza problemi.

EDIT: nel caso specifico, il problema ulteriore è che non abbiamo neanche l'handle al file, ma un classico puntatore FILE*...Mi intriga parecchio la cosa... anche se mi rendo conto ho molto da studiare. :cry:
"Ever wondered which program has a particular file or directory open? Now you can find out. "
http://www.sysinternals.com/Utilities/Handle.html Se leggi il mio secondo messaggio quella utility la conosco ;) ma non risolve il problema.
Analizzando la libreria MSVCRT.DLL ho notato che:
MSVCRT.DLL alloca un vetore di tipo __pioinfo(almeno credo :D )
Quando viene chiamato fopen:
recupera dal vettore una struttura non utilizzata
la marca come utilizzata e salva l'indice
chiama "createfile" e salva l'HANDLE nei primi 4 BYTE di questa struttura.
RESTITUISCE LA STRUTTURA FILE CONTENENTE NEL CAMPO _file l'indice del vettore di strutture __pioinfo
quando viene chiamato fread:
recupera l'indice del vettore (FILE->_file)
recupera l'HANDLE del file dalla struttura
chiama fileread
Quindi se non ho scritto troppe cavolate il mio programma dovrebbe:
recuperare il puntatore al vettore allocato da MSVCRT (lo puo trovare facilmente un debugger)
recuperare la struttura all'indice FILE->_file e leggere l'HADLE
utilizzare la funzione postata da cionci per recuperare il nome del file
Si può fare?

[-fidel-]

ma se debuggi con VC non riesci a capire quello che fa sta benedetta GetMappedFileName() ?
mi ricordo che con il debugger, funzione stepin, si andava a finire in sorgente di windows PIENO di :Puke: goto

Ma a te basta conoscere l'handle del file aperto, il quale viene passata al tuo codice (nella GetMappedFileName()). Con il debugger devi solo andare nel programma target per recperare l'handle del file, dal quale poi recupererai il nome con la GetMappedFileName().

[-fidel-]

Mi intriga parecchio la cosa... anche se mi rendo conto ho molto da studiare. :cry:
Se leggi il mio secondo messaggio quella utility la conosco ;) ma non risolve il problema.
Analizzando la libreria MSVCRT.DLL ho notato che:
MSVCRT.DLL alloca un vetore di tipo __pioinfo(almeno credo :D )
Quando viene chiamato fopen:
recupera dal vettore una struttura non utilizzata
la marca come utilizzata e salva l'indice
chiama "createfile" e salva l'HANDLE nei primi 4 BYTE di questa struttura.
RESTITUISCE LA STRUTTURA FILE CONTENENTE NEL CAMPO _file l'indice del vettore di strutture __pioinfo
quando viene chiamato fread:
recupera l'indice del vettore (FILE->_file)
recupera l'HANDLE del file dalla struttura
chiama fileread
Quindi se non ho scritto troppe cavolate il mio programma dovrebbe:
recuperare il puntatore al vettore allocato da MSVCRT (lo puo trovare facilmente un debugger)
recuperare la struttura all'indice FILE->_file e leggere l'HADLE
utilizzare la funzione postata da cionci per recuperare il nome del file
Si può fare?

E' quello che voglio fare io, il fatto è che l'handle al file è rrelativo allo spazio indirizzi del processo, quindi se passi l'handle al tuo programma (che gira in un suo spazio dei processi) quell'handle è inutilizzabile. Provo a fare l'injection e vediamo, vi faccio sapere a breve.

[trallallero]

ho trovato un sito che ne parla e dice NO :nonsifa: :
www.thescripts.com/forum/thread473896.html

anche se io lo devo vedere con il translate di google perché non mi ci fa andare sta cacchio di rete chiusa :muro:

[-fidel-]

ho trovato un sito che ne parla e dice NO :nonsifa: :
www.thescripts.com/forum/thread473896.html

anche se io lo devo vedere con il translate di google perché non mi ci fa andare sta cacchio di rete chiusa :muro:

...e invece sì :D L'ho appena fatto, dopo qualche tentativo (e un errore banale che non vedevo) ci sono riuscito ;)
Ho usato il metodo della dll injection descritto prima.

EDIT: la mia DLL prende l'handle al file aperto dal programma target (è hardcoded, lo devi sapere a priori, ma è facile con un quualunque debugger), lo mappa e dal mapped-file recupera il nome.
La DLL va iniettata nel programma target ovviamente.

[trallallero]

...e invece sì :D L'ho appena fatto, dopo qualche tentativo (e un errore banale che non vedevo) ci sono riuscito ;)
Ho usato il metodo della dll injection descritto prima.

EDIT: la mia DLL prende l'handle al file aperto dal programma target (è hardcoded, lo devi sapere a priori, ma è facile con un quualunque debugger), lo mappa e dal mapped-file recupera il nome.
La DLL va iniettata nel programma target ovviamente.
beh, bravo :mano: :)
ma su quel forum dicono che non é possibile tramite il pointer FILE * che poi é quello che serve all'autore del 3d. O sbaglio ?

[-fidel-]

beh, bravo :mano: :)
Grazie :)

ma su quel forum dicono che non é possibile tramite il pointer FILE * che poi é quello che serve all'autore del 3d. O sbaglio ?

Guarda, per quello che mi risulta, su Win32 la fopen fa da wrapper per la CreateFile, quindi chiamando fopen() in realtà stai chiamando CreateFile(), che restituisce un HANDLE. Non credo sia difficile recuperare l'handle dal puntatore FILE*.

EDIT: Ah, vedo che uReverendo ha già visto questo fatto della fopen() che chiama CreateFile, quindi non credo proprio sia un problema recuperare l'handle dalla fopen() :)
Ora vado finalmente a mangiare qualcosa...

EDIT2: dopo "pranzo" posto il codice.

[ilsensine]

ma su quel forum dicono che non é possibile tramite il pointer FILE * che poi é quello che serve all'autore del 3d. O sbaglio ?
Dice che non è possibile con metodi standard (ed è vero).

[71104]

Guarda, per quello che mi risulta, su Win32 la fopen fa da wrapper per la CreateFile, quindi chiamando fopen() in realtà stai chiamando CreateFile(), che restituisce un HANDLE. Non credo sia difficile recuperare l'handle dal puntatore FILE*. infatti è facile, ma il modo in cui lo fai cambia da un compilatore all'altro.

[trallallero]

Guarda, per quello che mi risulta, su Win32 la fopen fa da wrapper per la CreateFile, quindi chiamando fopen() in realtà stai chiamando CreateFile(), che restituisce un HANDLE. Non credo sia difficile recuperare l'handle dal puntatore FILE*.
Win qua ... Win la ... eccheppalle sto Win :muro:
la tecnologia va avanti ed io sto ancora col pro*c, fopen() e :Puke: vi :muro:

[-fidel-]

Ok, tempo di codice.

Allego due programmi compilati ed un sorgente.

Il semplice programma TestFile.exe crea un file in C:\, ne stampa l'handle
e attende la pressione di un tasto. A noi interesa ovviamente l'handle (che sul
mio pc è sempre 0x01C).
Lanciate il programma ed aspettate prima di concluderlo :)

Il programma DllInjection.exe si occupa di iniettare la nostra DLL nel processo
da noi richiesto. Il nome del processo viene chiesto all'utente.
NOTA: La DLL da iniettare deve trovarsi nella stessa cartella in cui si trova DllInjection.exe.
Lanciate il programma ed inserite come nome processo testfile.exe (in questo caso).

Il sorgente "FileName DLL source" contiene il progetto VS .NET 2003 della nostra DLL (potete compilarla con qualunque altro IDE ovviamente, basta aggiungere psapi.lib alle dipendenze del linker, se mancante).
Prima di compilarla, correggete se necessario il valore di "hFile", così che corrisponda all'indirizzo stampato da TestFile.exe.

Ricapitolando:

1) Lanciate TestFile.exe, e prendete nota dell'indirizzo stampato (è normalmente sempre lo stesso ad ogni esecuzione).
2) Correggete se necessario il valore di "hFile" nel sorgente della DLL e compilatela.
3) Copiate la DLL compilata nella cartella in cui risiede DllInjector.exe
4) Lanciate DllInjector.exe e scrivete il nome del processo testfile.exe quando richiesto.

Nel prossimo post (data la limitazione del forum...) allego anche la DLL compilata (con hFile = 0x0000001C).

EDIT: riallegato DllInjection.zip (ora più efficiente, e corretto un errore che avevo inserito appositamente :D)

EDIT 2: Il sorgente della DLL è settato per la compilazione in modalità "Release" (nell'IDE VS .NET 2003). Cambiatela pure in "Debug" se volete debuggare la DLL in esecuzione.

[-fidel-]

Ecco anche la DLL già compilata.
In questa DLL, il valore di hFile è 0x0000001C (che è quello che si presenta sempre sul mio PC ad ogni esecuzione di TestFile.exe: usate direttamente questa (senza necessità di compilarla) se TestFile.exe dà anche a voi 0x0000001C come handle del file).

[uReverendo]

Grazie mille -fidel- lo provo subito.

P.S. Sei un mito :)

[-fidel-]

Grazie mille -fidel- lo provo subito.

P.S. Sei un mito :)

Troppo buono :)
Ah, occhio che ho appena riallegato DllInjection.zip... Se lo hai già scaricato, riscaricalo ;)