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.