dll parameters v. functie achterhalen

[rjsomeone]

Ik heb een dll, waarvan ik drie functies heb weten te achterhalen met de dependency walker (deze dll heeft dus geen library oid).

Nu wil ik eigenlijk de parameters van deze functie achterhalen.
Nou weet ik dat dat normaal niet kan, maar ik heb een programma hier dat de dll-functies correct aanroept. Nou dacht ik, als ik die dll vervang door een eigen fake-dll, dan moet ik toch kunnen zien wat er in die fake-dll wordt aangeroepen?

Nu de vraag: is dit mogelijk? en zo ja, hoe ?

[Delpix]

Parameters achterhalen van de functies in een dll was dacht ik vrijwel onmogelijk. Tenzij je de source/documentatie heb

[Soultaker]

Dat hangt van de DLL af. Als er C++ functies in staan, zijn deze 'gemangled' met typeinformatie, van wat voor argumenten er meegegeven worden. Als er 'normale' functies in staan, heb je die zekerheid niet, maar dan kun je nog wel kijken in de code van de applicatie die de library gebruikt, welke variabelen die op de stack zet. Het blijft dan echter gissen in hoeverre die allemaal voor die DLL function call bedoelt waren en wat nu precies de typen waren.

[rjsomeone]

Jah ik weet wat je wil zeggen.. Maar ik heb dus een ander programma, dat die dll correct aanroept.. en heb je geen mogelijkheid voor een dll om te zien wat er wordt aangeroepen?
Dan zou mijn fake-dll best kunnen werken. ?

de dll heet toaster.dll.. daar zitten 3 functies is:
stoptoaster
starttoaster
en queuetoast

Ik kan wel de dll(ja, da;s ook een dll, maar dan wel met typelibrary of hoe dat heet) die deze dll aanroept uploaden ergens, zou iemand er dan uitkomen?

[ Voor 37% gewijzigd door rjsomeone op 17-12-2002 22:55 ]

[LordLarry]

Functienamen zijn meestal geen probleem. Paramaters is een andere zaak. Als je machine code (assembly) heb je nog een kans. Anders gewoon vergeten

Als het een COM Library is en een TLB bevat kan je wel alles terughalen. Je hoeft er niets eens veel moeite voor te doen. Zelfs het vervangen zou een simpel klusje moeten zijn.

[ Voor 38% gewijzigd door LordLarry op 17-12-2002 22:58 . Reden: COM Lib ]

[rjsomeone]

Jah dat weet ik allemaal, daarom had ik ook dat plannetje bedacht.... maar kennelijk werkt dat dus ook niet.. jammerz...

[.oisyn]

DLL functies zijn meestal stdcall, en stdcall functies poppen hun eigen functieargumenten van de stack. Dus je kunt met een disassembler iig zien hoeveel bytes er op de stack nodig zijn. Denkend aan het feit dat een parameter meestal 4 bytes is (dat geldt voor char, short, int, long, float en pointers, vrijwel alles dus, aangezien doubles en 64 bits ints zo goed als niet worden gebruikt), kun je er ook het aantal parameters uit halen

wat ze voorstellen... tja, das een andere vraag

[madwizard]

Open het programma met ollydbg of je favoriete debugger en zet een breakpoint op de dll functies (in ollydbg gewoon ctrl+g, functie invullen, ok en F2 voor een breakpoint). Dan het programma runnen en wachten tot de functie aangeroepen wordt. De parameters staan dan op de stack vanaf esp+4. Zoals .oisyn al zei schonen stdcall functies zelf de parameters op dus kan je waarschijnlijk wel zien hoeveel parameters er gegeven zijn. Anders kan je ook bij de call zelf kijken of je er wat zinnings uit kunt halen.

[Verwijderd]

ik neem aan dat het geen .NET DLL is, maar anders kan je het wel makkelijk bekijken... (met ILDasm.exe ofzo dacht ik)

[party42]

je zou toch de autocomplete van Visual Studio kunnen gebruiken?

als je een DLL netjes registreert zou VS met auto complete er voor moeten zorgen dat je na bijvoorbeeld al het zetten van een punt info zou moeten krijgen over het wat en hoe van een dll.

Delphi doet dat iig erg goed. Neem aan dat VS dat ook doet.

[LordLarry]

party42 schreef op 18 December 2002 @ 08:51:
je zou toch de autocomplete van Visual Studio kunnen gebruiken?

als je een DLL netjes registreert zou VS met auto complete er voor moeten zorgen dat je na bijvoorbeeld al het zetten van een punt info zou moeten krijgen over het wat en hoe van een dll.

Delphi doet dat iig erg goed. Neem aan dat VS dat ook doet.

Dat werkt alleen als de DLL het een COM Library is en geimporteerd is. Het werkt ook op een normale DLL ook als iemand een unit heeft gemaakt en daar ingeschreven heeft welke functies de DLL heeft en welke parameters die functies hebben. En daar zit nu juist het probleem. Hoe kom je daar achter?

Nog over de DLL, als er geen DllRegister functie enzo inzit is het geen COM Library en is het zeer onwaarschijnlijk dat er een TLB in zit.

[rjsomeone]

madwizard schreef op 17 December 2002 @ 23:29:
Open het programma met ollydbg of je favoriete debugger en zet een breakpoint op de dll functies (in ollydbg gewoon ctrl+g, functie invullen, ok en F2 voor een breakpoint). Dan het programma runnen en wachten tot de functie aangeroepen wordt. De parameters staan dan op de stack vanaf esp+4. Zoals .oisyn al zei schonen stdcall functies zelf de parameters op dus kan je waarschijnlijk wel zien hoeveel parameters er gegeven zijn. Anders kan je ook bij de call zelf kijken of je er wat zinnings uit kunt halen.

hm.. ik ben hooguit gevorderde vb'er dus dat stack verhaal volg ik niet helemaal... maar kan je hiermee dus de functie-parameters achterhalen van een dll zonder tbl (een niet com dll dus ook)?

[madwizard]

rjsomeone schreef op 18 december 2002 @ 14:13:
[...]

hm.. ik ben hooguit gevorderde vb'er dus dat stack verhaal volg ik niet helemaal... maar kan je hiermee dus de functie-parameters achterhalen van een dll zonder tbl (een niet com dll dus ook)?

Zonder assembler kennis zal het wel wat lastig worden... In principe kan je de functie parameters hiermee achterhalen (zonder tlb, met tlb zou dit geen handige methode zijn) maar het blijft gokken. Je krijg zoiets te zien als:

code:

(esp+4):
0006F9B4  6C 04 03 00 68 80 07 00 70 65 07 00 33 00 00 00  l...h...pe..3...

Als elke parameter 4 bytes is (meestal wel) zou de regel hierboven dus voor de parameters 0x3046C, 0x78068, 0x76570, 0x33 staan (elke parameter is 4 bytes in little-endian formaat). Je zult zelf dan moeten bedenken waar die waardes voor staan. In dit geval was het een MessageBox call, de eerste waarde is een window handle, de 2e en 3e een string pointer (die kun je wel met je debugger vinden door gewoon te kijken wat er op adres 0x78068 staat). De 4e is een combinatie van flags.
Als de parameters vrij simpel zijn is het wel te doen, als er ook nog eens bijvoorbeeld structures als pointer worden meegegeven kan het wel flink lastig worden, het hangt helemaal van de DLL af.