Pull request #3934
Under the TODO section of the pull request, I've written about some of the burning issues that need to be addressed:
- To enable Alas to obtain the process creation event, it is necessary to open the audit process creation in the Local Group Policy Editor -> Computer Configuration ->Windows Settings -> Security Settings -> Advanced Audit Policy configuration -> System Audit Policy - Local Group Policy object -> Detailed Trace, and set it to "Success and failure".
- It is necessary to reconstruct the startup chain according to the event log after capturing the event log, and maintain the startup chain regularly.
For example: "MuMuPlayer.exe" starts "crashpad_handler.exe" and "MuMuPlayerUpdater.exe", "MuMuPlayerUpdater.exe" starts "aria2.exe" and another "crashpad_handler.exe", "aria2.exe" starts "conhost.exe".
Additionally, "svchost.exe" starts "MuMuVMMSVC.exe", "MuMuVMMSVC.exe" starts "MuMUVMMheadless.exe", The latter in turn starts two "RendererDetector.exe" and another "conhost.exe".
The difficulty here is that "MuMuPlayer.exe" is not associated with "svchost.exe".
Possible solutions:
- It is recommended to use Python/C/C++ to temporarily turn on the above Settings for the lifetime of the program via the cmd/ registry/groups policy.
- Maintain a whitelist or try to find the association between the simulator process and "svchost.exe -k DcomLaunch-p".
Pull request #3934
Under the TODO section of the pull request, I've written about some of the burning issues that need to be addressed:
For example: "MuMuPlayer.exe" starts "crashpad_handler.exe" and "MuMuPlayerUpdater.exe", "MuMuPlayerUpdater.exe" starts "aria2.exe" and another "crashpad_handler.exe", "aria2.exe" starts "conhost.exe".
Additionally, "svchost.exe" starts "MuMuVMMSVC.exe", "MuMuVMMSVC.exe" starts "MuMUVMMheadless.exe", The latter in turn starts two "RendererDetector.exe" and another "conhost.exe".
The difficulty here is that "MuMuPlayer.exe" is not associated with "svchost.exe".
Possible solutions: