Infection messages?
in [Spyware]
|
From: Rick on 9 Dec 2009 06:05 "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in news:hfmpie02rbv(a)news3.newsguy.com: > >| When is wininit.ini processed? > > > > What OS are you referring to because NT based OS' don't use INI files. > Everything is pretty much stored in the Registry and evaluated there. > > Since this was x-posted to a WinXP group, the answer is NEVER. Not to be argumentative, but you're saying these folks are incorrect? http://www.aumha.org/a/loads.php http://support.microsoft.com/kb/140570 While I don't run into it as much as I used to, I still do find XP systems that appear to be using wininit.ini for file deletions/renames on occasion. -- Rick Simon rsimon(a)cris.com Include "spam(trap)key" somewhere in the body of any email to avoid spam filters.
From: David H. Lipman on 9 Dec 2009 06:50 From: "Rick" <rsimon(a)cris.com> | "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in | news:hfmpie02rbv(a)news3.newsguy.com: >>| When is wininit.ini processed? >> What OS are you referring to because NT based OS' don't use INI files. >> Everything is pretty much stored in the Registry and evaluated there. >> Since this was x-posted to a WinXP group, the answer is NEVER. | Not to be argumentative, but you're saying these folks are incorrect? | http://www.aumha.org/a/loads.php | http://support.microsoft.com/kb/140570 | While I don't run into it as much as I used to, I still do find XP systems | that appear to be using wininit.ini for file deletions/renames on occasion. Well the aumha article is for mostly Win9x/ME and the MS KB140570 is more for NT4 and Win9x/ME and you'll note mention of "Wininit.exe" which is NOT present in WinXP. So let me modify my NEVER answer to practically NEVER. Interpreting .INI files is an old construct that was used in Win9x/ME and and to a lesser degree in NT v3.5x and NT4 and thus *may* have some left over functionality in subsequent OS'. However for the most part, .INI files are no longer interpreted by the OS. Notice in the aumha article it states... "In Windows 2000 and XP, the WININIT.INI file, if existing, will be executed. However it is usually replaced by the �PendingFileRenameOperations� sub-key in the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager." This shows that for backwards compatibility Win2k and WinXP may interpret WININIT.INI but has been really replaced by Registry functionality. This will not affect Robin's problem as the message "INFECTION: DOCUMENTS AND SETTINGS\ROBIN BIGNALL\COOKIES\INDEX.DAT COULD NOT BE REMOVED. FILE IS NO LONGER EXISTENT" occurs "before the logon screen" and would not be generated by such a process. This is presumed to be a security tool/utility in action. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp
From: Rick on 9 Dec 2009 10:51 "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in news:hfo2tu0md9(a)news3.newsguy.com: > > So let me modify my NEVER answer to practically NEVER. Interpreting > .INI files is an old construct that was used in Win9x/ME and and to a > lesser degree in NT v3.5x and NT4 and thus *may* have some left over > functionality in subsequent OS'. However for the most part, .INI > files are no longer interpreted by the OS. Yes, I'm aware of how .ini files have been used going back through Win3.x. > Notice in the aumha article it states... > "In Windows 2000 and XP, the WININIT.INI file, if existing, will be > executed. However it is usually replaced by the > �PendingFileRenameOperations� sub-key in the Registry key > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager." > > This shows that for backwards compatibility Win2k and WinXP may > interpret WININIT.INI but has been really replaced by Registry > functionality. I'm also aware of how wininit.ini is just a hangover and there are other, preferred methods of doing the same thing. According to the aumha article however, even though it is not the preferred method, Win XP will execute the instructions in a wininit.ini file if one is found. > This will not affect Robin's problem as the message "INFECTION: > DOCUMENTS AND SETTINGS\ROBIN BIGNALL\COOKIES\INDEX.DAT > COULD NOT BE REMOVED. FILE IS NO LONGER EXISTENT" occurs "before the > logon screen" and would not be generated by such a process. This is > presumed to be a security tool/utility in action. And this is where my original question comes in. Just where in the boot process does wininit.ini get processed? Since the aumha article points out that: a) "WININIT.INI is used to complete Windows and program installation steps that cannot be completed while Windows is running" b) "During the boot process, Windows checks to see if there is a WININIT.INI file and, if it finds one, executes its instructions." c) and specifies that Windows XP will execute such a file, if it exists (assumedly to maintain backwards compatibility) I was just curious if anyone happened to know where in the boot process that execution was performed. Whether it was before or after the logon process. -- Rick Simon rsimon(a)cris.com Include "spam(trap)key" somewhere in the body of any email to avoid spam filters.
From: David H. Lipman on 9 Dec 2009 16:45 From: "Rick" <rsimon(a)cris.com> | "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in | news:hfo2tu0md9(a)news3.newsguy.com: >> So let me modify my NEVER answer to practically NEVER. Interpreting >> .INI files is an old construct that was used in Win9x/ME and and to a >> lesser degree in NT v3.5x and NT4 and thus *may* have some left over >> functionality in subsequent OS'. However for the most part, .INI >> files are no longer interpreted by the OS. | Yes, I'm aware of how .ini files have been used going back through Win3.x. >> Notice in the aumha article it states... >> "In Windows 2000 and XP, the WININIT.INI file, if existing, will be >> executed. However it is usually replaced by the >> �PendingFileRenameOperations� sub-key in the Registry key >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager." >> This shows that for backwards compatibility Win2k and WinXP may >> interpret WININIT.INI but has been really replaced by Registry >> functionality. | I'm also aware of how wininit.ini is just a hangover and there are other, | preferred methods of doing the same thing. According to the aumha article | however, even though it is not the preferred method, Win XP will execute | the instructions in a wininit.ini file if one is found. >> This will not affect Robin's problem as the message "INFECTION: >> DOCUMENTS AND SETTINGS\ROBIN BIGNALL\COOKIES\INDEX.DAT >> COULD NOT BE REMOVED. FILE IS NO LONGER EXISTENT" occurs "before the >> logon screen" and would not be generated by such a process. This is >> presumed to be a security tool/utility in action. | And this is where my original question comes in. Just where in the boot | process does wininit.ini get processed? Since the aumha article points out | that: | a) "WININIT.INI is used to complete Windows and program installation steps | that cannot be completed while Windows is running" | b) "During the boot process, Windows checks to see if there is a | WININIT.INI file and, if it finds one, executes its instructions." | c) and specifies that Windows XP will execute such a file, if it exists | (assumedly to maintain backwards compatibility) | I was just curious if anyone happened to know where in the boot process | that execution was performed. Whether it was before or after the logon | process. Rick I think you have a good point in that if the WININIT.INI file is found by the OS it will do a a file move/delete function "before the logon screen" which is 100% relevant to Robin's problem. However, this is a silent function. No screen displays and certainly not "INFECTION:...". Since you know this INI file and its directives, maybe you could create a test and see what it does. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp
From: Buffalo on 9 Dec 2009 20:19
Robin Bignall wrote: [snip] > John, Andy, thanks for the suggestions. I have checked autoruns. In > fact, A-squared contains a very useful feature called Hijackfree which > gives detailed information on what's present in 5 categories: > processes, ports, autoruns, services and others. I don't see anything > amiss. PCButts emailed me to make the sensible suggestion of checking > the runonce registry entries. They're empty. The weird thing is > where the message is coming from, since no executable on my system > disk contains the string "infection". Dl and instal a free anti-virus program like Avira AntiVir and install it. Disable or uninstall your present anti-virus program (A-squared) Uninstall your anti-malware programs and install the free version of MalwareBytes AntiMalware. Use it to scan frequently. See if you have the same problem. If not, install each of the programs you uninstalled or disabled one at a time to see if you can find out which one causes the problem. I don't think you ever said you installed and ran the free version of MBAM (MalwareBytes Anti-Malware) and the free version of SAS (SuperAntiSpyware). If you didn't (this is a damn long thread) please do it. Buffalo |