Can you sign the dll's?

[PGomersall]

Hi Valinet,
In our enterprise we have quite rigorous monitoring of system files on all desktop clients. Typically they are flagging files in system areas that look to be making "hijacks" to files like Explorer.
Our security team has seen me testing explorerpatcher and saw it as a possible hijack. After investigation they determined what the file was for was but they have asked me to enquire if you can sign the files with a valid software cert?
Previously I had a script to download new versions, install and then sign before I reloaded explorer.
With your new process of updating it makes it more difficult. I suppose I could just disable your updater and continue my old process as long as the dll's were still programmatically accessible on your site. Currently under releases you only have the setup file.

I did look here: "An archive containing all the files generated during the build process (including dxgi.dll and symbol files) is available here." but accessing dxgi.dll this way would be programmatically difficult.

Pete

[valinet]

Hi

As I think you are aware, certificates cost quite some money. It would be interesting to have these signed, but generally I don’t think it adds much value, since the chain of trust is pretty much guaranteed with the current setup: the code is public, builds are automated so that my potentially unsafe machine is excluded, and then builds are hosted on GitHub’s infrastructure. If one trusts my code and GitHub, then the file they get is virtually guaranteed to have only these 2 actors involved, so what would signing achieve in this instance for the general public…?

DLLs are still accessible, as noted, in the build page, as artifacts. There has already been a lengthy discussion about this. The current setup is more easy to understand for users, so it will stick. GitHub has a public API for accessing the artifacts and downloading them etc.

Alternatively, simply download the exe and extract the resources you want from it, for example: RH.exe -open ep_setup.exe -save dxgi.dll -action extract -mask RCData,103, -log NUL. RH is the command line version of Resource Hacker. Resources are standard packed in the PE executable, nothing complicated. You can make a simple C program that extracts them for you, no need to use RH either, relevant example of this is in the source code of ep_setup.exe and ep_setup_patch.exe. Maybe the installer will include an option to unpack the files to disk eventually, why not…?

More details about these approaches in this other thread: #347

Alternatively alternatively, even more fancy, host your own update server! It’s super simple: host the signed ep_setup at some endpoint, let’s say http://10.1.1.222/ep/ep_setup.exe. Then, just go to HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ExplorerPatcher, make a new registry key, call it UpdateURL, and use http://10.1.1.222/ep/ (do not forget the slash at the end). Now check for updates: the new version will be picked from your custom server. This can be quite nice automated as well. Security is maintained by the text in the UAC prompt: that’s why I included the URL there, so the user knows where the file comes from and avoids running it if someone hijacked that regentry in HKCU.

The source code is the best manual for this software, it’s hard for me as a single entity to keep everything else updated with the latest changes at the pace the questions arrive. There is a plan to document this thoughtfully in the wiki, but time is the main issue: I can’t be instantaneous, it takes time and I have lots of other things to take care of as well, I also have a workplace etc.

So yeah, I think there are some great methods available out there and at least 3 alternatives out there, the last one being my favorite, since it’s pretty easy to set up a web server (IIS is fine for this task, takes 3 minutes to install) and it works nicely with the updater in EP.

As for checking for updates, again, the source code tells you the mechanism: the md5 hash of ExplorerPatcher.amd64.dll (same file as dxgi.dll) is written at the beginning of ep_setup.exe when it is generated (by ep_setup_patch.exe), over the nowadays useless “This program cannot be run in DOS mode.” text. The updater downloads the first 78 (offset to the text) + 32 (length of hash) bytes of the update file every time a check is made and compares that hash with the hash of the current file. When they differ, an update exists. Super simple, lightweight and it just works, I hate complicated solutions and love intelligent hacks and workarounds. It does the job more than well for this type of software.

Thanks, hope you put together something with the info provided. Good luck!

[PGomersall]

Thanks for the lengthy explanation. I read through the thread your provided the link to and it provides a mechanism for me to follow.
However, from a completeness perspective, maybe you could add the extract functionality to the ep_setup.exe?

[valinet]

Implemented in latest version.

[PGomersall]

Signed the files or added the ability to extract the files?
If signed have you NOT released that version yet? Non of the files in 22000.318.38.2 are signed?

So I was just working on my way using our signing cert. I had the script all done but found an issue with restarting Explorer. Anyway take a look at the PS code below, but for me the last line no longer works:

$Downloads = (New-Object -ComObject Shell.Application).NameSpace('shell:Downloads').Self.Path
$EP = "$Downloads\ExplorerPatcher"
cd $EP
$File = "ep_setup.exe"
$OutFile = "$EP\$File"
$PatchFile = "$EP\ExplorerPatcher.amd64.dll"
If (Test-Path $OutFile) {
	Remove-Item $OutFile -Force
}
If (Test-Path $PatchFile) {
	Remove-Item $PatchFile -Force
}
If (Test-Path "$EP\ExplorerPatcher.IA-32.dll") {
    Remove-Item "$EP\ExplorerPatcher.IA-32.dll" -Force  | Out-Null
}
$uri = "https://api.github.com/repos/valinet/ExplorerPatcher/releases"
$Get = Invoke-RestMethod -uri $uri -Method Get -ErrorAction stop
$Tag = ($get | Select-Object -first 1).tag_name
$Download = "https://github.com/valinet/ExplorerPatcher/releases/download/$tag/$file"
Invoke-RestMethod -uri $Download -OutFile $OutFile
Start-Process $OutFile -ArgumentList "/extract" -Wait -WindowStyle Hidden
If (Test-Path C:\Windows\dxgia.dll) {
	Remove-Item C:\Windows\dxgia.dll -Force | Out-Null
}
If (Test-Path C:\Windows\dxgi.dll) {
	Rename-Item C:\Windows\dxgi.dll C:\Windows\dxgia.dll -Force  | Out-Null
}
Move-Item $PatchFile C:\Windows\dxgi.dll | Out-Null
Start-Process "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\signtool.exe" -ArgumentList 'sign /n "Our Cert Name" /t "http://timestamp.globalsign.com/scripts/timstamp.dll/?signature=sha2" "C:\Windows\dxgi.dll"' -WindowStyle Hidden -Wait
rundll32 "C:\Windows\dxgi.dll",ZZRestartExplorer

[valinet]

From https://github.com/valinet/ExplorerPatcher/releases/tag/22000.318.38.2_3bbd227:

Implemented /extract switch which unpacks the files from ep_setup.exe to disk

[PGomersall]

OK, but is rundll32 "C:\Windows\dxgi.dll",ZZRestartExplorer still supposed to work - for me it doesn't?
It just kills explorer and it never restarts.

[valinet]

It works, but sometimes Explorer hangs. It happened to me as well, especially when restarting it a couple of times. Idk, close it using taskkill /f /im explorer.exe and then run explorer.exe.

[BraINstinct0]

Done the kill-and-run up until now, had (mostly) no issues.