Detours and Internet Explorer
in [Win32 Kernel]
|
From: Daniel McCann on 7 Apr 2006 11:47 How would one then trace the calls made by the second DLL? That may be why I'm not getting any recv or WSPrecv traces for IE - probably because it uses the Wininet module, which probably loads the ws2_32.dll file to make all its calls. For this, I know that I could use a LSP, but I also want to trace calls made by the other DLLs (such as schannel or cryptoapi), where a LSP wouldn't help me. Any advice? "Rich S." <RichS(a)discussions.microsoft.com> wrote in message news:1775826F-E581-49CF-A1E3-90F4B4C361CE(a)microsoft.com... > Every function that you want to intercept must be physically hooked by the > library. If one DLL uses a second DLL, and only the first DLL has been > hooked, then you won't see any calls to the second DLL > > Regarding send() versus WSASend(), I can't answer that without looking > into > it myself. > > Rich > > "Daniel McCann" wrote: > >> Thanks for the info Rich. In the trace below, IE is clearly using >> Send(), >> not WSASend(). Why would that be happening? >> >> You seem to have a lot of experience in this. I have a question that >> perhaps you would have > insight into - Since Detours implements user-lever >> hooking, if I have a Detours application that is monitoring a program >> such >> as IE, which calls a DLL, I can monitor that call. However, if this DLL >> calls another DLL, would the call to the second DLL be traced? >> >> "Rich S." <RichS(a)discussions.microsoft.com> wrote in message >> news:D4FF2AAA-C67D-4E2B-85DE-57E02B846AB8(a)microsoft.com... >> > Daniel, >> > >> > I have experimented extensively with API hooking, and I can tell you >> > that >> > the code provided by the Detours library is only the beginning of what >> > you >> > need to successfully intercept large numbers of API's without breaking >> > the >> > application being studied. I am currently working on a complete API >> > tracing >> > application, but that is beside the point. >> > >> > I also happen to know first-hand that IE makes use of the WSASend and >> > WSARecv functions. It does not use send() and recv(). >> > >> > Good luck! >> > >> > "Daniel McCann" wrote: >> > >> >> I seem to have narrowed it down to the "Connect" call being the >> >> problem >> >> (eg >> >> mine_connect(...) in tracetcp.cpp). It appears to be breaking the >> >> socket. >> >> Any idea why this would be happening? >> >> >> >> On a sidenote, it also appears from my trace that IE uses a completely >> >> different socket implementation for send than recv, as Detours does >> >> not >> >> appear to capture any recv events. Can anyone confirm this? >> >> >> >> Thanks! >> >> >> >> "Daniel McCann" <dmccann(a)lde-innovations.com> wrote in message >> >> news:OEzfrjdWGHA.4212(a)TK2MSFTNGP02.phx.gbl... >> >> > Hi, >> >> > >> >> > I'm trying to use Detours's TraceTcp sample to monitor the calls >> >> > made >> >> > by >> >> > Internet Explorer to the winsock libraries, and the tracetcp sample >> >> > appears to be breaking IE. As you can see from the trace below, >> >> > everything seems to be working fine, and then all of a sudden a >> >> > closesocket() message appears and IE displays a "This page cannot be >> >> > displayed" message. I haven't changed the code in the sample. What >> >> > could >> >> > be causing this? Any assistance would be greatly appreciated! >> >> > >> >> > Here's the output from SYELOGD: >> >> > >> >> > SYELOGD: Ready for clients. Press Ctrl-C to stop. >> >> > 20060407000439562 2072 50.60: tracetcp: >> >> > ######################################## >> >> > ########################## >> >> > 20060407000439562 2072 50.60: tracetcp: ### c:\program >> >> > files\internet >> >> > explorer\i >> >> > explore.exe >> >> > 20060407001019578 4004 50.60: tracetcp: >> >> > ######################################## >> >> > ########################## >> >> > 20060407001019578 4004 50.60: tracetcp: ### c:\program >> >> > files\internet >> >> > explorer\i >> >> > explore.exe >> >> > 20060407001019843 4004 50.60: tracetcp: 003 4b0: >> >> > connect(,1dafc48:127.0.0.1:1669 >> >> > ,10) -> 0 >> >> > 20060407001019890 4004 50.60: tracetcp: 005 >> >> > WSAStringToAddressW(1a73d8,17,0,1faf >> >> > b00,1fafaf4) >> >> > 20060407001019890 4004 50.60: tracetcp: 005 >> >> > WSAStringToAddressW(,,,,) -> >> >> > fffffff >> >> > f >> >> > 20060407001019890 4004 50.60: tracetcp: 005 >> >> > WSAStringToAddressW(1a73d8,17,0,1faf >> >> > b00,1fafaf4) >> >> > 20060407001019890 4004 50.60: tracetcp: 005 >> >> > WSAStringToAddressW(,,,,) -> >> >> > fffffff >> >> > f >> >> > 20060407001019953 4004 50.60: tracetcp: 005 41c: >> >> > connect(,1708e4:64.4.43.250:80, >> >> > 10) -> ffffffff >> >> > 20060407001019953 4004 50.60: tracetcp: 005 41c: send(,1d6898,362,0) >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: GET >> >> > /cgi-bin/HoTMaiL?curmbo >> >> > x=F000000001&a=f819ce6d09d02&fti=y >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: es HTTP/1.1\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: Accept: */*\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > Accept-Language: >> >> > en-ca\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > Accept-Encoding: >> >> > gzip, defl >> >> > ate\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: User-Agent: >> >> > Mozilla/4.0 (co >> >> > mpatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1 >> >> > 20060407001019968 4004 50.60: tracetcp: 00 >> > 5 41c: .4322)\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: Host: >> >> > by17fd.bay17.hotmail. >> >> > msn.com\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: Connection: >> >> > Keep-Alive\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: Cookie: >> >> > MUID=BBB4BB69428842 >> >> > 4E9ED37C4C1E3ACA19; MSNADS=UM=; ANON=A=069CB94DC29173 >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > 999079032AFFFFFFFF&E=3ed&W= >> >> > 1; NAP=V=1.3&E=393&C=CBMJ_HGB3_yXa-Jfah6u8w8lxWH5qOUc >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > qiVT6_843qPOfPD65M-WkQ&W=1; >> >> > MSPAuth=76xLcRJXABR3yV8gnk89VN2%21yGOvUpxT4cG4%21V9s >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > 1GL09NmJh50XLYAB87vVzxfZPIP >> >> > TKfexNbL9kR%2aSlMsR%21lb8beo6Gs09Tn62Z6v%2aik8Ro9ft95 >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: csAEhg%24%24; >> >> > MSPProf=7nbIY >> >> > yD14BRUuv9gspk8w0Iux2EYyXptupqDA0vgBSqlgFihSUjoYoox4K >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > 58WND%212jQqvlLGkYQAzaxaR98 >> >> > YI8ya6rjb4DCMkaIxY2SUAoo7GonVkk9NQEH9S0kEsdRQtybYvAro >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: >> >> > 9h1QBuSTi%21Z%21eU9pCIFbFhU >> >> > s3pyIXmAgumEpTT3n%21qNWp0xVJglmS5AyqS; HMP1=1\r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: \r\n >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: send(,,,) -> >> >> > ffffffff >> >> > 20060407001019968 4004 50.60: tracetcp: 005 41c: closesocket() -> 0 >> >> > >> >> > >> >> >> >> >> >> >> >> >>
From: Le Chaud Lapin on 8 Apr 2006 00:45 Daniel McCann wrote: > How would one then trace the calls made by the second DLL? That may be why > I'm not getting any recv or WSPrecv traces for IE - probably because it uses > the Wininet module, which probably loads the ws2_32.dll file to make all its > calls. For this, I know that I could use a LSP, but I also want to trace > calls made by the other DLLs (such as schannel or cryptoapi), where a LSP > wouldn't help me. Any advice? No DLL should be able to escape detouring. Detours works by replacing the first few instructions of the targeted function with a JMP instruction. So if a function is in a DLL, and you Detour that function, you get results no matter what. Note that detouring will occur even if the function is invoked via LoadLibrary/GetProcAddress sequence. -Le Chaud Lapin-
From: Daniel McCann on 8 Apr 2006 03:05 I thought that was supposed to be the way it works, but something is amiss, because I'm getting the following symptoms that I can't seem to figure out: 1) There appear to be no recv or WSARecv calls made. The application has to receive the incoming page from the socket, and somewhere along the line one of those calls would have to be made. IF recv and WSArecv are detoured, why aren't those calls being traced? 2) I cannot seem to get Detours to instrument the cryptapi functions when accessing an HTTPS page, (unless I'm trying to instrument the wrong functions, but I don't think so - does anyone know which functions are called when setting up/using an SSL connection?) 3) Any attempt to detour a function such as Connect or InternetConnect breaks the target application, even if the detour does nothing but pass the request to the original function. Odd stuff. Theoretically, it should all work, but I can't seem to figure out why it isn't working... "Le Chaud Lapin" <unoriginal_username(a)yahoo.com> wrote in message news:1144471539.337619.198060(a)i39g2000cwa.googlegroups.com... > Daniel McCann wrote: >> How would one then trace the calls made by the second DLL? That may be >> why >> I'm not getting any recv or WSPrecv traces for IE - probably because it >> uses >> the Wininet module, which probably loads the ws2_32.dll file to make all >> its >> calls. For this, I know that I could use a LSP, but I also want to trace >> calls made by the other DLLs (such as schannel or cryptoapi), where a LSP >> wouldn't help me. Any advice? > > No DLL should be able to escape detouring. Detours works by replacing > the first few instructions of the targeted function with a JMP > instruction. So if a function is in a DLL, and you Detour that > function, you get results no matter what. Note that detouring will > occur even if the function is invoked via LoadLibrary/GetProcAddress > sequence. > > -Le Chaud Lapin- >
From: Rich S. on 8 Apr 2006 19:27
What La Chaud Lapin said is true, once a function is hooked, then you should get a trace for it no matter what DLL calls it. I originally thought you were asking about how to hook the functions in the second DLL. Anyway, how are you getting the traceapi DLL into the target process? You should be using WithDLL to launch the target process. Is this how you are doing it? "Daniel McCann" wrote: > I thought that was supposed to be the way it works, but something is amiss, > because I'm getting the following symptoms that I can't seem to figure out: > > 1) There appear to be no recv or WSARecv calls made. The application has to > receive the incoming page from the socket, and somewhere along the line one > of those calls would have to be made. IF recv and WSArecv are detoured, why > aren't those calls being traced? > 2) I cannot seem to get Detours to instrument the cryptapi functions when > accessing an HTTPS page, (unless I'm trying to instrument the wrong > functions, but I don't think so - does anyone know which functions are > called when setting up/using an SSL connection?) > 3) Any attempt to detour a function such as Connect or InternetConnect > breaks the target application, even if the detour does nothing but pass the > request to the original function. > > Odd stuff. Theoretically, it should all work, but I can't seem to figure > out why it isn't working... > > "Le Chaud Lapin" <unoriginal_username(a)yahoo.com> wrote in message > news:1144471539.337619.198060(a)i39g2000cwa.googlegroups.com... > > Daniel McCann wrote: > >> How would one then trace the calls made by the second DLL? That may be > >> why > >> I'm not getting any recv or WSPrecv traces for IE - probably because it > >> uses > >> the Wininet module, which probably loads the ws2_32.dll file to make all > >> its > >> calls. For this, I know that I could use a LSP, but I also want to trace > >> calls made by the other DLLs (such as schannel or cryptoapi), where a LSP > >> wouldn't help me. Any advice? > > > > No DLL should be able to escape detouring. Detours works by replacing > > the first few instructions of the targeted function with a JMP > > instruction. So if a function is in a DLL, and you Detour that > > function, you get results no matter what. Note that detouring will > > occur even if the function is invoked via LoadLibrary/GetProcAddress > > sequence. > > > > -Le Chaud Lapin- > > > > > |