Fixed and updated memprocfs.vm to latest version#1411
Fixed and updated memprocfs.vm to latest version#1411socketz wants to merge 3 commits intomandiant:mainfrom
Conversation
| $category = VM-Get-Category($MyInvocation.MyCommand.Definition) | ||
| # Get latest version from GitHub releases with a curl equivalent in powershell | ||
| $latestFileName = 'MemProcFS_files_and_binaries-win_x64-latest.zip' | ||
| $latestVersionUrl = 'https://api.github.com/repos/ufrisk/MemProcFS/releases/latest' |
There was a problem hiding this comment.
I have concerns about using https://api.github.com/repos/ufrisk/MemProcFS/releases/latest, as this means we potentially update to major versions without any tool testing, which could cause issues with newer dependency requirements. I think we should use a concrete version and allow our bot to update it so that we can test it by using https://github.com/ufrisk/MemProcFS/releases/download/v5.15/MemProcFS_files_and_binaries-win_x64-latest.zip.
|
|
||
| $toolName = 'MemProcFS' | ||
| $category = VM-Get-Category($MyInvocation.MyCommand.Definition) | ||
| # Get latest version from GitHub releases with a curl equivalent in powershell |
There was a problem hiding this comment.
Use Get-ChocolateyWebFile chocolatey helper instead of curl, as we do when we use signature verification
| $zipUrl = 'https://github.com/ufrisk/MemProcFS/releases/download/v5.14/MemProcFS_files_and_binaries_v5.14.11-win_x64-20250501.zip' | ||
| $zipSha256 = '40ce4ac604933dd919444a9cee42431b3fe43813fa4155bef17466b7db03d764' | ||
| if (-not (Get-Command Invoke-RestMethod -ErrorAction SilentlyContinue)) { | ||
| Write-Error "Invoke-RestMethod is not available. Please ensure you are running PowerShell 3.0 or later." |
There was a problem hiding this comment.
We require PowerShell >= 5: https://github.com/mandiant/flare-vm?tab=readme-ov-file#requirements
| $latestVersionResponse = Invoke-RestMethod -Uri $latestVersionUrl -Headers @{ 'User-Agent' = 'VM-Installer' } | ||
| } | ||
|
|
||
| # Get the latest version's SHA256 from the assets searching in the array by the name key and getting the digest |
There was a problem hiding this comment.
Normally we have a hardcoded hash we use for verification, while here it is being proposed to extract the hash for the GitHub release assets. Providing the hashes seems to be a new GH feature and the hash is calculated automatically: https://github.blog/changelog/2025-06-03-releases-now-expose-digests-for-release-assets/ I have concerns about verifying the download in this way and would prefer to use a hardcoded URL (we may need to clarify what we need in ufrisk/MemProcFS#389 or use an older version that is not updated anymore). what do others think? @vm-packages @emtuls @naacbin
If we decide it is ok to verify the download in this way, we need to document in this package WHY we are doing it such a special way in this case: MemProcFS updates the release assests without increasing the version when Microsoft updates the cached symbol offsets.
There was a problem hiding this comment.
From reading @Ana06's issue for MemProcFS (ufrisk/MemProcFS#389), it sounds like the developer isn't willing to provide the tool in a way that is preferred for our scripts, which is unfortunate.
I might be okay with grabbing the sha256 dynamically from the asset release though I would usually prefer not to do it this way for consistencies sake, but this seems to be a slightly special case for a highly used tool and this might be the easiest way to keep the tool up to date (if that is our intent).
I don't use the tool enough to know if using an older version would work consistently, as it sounds like things are based off of offsets which can change often. If an older version works well for most recent Windows versions, then I'd prefer to stick with a slightly older version for a longer period of time. Not sure what the trade-off is if we don't keep the tool at the latest update.
Could someone chime in and let me know how crucial it is to have the most recent update for this tool?
If we do go the route of the dynamic hash grabbing, then the minor version may need to be modified as well due to the releases only being something like X.XX rather than the X.XX.X style that some assets have in the name.
There was a problem hiding this comment.
@emtuls I think the developer was very supportive and willing to help us, but maybe it was not clear what we exactly need.
3 participants
No description provided.