Open czaczaczar opened 2 months ago
same here. I'll hold off until the dev can confirm this is a false positive.
Same.
So:
1) I read the Falsely detected as HackTool:Win64/ExplorerPatcher!MTB #3228issue that deals with the ExplorerPatcher!MTB
alarm.
2) I set WD to ignore this alarm.
3) But WD throws alarm for Backdoor:Win32/Bladabindi!ml
Windows Defender also complains
Bitdefender also quarantines the update stating: 'The file C:\Users\xxxxxxx\AppData\Roaming\ExplorerPatcher\Update for ExplorerPatcher from https꞉∕∕github.com∕valinet∕ExplorerPatcher∕releases∕latest∕download∕ep_setup.exe has been detected as infected with Trojan.GenericKD.74037883 and Bitdefender could not clean this item. A device restart is required to finalize the cleaning process.'
Seriously? We've been over this. https://github.com/valinet/ExplorerPatcher/issues/3228
Same for me - Bitdefender
Confirming issue with MS Defender
Detected: HackTool:Win32/Patcher!MTB Affected items: file: C:\Users\XXXX\AppData\Roaming\ExplorerPatcher\Update for ExplorerPatcher from https꞉∕∕github.com∕valinet∕ExplorerPatcher∕releases∕latest∕download∕ep_setup.exe
Same here...
Also not able to update. Windows defender blocks it as saying its a virus / hacktool.
quote from the release page at https://github.com/valinet/ExplorerPatcher/releases/tag/22621.3880.66.5_5094108
> [!WARNING]
You are downloading a file flagged as malware by Microsoft and very likely by other major antivirus vendors. We believe that this false flag indicates Microsoft's hatred against this software, not because this contains a virus or such.
Please include the following files and folders in your antivirus' exclusion list to prevent issues due to antivirus detections:
`C:\Program Files\ExplorerPatcher`
`%APPDATA%\ExplorerPatcher`
`C:\Windows\dxgi.dll`
`C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy`
`C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy`
For Defender, you can run the following script in PowerShell as an administrator:
```ps
Add-MpPreference -ExclusionPath "C:\Program Files\ExplorerPatcher"
Add-MpPreference -ExclusionPath "$env:APPDATA\ExplorerPatcher"
Add-MpPreference -ExclusionPath "C:\Windows\dxgi.dll"
Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy"
Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy"
If you are downloading from this page, please temporarily disable real-time protection or save to a folder excluded from antivirus scans.
Issues related to antivirus detections will be closed immediately. Discuss about this in #3228.
This is new - previous updates worked fine
This is new - previous updates worked fine
It is indeed new. MS has deemed EP dangerous and conveyed it as such to the AV world. Hence all the sudden commotion.
[!WARNING] You are downloading a file flagged as malware by Microsoft and very likely by other major antivirus vendors. We believe that this false flag indicates Microsoft's hatred against this software, not because this contains a virus or such.
Please include the following files and folders in your antivirus' exclusion list to prevent issues due to antivirus detections:
C:\Program Files\ExplorerPatcher
%APPDATA%\ExplorerPatcher
C:\Windows\dxgi.dll
C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy
C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy
For Defender, you can run the following script in PowerShell as an administrator:
Add-MpPreference -ExclusionPath "C:\Program Files\ExplorerPatcher" Add-MpPreference -ExclusionPath "$env:APPDATA\ExplorerPatcher" Add-MpPreference -ExclusionPath "C:\Windows\dxgi.dll" Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy" Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy"
If you are downloading from this page, please temporarily disable real-time protection or save to a folder excluded from antivirus scans.
Issues related to antivirus detections will be closed immediately. Discuss about this in #3228.
Read, everyone. I do not want to say that this is not a virus other than the reason statement above. If you are scared then stay on 65.5 (last release without detections) and freeze your OS updates.
It is just the installer that is flagged -- the DLLs that carry the patches are fine.
@Menno5 So 65.5 just got flagged as dangerous today by Kaspersky?
@Menno5 So 65.5 just got flagged as dangerous today by Kaspersky?
Sorry, I was confused here. Kaspersky started whining when trying to update within EP and also when downloading it manually. But that's of course for the 66.5 version. Just downloaded the 65.5 to check and when scanned, Kaspersky has no problems with it.
@hpchavaz Add the folders mentioned into exclusions. You will never have a luck with the "Allow on device" button.
I am making a new PowerShell-based online installer now so that what it does should be more transparent. And most importantly it shouldn't do various of stuff just by opening it which is what a malware usually does.
I ran the above script in PowerShell as an administrator. All is working as expected. Thank you.
I am getting this error when trying to run in power shell (as administrator):
@alex-zadara 0x800106ba means Defender is not active. You may have another antivirus program active.
Adding "c:\Users\XXuserXX\AppData\Roaming\ExplorerPatcher\" in antivirus exclusion solved the issue. Taskbar update and finally Win10 start menu is back again :)
You should report it to MS as a "FALSE POSITIVE" and ask them to justify their classification of it as malware. If you don't complain to them they will continue doing it - if you do there's a chance they will stop
@perdrix52 Tried, no luck. They did not give me a reason why but instead added it as malware into the "next definition update."
@perdrix52 Tried, no luck. They did not give me a reason why but instead added it into the "next definition update."
Probably that means that it will be marked safe again when the next definition update is received.
Edit: So no, they just flagged it?
Edited my comment.
I got errors trying to run the script:
Add-MpPreference : Operation failed with the following error: 0x%1!x!
At line:1 char:1
+ Add-MpPreference -ExclusionPath "C:\Program Files\ExplorerPatcher"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (MSFT_MpPreference:root\Microsoft\...FT_MpPreference) [Add-MpPreference],
CimException
+ FullyQualifiedErrorId : HRESULT 0xc0000142,Add-MpPreference
David
Did you run PowerShell as admin? Can you screenshot the console window fully with the title bar?
Running as Admin seemed to work - 66.5 now installed
Edit: So no, they just flagged it?
@goedzo Yup. Maybe a security expert can review my code for a formal justification.
This Looks Scary
it dosent run
Norton also finds it as virus... :-(
Same for me.
WD are warning me as well, can I install new EP safety ?
New update of Windows11 takes away full screen StartMenu(Windows10 style), I really love this. Can I take it back through install new EP ?
Duplicate of: https://github.com/valinet/ExplorerPatcher/issues/3228
Please close this.
MS just doesn't like EP and has added it to windows defender, even though it is not a virus and not a hack tool.
See the release notes here for the powershell script you can run that excludes all the directories necessary in windows defender: https://github.com/valinet/ExplorerPatcher/releases
The powershell script you must run with elevated privileges.
Future updates to EP won't be flagged then.
You can also set windows defender to exclude the directory that you manually download EP to so you can install it without windows defender blocking it.
if you get the error: 0x800106ba, it means Windows Defender is not active. You may have another antivirus program active.
If every AV tool on the planet reports a problem then I suggest that a thorough check to see that the sw is completely virus might be in order.
Most copy what Microsoft is doing, hence why you get so many false positives.
Also, all builds are done by github servers. And the source code is available, so you can verify yourself.
@pyrates999 Except the taskbar.
Just some progress on making an installer that's transparent on what it does. Hopefully this will be the way out of this situation.
I think it's about time the binaries get digitally signed - either via the Windows facilities or otherwise and introduce reproducible builds. Currently there is no way to verify the authenticity of the published binaries and whether the published binaries are built based on the open source code.
i ran
Add-MpPreference -ExclusionPath "C:\Program Files\ExplorerPatcher"
Add-MpPreference -ExclusionPath "$env:APPDATA\ExplorerPatcher"
Add-MpPreference -ExclusionPath "C:\Windows\dxgi.dll"
Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy"
Add-MpPreference -ExclusionPath "C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy"
But that didnt work
I think it's about time the binaries get digitally signed - either via the Windows facilities or otherwise and introduce reproducible builds. Currently there is no way to verify the authenticity of the published binaries and whether the published binaries are built based on the open source code.
All builds are done using github servers. So yes, it is verified.
I think it's about time the binaries get digitally signed - either via the Windows facilities or otherwise and introduce reproducible builds. Currently there is no way to verify the authenticity of the published binaries and whether the published binaries are built based on the open source code.
All builds are done using github servers. So yes, it is verified.
I don't think that is what is meant by this. Github servers are not a replacement for binary signing or SHA checkings.
Digital Signing
Digital signing is a cryptographic technique used to verify the authenticity and integrity of software. When binaries are digitally signed, a cryptographic signature is applied to them using a private key. Users can then verify this signature using a corresponding public key. This process ensures that the software has not been tampered with and that it comes from a trusted source. Digital signatures provide:
Authenticity: Verifies that the software is from a legitimate source.
Integrity: Ensures that the software has not been altered since it was signed.
Non-repudiation: The signer cannot deny their involvement in the signing process.
Windows facilities often involve tools like SignTool, which allows developers to sign their binaries with a code-signing certificate. Reproducible Builds
Reproducible builds ensure that the same source code will always produce the same binary when built with the same build environment. This is important for:
Verifying Source-to-Binary Correlation: Users can rebuild the software from the source code and compare the resulting binary with the published binary to ensure they match.
Trustworthiness: Reduces the risk of the binaries being modified or compromised between the source code and the final distribution.
GitHub Servers and Verification
While GitHub can handle build processes, it does not inherently ensure that the binaries are what they claim to be or that they are built from the expected source code. GitHub Actions and other CI/CD tools can build software, but they do not:
Sign Binaries: Binaries built on GitHub servers are not automatically signed.
Verify Authenticity Independently: GitHub's role is in facilitating the build; it does not provide a mechanism to verify that the build artifacts match specific source code or are signed.
Verification and Trust
To address the concern mentioned:
Binary Signing: Implementing digital signing of binaries ensures that users can verify the authenticity of the binaries.
Reproducible Builds: Ensuring that builds are reproducible helps verify that the published binaries are built from the exact source code available.
Both practices add layers of security and trust, allowing users to verify that the software they are downloading and using is genuine and has not been tampered with.
I think it's about time the binaries get digitally signed - either via the Windows facilities or otherwise and introduce reproducible builds. Currently there is no way to verify the authenticity of the published binaries and whether the published binaries are built based on the open source code.
All builds are done using github servers. So yes, it is verified.
I don't think that is what is meant by this. Github servers are not a replacement for binary signing or SHA checkings.
Digital Signing
Digital signing is a cryptographic technique used to verify the authenticity and integrity of software. When binaries are digitally signed, a cryptographic signature is applied to them using a private key. Users can then verify this signature using a corresponding public key. This process ensures that the software has not been tampered with and that it comes from a trusted source. Digital signatures provide:
Authenticity: Verifies that the software is from a legitimate source. Integrity: Ensures that the software has not been altered since it was signed. Non-repudiation: The signer cannot deny their involvement in the signing process.
Windows facilities often involve tools like SignTool, which allows developers to sign their binaries with a code-signing certificate. Reproducible Builds
Reproducible builds ensure that the same source code will always produce the same binary when built with the same build environment. This is important for:
Verifying Source-to-Binary Correlation: Users can rebuild the software from the source code and compare the resulting binary with the published binary to ensure they match. Trustworthiness: Reduces the risk of the binaries being modified or compromised between the source code and the final distribution.
GitHub Servers and Verification
While GitHub can handle build processes, it does not inherently ensure that the binaries are what they claim to be or that they are built from the expected source code. GitHub Actions and other CI/CD tools can build software, but they do not:
Sign Binaries: Binaries built on GitHub servers are not automatically signed. Verify Authenticity Independently: GitHub's role is in facilitating the build; it does not provide a mechanism to verify that the build artifacts match specific source code or are signed.
Verification and Trust
To address the concern mentioned:
Binary Signing: Implementing digital signing of binaries ensures that users can verify the authenticity of the binaries. Reproducible Builds: Ensuring that builds are reproducible helps verify that the published binaries are built from the exact source code available.
Both practices add layers of security and trust, allowing users to verify that the software they are downloading and using is genuine and has not been tampered with.
see here: https://github.com/valinet/ExplorerPatcher/discussions/2353
I think it's about time the binaries get digitally signed - either via the Windows facilities or otherwise and introduce reproducible builds. Currently there is no way to verify the authenticity of the published binaries and whether the published binaries are built based on the open source code.
All builds are done using github servers. So yes, it is verified.
I don't think that is what is meant by this. Github servers are not a replacement for binary signing or SHA checkings. Digital Signing Digital signing is a cryptographic technique used to verify the authenticity and integrity of software. When binaries are digitally signed, a cryptographic signature is applied to them using a private key. Users can then verify this signature using a corresponding public key. This process ensures that the software has not been tampered with and that it comes from a trusted source. Digital signatures provide:
Authenticity: Verifies that the software is from a legitimate source. Integrity: Ensures that the software has not been altered since it was signed. Non-repudiation: The signer cannot deny their involvement in the signing process.
Windows facilities often involve tools like SignTool, which allows developers to sign their binaries with a code-signing certificate. Reproducible Builds Reproducible builds ensure that the same source code will always produce the same binary when built with the same build environment. This is important for:
Verifying Source-to-Binary Correlation: Users can rebuild the software from the source code and compare the resulting binary with the published binary to ensure they match. Trustworthiness: Reduces the risk of the binaries being modified or compromised between the source code and the final distribution.
GitHub Servers and Verification While GitHub can handle build processes, it does not inherently ensure that the binaries are what they claim to be or that they are built from the expected source code. GitHub Actions and other CI/CD tools can build software, but they do not:
Sign Binaries: Binaries built on GitHub servers are not automatically signed. Verify Authenticity Independently: GitHub's role is in facilitating the build; it does not provide a mechanism to verify that the build artifacts match specific source code or are signed.
Verification and Trust To address the concern mentioned:
Binary Signing: Implementing digital signing of binaries ensures that users can verify the authenticity of the binaries. Reproducible Builds: Ensuring that builds are reproducible helps verify that the published binaries are built from the exact source code available.
Both practices add layers of security and trust, allowing users to verify that the software they are downloading and using is genuine and has not been tampered with.
see here: #2353
You don't have to use a paid solution for this. many Linux distributions and projects use digital signing and reproducible builds without significant costs. Here's how they manage it: Digital Signing in Linux
Free Tools and Certificates: Linux distributions often use free tools and mechanisms for signing. For example, GPG (GNU Privacy Guard) is widely used for signing packages and is free. Many distributions use GPG keys for signing packages and repository metadata.
Community Support: The Linux ecosystem benefits from a large, collaborative community that contributes to infrastructure and security practices. This can reduce costs associated with digital signing.
Built-In Support: Package management systems like apt for Debian-based distributions and dnf or yum for Red Hat-based distributions have built-in support for handling signed packages and repositories.
Reproducible Builds in Linux
Open-Source Tools: Many Linux distributions and projects use open-source tools for reproducible builds, such as reproducible-builds.org tools and scripts. These tools are generally available at no cost.
Collaborative Effort: The reproducible builds effort often involves a collaborative community of developers and organizations that contribute to and support the necessary infrastructure.
Cost Considerations
Initial Setup: There can be costs associated with the initial setup of signing infrastructure, such as obtaining code-signing certificates. However, many projects manage to offset these costs through community support, sponsorship, or by utilizing free tools.
Ongoing Maintenance: For larger organizations or projects, there might be ongoing costs related to maintaining the signing infrastructure and ensuring that builds remain reproducible. However, many of these costs are absorbed by the community or through collaboration with other projects.
In summary, while there may be costs associated with digital signing and reproducible builds, many Linux distributions manage these costs through community efforts, free tools, and collaborative support. For open-source projects, leveraging community resources and tools can make these practices more accessible and affordable.
discuss it here please: https://github.com/valinet/ExplorerPatcher/discussions/2353
22621.3880.66.5 New Kaspersky virus definitions and it doesn't see it as dangerous anymore. Also in the KSN (Kaspersky Safety Network) it's flagged as Trusted. Deleted all the rules for both Defender and Kaspersky. Defender still sees it as dangerous, Kaspersky is completely okay with it.
Also downloaded the 22621.3880.66.6 exe (no install) and that is also safe with a Kaspersky scan.
It's the first time I've seen this app as a trojan. Any thoughts? https://www.virustotal.com/gui/file/1c4e1847c722db18d58216c43aa40ad87c8a38aa6196e69d55c0687b8506bf94/details