Tool finds text strings in files that Win XP won't search

[Tom T.]

This topic, especially this post, demonstrated the limitations of the Windows XP "Search" tool in finding text strings: namely, that many file types are excluded. The malware in question would have been found very quickly with a tool that would search for text strings In *all* file types.

I have found one: http://www.pcl-online.org/watchetsoft/h ... tfind.html

*Totally* freeware. Only 1.29 MB, and *very* quickly found a test case that duplicated the malware situation. More info in this post, where it was described as related to the hunt for that malware.

Claims to support only up through XP. Someone might wish to try it on Vista/7, under controlled conditions -- unless their text searchers don't have the exclusions that XP's does.

Also very nice: I keep Indexing Service disabled because it is a large resource hog. With watchetfind, I did *not* have to re-enable Indexing Service. It appeared to be scanning *every* text-readable file on the machine, AFAICT, *very* rapidly.

Feedback welcome!

[computerfreaker]

I checked out WatchetFind; unfortunately, it's not portable and even UniExtract can't change that. So, since I'm a guy who won't install anything if a portable version is available, I decided to do some searching of my own.
I found this great application from NirSoft (not sure if you've heard about them before, but they make some really great apps): SearchMyFiles. http://www.nirsoft.net/utils/search_my_files.html

Totally and natively portable, and it found all kinds of stuff Windows search missed - including the contents of .xul, .nsi, .vbp, .bas, and .cls files. The size is pretty much unbeatable too - 49 KB zipped, and just 70 KB unzipped. Finally, the search parameters are insanely powerful - you can search the contents of a folder, exclude folders from the search, include/exclude files by their attributes, scan recursively, stop recursively scanning at a certain depth, stop after finding a certain number of files, and - best of all, IMHO - search a file's contents based on a text string or a binary string. Doesn't get much better than this...

[therube]

There are all kinds of tools that can be used to search within files. Any number may work depending on your needs.
I don't have enough of a need to use anything other then what my file manager (<Altap> Servant Salamander) has built-in.


Freeware-guide: File Searching

[Tom T.]

"Kissing a girl is like getting pickles out of a jar: Once you get the first one, the rest come more easily".

So *one* person finds a tool that would have worked, and suddenly the market is flooded with them.

Wish therube had mentioned that when we were trying to find the file, and Montagar couldn't. He referred to XP's limitations, but I (at least) was focused elsewhere. Glad that we now have a large list of tools that would have worked in the referenced case, and many other.

Kinda makes you wonder why XP's native search function always excludes certain file types. Seems that should be the user's choice. Score another one for MS.

[computerfreaker]

"Kissing a girl is like getting pickles out of a jar: Once you get the first one, the rest come more easily".

So *one* person finds a tool that would have worked, and suddenly the market is flooded with them.

Beg to differ with you... the market was flooded before, we just didn't need (read: didn't think we needed) any of them. Human hindsight again...

Wish therube had mentioned that when we were trying to find the file, and Montagar couldn't. He referred to XP's limitations, but I (at least) was focused elsewhere. Glad that we now have a large list of tools that would have worked in the referenced case, and many other.

Add me to the list of people who should have mentioned the limitations of XP Search... I know those limitations, and I'd bumped up against them only a day or so earlier. I just didn't put 2 and 2 together... in my sole defense, though, I'd never tried searching an xul file. My bad...

Kinda makes you wonder why XP's native search function always excludes certain file types. Seems that should be the user's choice. Score another one for MS.

Apparently the indexing service needs to be on to search all kinds of files - yes, score another one for MS and their goal of world domination.
(Just a guess, OTOH the XP Search only looks at a certain, pre-defined list of "text files" - rename the xul files to have .txt extensions, and I'll bet Search works for them again)

[Tom T.]

Beg to differ with you... the market was flooded before,...

That's what I meant. Bad choice of wording -- I gotta watch that on these rapid-fire posts. *Meant* to say that once the topic was brought up, suddenly we become aware of a zillion tools that would have filled the need.

Add me to the list of people who should have mentioned the limitations of XP Search... I know those limitations, and I'd bumped up against them only a day or so earlier. I just didn't put 2 and 2 together... in my sole defense, though, I'd never tried searching an xul file. My bad...

Nor had I (tried to search an xul). Yesterday, I searched MS Knowledge Base, trying to find a KB article that described XP's Search function in detail, *including* file types excluded, and whether that could be modified. The search term "search" produced *zero* results, as did a couple of similar ones.

I just searched the Reg for any possibilities. HKCU\Sw\MS\Windows\CurrentVersion\Explorer ... Right pane: SearchSlowFiles = 0.
Perhaps setting it to 1 would include more files? Anyone care to try it?

... OTOH the XP Search only looks at a certain, pre-defined list of "text files" - rename the xul files to have .txt extensions, and I'll bet Search works for them again)

Yeah, but how much work is that -- we didn't even know it was an xul file at first. You'd have to rename all .js files, etc. -- then when done, go back to the correct extensions. These other tools are the answer -- just stupid that XP won't let a user configure this. They want faster searches for novices, who won't be searching system/app files, to be sure, but it could be an option under "Advanced". Or even a Reg config, like the above possibility. But they don't, apparently. Same old, same old ....

[computerfreaker]

Add me to the list of people who should have mentioned the limitations of XP Search... I know those limitations, and I'd bumped up against them only a day or so earlier. I just didn't put 2 and 2 together... in my sole defense, though, I'd never tried searching an xul file. My bad...

Nor had I (tried to search an xul). Yesterday, I searched MS Knowledge Base, trying to find a KB article that described XP's Search function in detail, *including* file types excluded, and whether that could be modified. The search term "search" produced *zero* results, as did a couple of similar ones.

No surprise, this is MS we're trying to deal with.

I just searched the Reg for any possibilities. HKCU\Sw\MS\Windows\CurrentVersion\Explorer ... Right pane: SearchSlowFiles = 0.
Perhaps setting it to 1 would include more files? Anyone care to try it?

I'll try it in the morning, I need a little sleep right now... and I want to do a thorough analysis of the results. (Although that would be sheer stupidity on MS's part, since XUL files are little text files, as are vbs, vbp, bas, etc.)

... OTOH the XP Search only looks at a certain, pre-defined list of "text files" - rename the xul files to have .txt extensions, and I'll bet Search works for them again)

Yeah, but how much work is that -- we didn't even know it was an xul file at first. You'd have to rename all .js files, etc. -- then when done, go back to the correct extensions. These other tools are the answer -- just stupid that XP won't let a user configure this. They want faster searches for novices, who won't be searching system/app files, to be sure, but it could be an option under "Advanced". Or even a Reg config, like the above possibility. But they don't, apparently. Same old, same old ....

Now it's my fault for not being clear - I was essentially offering a POC that XP Search only looks at a list of extensions in determining whether to search a file, not the actual file contents.

[Tom T.]

Now it's my fault for not being clear - I was essentially offering a POC that XP Search only looks at a list of extensions in determining whether to search a file, not the actual file contents.

I think Montagar has already proven that for us.

[computerfreaker]

Now it's my fault for not being clear - I was essentially offering a POC that XP Search only looks at a list of extensions in determining whether to search a file, not the actual file contents.

I think Montagar has already proven that for us.

My intended POC was a little different than what Monty proved - I was trying to prove that Windows looks at a file's extension, not its size, when determining if it should be searched or not.

btw, that SearchSlowFiles registry entry is simply there to determine if Windows should search through a tape-drive-backup or system backup for your desired info, or if Windows should ignore that kind of thing. http://www.liutilities.com/products/reg ... aks/10183/

This setting enables you to modify the search options used for files and folders. "search tape backup" option searches for the specified files in your tape backup system/device, if you have one. Note: tape backup means that you keep a supplement copy of your data on a cartridge tape. This measure protects you from loss of data like disk crash etc. For this, go to start > run menu, enter regedit and navigate to the registry path listed below. You can create a dword value searchslowfiles, if this value does not exist. Now, right-click and modify the value to 1 which can search for files and folders in tape backup. However, if you want to exclude the option, change the value to 0. The changes take effect after a restart or logoff.

[Tom T.]

My intended POC was a little different than what Monty proved - I was trying to prove that Windows looks at a file's extension, not its size, when determining if it should be searched or not.

I must be missing something. I thought that that is exactly what Monty said -- that Windows wouldn't search .xul files, and that you added other text-editable files in the VBscript family -- that it wouldn't search, regardless of size. The .xul files I have (3) are about 500 bytes each, so clearly, max size is not an issue.

I thought we'd agreed that MS just wanted to confine the searches to user-type files, so that AHU (average home users), who wouldn't be searching system and app files, would get the fastest possible results in locating their love letters, etc. Or their significant other's love letters to The Other Woman/Man.

[computerfreaker]

My intended POC was a little different than what Monty proved - I was trying to prove that Windows looks at a file's extension, not its size, when determining if it should be searched or not.

I must be missing something. I thought that that is exactly what Monty said -- that Windows wouldn't search .xul files, and that you added other text-editable files in the VBscript family -- that it wouldn't search, regardless of size. The .xul files I have (3) are about 500 bytes each, so clearly, max size is not an issue.

I missed something - the size of the .xul files. This is what I get for posting late at night...
That's exactly what Monty had proved, but I had misunderstood because I didn't notice the size of the files...

I thought we'd agreed that MS just wanted to confine the searches to user-type files, so that AHU (average home users), who wouldn't be searching system and app files, would get the fastest possible results in locating their love letters, etc. Or their significant other's love letters to The Other Woman/Man.

yes, that's what we'd agreed. Late-night posting isn't conducive to remembering that kind of thing, though...

[Tom T.]

yes, that's what we'd agreed. Late-night posting isn't conducive to remembering that kind of thing, though...

Go to sleep earlier. The Forum will still be here tomorrow.