The file has a PE structure (Mark Zbikowsky's marker, 16 bit EXE stub, PE extended header and sections) but it isn't directly executable. Which doesn't mean much as many non-executable objects used in Windows have that structure, like font files, to mention one example.
It could be malware related, but it could be anything else just the same.
Most scanners have the option to scan "all files", regardless of their extension name. Generally, it's a bad idea to scan all files as it increases both false alarms and scan time.
As for on-access AV, I wouldn't recommend it checking all files, under no circumstances.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
formatting link
formatting link
(Hebrew) InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
Just perform a forensics analysis on the drive and load another drive. That (loading a new drive, not the analysis) would've taken less time than all the back and forth flames and insults within this thread that haven't really solved anything.
If you can duplicate it, then document it and contact some companies and pass on the info. Examine the c:\\null file yourself to see what the content is, and then make your own call on what exactly it is, based on the content (if possible.)
And Belkin routers aren't the world's greatest, and neither is ZA as far as firewalls go. It's entirely possible that something managed to get past both of them, especially if it was invited from the inside.
Then again, just is just my .02 on this thread, which I will now be ignoring, since it isn't contributing to anything except more insults.
-Kevin (All flames/insults will be forwarded to /dev/null)
What prevented Integrity Master, and checkers in the same category (e.g. CRC, MD5, etc.), from becoming widely used in AV, are the following reasons:
Plain integrity ("plain" here refers to the processing of the entire file, not to the method used) is useless for AV purposes as it's unable to discriminate between legitimate changes and malware related changes.
Integrity records obtained by IM and its likes were useless in restoring modified objects to their original state. This last capability is now less important due to the complexity in restoring 32 bit objects from an "integrity signature" (the size of the signature required for that is prohibitively large), but was cardinal in the days of DOS.
The above reasoning was adopted by the AV industry soon after the 1991 AV Products Developers conference held in Washington D.C., where I first presented the AV adapted integrity checker *and restorer* concept. The idea were soon implemented in products such as in NAV's "inoculation", Eliashim's PIC (now Aladin's), Thunderbyte Tbsetup/Tbclean, and in others.
Today, *real-time* integrity monitoring is successfully implemented in InVircible's Interceptor (see
formatting link
).
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
formatting link
formatting link
(Hebrew) InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
as malware can make arbitrary changes, processing the entire file is required... if you're only worried about parasitic infection then sure, for some types of files you may only need to check a subset of the entire file, but integrity checkers aren't *just* for detecting that sort of thing...
of course we've had this disagreement for a good long time now... you feel integrity checkers should behave like your product but your product has been highly specialized/optimized for detecting infection... plain integrity checkers detect a broader range of changes and, correctly or incorrectly, leave the interpretation of those changes up to a non-autonomous agent also known as the user (which is the real reason the non-technical majority never adopted them)...
there are those who feel that programmatically restoring infected/corrupted objects to their original state is a losing proposition... some anti-virus vendors (like sophos) don't offer virus disinfection for most file infecting viruses because of this philosophy...
while the average joe may certainly prefer a magic bullet (and there are plenty of examples of people expressing exactly that), i'm not about to penalize a technology for failing to be a panacea - i'd rather penalize a proponent of it for falsely leading users to believe it is a panacea...
plain integrity checkers are purely detective mechanisms... they do not prevent and they do not restore, but they are (when used properly) practically infallible at detecting change...
Right - hence my QBASIC "text" file scenario. If I wrote a batchfile that fed that textfile to the QBASIC interpreter, then the batchfile would be the trojan threat - not the "text" file itself. Sure, I probably wouldn't want that textfile sitting around, but it is no more a trojan than deltree.exe is when a deltree.bat trojan is found.
All files could be a threat - most program files undergo stages of translation before ending up as an executable image. Even a PE file is an admixture of code, data, and program control data for the loader to use in building the executable image. Up until the point where tha user is taken out of the loop (the remaining points in the path to execution of the program are automated) the program is not a threat. Once the program is in a state where the next action taken by the user (invoking the program) is the last action he need take - the program file is usually termed "executable". Take a zipped (archive) file for instance - it is not a threat, and there is no reason to scan it at this point; but if Microsoft decided that users wanted to have double-click functionality that automatically extracted files from an archive and then automatically executed extracted program files named "install.exe" or "setup.exe" then we would have to consider zipfiles as executables on that system.
Your c:\\null file still requires something more before it can become a threat, and so should not be detected as a threat. A .doc file on the other hand might be associated with Microsoft "Word" and the path to execution of embedded macros is automated - so .doc files are "executable" under this condition. Incidentally, it used to be the case that OLE2 .doc files renamed to an extensionless filename (like NULL for instance) would be recognized when invoked as OLE2 filetype and opened in "Word" automatically running embedded macros. As long as the actual file structure is not OLE2, then your file was not "executable" sans extension.
So not being a "32 bit executable" means what exactly? How many different forms of executables are there? What about a DOS 6 device driver?
Relevance?
That it isn't by your findings a "32 bit executable" and therefore a false alarm does NOT follow logically. The detection did coincide with some nefarious virus like activity and was therefore NOT a false alarm. That the detection did coincide with a file that seems to contain code further seems to suggest that it's not a false alarm.
That conflicts with your assertion that the detection was a false alarm.
"it isn't one and won't execute "...."The code"...are opposite statements. Whether the code gets executed depends entirely or what/who loads the code and then jumps to the entry point. In this arena the definition of an executable or virus code needs to be very precise. Whether it runs by entering it's name at the DOS prompt isn't relevant.
The opposite appears to be the case although c:\\null may be just a part of the overall trojan or an intentional misdirection.
All the entries there are one of the following two: NUL=C:\\WINDOWS\\TTFCACHE C:\\WINDOWS\\SYSTEM\\CP_28605.NLS=C:\\WINDOWS\\SYSTEM\\TBMA0B0.TMP
The second appears ~15:1 over the first. Both appear multiple times.
Qdowas2.dll isn't found by Find on this W98se system nor is it found a on similarly configured other nearby W98se system I tried
SO, why did AVG suddenly trigger(find it)? Check all files was NOT turned on and I wasn't doing any kind of explorer window on c:\\ or anywhere else.
An action that you claim AVG wouldn't have noticed.
Careful parsing of your posts/assertions lead one to see that it is a self contradictory circle on this. The strong evidence is that it was NOT a false positive by a logical definition of 'positive'. Someone in this thread said "A systematic approach, will." I couldn't agree more.
So AVG could have been newly updated that day(6/15 I think) to look for this C:\\NULL behavior which it believes is a detectable symptom of nefarious activity: a positive.
No such user activity occurred proximate to this incident.
HUH, the detection DID occur. It happened in real time and NOT scan time at a moment that seems NOT to coincide with any usual virus time system activity.
It's initial detection was in real time on I think 6/15.
The file's date was 5/5/5.
That doesn't pass logical muster. I parse that statement to mean that there was NO FALSE positive in this case.
Seems NOT. AVG warned me about something unwanted. AVG apparently was NOT crying wolf. The fact that AVG seems to have worked outside the range of your experience isn't relevant.
Not relevant. It contains code. You find the loader.
You forgot to include the fact that half the scanners find it. In fact AVG starting finding it on the VERY DAY it found it on my system. AVG's day before's def file used at
formatting link
did NOT find it. Just a fortuitous introduction of a new false positive by AVG that corresponds to some unusual activity of my system?? What is starting to appear to be the most likely situation here? AVG and some others seem to know something you don't maybe?
Some WEP keys or most all WEP keys? By a competent hacker or only by the NSA? What's better than WEP, not easily cracked, widely & robustly implemented and easy to install/maintain? A 26 char hex key in minutes seems like it'd take something with Blue in it's name.
Define in detail please or provide URL[s].
Can you provide any reviews? What are its weaknesses? What's better in the reasonably priced wireless router market?
Are there any known(previously exploited) hacks through a Belkin and ZA in series?
Seems that case as also does the possibility of an undetected internal trojan on this machine or on the local LAN is the likely path/culprit.
??? wep always uses rc4 so you always know the stream cipher used to encrypt...
that's not the real issue though - the real issue is that with an output feedback stream cipher (like rc4), if you encrypt 2 messages (packets) with the same key (wep key + initialization vector) you can cancel out the key by XORing the 2 encrypted messages together... to keep this condition from happening you should change the wep key before the initialization vector has a chance to go through every possible value - but as has been shown not too long ago, the initialization vector can be forced through all possible values in a matter of minutes with properly crafted traffic...
so to ron: it's not a matter of breaking a 26 character hex key, it's actually no more difficult than getting the device to cycle between all possible 24bit initialization vectors... that's a much smaller number of possibilities and is easily accomplished in minutes...
lets save some time - zvi is an anti-virus developer/designer/vendor/what-have-you... if he says that something he's analyzed isn't a virus/worm/trojan then it probably isn't...
YES, the text file itself is and I'd expect a good checker to find and eliminate it if it was in fact part of a multistepped attack/penetration.
WRONG, deltree is part of a protected class...the OS itself. The WHOLE goal is protect the OS's integrity and intended functionality.
NO, that makes assumptions that a/the standard loading functions are being used.
Not relevant.
It is a threat or at least the tracks of a threat or at least a misdirection from a threat. The file didn't belong there. The file didn't get there by any ordinary and intended process. AVG detected it in real time and not by any user initiated scan. All indications are that there was NO FALSE positive. All the other circumstances surrounding this seem to support that. The fact that the file doesn't fit some parochial definition of a threat/executable isn't relevant.
Deduce the whole original 26 hex char key or just that particular packet? How much time/effort does it take a competent hacker to get the whole 26 hex char key and have full immediate access to the WiFi net?
I'll have a look at WPA. Is WPA secure outside an NSA effort?
Don't pay too much attention to the size of the key. You don't need to know the wep key to decrypt a packet if you know the cipher stream used to encrypt it. The initialisation vector used to generate cipher streams is only 24 bits (16-17 million possible streams) and is sent in the clear with the packet.
Hacking tools like airsnort
formatting link
collect particular packets within these 16 million possibilities and can deduce keys automatically.
These days WPA is the norm since WEP is so easy to break. Having said that, there are enough wireless networks around running no encryption at all to keep the hackers occupied. Why hack into yours when there will be one around the corner that doesn't require any hacking?
Whether you can upgrade to WPA with your win9x kit depends on the wireless equipment in use. With Linksys wireless cards, WEP is as good as it gets without upgrading to winxp and using the built in wireless support. Don't know about other hardware but certainly you should pay a visit to the manufacturer's website to see if there's a WPA update available.
It depends on the volume of your wireless output. The airsnort FAQ (as above url) will give you an idea of how long it could take to find yours.
Apart from having better encryption, it deals with some of the flaws of WEP eg. changing keys every few minutes and using proper hash authentication instead of crc based.
It's not perfect but it's much better than WEP if used with a long master key.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.