Newsgroup: it.comp.programmare.win32
Titolo: Lista funzioni in DLL aliena

Mi piacerebbe sapere se esiste un metodo per ottenere la lista dei nomi
delle funzioni presenti in una DLL e dei relativi parametri di chiamata.
Tramite un hex editor si puo' capire abbastanza bene quali siano i nomi
delle funzioni definite, ma il problema rimane l'identificazione dei
parametri e dei valori di ritorno.
Esiste gia' un tool per fare questo ?
Mik
--



Ciao,
per i paramentri e i valori di ritorno che io sappia no (ma non ho
molta esperienza in merito).
La lista delle funzioni pero' la puoi ottenere più comodamente usando
il Dependency Walker, sia per avere la lista dei nomi, sia per avere
l'elenco delle DLL che sono richiamate da quella che stai analizzando.
Ciao!
Stefano "HappyMan" 
--
IABLA Sezione Lago Maggiore (NO)
Web 
http://happyman.n3.net
 [Foto salseri/e & I.A.B.L.A. Ring]
Email: 
happyman...@libero.it
 [Togliere nospam per scrivermi]

Stefano "HappyMan" 
no, questo genere di informazioni se non fa revere engineering di una
dll non le può ottenere
IDA permette di fare una cosa del genere, ma poi non sa a cosa servono
quei parametri...
cod

 dll non le può ottenere
Per i parametri delle funzioni, OK, non so se siano pubblici.
Ma la lista delle funzioni esportate e' ottenibilissima.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Ma la lista delle funzioni esportate e' ottenibilissima.
Non avrebbe senso se ci fossero i parametri: una volta compilato il
codice c, i parametri non esistono più!
Se qualcuno ha mai programmato in assembler (io no... ma so qualcosa),
saprebbe che non esistono le "chiamate a funzioni" che ritornano un
valore, ne i parametri. Per questo esistono i file .h che definiscono
dettagliatamente una funzione con i parametri, il valore di ritorno e
lo standard di chiamata (cdecl,stdcall,thiscall...)
Spero di non aver detto un mare di ca..ate :)
Ciao
--
The Secret of Tabboz Island
http://it.geocities.com/tabbozisland

codice c, i parametri non esistono più!
I parametri sono deducibili se il codice è c++ e i nomi sono stati
decorati, questo avviene se non si usa extern "C" (o qualche opportuna
impostazione del compilatore). In altri casi non penso sia possibile.
-- 
Marco Barisione (ICQ 84277092)

codice c, i parametri non esistono più!
Credo che la scelta di non inserire anche informazioni sui
parametri sia stata fatta perche' non e' possibile fare un
controllo dinamico sull'esattezza dei tipi passati alle
funzioni, mentre e' strettamente necessario conoscere quali
funzioni sono esportate da una DLL per potersi agganciare ad
una di esse.
-- 
The Follet

decorati
Pressoche' impossibile.
Il metodo di decorazione dei nomi di ciascun compilatore C++
puo' essere sconosciuto e, nella maggiorparte dei casi,
quando si scrive una DLL si abolisce la decorazione dei nomi
(per compatibilita' con gli altri linguaggi).
-- 
The Follet

(per compatibilita' con gli altri linguaggi).
Sì lo so intendevo proprio dire che è una cosa rara trovare funzioni
esportate con decorazione non solo per compatibilità con altri
linguaggi ma anche con lo stesso C++, proprio perché ogni compilatore
fa quello che vuole.


 impostazione del compilatore).
Se si esporta con WINAPI il nome della funzione è seguito da @ + il numero
di dword passate sullo stack. Nota bene - non il numero di parametri, solo
quante dword ci sono sullo stack. Poi o si fa reverse engineering, o si tira
a indovinare.
Ciao,
Zello


a indovinare.
Con quale compilatore ?
-- 
The Follet

Con quale compilatore ?
Tutti. Le cdecl diventano _nomefunzione, le pascal _NOMEFUNZIONE, le 
stdcall _nomefunzione@stacksize. Ma generalmente il linker fa poi 
pulizia

pulizia
Non ti offendere, ma hai frainteso.
Non si sta parlando di nomi non decorati (la compilazione in
underscore + identificatore e' tipica del C), ma di nomi
decorati dai compilatori C++.
Non c'e' un metodo standard (percio' chiedevo di specificare
il compilatore) di fare un reverse engineering per risalire
dal nome decorato da un compilatore C++ ai parametri della
funzione.
-- 
The Follet


Beh, a prescindere dal compilatore, a meno che non ci siano le info di
debug, tutto quello che hai e' il codice macchina.
Anche se ci fossero le info di debug, poi, le quali si' sono specifiche del
compilatore, non sarebbe comunque facile fare il reverse engineering del
compilato...
Vorrei farti notare che ti agganciavi ad una esportazione WINAPI, percui i
nomi decorati C++ sono gia' andati persi...
Ciaotutti,
*

nomi decorati C++ sono gia' andati persi...
In che senso ? WINAPI e' solo una direttiva che informa il
compilatore sulla modalita' di passaggio dei parametri, non
dice nulla sull'abolizione della eventuale decorazione.
-- 
The Follet

 dice nulla sull'abolizione della eventuale decorazione.
Sicuro? Non sono andato a controllare documentazioni varie, ma le risposte
di Hyperion sono generalmente affidabili :)
Ciaotutti,
*

Sicuro? 
Si'.
-- 
The Follet

dice nulla sull'abolizione della eventuale decorazione.
Uffa. Tratto dalla guida di Borland C++: "The C, Pascal, and Register 
calling conventions differ in the way each handles stack cleanup, order 
of parameters, case, and prefix of global identifiers."
Borland C++ li decora così:
 - C:        _nomefunzione
 - Pascal:   NOMEFUNZIONE
 - Register: nomefunzione
 - Standard: nomefunzione
GCC (e credo anche Microsoft C++) così:
 - C:        _nomefunzione
 - Pascal:   <non supportata>
 - Register: <non supportata>
 - Standard: _nomefunzione@dimensionistack
Ovviamente questo compilando C, non C++. In modalità C++ ognuno dei tre 
compilatori decora i nomi secondo il proprio standard. Ad esempio, int 
__stdcall dummy(int) viene decorata come:
 - Borland C++:   @dummy$qqsi
 - Microsoft C++: ?dummy@@YGHH@Z
 - GCC:           _dummy__Fi@4
(e sarà meglio che ti basti, non hai idea di che viaggio ho dovuto fare 
per costruire a mano il valore decorato da MSC++)

compilatori decora i nomi secondo il proprio standard.
Quello su cui sto insistendo e' che non c'e' modo di
risalire da una decorazione di un nome C++ al numero e tipo
di parametri (proprio perche' ogni compilatore segue il suo
schema, che potrebbe essere proprietario e riservato). 
WINAPI e le convenzioni di passaggio dei parametri non
c'entrano nulla col problema.
-- 
The Follet