[Bug]: Xenos might CreateRemoteThread without admin privilege, fucking up YimMenu OS permissions. Add a log to user when that happens

[Deadlineem]

Describe the bug

This issue seems to be for some windows 10 users, its not allowing the scripts_config folder or files to be read, which is causing the lua scripts to fail to load if they cant read/write to the config file. In this case HSConfig.lua

https://github.com/YimMenu-Lua/Harmless-Scripts/issues/4

Steps To Reproduce

If you are on windows 11, this issue does not appear as windows 11 has 3 settings for readonly Enabled/disabled/passive

Passive shows up as a - but this is not part of windows 10 systems, win10 and below only have enable/disable

Setting readonly to enabled and running yim will reproduce the error in the link provided on windows 11.

Expected Behavior

The folder should not be readonly by default.

Logs

In provided link

Screenshots / Video

Store

Other (please mention in "Additional context")

Language

English

YimMenu Language

English (US)

Additional context

OS windows 10 and under

Build

• [X] I've confirmed the issue exists on the latest version of YimMenu

Coload

• [X] I've tested this without co-loading anything.

[xiaoxiao921]

Windows read only attribute flag on folders is initially in an indeterminate state, if you had read the log correctly of the issue you linked you should've seen that there is already similar problems about permissions for this user (failing to read regedit keys and such properly), this is just an issue with their antivirus or similar blocking the OS handles from the YimMenu.dll to function properly

[Deadlineem]

Windows read only attribute flag on folders is initially in an indeterminate state, if you had read the log correctly of the issue you linked you should've seen that there is already similar problems about permissions for this user (failing to read regedit keys and such properly), this is just an issue with their antivirus or similar blocking the OS handles from the YimMenu.dll to function properly

So the only solution is to manually disable the readonly or disable their virus protection? I guess that makes sense but this should be noted/documented on the readme or docs. Some people have some weird virus scanners though which could be a major factor as you said.

[xiaoxiao921]

The read only flag has nothing to do with the user problem. We don't create folders with read only enabled. It's just something that is installed from their PC that is blocking WinAPI handles of YimMenu.

[Deadlineem]

The read only flag has nothing to do with the user problem. We don't create folders with read only enabled. It's just something that is installed from their PC that is blocking WinAPI handles of YimMenu.

I wonder if the two users having this issue have a common antivirus software or maybe not having the proper user account privileges or having UAC disabled/enabled. Idk what the cause is specifically but ill try and find out.

There are 2 people with the issue on that post.

[xiaoxiao921]

I'm gonna reopen this and use this issue as a Todo for us that we should show message to the user that xenos should be launched as admin and that no antivirus should block the YimMenu dll

[FIying-Scotsman]

I'm gonna reopen this and use this issue as a Todo for us that we should show message to the user that xenos should be launched as admin and that no antivirus should block the YimMenu dll

Would just want to add to the message - users should not outright disable their antivirus. Add Yimmenu and Xenos as exceptions.

There's a infostealer campaign going about which is abusing this to compromise victim PCs to steal their accounts to sell on their forum. The infostealer is packed in fake game cheats including injectors and drivers and prompts the user to disable their AV to function (as soon as they click on it the infostealer is loaded regardless but it'll wait until the AV is disabled before running fully).

It's incredibly bad practice to just disable your AV regardless.

[xiaoxiao921]

This is planned, actually, we finally found the issue on why the rpf stuff is failing etc, just logging that the thread was made with the right privilege or not. This bug happens when xenos default injection method is used, it uses CreateRemoteThread and don't have the right thread privilege if not launched as admin