Deciphering Fluffy Bunny

From CommerceNet Wiki

Jump to: navigation, search

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.

Personal tools