谷歌更新服务是个败类

所以最近我在 google omaha updater 上做了一些研究，我创建了一些迷你工具来与服务通信并完成一些任务。我注意到 google omaha 正在寻找一个不存在的配置文件“C:\GoogleUpdate.ini”，这引起了我的兴趣。该文件似乎主要用于记录/调试详细信息，如此处所述，并且由于该服务作为特权组件运行并且可供非管理员人员访问，因此它可能是一个有趣的研究领域。

很多人会说“C:\”默认情况下不允许用户在那里创建新文件，但从 Windows 10 2009 开始，它似乎默认允许经过身份验证的用户在那里写入，并且在那里完成了一些 DACL 更改，以下图片取自默认的 Windows 安装。

正如您在 Windows 10 2009 中看到的那样，经过身份验证的用户现在可以在根目录中创建文件，在这种情况下，我们可以将“C:\GoogleUpdate.ini”创建为标准用户。

如果您要询问 Windows 服务器，则 C:\ 不允许非管理员在那里创建文件。

查看日志配置文件，它看起来有点有趣，参数“LogFilePath”似乎很有趣，据我所知，它允许我们指定日志文件。

你可以猜到我们已经在那里覆盖了我们的任意文件，但它会停在这里吗？不幸的是，不，再次查看有一个“MaxLogFileSize”参数的结构，该参数采用文件大小，它可以为 0。查看实现时，每次 google omaha 尝试创建允许“经过身份验证的用户”的新文件时都会写入 DACL根据此代码段具有写访问权限。

现在唯一剩下的就是启动服务本身，这很容易，因为我在编写一些 google omaha 工具时曾经这样做过，您只需调用 CoCreateInstance 并确保传递 google updater CLSID 并作为系统启动服务。