Newsgroup: it.comp.programmare.win32
Titolo: GetProcAddress per processo remoto

Saluti.
Quale è il modo per ottenere l'indirizzo di una procedura in un
determinato modulo, per un processo remoto?
Tutto quello che sono riuscito a fare è trovare l'indirizzo a cui è
mappata la DLL, con ToolHelp32.
Grazie  Manlio Perillo

Manlio Perillo <manlio_p...@SPAMlibero.it> wrote in news:_j_
6g.111164$
PR2.1...@twister2.libero.it
:

L'offset dovrebbe essere lo stesso e quindi, in funzione di dove è 
mappata la stessa DLL caricata nel tuo processo, potresti calcolarlo.
Però non puoi richiamarla.
In alternativa puoi "iniettare" una DLL nel processo remoto (ci sono 
diversi tutorial in merito) e fare in modo che sia questa DLL a 
richiamare GetProcAddress ed eventualmente a richiamare la funzione.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 
Io richiamo direttamente la funzione che mi interessa, senza bisogno di
DLL intermedie.
Sono riuscito a creare una funzione kill che si comporta come l'analogo
Posix, in grado cioè di mandare segnali ad un processo.
http://developer.berlios.de/projects/pykill32/
Contiene alcune "ingenuità" che correggerò entro poco.
Saluti  Manlio Perillo

 Però non puoi richiamarla.
se è compatibile col prototipo dell'entry point di un thread (4 bytes di
parametri, stack cleanup da parte della funzione chiamata) può usare
CreateRemoteThread
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
E' quello che faccio, la funzione raise della librerie MSVCR71.dll ha il
prototipo giusto.
Comunque, nessuno conosce il modo diretto per ricavare l'indirizzo delle
procedure importate in un processo?
Tra l'altro ho notato che alcuni processi importano sia la msvcrt.dll
che MSVCR71.dll (ed Explorer anche MSVCR80.dll!).
Saluti e grazie  Manlio Perillo

 chiamata) può usare CreateRemoteThread
Questo è vero.
Però il parametro passato non può essere un puntatore in memoria 
poichè questo farebbe riferimento al processo chiamante e non avrebbe 
nessun senso dentro il chiamato.


 nessun senso dentro il chiamato.
se gli serve di fare riferimento a qualcosa nel processo chiamato, e se ha
tutti i permessi di accesso necessari ad esso, puň usare VirtualAllocEx e
WriteProcessMemory per scrivercelo; oppure volendo (soluzione forse piů
semplice o piů performante in certi casi) un File Mapping Object.


 procedure importate in un processo?
guarda la mia ultima risposta a Valter Minute :)


 casi) un File Mapping Object. 
Il file mapping richiede che anche l'altro processo apra il mapping. Se 
il "giochetto" è fatto per richiamare una funzione pre-esistente dentro 
un altro processo di cui non puoi cambiare il codice, il metodo non 
funzionerebbe. Se, invece, il nostro amico ha accesso al codice, allora 
il file mapping è sicuramente la soluzione migliore.


 
Perfetto, grazie per la conferma.
Nel mio caso tutto quello che faccio è:
- prendere l'indirizzo della funzione "raise" della libreria "MSVCR71"
(facendo attenzione a prendere la versione più aggiornata??),
- eseguire un thread nel processo remoto che esegue raise con il tipo di
segnale passato come argomento.
In questo modo riesco ad emulare la funzione kill POSIX.


 il file mapping è sicuramente la soluzione migliore.
d'accordo, non puoi fare in modo che l'altro processo chiami direttamente
MapViewOfFile, ma puoi sempre usare VirtualAllocEx/WriteProcessMemory per
scrivere nell'altro processo il codice (position independent ovviamente)
che chiama MapViewOfFile :)
quale vantaggio ha la cosa dunque rispetto all'usare *solo*
VirtualAllocEx/WriteProcessMemory senza complicarsi la vita coi File
Mapping Objects? be', ricopiare 40 megabyte tali e quali nell'altro
processo non è proprio il massimo, mentre una chiamata a MapViewOfFile
richiede solo pochi bytes ^^
dipende insomma da quanto occupano i dati condivisi, if any.


 In questo modo riesco ad emulare la funzione kill POSIX.
interessante... ma il problema è che la emuli in un altro thread, e da
quel poco che ho imparato di Linux al corso di Laboratorio di Sistemi
Operativi ciò non è quello che avviene in Linux, dove in un programma
single-threaded posso dare per scontato che null'altro venga eseguito
contemporaneamente al mio signal handler.
in Win32 le notifiche asincrone tipo "interrupt" non esistono, a meno che
non usi un'APC (però non hai la certezza che il thread da interrompere
entri in stato di wait e la possa eseguire, e anche se lo facesse chi
chiama la kill potrebbe dover attendere molto) o a meno che non sospendi
tutti i thread, esegui il signal handler nel thread "clandestino" creato
da CreateRemoteThread, e poi li riesumi tutti. occhio a sospenderli
veramente: SuspendThread non fa altro che modificare un contatore, tu devi
assicurarti che quel contatore raggiunga il "valore di sospensione", e
devi anche salvare il valore originario per poi ripristinarlo a suon di
ResumeThread.


 [...]
Mai usato gli APC, la mia soluzione "sembra" funzionare e tanto mi basta.
Male che va ottengo gli stessi risultati di TerminateProcess... (o no?)


 Male che va ottengo gli stessi risultati di TerminateProcess... (o no?)
eh, no... male che vada il programma a cui mandi il signal avrà dei
problemi di sincronizzazione tra il thread che esegue l'handler e tutti
gli altri; se il programma è mono-threaded allora hai bisogno di
sincronizzare tutte le variabili usate dal thread primario e dall'handler
(mentre in Linux questo non è assolutamente necessario!).
e i problemi di sincronizzazione, a seconda della situazione, ne generano
altri delle specie più svariate; per esempio potresti scrivere dati senza
senso nei tuoi files, potresti inviare dati senza senso sui tuoi sockets,
e via dicendo. per non parlare poi ovviamente di quando l'handler accede a
memoria dinamicamente allocata con malloc che nel frattempo l'altro thread
sta deallocando con free... in tal caso un bel crash lo vedo garantito,
anche se non è detto che si verifichi immediatamente (dipende dalle
librerie di runtime del compilatore).


 [...] se il programma è mono-threaded [...]
MONO-THREADED??!? ma come mi è uscita questa...? :|
SINGLE-threaded, per Dio ^_^'
asd


 [...]


 MSVCR71 => multithread.
embe'? se a una tua variabile globale accedi da due thread diversi
contemporaneamente non ti salvi, indipendentemente dalla thread-safety del
runtime che usi. prova... :)


 
Ovvio.
Ma io chiamo una funziona, raise, che si suppone essere thread safe.
Saluti  Manlio Perillo

 Ma io chiamo una funziona, raise, che si suppone essere thread safe.
deve esserlo anche il signal handler registrato dal programma.



Almeno per programmi scritti con il frameword Twisted
http://twistedmatrix.com/trac/
lo č.
E di solito i server li scrivo con questo framework.
Grazie per la consulenza.
Manlio Perillo

 lo č.
non conosco Twisted, ma mi pare strano che della roba scritta in Python ti
permetta di installare signal handlers, che sono legati a determinati tipi
di piattaforme... Python non č cross-platform?


 
Si, ma, in generale, cross platform non vuole dire solo avere
funzionalità che funzionano ovunque ed allo stesso modo.
Infatti la libreria standard di Python contiene diverse cose specifiche
per le diverse piattaforme, ad esempio c'è un modulo per accedere al
registro di Windows.
Infine anche per le sole funzinalità Posix implementate anche su
Windows, quest'ultimo volentieri si comporta in modo diverso (ci
vorrebbe una guida a Windows per programmatori Posix).
Saluti  Manlio Perillo