Pelles C forum
C language => Windows questions => Topic started by: Joris Claassen on July 30, 2012, 12:08:55 PM
-
A couple of anti virus programs mark all my compile results as viruses:
(13:CLAMAV:PUA.Win32.Packer.PellesC400450Ex-1 ()).
I can't control the anti virus programs which clients use. At least one client uses one of these to scan all incoming mail. So my e-mail with the program attached (in a zip) is never "delivered to the person". (i.e. the e-mail is removed by the virus scanner before it arrives in the mail inbox.) After searching at the web for a few days, I have only found that this is caused by the «runtime packed» a.k.a. «execution compression» feature of the compiler (or linker?). But I could find nowhere how to disable this feature. Does anyone know a pragma directive (or anything else) to achieve this?
I already installed UPX and tried to undo the compression (on the compile result «test.exe») with « packer -d test.exe » resulting in the message: packer: test.exe: NotPackedException: not packed by UPX
-
Pelles C does not produce compressed or packed executables. They're in standard windows Portable Executable (PE) format. Provided you are not actually writing virii :D .. if the AV scanner is complaining about them it is most likely a "false positive". What I would suggest is that you find out which AV programs are tagging your code and contact the companies to get this straightened out.
In the mean time there are some things you can investigate on your own...
1) Do the programs that get tagged have something in common? eg. A self-written function or library that might be causing the problem?
2) Do your programs include manifests? If not this may be the cause.
3) Are the programs in installers? It may be the installer that's triggering the AV alert.
4) Are you using the Pelles C wizards to create your programs? It could be that the wizard template is the problem.
... and probably more.
-
Thanks CommonTater, that explains why I can't find anything about disabling the packer ... ;)
Strange for a virus scanner to mark something as PUA.Win32.Packer.PellesC and then explain in their FAQ (http://www.clamav.net/lang/en/faq/pua/):
PUA – Possibly Unwanted Applications
ClamAV supports the detection of so called PUAs. At the moment the following categories are available:
Packed
This is a detection for files that use some kind of runtime packer. A runtime packer can be used to reduce the size of executable files without the need for an external unpacker. While this can‘t be considered malicious in general, runtime packers are widely used with malicious files since they can prevent a already known malware from detection by an Antivirus product.
I want to extend the possibilities at the command prompt of CAD programs (special request by a client). In order to place my extended version above the original one (so the end user might not even notice it's another application; and doesn't need to move eyes and mouse cursor ...) I have to find out where the command prompt is. So I use FindWindow(Ex) to determine the location (and size) and I use SendMessage at start to set the prompt text (which can differ!) and to retrieve the user input. I know virus scanners might detect this as suspected, but I think in that case the scanner shouldn't mark it as a «Packer» but as something like «interapplication communication, might be harmful». Then I know at least the right reason.
-
Ummmm... are you shure it's not reacting to the installer?
That's the only reason I can see that it might dub it a packing error, most installers do use self-expanding code.
I ran into this with an older version of Inno-Setup... someone must have submitted it as a trojan and all of a sudden none of my installers worked... Updating to the newest version (at the time) fixed the problem. But I also wrote to the AV company in question and chewed them out about not checking user sumbissions...
Given the "cheat" you're using I can see why a virus scanner might freak out on you... You are doing exactly what many viruses do; reading text from the screen. Although, not for nefarious reasons.
Maybe you should consider opening your own command prompt as a replacement for the standard one in the CAD program.... and "going legit" on how you gather input?
:D Sometimes we're too clever for our own good...
-
Hi Joris,
Try to configure your AV to define the executable in the exceptions list.
-
Try to configure your AV to define the executable in the exceptions list.
This only solves the problem for him, but not for the clients.
If you send the file to the clients use 7-zip to create a password protected archive, where the file names are encrypted too.
This has always worked for me to prevent the executable causing the whole message being dropped.
-
Try to configure your AV to define the executable in the exceptions list.
This only solves the problem for him, but not for the clients.
If you send the file to the clients use 7-zip to create a password protected archive, where the file names are encrypted too.
This has always worked for me to prevent the executable causing the whole message being dropped.
OR rename the .ZIP as .TXT and include instructions to rename it before unpacking it.... That's worked for me a few times.
-
OR rename the .ZIP as .TXT and include instructions to rename it before unpacking it.... That's worked for me a few times.
This does only work with virus scanners that do not scan the contents of the file, which are getting less and lesser.
Sure the encrypted 7-zip archive is sometimes rejected too, but that is only if the user selects to do so.
-
Ummmm... are you shure it's not reacting to the installer?
...
I don't use an installer at all. Whenever possible I only send a zip file. I think a big advantage of Pelles C results is that they usually don't depend on third party dll's/ocx's. Unless you code to. So there's no need to use installers to check the registry for existence of those and install them when absent. When the first clients start using MS Window 7, I also removed any use of/dependency on the registry for settings in favour of the ancient INI files to avoid UAC issues (and the risk of false positives).
...
Given the "cheat" you're using I can see why a virus scanner might freak out on you... You are doing exactly what many viruses do; reading text from the screen. Although, not for nefarious reasons.
...
I understand that a scanner might freak by the API calls, but it shouldn't mark it as PUA.Win32.Packer. (But something like PUA.Win32.I-dont-trust-apps-using-API-calls. )
I only determine the location of the command prompt to place my custom made command prompt1 above it to mimic the CAD one. It has it's own application window2. I don't change any properties of the CAD one (or any other CAD owned control/window). The user input is saved in a file which is read by a lisp routine. The build in lisp functions to retrieve user input are too restricted in functionality (=user experience).
Years ago I dropped LCC because a virus scanner marked all my compile results (even "Hello world"!) as threats. The "same code" in Pelles C didn't raise any suspicion. I don't know any of them (!) but I think that when a virus creator can write a virus using LCC as compiler, he can use any C(++) compiler.
1: Including a combobox "loaded" with previous entries for the specific function in progress.
2: Without caption/control bar/borders so the end user doesn't need to bother and might think it's the original CAD command prompt, but it's actually an external program. The window is not put in the window hierarchy of the CAD program.
-
I don't use an installer at all. Whenever possible I only send a zip file. I think a big advantage of Pelles C results is that they usually don't depend on third party dll's/ocx's. Unless you code to. So there's no need to use installers to check the registry for existence of those and install them when absent. When the first clients start using MS Window 7, I also removed any use of/dependency on the registry for settings in favour of the ancient INI files to avoid UAC issues (and the risk of false positives).
Using INI files will not get you around the UAC... UAC works by examining the resources of the EXE or DLL files looking for an imbedded manifest. If that fails it looks for a free standing manifest in the same folder as the executable. When there is no manifest it usually decides the program is risky and asks the user to confirm they want to proceed. Many virus scanners also check manifests...
1: Including a combobox "loaded" with previous entries for the specific function in progress.
2: Without caption/control bar/borders so the end user doesn't need to bother and might think it's the original CAD command prompt, but it's actually an external program. The window is not put in the window hierarchy of the CAD program.
It might be #2 that's tripping you up.
A virus scanner cannot legitimately freak out about individual windows API calls, directly, since they are by definition legitimate subroutines made available to the user. They work mostly by pattern recognition so it would take a complex of several calls to trip a legitimate positive. (For example a keyboard hook in a tight loop with disk writes might signal a keylogger.) Also keep in mind that C library functions are not magic, at some point many of them call Windows API functions to do their thing.
Given your descriptions so far, I would say your best bets are to 1) Add a manifest into your program's resources, 2) Use a properly formed window, 3) return to using registry settings. Each of these is at least worth a try... but I'd suggest you do all of them.
Since manifests are poorly explained on MSDN here's an example you can modify to your own uses...
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32"
name="AutoLogon"
version="1.0.0.0"
processorArchitecture="X86" />
<description>
Auto logon tool
</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
To personalize it for your programs you will need to change the name= to the name of your program (without extension), the description block to describe your program in 10 words or less, and if it's a 64bit program you would change the processorarchitecture to amd64. DO NOT change anything else. You would then import this file into your program's resources (create them if they don't already exist).
About the only other possibility I can think of is that some #$%#$%^ has reported a virus written in Pelles C (yes, it can happen) and now the scanner is freaking out about every Pelles C program. In that case I'd be getting hold of these AV guys right quick...
-
Given your descriptions so far, I would say your best bets are to
1) Add a manifest into your program's resources, ...
I do use manifest files in order to be able to communicate with CAD (and UAC not disabled!). That's not the issue here.
2) Use a properly formed window,
I made a VB6 exe version with the same API calls and window without caption/control bar/border : accepted by the mail virus scanner!
3) return to using registry settings. Each of these is at least worth a try... but I'd suggest you do all of them.
I mentioned the INI files, because I know a lot of registry sections are restricted by now. An ini file in the application (private) folder is still accepted (when compiled without PellesC) Actually the program which triggered this issue doesn't use INI files at all.
The program isn't run at all at the client side. The mail virus scanner blocks the mail before the recipient can look at it.
About the only other possibility I can think of is that some #$%#$%^ has reported a virus written in Pelles C (yes, it can happen) and now the scanner is freaking out about every Pelles C program. In that case I'd be getting hold of these AV guys right quick...
I think that's the case. (As usual the good suffer from the bad.)
I made a DLL version with exacly the same API calls: accepted by the virus scanner.
I made the hello world program with the Windows exe wizard (unmodified): blocked!
Unfortunately using the DLL inside VBA makes CAD crash, otherwise I would use that. The VB6 version interpreted the coordinates as negative values (because VB doesn't know unsigned variable types). So now I decided to make a VB6 version using a DLL for repositioning. So except for the calls to «GetWindowRect» and «MoveWindow», all API calls are inside the VB6 exe.
I think it's pity that I need to use VB6 to workaround this.
-
I think it's pity that I need to use VB6 to workaround this.
It is... there's obviously something very wrong here.
That it blocked "hello world" is troubling, since it could indicate there's a problem in the PE file structure itself.
Try this... (Assuming you're on Pelles C ver7) Uninstall Pelles C, completely. Even go to the registry and remove the Pelle Orinius branch from the software section... Install Pelles C 6.5 ...
In your project folders open the .prj files in notepad and change the POC_PROJECT_VERSION macro to 6.0... This will cause a couple of errors you'll have to fix in the compiler flags, but that's not hard... recompile your project and let me know what happens when you email it...
(I'm operating on the theory there's something about the new version... )
-
HelloC.c with versions 6.0, 6.5 and 7.0 for testing.
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello C\n");
return 0;
}
-
Actually I'm still using version 6.00.4, my ppj files contain:
POC_PROJECT_VERSION = 6.00#
Until last week this version worked for me, so I had no reason to change.
I have sent 3 e-mails each containing one of the files posted by timovjl: all resulting in
Remote host said: 550 5.7.1 Message contains a virus (13:CLAMAV:PUA.Win32.Packer.PellesC400450Ex-1 ()) [BODY]
So I think some #$%#$%^ made a virus with Pelles C and now we are all ... up, because Clamav has marked the Pelles C exe PE structure to be suspected.
-
So I think some #$%#$%^ made a virus with Pelles C and now we are all ... up, because Clamav has marked the Pelles C exe PE structure to be suspected.
Then you need to take those samples and send them to the AV company and get this straightened out. I'd send the whole project so they can see there's nothing wrong.
@Timo ... thanks for that. Very helpful!
Update: I just sent timo's samples to a friend of mine. He confirms over the phone they went through his scanners just fine (AVG)...
-
Just made a couple of quick tests before leaving the house:
- on my local PC here, running AVast! as the AV, those files from timovjl come up clean.
- on another PC, running AVG, likewise no problem with a local scan
- sending those files as attachments to my own email server, which has a plug-in to scan for viruses with ClamAV, results in a error message because of the attachments (error message in this case is a bit vague though)
- scanning those files on the same server locally with ClamWin (which uses the very same ClamAV engine!) comes up clean again... WTF?
Definitely something that the folks at ClamAV/SourceFire need to look at I guess...
Ralf
-
From « http://www.clamav.net/lang/en/sendvirus/submit-fp/ »
Please do not report false positives for PUA.* signatures because they are automatically rejected (What is PUA?).
So I think the Clamav folks are not willing to cooperate at all!
-
From « http://www.clamav.net/lang/en/sendvirus/submit-fp/ (http://www.clamav.net/lang/en/sendvirus/submit-fp/) »
Please do not report false positives for PUA.* signatures because they are automatically rejected (What is PUA?).
So I think the Clamav folks are not willing to cooperate at all!
:D You give up too easily...
Try writing to jesler@sourcefire.com (jesler@sourcefire.com) ... attach the projects Timo provided and give a thorough description of the problem... Lets hope you get a favourable response because this is their fault and it's not funny. It will affect the distribution of many people's work (including my own).
Update... got a reply from sourcefire...
The following message to <jesler@sourcefire.com> was undeliverable.
The reason for the problem:
5.3.0 - Other mail system problem 552-'5.7.0 Our system detected an illegal attachment on your
message. Please\n5.7.0 visit http://support.google.com/mail/bin/answer.py?answer=6590 (http://support.google.com/mail/bin/answer.py?answer=6590) to\n5.7.0
review our attachment guidelines. tu10si5762653pbc.321'
Renaming the .zip files as .txt appears to have gotten them past GMail's paranoia...
Update2 : Reply from Joel Esler... (Highlights, mine)
ClamAV is not flagging your software as malicious. ClamAV is simply just identifying the packer used to pack
the software into an executable form. This is off by default in our product, and has to be explicitly enabled.
Recently we've become aware that certain file scanning sites (like Virustotal) scan using this option enabled.
We have been in contact with Virustotal to remove this functionality on their site, and they have assured us
that they will.
Again, we are NOT flagging your product as malicious, we are simply providing information as to the packer of
the software.
$ clamscan HelloC-v*
HelloC-v65.txt: OK
HelloC-v6.txt: OK
HelloC-v7.txt: OK
----------- SCAN SUMMARY -----------
Known viruses: 1278845
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 3
Infected files: 0
Data scanned: 0.12 MB
Data read: 0.04 MB (ratio 3.33:1)
Time: 6.123 sec (0 m 6 s)
$ clamscan --detect-pua=yes HelloC-v*
HelloC-v65.txt: PUA.Win32.Packer.PellesC400450Ex-1 FOUND
HelloC-v6.txt: PUA.Win32.Packer.PellesC400450Ex-1 FOUND
HelloC-v7.txt: PUA.Win32.Packer.PellesC400450Ex-1 FOUND
----------- SCAN SUMMARY -----------
Known viruses: 1284100
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 3
Infected files: 3
Data scanned: 0.08 MB
Data read: 0.04 MB (ratio 2.33:1)
Time: 3.344 sec (0 m 3 s)
=========================
Based on this it would appear to be the settings on some servers that's the problem...
-
Last update on this issue... ClamAV is going to remove the signature that tags Pelles C as a virus.
======================================================
> Really, Joel, in all due respect this whole problem was 100% preventable
> with nothing more dramatic than a bit of foresight. Seriously, you have to
> know that someone is not going to know what a "PUA" is and decide to enable
> it "just in case"...
I can see your point there. I'll drop the signature for your particular packer.
--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire
-
New development in the AV world.
I happen to start a scan today (during lunch/diner; Comodo) which resulted in UnclassifiedMalware@285363702 ...\HelloC-v7.zip|HelloC.exe
I notified Comodo that this is a false positive. So I wonder what will happen in a few days during a new scan ...
Unzipping caused Comodo to freak out. (Also a flash message appeared -maybe by Universal Extractor- claiming that the zip contains strange characters in the path name. The message doesn't appear again when re-unzipping [?!])
Scan on resulting files: no threats found.
Scan on zip file HelloC-v7.zip: UnclassifiedMalware@285363702.
-
New development in the AV world.
I happen to start a scan today (during lunch/diner; Comodo) which resulted in UnclassifiedMalware@285363702 ...\HelloC-v7.zip|HelloC.exe
I notified Comodo that this is a false positive. So I wonder what will happen in a few days during a new scan ...
Unzipping caused Comodo to freak out. (Also a flash message appeared -maybe by Universal Extractor- claiming that the zip contains strange characters in the path name. The message doesn't appear again when re-unzipping [?!])
Scan on resulting files: no threats found.
Scan on zip file HelloC-v7.zip: UnclassifiedMalware@285363702.
Did it not react to 6.0 and 6.5 versions?
I would like you to try something with the same files... recompile the EXE with optimizations off and try it again... I know this seems like an unlikely cause but given events in another thread, we shouldn't write it off as a possibility.
This is getting to be a real annoyance... I had one of my "small utilities" (a text file converter; various unicodes to utf8) stripped by an ISP last Wednesday and they didn't seem at all interested in fixing the problem, even when I sent them a copy to examine. I ended up sending a cd to the client via overnight courier at my own expense. ( :( and who uses cd's anymore?)
-
From http://pellesc.de/index.php?page=download&lang=en&version=7.00 (http://pellesc.de/index.php?page=download&lang=en&version=7.00)
Please uninstall any older version of Pelles C before installing version 7.00.
So you mean: only play with different optimizations/settings for the 6.0 version?
I • made 10 different versions: -Tx86-coff -MT -Os -Ob1 -fpprecise -W0 -Gz -Ze -Zx -Go -Gn -J
-Tx86-coff -MT -Os -Ox -Ob1 -fpfast -W0 -Gz -Ze -Zx -Go -Gn -J
-Tx86-coff -MT -Ot -Ox -Ob1 -fpfast -W0 -Gz -Go -Gn
-Tx86-coff -Ot -Ob1 -fpprecise -W0 -Gd
-Tx86-coff -MT -Ob0 -fpprecise -W0 -Gr -Ze -Gn
-Tx86-coff -MD -Ot -Ob1 -fpprecise -W0 -Gd -Zx -J
-Tx86-coff -MT -Ot -Ob1 -fpprecise -W0 -Gd -Zx -J
-Tx86-coff -MD -Ot -Ob1 -fpprecise -W0 -Gz -Ze -Zx -Go -Gn -J
-Tx86-coff -MT -Ot -Ob1 -fpprecise -W0 -Gz -Ze -Zx -Go -Gn -J
as wince(!) + -Tx86-coff -MT -Ob0 -fpprecise -W0 -Gd -Ze -Gn + -AIA32 -Gr
• scanned them all with Comodo: no threat(s) found
• sent them one at a time to the e-mail address at the server using Clamav scanner: all e-mails arrived.
Although -Tx86-coff -MT -Os -Ob1 -fpprecise -W0 -Gz -Ze -Zx -Go -Gn -J
-Tx86-coff -MT -Os -Ox -Ob1 -fpfast -W0 -Gz -Ze -Zx -Go -Gn -J
needed much more time to be sent (but that can also be caused by network or server load ...)
So I rescanned «HelloC-v7.zip» with Comodo: same UnclassifiedMalware threat recognized.
Sending «HelloC-v7.zip» to the Clamav-using e-mail server: no threat found.
Resending the original e-mail which made me start this discussion to the same e-mail server: no threat found. So the false positive by Clamav seems to be fixed (unless someone has changed the settings on this server).
-
Please uninstall any older version of Pelles C before installing version 7.00.
So you mean: only play with different optimizations/settings for the 6.0 version?
:D Yeah, I suppose I do mean that :D ...
I made 10 different versions
...
• scanned them all with Comodo: no threat(s) found
• sent them one at a time to the e-mail address at the server using Clamav scanner: all e-mails arrived.
That's progress... What I was trying to discover was if a code difference between optimized and non-optimized compiles might be causing the problem. (The optimizer has it's own set of problems.)
So I rescanned «HelloC-v7.zip» with Comodo: same UnclassifiedMalware threat recognized.
Sending «HelloC-v7.zip» to the Clamav-using e-mail server: no threat found.
Resending the original e-mail which made me start this discussion to the same e-mail server: no threat found. So the false positive by Clamav seems to be fixed (unless someone has changed the settings on this server).
It appears Joel was true to his word. He was nice enough to change that for us without much of a fuss.
Now the problem shows up with Comodo... Nice... :(
Remember when programming used to be a fun and creative undertaking?
-
Great news (Not)... Emsisoft's Emergency Kit on demand virus scanner has begun tagging Pelles C as infected.
-
All downloads of the Pelles C setup files with I.E. 10 on Windows 8 produces the following message
"setup.exe was reported as unsafe."
Something is really amiss with so many vendors reporting a problem.
Robert Wishlaw
-
All downloads of the Pelles C setup files with I.E. 10 on Windows 8 produces the following message
"setup.exe was reported as unsafe."
Something is really amiss with so many vendors reporting a problem.
Robert Wishlaw
Hi Robert...
This is the first time I've heard anyone say the setup for Pelles C itself was a problem. Up to now it's mostly been programs written in Pelles C.
But yes, I agree this is not good at all...
All versions were tagged or just version 7?
-
All downloads of the Pelles C setup files with I.E. 10 on Windows 8 produces the following message
"setup.exe was reported as unsafe."
Something is really amiss with so many vendors reporting a problem.
Robert Wishlaw
Hi Robert...
This is the first time I've heard anyone say the setup for Pelles C itself was a problem. Up to now it's mostly been programs written in Pelles C.
But yes, I agree this is not good at all...
All versions were tagged or just version 7?
Hi Tater:
On the download site
http://smorgasbordet.com/pellesc/download.htm
only Version 7 setups are available. Both 32 and 64bit setups and add in SDKs were flagged as unsafe.
Robert Wishlaw
-
Both 32 and 64bit setups and add in SDKs were flagged as unsafe.
This might just be due to the missing certificate as mentioned at the top of that page.
-
Hi Tater:
On the download site
http://smorgasbordet.com/pellesc/download.htm (http://smorgasbordet.com/pellesc/download.htm)
only Version 7 setups are available. Both 32 and 64bit setups and add in SDKs were flagged as unsafe.
Robert Wishlaw
You can access old versions all the way back to 2.8 on the mirror site ... HERE (http://www.pellesc.de/index.php?page=download&lang=en&version=7.00)
It would be nice to know if it's version 7, some versions or all versions...
Although it may simply be as Stephan said... the lack of a certificate.
(Oh how I hanker for simpler times...)
-
Hi Tater:
On the download site
http://smorgasbordet.com/pellesc/download.htm (http://smorgasbordet.com/pellesc/download.htm)
only Version 7 setups are available. Both 32 and 64bit setups and add in SDKs were flagged as unsafe.
Robert Wishlaw
You can access old versions all the way back to 2.8 on the mirror site ... HERE (http://www.pellesc.de/index.php?page=download&lang=en&version=7.00)
It would be nice to know if it's version 7, some versions or all versions...
Although it may simply be as Stephan said... the lack of a certificate.
(Oh how I hanker for simpler times...)
I just installed Windows 8 RTM Enterprise and the Pelles C 7 setup64.exe downloads from both Christian Heffner's and the Smorgasbordet sites are flagged as
"The signature of setup64.exe is corrupt or invalid."
Thank you for the link to the old versions. The 6.5 RC4 download does not raise any warnings.
Robert Wishlaw
-
Thank you for the link to the old versions. The 6.5 RC4 download does not raise any warnings.
That's interesting...
I know the version 7 is OK, I use it... Can you not bypass the warning and download it anyway?
-
So this really seems to be related to the custom certificate used for v7, which is based on a SHA1 hash only.
-
Thank you for the link to the old versions. The 6.5 RC4 download does not raise any warnings.
That's interesting...
I know the version 7 is OK, I use it... Can you not bypass the warning and download it anyway?
The warning can be bypassed.
I know, trust me, I'm from the Internets but is this the party to whom I am speaking?
Robert Wishlaw
-
I know, trust me, I'm from the Internets but is this the party to whom I am speaking?
Ahhh... I sense a hint of Lily Tomlin.... One Ringy Dingy... Two Ringy Dingy... :D
But seriously folks...
I think Stefan has it... it's probably the certificate.
-
I know, trust me, I'm from the Internets but is this the party to whom I am speaking?
Ahhh... I sense a hint of Lily Tomlin.... One Ringy Dingy... Two Ringy Dingy... :D
But seriously folks...
I think Stefan has it... it's probably the certificate.
Yeah probably but after finding
2012-06-18 20:10:43:006 960 4fc Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\Handler\WuSetupV.exe:
2012-06-18 20:10:43:037 960 4fc Misc Microsoft signed: Yes
2012-06-18 20:10:43:037 960 4fc Misc WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\SelfUpdate\Handler\WuSetupV.exe are not trusted: Error 0x800b0001
....
2012-06-18 20:10:45:861 960 4fc Misc Validating signature for C:\Windows\SoftwareDistribution\WuRedir\7971F918-A847-4430-9279-4A52D1EFE18D\muv4muredir.cab:
2012-06-18 20:10:45:907 960 4fc Misc Microsoft signed: Yes
2012-06-18 20:10:45:907 960 4fc Misc WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\WuRedir\7971F918-A847-4430-9279-4A52D1EFE18D\muv4muredir.cab are not trusted: Error 0x800b0001
in my WindowsUpdate.log I have become a little more cautious even though I live in Canada and not Iran.
Robert Wishlaw
-
Hi Robert ... I'm in Canada too. Just across the lake from Toronto...
Sounds to me like this whole virus thing is getting out of hand. IZArc is having the same problems, they even have a note on their website about it... and it's written in VC++... go figure.