NO, I simply followed his own logic and assertions which proved to be circular. His definitions are also parochial. Any expert should be able to express his views or opinions in plain logic without resorting to arcana. That's especially in this case which has very special properties. His own analysis included the assertion c:\\null "isn't benign".
kurt wismer wrote: [snip]
apparently this is the naive approach - the real method involved in the most recent demonstrations uses additional tricks to cut down the amount of traffic that needs to be collected...
it's still all done with publicly available tools, though...
My standard and any resonable standard would include the case where I was warned of nefarious activity involving this file. Apparently that happened.
YES, and this case clearly falls on the side of AVG having done its assigned job. It apparently did not give a false warning. I suspect that you'll find that what's accepted in the industry as a false positive is when a totally innocuous file from an innocuous source is flagged and reported by the anti-virus program. Apparently that did not happen in this case.
Not according to industry standards. It's "false" because it isn't malware and is a false *positive* because it isn't what the erring scanners claims it to be. The only way for it to be a true positive is if it the file contained the Qdown.s Trojan, incarnated.
Windows constantly writes uninvited stuff to your drive, which doesn't make it malware. The real world isn't only black or white, Ron, it's mostly gray over a large scale.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
That means that the file won't execute when directly loaded, with one of the Windows' executable extensions, e.g. exe, com, scr, pif, bat, vbs, ... etc. As for a DOS driver, forget it, it doesn't have the structure for that, not even close to.
The highest.
If you are that knowledgeable and know the answers to your questions, then why asking them? You can't ask questions, and at the same time set the terms of the answer should be.
You seem starting to comprehend.
You don't specify the date of the Wininit.bak file. The content doesn't seem related to the subject.
OK.
I don't know, you don't know, and repeating the question won't get you the answer. The way to know is to replicate the event in a controlled setup, and under surveillance.
I gave the two as examples, and you made them the rule. You won't get to the bottom of this if you won't relax that stiffness and open your mind to possibilities that aren't in your predefined checklist.
If the creation of NULL was originated from the outside (of your PC), then no, AVG wouldn't detect it, nor anything else, The only way to capture the creation of the NULL file is a trap set to capture that specific event.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
The beauty of logic is that you can prove with whatever you like. Suit yourself if it makes you happy. :)
I mentioned folder viewing by Explorer as an example, out of tens of activities that could have caused access to the file. Here is one more that people don't pay attention to: Background file indexing ... and the list goes on.
Your reluctance to accept won't bend the rules of science. ;) The AVG detection didn't occur at the time of the NULL file creation. Everything else is irrelevant.
What proof do you have?
Non sequitur.
Call it what you like, as long as we understand each other that the sample doesn't execute (i.e. a negative, in common terminology), and isn't the Qdown.s Trojan (i.e. false, in common terminology).
Frankly, you begin to tire me.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
"Nefarious" can't be quantified, nor qualified as false or true, therefore cannot serve as classification criterion in a standard.
If you insist on resolving that issue, then wait a couple of months and resubmit the sample to a
If OTOH it's a false positive, as I claim, then you will get more or less the same results as the current ones. [...]
If you think that your AV performed as expected, then be happy.
As for the definition of a false positive, you are in barren solitude.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
Malware doesn't make arbitrary changes, full stop. That's a fallacy that has been nurtured by ignorance, fools (e.g. Lambdin, with his unsolicited CRCs), and AVers that had an interest that users assimilate that nonsense.
You are actually saying the same thing, but from a different angle: Users were incapable to tell on base of the plain integrity change whether it was caused by virus or was benign.
Again, part of the above is propaganda, that was cultivated by interested parties. The fact is that DOS objects, all types, were recovered through integrity methods to their *exact* original state, to the byte, including the time and date stamp. The restored file would even occupy the same exact location on the hard drive, that it occupied before it was infected. Several products like NAV's inoculation, Eliashim's PIC, and Thunderbyte's Tbclean performed just as well as IV in restoring infected DOS files. The advantage of IV on the above was its better false positives rejection. Eventually, this was one of the reasons the integrity module lost importance in the above products (the other reasons are the advent of the Windows infectors, also known as PE infectors, and the orientation of the producers to scanners).
Your above assertion became true with the appearance of PE infectors. Disinfection of a PE object by scanner does never restore it to its exact pre infected state. It has nothing to do with malware modifying the file "arbitrarily" (malware doesn't do that), but with the complexity of the PE file structure and reverting the changes made to. Theoretically, *only* restoration from a suitable integrity signature can assure full recovery of PE objects, but as said, the signature file to do that will be prohibitively large. That's why we ended with real-time integrity monitoring only for PE file in our on-access module, and recovery for 16 bit objects only (in the offline module, not on access).
I hope that you don't point to me as I never made such claim. Which didn't prevent professional bashers from pretending that I did.
Let's extend the above now: Real-time AV optimized integrity checkers can detect an infection and block execution of that object. When implemented properly, real-time integrity monitoring is nearly infallible at detecting viral changes in monitored files.
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
Gaining access to the router setup, I suppose. Then disabling the router's firewall. But then what? What if only connection sharing and no print/file sharing is involved? In my case, the hacker would find a hardened OS with no open ports, no services running, and no known vulnerabilities to exploit He might also have a sw firewall behind the router to deal with.
Art
And just what criteria have been used to determine that it's "not benign"? Please be very specific.
No, it found smoke and shouted "Gun, Gun!". The smoke might just as well have come from a barbecue.
Since 5/5/05 is "Cinco de Mayo" maybe you should ask the Mexican authorities about it...PLONK!
DUH and why do you think I brought it up?
The only terms I set are that the answers be logically self consistent.
I never of course claimed any of the above. What I claim and you seem to support is that AVG warned me about something nefarious going on ragarding the not benign file c:\\null. AVG did its job therefore to regard its performance in this situation as a 'alse positive' is inaccurate.
I was hoping for some greater insight into what may have happened in my case rather than having the incident brushed off as a false positive which clearly it was NOT!
ALL very true. The fly in that ointment is that AVG chose that moment unrelated to anything seemingly going on suddenly to find that file. A file that seems not to contain some arbitrary fragments but something "not benign".
Maybe it just found the smoke from the smoking gun but apparently it did find a shooting.
Why do you insist that this file is *actively* malign? It might be the remnants of what happened in another place, and was left instead of being cleared after action (installaion? be it for good or evil purposes). I had leftovers of stuff, mostly in C:\\windows\\temp all the time, but a bad coder might use C:\\null instead and then fail to remove it properly.
Or the file is a "cookie", belonging to another program which you still haven't detected or meanwhile removed. It could be anything. AV scanners don't only alert on active malware. I once copied a portion of an infectious mail into a newsgroup posting, it was along the lines
Content-Type: audio/x-wav; name="message.scr"
(this example is taken from a worm I received just a few days ago; obviously there are stil many IE 5.x without SP2 out there, so that it would work)
Guess what happened: a virus scanner (not to be named here) screamed "dangerous content" and even spammed it into the news group. Other regulars got amused about this, and quoted my lines. And the AV screamed again, in spite of the quotation characters.
How good/bad is your AV program, to tell the difference?
Gabriele Neukam
snipped-for-privacy@t-online.de
attack/penetration.
A "trojan" is a program - and a text file is not a program - therefore a text file is not a trojan.
You profess to prefer logic, so there it is.
WRONG.
Microsoft (the developers of both "deltree.exe" the OS in question) say it is an application Just because something is bundled with an OS doesn't make it a part of that OS.
Don't go off on a tangent - the 'deltree.bat trojan' would be the trojan even if it first renamed "deltree" to "nulllfile.exe" and contained the line "nullfile /y c:\\windows".
execution
I don't understand what you mean here. Standard loading functions help determine that some filetypes are henceforward executed when invoked - that is, they are the reason these filetypes are termed executables. You want "all" files to be scanned for "everything" because you might want to feed them to an executable which translates and delivers an executable image to virtual memory without even using standard loading functions? A textfile, a script file, and "debug.exe" may fit the bill - but the scriptfile would be the threat and not the textfile.
What if your on-access scanner relied solely on emulation to use behavioral malware detection? Would you expect it to execute text files in emulation?
(invoking
instance -
"install.exe"
executables on
Invoking would result in execution of content without any further user interaction, and you say it is irrelevent and that something that is non-executable (invoking it reasults in nothing happening) is malware?
misdirection
I can't disagree with that (after all, it "is" something), I wouldn't mind too much if an on-demand scan flagged it as damaged or corrupted malware, but on-access scanners shouldn't waste any time on it.
Probably correct.
So I assumed by your earlier posts. If you had indicated it was flagged by an on-demand scan I would have thought it a misidentification rather than strictly a false positive detection. Clearly it "is' something - just not what it was identified as.
Quite the opposite actually.
No they don't, it seems that you don't know what a false positive detection is. It is not enough that a file looks like the malware it is identified as, it has to be capable of acting like that malware. Otherwise, why bother with it.
The fact that a trojan is an executable program isn't relevent to the fact that your AV flagged a non-executable as a trojan?
No, the point is that your "NULL" file is not a trojan - and "you" are missing that point.
WEP is WEP, whether it's 64 or 128-bit, and it's a known fact that you can crack the key within minutes using free software (AirSnort, WEPCrack, AirCrack, etc.)
Google search:
Here's 2 for starters for ZA:
Probably..
Was there anything human-readable in the NULL file?
(wasn't able to revisit this thread (read: no net access) for the past few days, or I would've replied earlier)
I could save $50/month by using one of the three open wireless networks available in my home office using a standard antenna, but I prefer to pay for my own DSL so I can secure it.
One neighbor told me to fsck off when I pointed out that his DSL and porno collection were publicly accessible, so I don't bother offering advice anymore - but it's nice to know I have backups if my service goes down :-)
Triffid
My admin password is 12 characters in length. Even if a somewhat longer one is allowed, it seems with processing speeds what they are now, a brute force approach might not take long to crack it.
I live way out in the boonies, about fourteen miles from the small city of Harrisburg. Hard for me to imagine hackers with high gain antennas roaming rural areas :) They say such antennas may work up to four miles away.
But no doubt the general wireless security situation is the pits. Most people I've talked to about it seem like they couldn't care less.
Art
Spoofing an approved mac address will probably also be required to gain LAN access but assuming that is sucessfully accomplished, that should give access to the router's web interface. However, its admin password is not known by the hacker at this stage and like all your other pc's there's no way into them.
Though your files might be safe (for the time being at least) there is still a listener on the network capable of picking up your "in the open" username/password combinations like pop3 email accounts or maybe when you ftp some new pages up to your website. And, of course, you might eventually access the router via. it's web interface. All these are plain text and there are plenty of tools available to list them all.
If the hacker gains access to the router, there is no point switching the firewall off because it isn't doing anything.
Jim.
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.