Update Resource Hacker

[MalwareMechanic]

Update Resource Hacker to use the latest chocolatey package 5.2.4 (https://community.chocolatey.org/packages/reshack.portable).

Closes #739

[MalwareMechanic]

It's failing on windows-2022 with:

Attempt to get headers for http://www.angusj.com/resourcehacker/resource_hacker.zip failed.
  The remote file either doesn't exist, is unauthorized, or is forbidden for url 'http://www.angusj.com/resourcehacker/resource_hacker.zip'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (403) Forbidden."
Downloading reshack.portable 
  from 'http://www.angusj.com/resourcehacker/resource_hacker.zip'
ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'http://www.angusj.com/resourcehacker/resource_hacker.zip'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (403) Forbidden." 
This package is likely not broken for licensed users - see https://docs.chocolatey.org/en-us/features/private-cdn.
The upgrade of reshack.portable was NOT successful.

Not sure how to handle cases like this since it is out of our control.

@mandiant/flare-vm thoughts?

[Ana06]

@MalwareMechanic the issue is that GH is blocking this url, right?

[Ana06]

did reshack work?

[MalwareMechanic]

Previously the issue was that the URL was inaccessible from the GitHub's perspective (unauthorized or forbidden). In the most recent run, the hash has already changed.

The issue now is we rely on a fixed version of the community package and the community package uses a URL that is NOT versioned (see: https://community.chocolatey.org/packages/reshack.portable#files).

This results in multiple failure points when the hash changes:

• The community package will break if not updated very quickly
• Our package will fail since we rely on an older version of the community package (the hash won't match in the older version due to the URL pointing to a newer tool version).

Below is the most recent error:

reshack.portable v5.2.4.386 (forced) [Approved]
reshack.portable package files upgrade completed. Performing other installation steps.
WARNING: Url has SSL/TLS available, switching to HTTPS for download
File appears to be downloaded already. Verifying with package checksum to determine if it needs to be redownloaded.
Error - hashes do not match. Actual value was 'F958DB1D239E69051145[77](https://github.com/mandiant/VM-Packages/actions/runs/6828057488/job/18937701487?pr=741#step:4:78)7DE9943B267A3230CC3D140599B48CF024E2C8B3A2'.
Downloading reshack.portable 
  from 'https://www.angusj.com/resourcehacker/resource_hacker.zip'

Download of resource_hacker.zip (3.2 MB) completed.
Error - hashes do not match. Actual value was 'F958DB1D239E69051145777DE9943B267A3230CC3D140599B48CF024E2C8B3A2'.
ERROR: Checksum for 'C:\Users\runneradmin\AppData\Local\Temp\chocolatey\reshack.portable\5.2.4.386\resource_hacker.zip' did not meet '8e56a5c84999f036355759e5cb759e3055df761b55d9ae6a72[82](https://github.com/mandiant/VM-Packages/actions/runs/6828057488/job/18937701487?pr=741#step:4:83)5d4199f328e9' for checksum type 'sha256'. Consider passing the actual checksums through with --checksum --checksum64 once you validate the checksums are appropriate. A less secure option is to pass --ignore-checksums if necessary.

Since the download for the tool isn't versioned: https://angusj.com/resourcehacker/#download, we'll continue to run into hash issues even if we try to maintain a custom package. Though if we maintained a custom package we may be able to bypass hash checks if we really needed to (though off hand I'm not familiar with how to do this).

[MalwareMechanic]

A stop gap we could do is not version the dependency in our metapacakge and hope that the community package is updated when the hash changes.

[MalwareMechanic]

So strange, now it's trying to use resourcehacker.portable instead of reshack.portable:

Upgrading the following packages:
resourcehacker.vm
By upgrading, you accept licenses for the packages.

resourcehacker.portable v5.1.8 (forced) [Approved]
resourcehacker.portable package files upgrade completed. Performing other installation steps.
WARNING: Url has SSL/TLS available, switching to HTTPS for download
Downloading resourcehacker.portable 
  from 'https://www.angusj.com/resourcehacker/resource_hacker.zip'

Download of resource_hacker.zip (3.2 MB) completed.
Error - hashes do not match. Actual value was 'F958DB1D239E69051145777DE9943B267A32[30](https://github.com/mandiant/VM-Packages/actions/runs/6960518789/job/18940215513?pr=741#step:4:31)CC3D140599B48CF024E2C8B3A2'.
ERROR: Checksum for 'C:\Users\runneradmin\AppData\Local\Temp\chocolatey\resourcehacker.portable\5.1.8\resource_hacker.zip' did not meet 'D158BEBC2993CF6BEBF2C23A9[35](https://github.com/mandiant/VM-Packages/actions/runs/6960518789/job/18940215513?pr=741#step:4:36)72A68544C2BA5AE0565[38](https://github.com/mandiant/VM-Packages/actions/runs/6960518789/job/18940215513?pr=741#step:4:39)F70A58075C9[39](https://github.com/mandiant/VM-Packages/actions/runs/6960518789/job/18940215513?pr=741#step:4:40)2D6' for checksum type 'sha256'. Consider passing the actual checksums through with --checksum --checksum64 once you validate the checksums are appropriate. A less secure option is to pass --ignore-checksums if necessary.
The upgrade of resourcehacker.portable was NOT successful.

Our metapackage .nuspec file depends on: <dependency id="reshack.portable" />
I wonder if it's because I essentially reset the metapackage's version?

[MalwareMechanic]

Alright, so if I revert our metapackage version the modified .nuspec file is not picked up in the change for testing ( test uses the old version). So we're at a standstill until we figure out the direction we want to go.

I see the following solutions:

• Ask the tool author to maintain versioned download links
• Delete and remake our metapackage with versioning syntax 0.0.0.YYYYMMDD and use a non-versioned dependency

Thoughts @Ana06 ?

[Ana06]

Delete and remake our metapackage with versioning syntax 0.0.0.YYYYMMDD and use a non-versioned dependency

We have decided not to do this for other packages because then we are "acepting" having broken packages. This is an issue when installing FLARE-VM as you don't know if some packages will install until you try. It also increases the number of bug reports we get from users. If we go this route, I wouldn't add this package to the default flare-vm configuration, which I think it is a pity because this is a great tool.

So I would prefer to ask the tool author if he is willing to help us to be able to include his tool in the default flare-vm installation. @MalwareMechanic can you contact him? His contact details are in https://www.angusj.com/resourcehacker

[Ana06]

Also, if the download url is blocked by GH in Windows 11, the tool maintainer may also be able to help us fix it, either by providing another url or by requesting GH not to block this url (not sure if we could request it).

[Ana06]

@MalwareMechanic any updates? 😄

[Ana06]

There seems to be a similar issue with peanatomist: #831

[Ana06]

@MalwareMechanic 👀

[MalwareMechanic]

@Ana06 My previous attempt at contacting the author wasn't successful, but I'll reach out again and ping back if I hear anything

[Ana06]

@MalwareMechanic is the tool signed? If so, we could use VM-Assert-Signature to install it.

@MalwareMechanic was reshack working (vs the portable version)? I think it would be ok to use that version if it works.

[naacbin]

Both version works but reshack.portable seems to update faster than resourcehacker.portable. It has been 4 months since any new updates and this package still failed to install, I think we should at least update to the latest version for now and keep an issue for long term support.

[Ana06]

@naacbin I agree. Would you like to take over fixing resourcehacker? @MalwareMechanic is likely not going to have time soon.

[naacbin]

@naacbin I agree. Would you like to take over fixing resourcehacker? @MalwareMechanic is likely not going to have time soon.

I will see to do it before end of week.

[Ana06]

Thanks a lot for the changes @naacbin!! I have tested locally and it works. Just some comments about the version/package name that we need to address before we can merge it.

[Ana06]

Thanks for the changes @naacbin! I have removed the old package from MyGet and retriggered the test suite so that the new package is tested.

[Ana06]

Thanks @naacbin! It works perfectly. I think we should add this package to the default flare-vm configuration. 😄