mirror of
https://github.com/Cockatrice/Cockatrice.git
synced 2026-11-05 09:33:25 -08:00
068ea1627f
The guard answered "nothing is holding the payload" from two lookups that can both miss a running instance: Restart Manager does not reliably report a program's own image or the modules it mapped, and the image path of a process running under another account cannot be read from the probe at all. A user log showed exactly that: the first guard passed while cockatrice.exe was running from the directory, the old uninstaller silently skipped the file it could not delete, and the update aborted half an uninstall later with "cancelled by user" after a close attempt the running window ignored. Ask the file itself. A running image is opened without write sharing, so the write open replacing it needs is refused with ERROR_SHARING_VIOLATION for as long as the program runs, while a file that is merely being read still accepts it. When neither lookup named anybody and a payload executable refuses that open, the probe answers that the file is in use and that the program holding it could not be identified - the guard's "could not confirm" dialog, whose Retry works once the user has closed it - instead of passing the payload as free. Only the payload executables are tested, not every file the purge removes: a locked executable proves a program is running and a mapped DLL belongs to a running executable, while a locked DLL or qt.conf can be the asking process itself, which is the loop the guard already had. The open is retried once after 300 ms, and only for the files that refused, so a scanner holding a file for a moment cannot stop an install for nothing. The Windows probe check now covers that answer: a payload executable held by the asking process, so that it cannot be named, has to come back as in use rather than as free. Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
36 lines
1.9 KiB
C++
36 lines
1.9 KiB
C++
#ifndef PAYLOAD_LOCKS_H
|
|
#define PAYLOAD_LOCKS_H
|
|
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
/**
|
|
* @brief The payload executables in @p installDir that refuse to be written, as full paths:
|
|
* the programs that are running from it right now.
|
|
*
|
|
* The guard asks two questions and both can come back empty for a running instance: the
|
|
* Restart Manager does not reliably report a program's own image or the modules it mapped,
|
|
* and the image path of a process running under another account cannot be read from here,
|
|
* so the process is not named either. The file itself is the evidence neither question
|
|
* depends on: a program's image is opened without write sharing for as long as it runs, so
|
|
* the write access replacing it needs is refused for exactly that long, while a file that is
|
|
* merely being read still accepts it.
|
|
*
|
|
* An installer that answers "nothing is holding the payload" from two lookups that both
|
|
* missed is what sent updates into an uninstall that could only fail halfway, leaving the
|
|
* previous version half removed. This answer is what keeps that from being said: a payload
|
|
* executable that refuses the write is running, whether or not this process may name it.
|
|
*
|
|
* Only the programs the payload installs are tested, not every file the purge removes. A
|
|
* payload executable refusing the write proves that it is running; a mapped module belongs
|
|
* to a running executable, which is tested. A DLL or qt.conf on its own can be held by the
|
|
* program that is asking - the uninstaller runs in place from the directory it empties - and
|
|
* naming that as a holder is the loop the guard already had.
|
|
*
|
|
* @return one full path per executable that still refused after the re-test, in the order
|
|
* PAYLOAD_PROGRAMS names them; empty when every one of them can be written, or none
|
|
* is installed.
|
|
*/
|
|
std::vector<std::wstring> payloadExecutablesInUse(const std::wstring &installDir);
|
|
|
|
#endif
|