by Kragen Sitaker, Friday October 15; see also Publications
(Detailed notes that supplement our notes on Google Desktop Search’s WinSock integration.)
For Firefox, it looks like what goes over the wire has a < ! – – tro2 – – > in
the appropriate place, which somewhere gets replaced by a < p
class=e>< table …ID=”Google Desktop Search”>…</ table>. So somewhere
between where the bytes come in over the wire and where they go into
FireFox’s “view source” and rendering engine, this HTML comment gets
rewritten with the local desktop search results.
No clues yet on how that happens. Maybe a FireFox? plugin? Maybe it
patched the TCP/IP stack?…
Also of note:
- the User-Agent string is Mozilla/5.0 (Windows; U… Google-TR-1) Gecko/20041001 Firefox/0.10.1 — so clearly somewhere in the request path the desktop search code is munging the user-agent.
- GoogleDesktopNetwork1.dll and GoogleDesktopNetwork2?.dll are loaded into FireFox?, according to CurrProcess?
- GoogleDesktopNetwork2.dll says in its .rdata section, some in UTF-16 and some in ASCII:
Layered Hidden Window Layered WS2 Provider Content-length: %d <!--tro2--> <!--trh2--> QUERY SEARCH WEBSERVER <!--trl2--> : content-length: text/html content-type: gzip content-encoding: chunked transfer-encoding: HTTP/1.0 HTTP/ charset= X-TR: 2 X-TR: 1 <body Content-Type: text/html http:// GET http:// toolbarqueries.google .google.
and other related stuff.
- objdump -p says GoogleDesktopNetwork2.dll calls only a few functions
from WS2_32.dll: WPUCompleteOverlappedRequest, WSCGetProviderPath,
and WSCEnumProtocols (plus five anonymous entry points), and provides
only a few functions: WSPAccept, WSPAddressToString, and 28 more WSP*
functions. Plus DoNothing.
It appears that WSCEnumProtocols gives you a bunch of protocols, each of
which contains a protocol chain: a list of Winsock SPI transport
providers (“Winsock 2 layered service provider”), each layered on top of
the next. The WSP* functions are those defined in the SPI interface.
In the registry, HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
\WinSock2\Parameters\Protocol_Catalog9\Catalog_Entries contains a bunch
of subkeys with values pointing to the GoogleDesktopNetwork1.dll — via
different pathnames. The old versions (conveniently saved under a
nearby key) point to “mswsock.dll” instead.
So apparently Microsoft Windows arranges to load the Google DLLs into
anything that accesses the network, and they have a chance to rewrite
HTTP streams before the application sees them.
Microsoft Word doesn’t seem to get the desktop search results, though,
even though CurrProc says it has the DLL loaded. Turns out
GoogleDesktopNetwork2.dll has a list of executable files:
WAOL.EXE OPERA.EXE NP.EXE NETSCP6.EXE NETSCP.EXE NEOPLANET.EXE NEOPLA~1.EXE MSN6.EXE MSN.EXE MOZILLAFIREBIRD.EXE MOZILLA.EXE IEXPLORE.EXE FIREFOX.EXE AIM.EXE AVANT.EXE AHTTP.EXE
And, in fact, if we rename FireFox’s executable to a different name, the
desktop search results stop showing up at the top of Google search
pages. (After we exit and restart the browser, anyway.)
Also, the string “Google-TR-1” occurs in the GoogleDesktopNetwork2.DLL.