Quote:
Originally posted by cnadice llano
i had limewire downloaded on my computer for about 6 months and i found that it had been infected with spywear and when i had the spywear removed i found that i could no longer connect to limewire i paid for the unlimted use of this program but its not doing me any good im getting married soon and was hoping to be able to burn some c d's but its not looking good help! |
Your spyware may have made LimeWire work because it modified the TCP/IP protocol stack to include what is called (on Windows) a "Winsock LSP", i.e. a plugin for Windows sockets that normally performs address resolution, or supports ancillary functions through helper processes.
I do think that you have not completely removed the spyware, and that the spyware's installed LSP is still there, even if it is no longer working as expected as the main part of the spyware components are no longer there.
I suggest you use "SpyBot Search & destroy", and get into its "advanced mode", where you'll find the "Tools" button on the sidebar: then click on "Winsock LSPs". You'll see a list of LSPs installed in the Windows networking stack. You need to keep the following ones:
(1) Transport Protocols:
(1a) MSAFD NetBios (\Device\NetBT_Tcpip_{...}): several instances are present, this is normal as there are several networking interfaces for the internal local host, in addition to remote accesses, DSL modems, Ethernet cards, Wifi adapters, ...
(1b) MSAFD NetBios (\Device\NetBT_Tcpip6_{...}): same thing, except that this is related to the support of the newest internet protocol "IPv6" instead of the legacy IPv4 protocol with 32-bit IP addresses.
(Both are supported in %systemroot%\system32\mswsock.dll; these two support the IP protocol for Internet, and optionally the NetBios protocol over IP, a.k.a. "SMB", used for Windows shared files and services; don't remove them as you would delete at the same time the support for TCP/IP transport, needed for Internet; instead configure your firewall to block the RPC/DCOM port and the Microsoft files/printers/services sharing server ports).
(2) NS Providers (namespaces, i.e. resolution of names to addresses):
(2a) TCP/IP (%systemroot%\system32\mswsock.dll): this contains the DNS client that resolves hostnames like "www.limewire.com" to an IP address. Don't remove it.
(2b) NTDS (%systemroot%\system32\mswsock.dll): this contains the WINS client that resolves Windows hostnames and services for NetBIOS/SMB or with a NT Directory Service: in a LAN, or optionally over the Internet over a secured virtual channel. Don't remove it, as it is needed to access to internal resources of your local host from local applications; instead, you need to configure the Firewall or IP settings to exclude the support of NetBios over Internet connections.
(2c) NLA namespace (Network Location Awareness) (in %systemroot%\system32\mswsock.dll): this supports namespaces needed for wireless or mobile networks, and allows locating a server managing you private domains. Also needed as the base support for PNRP (the secured Peer-2-Peer protocol from Microsoft). It is installed if you have enabled this P2P protocol, but possibly with other components, or with some Wifi connections (I think it is needed for the support of WEP and WPA authentication on WiFi accesses or routers).
(2d) the namespace provider for PNRP cloud (in %systemroot%\system32\pnrpnsp.dll): needed for Microsoft P2P protocol, it allows locating hosts and services in the P2P cloud with their GUID; it contains a search agent and a topology builder; in Microsoft P2P, searches occur only between authenticated servents, through secured channels, that create one or several "clouds" located anywhere on a private LAN, or on Internet, without a central server. Authentication works through hosts certificates; hosts, files or services are identified by GUIDs, and this PNRP protocol allows performing a distributed replication of a virtual file server or service, and locating hosts on this virtual network via their GUID. This MSPNRP protocol is still in beta form (Microsoft has learned a lot from experiments in Gnutella and other P2P protocols, notably when tuning its "topology builder" and optimizing searches with broadcasts in a instable network with lots of dynamic routes; I absolutely don't know the performance of this P2P protocol, but Microsoft does not intend to build it for free file sharing between unidentified servents: it requires using authentic certificates registered in a central PKI authority, with a verifiable identity, so the build topology will always be identifiable by a responsable network owner; apparently not suitable for personnal P2P applications due to privacy issues). The support for PNRP in uninstallable (check the Microsoft documentation about NETSH)
You may also find some other LSP's installed by some antivirus; but beware of LSP's installed by some free "popup remover" bars, as they sometime include their own spyware!
Note that the Windows XP Service Pack 2 contains tools to remove unsafe LSPs and restore the default configuration if it gets damaged.
Also XP SP2 contains a builtin local firewall that is known to cause problems to some Gnutella users: it requires a manual configuration to let incoming connections and datagrams from the Internet to your local Gnutella ports 6346 (TCP required for the base Gnutella protocol, UDP needed for the new Out-Of-Band search protocol).