[C++] DLL Proxy

[Olaf van der Spek]

Is er een applicatie die automatisch code voor een proxy DLL maakt voor een echte DLL (bijvoorbeeld kernel32) zodat ik een hook kan plaatsen op elke functie in die DLL?

De applicatie linkt dan met de proxy DLL en de proxy DLL linkt weer met de originele DLL.

[ Voor 22% gewijzigd door Olaf van der Spek op 20-12-2002 15:41 ]

[EfBe]

je kunt toch meteen met de uiteindelijke dll linken? Of wil je een COM object met als een van de interfaces de totale interface van de non-COM dll?

[Olaf van der Spek]

Ik kan de applicatie niet veranderen (zou bijvoorbeeld een spel als Red Alert 2 kunnen zijn).

[curry684]

OlafvdSpek schreef op 20 December 2002 @ 15:40:
Is er een applicatie die automatisch code voor een proxy DLL maakt voor een echte DLL (bijvoorbeeld kernel32) zodat ik een hook kan plaatsen op elke functie in die DLL?

De applicatie linkt dan met de proxy DLL en de proxy DLL linkt weer met de originele DLL.

Niet dat ik weet, ik heb al eens gezocht om een proxy voor de sourcesafe DLL's te kunnen maken...

[LordLarry]

Hier is al een topic over geweest nog niet zo lang geleden. Je maakt gewoon zelf die proxy met de hand, maar er schijnt ook een MS onderzoek over geweest te zijn die misschien interresant voor je is. Zoek even het vorige topic hierover op...

[Verwijderd]

http://www.codeproject.com/dll/apihijack.asp

[Olaf van der Spek]

LordLarry schreef op 20 december 2002 @ 17:09:
Hier is al een topic over geweest nog niet zo lang geleden. Je maakt gewoon zelf die proxy met de hand, maar er schijnt ook een MS onderzoek over geweest te zijn die misschien interresant voor je is. Zoek even het vorige topic hierover op...

Ik kan het niet vinden. Ik heb gezocht op DLL in de titel.

Verwijderd schreef op 20 december 2002 @ 17:11:
http://www.codeproject.com/dll/apihijack.asp

Had ik al gezien, maar leek iets anders te werken.

[EfBe]

Je zou een C-decompiler kunnen proberen, de dll's waar je op doelt hebben toch een c-style interface. anders wordt het wel een lastig verhaal denk ik.

[Olaf van der Spek]

Wat zou ik decompilen dan? De exported functies zijn al bekend.

[curry684]

Verwijderd schreef op 20 December 2002 @ 17:11:
http://www.codeproject.com/dll/apihijack.asp

Lijkt mij ook iets anders...

Wat je wil is simpelweg een app die de exported functies van een DLL uitzoekt en ze 'stubt' in een C file, oftewel een DLL bouwt die enkel en alleen de originele DLL laadt en alle exported functies in een lege functie linea recta doorjast in het origineel. Idee is dat je dan zelf functionele code kunt doen (zoals loggen) in de stub-call.

Ik heb het met SourceSafe zelf helemaal gedaan (is gelukkig maar 23 functies) maar weet nu wel een hoop van die API en hoe VS.net 'm gebruikt

[EfBe]

OlafvdSpek schreef op 20 december 2002 @ 17:58:
Wat zou ik decompilen dan? De exported functies zijn al bekend.

Ik bedoel, dat je je target dll gaat decompilen, zodat je een interface hebt in code, die compileer je naar je proxy dll nadat je de functies zelf leeg hebt gemaakt en hebt voorzien van callcode naar de target dll.

[Olaf van der Spek]

curry684 schreef op 20 december 2002 @ 18:18:
Lijkt mij ook iets anders...

Wat je wil is simpelweg een app die de exported functies van een DLL uitzoekt en ze 'stubt' in een C file, oftewel een DLL bouwt die enkel en alleen de originele DLL laadt en alle exported functies in een lege functie linea recta doorjast in het origineel. Idee is dat je dan zelf functionele code kunt doen (zoals loggen) in de stub-call.

Ik heb het met SourceSafe zelf helemaal gedaan (is gelukkig maar 23 functies) maar weet nu wel een hoop van die API en hoe VS.net 'm gebruikt

Ik wilde het doen voor file-handling (om een virtual filesystem te maken) en voor winsock.
Maar kernel32 heeft bijna 1000 functies.

[EfBe]

Indien het een NT-based OS betreft (en dus niet windows9x) dan kun je wellicht proberen een layer in de filesystem stack te plaatsen. Dit is de gebruikelijke methode om file I/O te manipuleren (virusscanners werken ook op die manier). Als je een virtual filesystem wilt maken kun je ook een filesystem driver bouwen en die in de filesystemstack hangen. Toegegeven, dat is wel complexe materie maar wel de manier om het te doen. (overigens heeft ieder NT based OS een virtual filesystem, dat is juist het mooie ).

[LordLarry]

OlafvdSpek schreef op 20 December 2002 @ 17:42:
Ik kan het niet vinden. Ik heb gezocht op DLL in de titel.

Is ook met DLL in de titel
[rml][ C++]DLL aftappen[/rml]

Maar het lijkt me van de zotte op dit uberhaupt te gaan doen met kernel32. Weet je hoe instabiel je je systeem maakt?! Verder denk ik dat je m toch niet kan vervangen opdat ie gewoon weg altijd bezet is. Ook zal winXP met zn system restore het ook niet toelaten en meteen weer vervangen. En virusscanners zijn er ook niet zo blij mee.

Er zijn legitieme en veiligere manier om te bereiken wat je wilt. Maar ik denk dat dat misschien een beetje boven je kunne is? No offence, maar dit is wel even andere koek dan een simpel c++ appje

[Olaf van der Spek]

LordLarry schreef op 20 December 2002 @ 20:16:
Is ook met DLL in de titel
[rml][ C++]DLL aftappen[/rml]

Leg dat maar eens uit aan de search (die vind hem echt niet)

Maar het lijkt me van de zotte op dit uberhaupt te gaan doen met kernel32. Weet je hoe instabiel je je systeem maakt?!

Waarom zou het instabiel worden?

Verder denk ik dat je m toch niet kan vervangen opdat ie gewoon weg altijd bezet is. Ook zal winXP met zn system restore het ook niet toelaten en meteen weer vervangen. En virusscanners zijn er ook niet zo blij mee.

Er zijn legitieme en veiligere manier om te bereiken wat je wilt. Maar ik denk dat dat misschien een beetje boven je kunne is? No offence, maar dit is wel even andere koek dan een simpel c++ appje

Ik zou hem bijvoorbeeld kernel33.dll kunnen noemen en de target app hex-editen.

Sinds wanneer kan ik alleen simpele C++ apps schrijven?

[LordLarry]

OlafvdSpek schreef op 20 december 2002 @ 20:21:
Leg dat maar eens uit aan de search (die vind hem echt niet)

probeer dan ook eens de externe search

Waarom zou het instabiel worden?
Ik zou hem bijvoorbeeld kernel33.dll kunnen noemen en de target app hex-editen.

Ja, dat zou kunnen. Je beperkt je dan wel tot een enkele gehackte app. Instabiel, omdat je DE primaire DLL van windows gaat aanpassen. Als daarin iets fout gaat stort je windows in. Het is zeker niet ontdenkbaar dat jij een foutje maakt, want niemand is onfeilbaar. Zeker niet tijdens het ontwikkelen. Aangezien je met veel functies te maken hebt waarvan sommigen ongedocumenteerd zijn lijkt me het een langdurige en pijnlijke zaak, zoniet ontdoenlijk. En dat terwijl er legitieme en waarschijnlijk veel stabielere mogelijkheden zijn om hetzelfde te berijken voor alle programma's binnen windows zonder te hacken!

Sinds wanneer kan ik alleen simpele C++ apps schrijven?

[/quote]
Aangezien het schrijven van drivers en andere systeemzaken geen kattepis is zal het heel wat kennis vereisen van de programmeur. Binnen bedrijven werken er waarschijnlijk meerdere programmeurs met veel ervaring op dit gebied voor een lange tijd aan zoiets. Ik weet niet of jij dat bent en heb dan ook nooit gezegt dat jij alleen simpele c++ apps kan schrijven. Ik zei alleen dat het wat anders was als een simpel c++ appje. Ik probeer je alleen te waarschuwen niet teveel hooi op je vork te nemen en hier te ligt over te denken.

[.oisyn]

Even terugkomend op je oorspronkelijke probleem, zo'n programmaatje moet niet moeilijk te maken zijn. Gewoon de exported functions uit een DLL halen en dan vervolgens code genereren die die exported functions aanroept

[ Voor 3% gewijzigd door .oisyn op 20-12-2002 20:57 ]

[madwizard]

OlafvdSpek schreef op 20 December 2002 @ 18:41:
Ik wilde het doen voor file-handling (om een virtual filesystem te maken) en voor winsock. Maar kernel32 heeft bijna 1000 functies.

Een proxy DLL lijkt me geen goede methode om een virtual filesystem te maken. Windows doet hoogstwaarschijnlijk veel meer achter de schermen met file I/O dus alleen functies aanpassen zal niet gauw werken. Een klein bugje in je hook DLL zou bovendien kunnen leiden tot bijvoorbeeld het verkeerd opslaan van bestanden en andere vervelende dingen.
Je kunt wel een shell namespace extension maken, net als sommige FTP programma's doen om een FTP site in explorer te integreren, maar niet alle programma's houden rekening met zulke extensions (omdat het fysiek gezien niet echt deel uitmaakt van het filesystem), maar in ieder geval is een correcte manier.
Ik weet niet wat je met de winsock DLL wil doen maar als je send en recv enzo wilt hooken om te debuggen dan kan dat wel, ook zonder proxy DLL. Hier staat nog wel een interessant artikeltje over hook methodes. Op mijn eigen site staat ook een tooltje (wshook) die winsock dataverkeer laat zien, al hookt die de DLL niet maar het programma zelf (als debugger). De code is wel wat goor maar het was maar voor het debuggen van m'n eigen programma's.

curry684 schreef op 20 December 2002 @ 18:18:
[...]Wat je wil is simpelweg een app die de exported functies van een DLL uitzoekt en ze 'stubt' in een C file, oftewel een DLL bouwt die enkel en alleen de originele DLL laadt en alle exported functies in een lege functie linea recta doorjast in het origineel. Idee is dat je dan zelf functionele code kunt doen (zoals loggen) in de stub-call.

Zoiets kun je inderdaad doen, je hebt dan een import library van de target DLL nodig (die kun je zelf bakken door de export list te dumpen (dumpbin /exports x.dll), de functies daaruit in een .def zetten (inclusief ordinals, veel progs importeren winsock functies by ordinal) en daar weer een lib van maken (lib /machine:ix86 /def:x.def).

Daarna kan je een DLL maken die deze lib importeert zodat ie de orginele functies kan aanroepen en bovendien alle functies ook zelf exporteert.
Hoewel het artikel van internals.com zegt dat je voor een proxy DLL voor alle functies een stub moet schrijven en bovendien de parameters moet weten is dat niet helemaal waar.

Je kunt namelijk voor je eigen DLL ook dezelfde .def gebruiken maar dan als library bijvoorbeeld ws2_33 neerzetten. Als je die voor je eigen DLL gebruikt en je net gefabriceerde lib in je link lijst zet kun je de DLL zonder moeite compileren en is het gewoon een stub die niks doet (alle exports verwijzen vrijwel direct naar de imports, elke export is een jmp [import]). Het is dus absoluut geen moeite om zoiets te maken, je moet nu alleen in je programma ws2_32 naar ws2_33 hernoemen.
Hier heb je natuurlijk nog niks aan, want je hookt niks. Je kunt een functie hooken door gewoon een implementatie in je DLL source code te zetten (die tot nu toe leeg was op winmain na), die iets doet en vervolgens het orgineel aanroept. Er zijn hier alleen twee (kleine) problemen:

1) De import lib die je gemaakt hebt werkt wel om een lege stub te maken (compiler kan het dan niet schelen wat de parameters van die functies zijn), dat wordt anders als je een functie wilt gebruiken. Dan moet je in de .def die je voor je importlib gemaakt hebt direct achter functienaam die je gaat hooken @x zetten, waarbij x het totaal aantal bytes aan parameters is (bij stdcall dan natuurlijk)). Voor socket zou er dan bijvoorbeeld dit staan:
socket@12 @23
(de laatste @23 is de ordinal waarde, die stond er als het goed is al)
Nu kun je de functie ook echt aanroepen in je programma zonder dat er linker errors komen.

2) Je geexporteerde functie en geimporteerde functie heten hetzelfde, dus socket aanroepen in je eigen socket stub wordt een oneindig recursieve functie. Ik heb nog geen methode gevonden om deze in de source code te kunnen onderscheiden, misschien kan het wel.. In ieder geval heb ik wel een workaround gevonden. Noem je eigen stub niet socket maar bijvoorbeeld socketSTUB ofzo, en pas je eigen .def (ws2_33.def) aan zodat de socket functie daar ook socketSTUB heet. Compile het geheel, en vervang daarna met hiew of een andere hex-editor 'STUB' in 4 0-bytes. Aangezien de export namen gewoon null terminated strings zijn kan dit geen kwaad, je hebt alleen wat onnodige bytes maar daar zal je niet wakker van liggen .
Als je wil kan ik het wel verder uitleggen of een voorbeeldje geven, heb nu even geen tijd..

[Verwijderd]

OlafvdSpek schreef op 20 december 2002 @ 17:42:
Had ik al gezien, maar leek iets anders te werken.

Wat doet het er toe *HOE* het werkt? je hebt 'n doel wat je wil bereiken.. wellicht is een complete core dll van windows proberen proxy/stubben niet de meest briljante actie? (zo zit er bv bij iedere windows versie een andere versie van die dll met meer/minder functies...) je wilt eigenlijk gewoon default win32 api's hooken als je met google zoekt naar [google=api hooking] weet ik zeker dat je wat gaat vinden waarmee je kan waar jij naar opzoekt bent, wellicht niet op de manier die je voor ogen hebt maar het kan...

[klinz]

Misschien is detours wat voor je? http://research.microsoft.com/sn/detours/

[Olaf van der Spek]

Detours ziet er inderdaad zeer interessant uit. Dank u.

[LordLarry]

Dat werd ook al gemeld in het vorige topic hierover die ik aangaf. Heb je die wel gelezen?

[Olaf van der Spek]

Eh, nee. Was ik vergeten (zat me druk te maken over de niet werkende search).

[klinz]

OlafvdSpek schreef op 20 december 2002 @ 18:41:
[...]

Ik wilde het doen voor file-handling (om een virtual filesystem te maken) en voor winsock.
[...]

Als je een virtual file system wil maken kun je het misschien beter anders oplossen. Mijn aanname is dat je C gebruikt, maar in Delphi is deze truuk ook mogelijk.

code:

#include <stdio.h>
#include "myvfs.h"

In myvfs.h staan dan je implementatie van de functies fopen, fread, fwrite, fseek, fclose (etc.) die met het VFS werken. Op de include na is het VFS dan geheel transparant voor de programmeur

Of is het de bedoeling dat willekeurig programma's gebruik kunnen maken van VFS? Vroeger had je bijvoorbeeld XLINK van Jinx/The Coexistence waarmee dat kon. Helaas was dat voor DOS en daar is dat redelijk eenvoudig.

[Olaf van der Spek]

klinz schreef op 23 december 2002 @ 16:27:
[...]


Als je een virtual file system wil maken kun je het misschien beter anders oplossen. Mijn aanname is dat je C gebruikt, maar in Delphi is deze truuk ook mogelijk.

code:

#include <stdio.h>
#include "myvfs.h"

In myvfs.h staan dan je implementatie van de functies fopen, fread, fwrite, fseek, fclose (etc.) die met het VFS werken. Op de include na is het VFS dan geheel transparant voor de programmeur

Of is het de bedoeling dat willekeurig programma's gebruik kunnen maken van VFS? Vroeger had je bijvoorbeeld XLINK van Jinx/The Coexistence waarmee dat kon. Helaas was dat voor DOS en daar is dat redelijk eenvoudig.

Ik wilde het voor Red Alert 2 doen (en daar heb ik jammer genoeg geen source code van).
Ik gebruik C++.