Newsgroup: it.comp.programmare.win32
Titolo: Da un handle al nome e al PID

Dispongo dell'handle di un file aperto. Esistono metodi piu` o meno
documentati per risalire al PID del processo che l'ha aperto, e al path
del file?
---
Bye! Lorenzo Lutti
http://antani.virtualave.net/

del file?
[fatti i fatti tuoi mode off]
scusa ma una domanda mi viene spontanea... come fai a possedere un
handle valido per un kobject aperto/creato da un'altro processo ? 
stai scrivendo un API logger, un IFS hook o filter driver ?
o stai sperimentando la queryapi di NT/2k ?
[fatti i fatti tuoi mode on]
cmq AFAIK solo vie non ducumentate.. in pratica si tratta di
deferenziare il kobject (che implica un KM o codice a r0) cui si
riferisce l'handle.. e prelevare da li le informazioni che cerchi.
PID, path/symlink, ecc dalla struct utilizzata dal kernel stesso..
insomma una implentazione in senso inverso a quella f.e. di Nthandle
che trovi su sysinternal (li si utilizza la query api x enumerare gli
handle e quindi ObReferenceObjectXXX  in un KM driver x "dumparli").
Inoltre in un numero di WDJ - ora non ricordo quale - era proposto un
sistema + semplice x ottenere il path partendo da un handle valido
(duplicato).. ma cmq presupponeva NT/2k e non ritornava informazioni
relative al PID/TID del creator..
Saluti,
            Walker Boh

 relative al PID/TID del creator..
Questo mi interessa molto, ho cercato su WDJ ma non ho trovato cio` che
dici... il PID non e` un problema, ci pensa gia` NtlTableHandle() a
dirmelo. Spremiti un po' le meningi, tenta di ricordare il titolo. :)
P.S. Giusto per curiosita`, ti spiego perche` devo fare questa cosa: il
mio sistema ha un malfunzionamento strano che nessuno e` riuscito a
risolvermi, quindi come al solito mano al compilatore. :)
In pratica molte volte restano delle copie "fantasma" dei socket aperti
dalle applicazioni, che magari non sono stati chiusi correttamente o
cose simili. Se lancio netstat -na ho una trafila di socket in LISTEN,
che in realta` sono morti e non dovrebbero dare problemi di sicurezza;
ciononostante mi occupano delle porte che magari devo riutilizzare.
Ciappinando un po' ho scoperto che gli handles dei socket fantasma sono
posseduti dal processo system (PID numero 2). Piu` in particolare, sono
handles ai devices \device\tcp o \device\udp. Quindi voglio fare un
programma che fa lo scan di tali handles all'avvio del sistema, e che
permetta a mio comando di chiudere quelli aperti in un secondo tempo. Ma
ovviamente non posso chiudere tutti i nuovi handles di system, non
sarebbe molto igienico. :)
Contorto, eh? :)


sarebbe molto igienico. :)
k.. hai ben illustrato la questione.. ed e' un problema annoso.. un
possibile work-around che mi viene in mente :
x enumerare gli handles ( x sistema o per processo), come del resto
gia' fai, si puo' utilizzare NtQuerySystemInformation e
NtQueryInformationProcess/Thread... per conoscerne la natura (ed a
secondo dal type path; x i sockets, come hai visto, si risolve su
\device\tcp,\device\udp, \device\rawip, ecc..) si puo' usare
NtQueryObject ed NtQueryObjectLink (se dissassembli nthandle/handleex
li vedrai utilizzati).. il problema semmai resta l'owner(s), intendo
dire il PID del processo/i thread/s che hanno handle aperti a quell
kobj.. o ti basi sulla "snapshot" di QuerySysxx e fai un analisi
"incrociata".. oppure "dumpi" il singolo handle .. ma come si diceva
e' necessario scrivere un KM driver ed andare a prendersi tutte le
info direttamente nelle struct che descrivono l'obj.
In ogni caso buon lavoro.
Saluti,
 
           Walker Boh
p.s. non so se hai intenzione di acquistare "Native...",  cmq x
reperire i prototypes/structs/info_class di cui sopra, oltre al DDK
ofcoz, puoi utilizzare quest' header
http://www.acc.umu.se/~bosse/ntifs.h

 
http://www.acc.umu.se/~bosse/ntifs.h
Mi hai dato un sacco di spunti interessanti, spero di sdebitarmi in futuro.
