IMON FIX (streaming media, massive temp files, url exclusion)

All -
I've been digging for awhile now and finally found a solution to the IMON URL exclusion problem. Here's the typcial problem we are all having..

PROBLEM: Client is using a program that generates or requests, via TCP, a form of streaming media. I've seen this is many variations. One user was pulling down stock reports with some 3rd Party Software. Another user was trying to publish RealPlayer content. Personally, I was trying to pull down a security camera feed onto my machine for recording/archiving. Anyways, NOD32 has one of the following problems when doing this:
1)Crashes the system after several hours of usage
2)Generates, either in number or in sheer size per file, massive .tmp files in your windows temp folder and max-es out hard drive space.
3)allows the client to make the CONNECTion to the media, but prevents the media from DOWNLOADING to the client.

Solution: It's easier than you think. THE easiest way to fix this would be to tell NOD32 to ignore all traffic from the specified IP of where your streaming media exists. Unfortunately though, Eset didn't program that into the UI. While it seems logical then to just restrict NOD32 from scanning your particular application, it may not always be the application you think that is pulling down the streaming media. Decentralized program development in VB these days almost guarantees that your little streaming media application has executable files scattered all over your computer's file system. So then, which darn executable is requesting that streaming media? Once you find it...you can exclude it from NOD32's scanning engine and thereby prevent all the above listed problems.

1. You'll need a copy of SmartSniff. It's a TCP port sniffer that can identify processes associated with TCP packets travelling in/out of your computer. Best of all, it's free! Go here.
2. Follow the tutorial entitled "Viewing process information" found at the link above. This will enable you to see which executables are grabbing the streaming media.
3. Open SmartSniff and push the green arrow button. If your machine is actively talking TCP to anything, you'll see the packets start to appear.
4. Open the program that pulls your flavor of streaming media. In SmartSniff, you should start to see the active TCP connections start to transfer packets quite rapidly.
5. Look for the connection that is eating up bandwidth A LOT more rapidly than any other. The dead-give-away is that the packets are travelling from the IP address of your streaming media. If all the numbers don't make sense, do a DNS LookUp for the word-name of your streaming media location. Odds are, the numeric IP address of your streaming media is displayed in SmartSniff.
6. Once you see the connection eating up bandwidth for breakfast, press the red square to stop SmartSniff from monitoring your packet traffic. SmartSniff will automatically try to resolve IP addresses to FQDN's for you.
7. Scroll the slider over to the right and check the path and filename of the executable eating up so much bandwidth (Process Name). In my system, my streaming video application pulled down about 45MB in five seconds.
8. Exclude this new executable in IMON, and test everything...again.


If you've done everything right, and excluded the right executable, NOD32 should stop generating those heinous temp files and ignore any TCP request/execution made by the selected file. IMON can still run just fine.


TECHNICAL BACKGROUND: The question is, WHY does NOD32 IMON generate these ugly temp files, crash my computer, and create havoc? The technical answer is that NOD32 is doing EXACTLY what it is supposed to do.
Your streaming media software is constantly downloading packets via a unicast TCP connection over a given port. Most often, it's port 80 (http). NOD32 caches EVERYTHING travelling across a user-defined set of TCP ports (default is 80, 8080, and 312 and scans that info using a heuristic algorithm before the data is stored, logged and viewed. The most common example is visiting a webpage with IE. Every gif, jpeg, html file, cgi script....EVERYTHING is cached, scanned and them stuck in the "Temporary Internet Files" system folder to be displayed by IE.
Streaming media is a STREAM and therefore doesn't have a pre-determined endpoint. So... NOD32 keeps caching the data, waiting to scan it once the executable that requested the stream receives an end-of-file signature and closes the open TCP connection. The cached data goes in a temp file in your temp file directory where it grows exponentially and eats up your entire hard drive.
Now if you were to close down that executable that initiated the TCP connection to pull the streaming media, amazingly the big 'ole temp file disappears! Because you're not requesting any information anymore, NOD32 finishes checking the cached file, and most likely, deletes it because it's not infected.


REMEMBER: The executable you double-click on to start your favorite streaming app MAY NOT be the one requesting/broadcasting streaming media. Use SmartSniff to find the culprit.

REMEMBER: NOD32 really isn't doing anything wrong in this whole dilemma. It's designed to cache and scan everything you download (all the stuff you see when surfing the net). Trouble is, streaming media is one long, continuous download.

REMEMBER: The culprit temp files typically are created in %SYSTEMROOT%/WINDOWS/TEMP or %SYSTEMROOT%/WINNT/TEMP and are named IHxxxx.tmp where the "x" represents an ASCII alpha-numeric character.

 

Nice post - Thanks for the tip.

Cheers
Damian

 

Wow, that is one heck of a first post. Nice!

I was wondering, does it make any difference if the IMON --> HTTP --> Client compatability is set to "Higher compatability" rather than "Higher efficiency"?

 

Again, I set everything to higher efficiency as BS recomended, unless it conflicts with a certain program. Which is doesnt for me at least.

 

Thanks! The problem really bugged me, especially because technically, NOD32 is working just fine, yet making my system go haywire.

As fas as higher compatibility versus higher efficiency. I've played with those at length and never really seen the scanning engine react sufficiently different between the two. I'd keep the defaults and make changing them a first-order troubleshooting step. This would be because of their relatively little effect on the most technical problems with NOD32