Page 2 of 5
Re: files corrupted, SHA not matching
Published: September 3, 2026 - 4:55 PM
by sfonteneau
After copying, is the MSI still signed by Microsoft?
Far-fetched theory:
Is the version still the expected one, or is it a higher version?
I'm starting to wonder if Microsoft might be replacing the binaries on the fly... that would be crazy, but anyway... it's a theory worth checking...
Re: files corrupted, SHA not matching
Published: September 4, 2026 - 10:27 AM
by Emmanuel64
Hello
, I hadn't seen your reply, so I added a line to my previous post which is still in the vein of bizarre things:
I copy the .msi to the desktop: hash OK.
I copy it to the root of C, the downloads folder, yes wapt\private\install: hash modified.
I bring it back to the desktop, the hash matches again
... so the file isn't modified. It's the hash calculation that seems to be truncated.
To answer your questions, I tried with all the new deployed package versions (currently 152.0.4191.62-48).
The Microsoft signature appears correctly on the .msi wherever it is.
In order to continue testing, I need clarification regarding wapt. When the .wapt package is downloaded to wapt\private\cache and then extracted to install, it is deleted even in case of failure (except for a few exceptions); Is there a way to manually decompress it on demand to study the decompressed files? => Found it... a simple decompression with 7-Zip, for example

Re: files corrupted, SHA not matching
Published: September 4, 2026 - 11:24 AM
by Emmanuel64
I'm finally starting to pinpoint the problem.
I download the .wapt file, manually extract it, and the hash is incorrect.
To speed things up, I manually scan the .msi file, and the hash is correct.
If I do the same thing with EDR completely disabled, the hash is incorrect for about twenty seconds (each test during this time yields a different hash, then the hash becomes correct).
However, on a machine without this issue, the behavior is different; the hash is correct immediately. The question now is
what's slowing down this check.

Re: files corrupted, SHA not matching
Published: September 4, 2026 - 11:57 AM
by sfonteneau
Emmanuel64 wrote: ↑Sep 4, 2026 - 11:24
To speed things up, I manually scan the .msi file; the hash is correct.
I didn't understand that sentence
Re: files corrupted, SHA not matching
Published: September 4, 2026 - 12:48 PM
by Emmanuel64
To clarify,
rather than waiting for an EDR scan, I scanned the file manually. A correct hash then appeared.
Re: files corrupted, SHA not matching
Published: September 4, 2026 - 1:23 PM
by Emmanuel64
Okay... I finally have the answer.
It was indeed the EDR that was causing the problem, despite a global policy applied to all machines.
When the EDR is completely disabled, some filters should remain active.
After uninstalling it, everything returns to normal and Wapt works correctly.
Now I just need to understand why the EDR is being overzealous on some machines, but I'll stop "polluting" this forum.
Thank you all for your interest and your answers.
Re: files corrupted, SHA not matching
Published: September 4, 2026 - 2:07 PM
by sfonteneau
Thanks for the feedback!
Could you please specify which EDR was used?
Re: files corrupted, SHA not matching
Published: September 4, 2026 - 9:02 PM
by Emmanuel64
I'm using the Withsecure EDR.
I now need to find out why, and how to properly purge the installation.
With wsuninstaller it worked on one machine, but not on another.
Re: files corrupted, SHA not matching
Published: September 7, 2026 - 9:23 AM
by sfonteneau
Emmanuel64 wrote: ↑Sep 4, 2026 - 9:02 PM
I use EDR Withsecure
It's always the same...
Of all the antivirus and EDR programs I've come across, it always seems to be the one causing problems... (even in wapt packages...)
Re: files corrupted, SHA not matching
Published: September 10, 2026 - 2:10 PM
by x-davidl
Hello,
I'd appreciate it if you find a solution, as we also use Withsecure and I can't seem to exclude this signature modification.
A third of our network is starting to have this error.
What's frustrating is why some computers have this issue while others, despite having the same Withsecure strategies, don't
. Regards.