Imperceptible security check mechanism (无感安检机制)

This will be moved to the app site once available.

Due to the evil plan carried out by miHoYo, PaimonTray has to decide how to significantly reduce the frequency of manually completing a security check in the specific section of the Miyoushe app. The imperceptible security check mechanism is my current solution to the requirements stated in Issue #22, and it is only applied to the CN server accounts’ characters when necessary.

This mechanism was primarily co-opted from Snap.Hutao. As per loads of automated experiments, as long as there are requests to the specific API for retrieving the real-time notes, the tool can trigger the GeeTest challenge used by miHoYo for security risk management at relatively regular intervals even if increasing the real-time notes refresh interval or acting more like a human.

Thus, I reckon that PaimonTray should try solving the challenge when it appears, but not wish to avoid its occurrence. Fortunately, there is a way to achieve this idea with several undocumented miHoYo and GeeTest APIs:

• createVerification: an undocumented miHoYo API to create a GeeTest challenge.
• “GeeTest ajax”: an undocumented GeeTest API to try solving the GeeTest challenge.
• verifyVerification: an undocumented miHoYo API to validate the GeeTest challenge result.

This process does not guarantee a validated challenge. Hence, PaimonTray takes at most 3 chances to get a validated challenge when the specific API for real-time notes returns the code indicating that a validated challenge is required. The challenge is then used as the value of the x-rpc-challenge header for the next request to the real-time notes API.

Note

Don’t catch me out! Experiments only show that there is no need to do frequent attempts for a validated challenge, but cannot support the rule “at most 3 chances”. Just 3 strikes and you are out. Anyway, no more than 3 attempts do sort it out generally with a satisfying success rate.