Hin und wieder findet man bei einem interessanten Programm ja eine zugehörige DLL-Datei, die einen dazu verlocken könnte, sie in eigenen Programmen selbst zu nutzen.
Die Funktionsnamen, die eine solche nach außen hin anbietet habe ich ja noch herausfinden können, z.B. mittels TDUMP von Borland/Codegear.
Leider aber dann eben doch nicht mehr.
Super wäre natürlich, wenn es ein Tool gäbe, das die Funktionsheader-Declaration liefern könnte. Diese könnte man dann in sein C-File übernehmen, die entsprechende Fkt. aufrufen und somit nutzen.
Soweit ich weiß, sind bei .NET oder COM-Funktionsbibliotheken die Eingangs/Ausgangstypen immer ersichtlich, oder? Sind dies dann auch DLL-Files? Oder haben diese eine andere Endung?
Kann ein halbwegs kundiger Assembler-Programmierer die Typen / Anzahl der Argumente / Größe der Argumente/eines Arguments/Rückgabewertes aus dem Assemblercode ersehen?
Danke und Grüße,
Mdl
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
Hi Mdl, probier es mal mit strace. strace kommt aus der linux welt, läuft aber mittels cygwin zb auch unter windows. das programm zeigt dir an, wann welche funktion mit welchen parametern aufgerufen wird. Das ist einerseits nützlich, um die ursachen von segfaults zu finden, andererseits kannst du damit eben auch die von DLLs exportierten funktionen debuggen. ein beispieloutput sieht zb so aus:
strace ./control-ng
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=20694, ...}) = 0
mprotect(0x2abde000, 4096, PROT_READ) = 0
mprotect(0x2aaec000, 4096, PROT_READ) = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
brk(0) = 0x41b6d4
brk(0x41c6d4) = 0x41c6d4
brk(0x41d000) = 0x41d000
open("/var/tmp/rs.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
ioctl(3, TIOCNXCL, 0x7fff7c48) = -1 ENOTTY (Inappropriate ioctl for device)
write(3, "1"..., 1) = 1
close(3) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
open("/etc/resolv.conf", O_RDONLY) = 4
ioctl(4, TIOCNXCL, 0x7fff7a68) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "nameserver 127.0.0.1\n"..., 4096) = 21
read(4, ""..., 4096) = 0
close(4) = 0
open("/etc/hosts", O_RDONLY) = 4
ioctl(4, TIOCNXCL, 0x7fff7a90) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "127.0.0.1 localhost.\n"..., 4096) = 21
read(4, ""..., 4096) = 0
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
send(4, "\0\2\1\0\0\1\0\0\0\0\0\0\nrapidshare\3com\0\0\1\0\1"..., 32, 0) = 32
_newselect(5, [4], NULL, NULL, {10, 0}) = 1 (in [4], left {10, 0})
recv(4, "\0\2\201\200\0\1\0\25\0\0\0\0\nrapidshare\3com\0\0\1\0\1\300"..., 512, 0) = 368
close(4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("195.122.131.20")}, 16) = 0
send(3, "GET /files/271463773/OpenWrt-i386"..., 91, 0) = 91
wie du siehst zeigt er die parameter an funktionen an. zwar zeigt er die im klartext an, aber das sollte nicht allzu problematisch sein, den datentyp kann man sich dann in der regel auch selbst rausfinden
man muss schon unterscheiden zwischen nativen library dll's und com inproc servern sprich com dll's
wenn man sich vs 6 installiert ist alles drin in den vs6 dienstprogrammen.
vc++6 kann zumindest bei com dll's einen client wrapper generieren.
für .net programme gibts zum beispiel den reflector,da ist es besonders einfach.
ansonsten stellt sicht sich die rechtliche frage bei fremdverwendung.
Danke für Eure Antworten.
@Syntetic_codes
STrace scheint ja recht gut zu sein.
Habe damit mal ein eigenes Programm aufgerufen, das eine DLL importiert, bin aber noch nicht so recht damit klargekommen. Muss mich also nochmals damit beschäftigen...
@PaoloP
Ich selbst bin noch nicht bei .NET angekommen... Aber diese klare Ersichtlichkeit bei den COM-DLLs macht schon Sinn. Eine falsche Version bei den Win32-.DLLs mit veränderten Parametern führt dann zum Absturz...
Die rechtliche Frage ist natürlich auch interessant:
Insbesondere vielleicht:
1) Eigene Verwendung einer DLL eines lizensierten Programms legal?
2) Eigene Verwendung einer DLL eines nicht-lizensierten Programms, das sich aber legal auf dem eigenen Rechner befindet, z.B. Trial-Version, deren DLL aber deren Ende nicht checkt...
3) Verwendung der DLL in einem öffentlichen Programm, ohne aber die DLL selbst mitzuliefern. Bei LAME.DLL ist dies ja oft der Fall: die liegt den Programmen, die sie benutzen ja oft gar nicht bei...
Gruß,
Mdl
Für Win32 DLL's hat der liebe Gott je den DependencyWalker erfunden.
Rechtlich würd ich nag dem Gefühl gehen das mir sagt: Wenn nirgendwo klar steht das es beliebig
weiterverwendet werden darf muss ich den Autor fragen. Für private/interne Programme nimmt man
das vermutlich nicht so genau. Oft sehe ich bei kleinen Programmen im Credit Screen einen Hinweis auf DLL xy von HansHubertSowieso. Das aber z.b. Adobe dir nicht zugestehen wird ihre DLL's zu verwenden davon kannst du fest ausgehen.