2

I have implemented prerequisites using ExePackage with RemotePayload because I need to download package using runtime webinstaller (DownloadURL). But in that when package is upgraded after sometime like quarterly update that time package version and hash value is also changed. So, I get error like 0x80091007 (Hash value is not correct). So, please help me if anyone have idea about how to ignore hash value check. Below is code which I have implemented:

<ExePackage
Id="MicrosoftEdgeWebview2"
DisplayName="Microsoft Edge Webview2 Runtime"
Compressed="no"
Cache="no"
PerMachine="yes"
Vital ="yes"
Permanent ="yes"
InstallSize="1"
InstallCommand="/silent /install"
DetectCondition="MicrosoftEdgeWebview2Version &gt;= $(var.MicrosoftEdgeWebview2MinimumVersion) OR MicrosoftEdgeWebview2Version64 &gt;= $(var.MicrosoftEdgeWebview2MinimumVersion)"
Name="MicrosoftEdgeWebview2Setup.exe"
DownloadUrl="https://go.microsoft.com/fwlink/p/?LinkId=2124703">
<RemotePayload
               ProductName="Microsoft Edge Webview2 Runtime"
               Description="Microsoft Edge Webview2 Runtime Setup"
               Hash="080e3e4cdcfc809762a32e8fa7cdc0f37b8e36a5"
               Size="1778968" Version="1.3.153.47" />
Harsh Modhiya
  • 41
  • 5

1 Answers1

5

For security reasons, the Burn engine will always verify the payload. To avoid hash validation, you have to specify certificate information in the RemotePayload so it validates the digital signature instead. You should use heat.exe payload ... to harvest this information.

"%WIX%\bin\heat.exe" payload windowsdesktop-runtime-5.0.5-win-x64.exe -o windowsdesktop-runtime-5.0.5-win-x64.exe.wxs

<RemotePayload
CertificatePublicKey="F49F9B33E25E33CCA0BFB15A62B7C29FFAB3880B"
CertificateThumbprint="ABDCA79AF9DD48A0EA702AD45260B3C03093FB4B"
Description="Microsoft Windows Desktop Runtime - 5.0.5 (x64)"
Hash="9CE1E77FE51E3F104D1DF7670F83F12B8ABF82F6"
ProductName="Microsoft Windows Desktop Runtime - 5.0.5 (x64)"
Size="54977944"
Version="5.0.5.29917"
/>
Sean Hall
  • 7,629
  • 2
  • 29
  • 44
  • 1
    FWIW I've seen certificate verification issues also. As an example, MSFT released the .NET 4.8 Web installer using the same URL but with a new certificate. Broke my remote payload. – Christopher Painter Jan 19 '22 at 03:43
  • Yes, that's by design. Certificate verification in Burn requires that the signature is valid and that the given certificate information is in the signing chain of certificates for that signature. Burn doesn't want an attacker to be able to serve a malicious file that is signed through any random certificate trusted by the machine. – Sean Hall Jan 19 '22 at 16:23
  • I have seen that certificate values is also changed after sometime. so, it is also not reliable and broke the remote payload. Anyone have any better approach for remote payload? – Harsh Modhiya Feb 10 '22 at 13:31
  • No, those are the only two choices - hash or certificate validation. Burn doesn't want an attacker to be able to serve a malicious file that then gets run under administrator privileges because that is a privilege escalation attack. – Sean Hall Feb 10 '22 at 15:34
  • I have noticed for major.minor.patch.build, when major, minor, patch has been changed then we might have different certificate value and if last build_number is different then we have same certificate. Is it correct? – Harsh Modhiya Feb 15 '22 at 14:38
  • In general, no that is not correct. Anyone can sign a file with a different certificate whenever they want. For Microsoft, they're not going to change it based on the version of the file they're signing. They'll change it based on other factors, like certificate expiration or if the certificate was created with outdated technology like SHA1. – Sean Hall Feb 15 '22 at 18:43