Feature Request: Root-Like Mode (unsecure mode)

[joeyoropesa-dev]

Description

Enable the user to be able to choose (at their own risk) to turn on Root-Like mode for gsudo so that gsudo will be able to inject itself into PID 4 (unlocked kernel-level PID) and run any privileged commands without UAC Prompts even if the Global UAC Settings are turned on by default

This is like an root for Windows but UAC is required to change the value of the config Root-Like mode to 1 so that in the next reboot of the device, the Windows service will be started automatically that allows those UAC changes only for one app and that is gsudo. All other apps will still require UAC but gsudo will not require it anymore because of the UAC isolated setting for gsudo executable.

As for the PID, I'm not sure if it's possible to implement that part of the feature but patching the kernel should allow PID 4 to be shared with gsudo.exe processes and be used without BSOD the device itself

So that's basically pure root for Windows (also known as unsecure mode) and only users who know what they're doing and the consequences about their security being exploited in that way they should consider it to use it

Anyway, for many also good reasons this feature can give to the users but how much powerful good is behind this, it's also evil so users need to be avare about this before they change that config

By default, of course that config should be set to 0 but users who accepts the security exploitation risks on their device can proceed with that config change from 0 to 1

Anyway, there is always a way for users to turn off patches (Root-Like Mode) with just changing again that value in config from 1 to 0 and reboot their device to apply changes and everything should be back to normal

Proposed technical details

Already explained above

[gerardog]

I've never heard of pure root for Windows or unsecure mode as standard terminologies in the Windows ecosystem before. Could you please share some reading materials?

If your objective is to bypass User Account Control (UAC) prompts for specific operations, you don't need to inject gsudo into the kernel. You can start a gsudo cache session, which would allow for elevated operations without triggering UAC.

DISCLAIMER: The following approach is not recommended and should be implemented at your own risk.

You can create a scheduled task to start the gsudo cache automatically and silently upon login:

# DISCLAIMER: Doing this is not recommended! Do at your own risk.
$Sta = New-ScheduledTaskAction -Execute 'gsudo.exe' -Argument 'cache on -p 0 -d infinite'
$StTrigger = New-ScheduledTaskTrigger -AtLogon -User "$env:USERDOMAIN\$env:USERNAME"
$Stset = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -Hidden
Register-ScheduledTask -TaskName "GsudoCache" -Action $Sta -Trigger $StTrigger -Settings $Stset -RunLevel Highest

Lastly, it's worth mentioning that gsudo is intended to be a convenience security tool. We have to consider the overall impact on system security, as we don't want gsudo to be flagged as a malware toolkit by Microsoft or AV vendors. Therefore, we need to be cautious about which features to include in its scope.

[joeyoropesa-dev]

I've never heard of pure root for Windows or unsecure mode as standard terminologies in the Windows ecosystem before. Could you please share some reading materials?

If your objective is to bypass User Account Control (UAC) prompts for specific operations, you don't need to inject gsudo into the kernel. You can start a gsudo cache session, which would allow for elevated operations without triggering UAC.

DISCLAIMER: The following approach is not recommended and should be implemented at your own risk.

You can create a scheduled task to start the gsudo cache automatically and silently upon login:

# DISCLAIMER: Doing this is not recommended! Do at your own risk.
$Sta = New-ScheduledTaskAction -Execute 'gsudo.exe' -Argument 'cache on -p 0 -d infinite'
$StTrigger = New-ScheduledTaskTrigger -AtLogon -User "$env:USERDOMAIN\$env:USERNAME"
$Stset = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -Hidden
Register-ScheduledTask -TaskName "GsudoCache" -Action $Sta -Trigger $StTrigger -Settings $Stset -RunLevel Highest

Lastly, it's worth mentioning that gsudo is intended to be a convenience security tool. We have to consider the overall impact on system security, as we don't want gsudo to be flagged as a malware toolkit by Microsoft or AV vendors. Therefore, we need to be cautious about which features to include in its scope.

I've already tried to use gsudo cache feature but that didn't work. It asks for the UAC approval at least once before it begins to automatically approve administrator gsudo without UAC. And that is actually for any cmd window I open - is that normal?

And by the way, the feature can be included but to be installed separatelly so that gsudo can avoid problems with companies to not get malware-flagged. The only thing is that the optional plugin that needs to be downloaded so that the feature can work is to install malware-flagged plugin that actually is giving that feature to the gsudo executable as long is that plugin installed - in that way, only the plugin will be flagged, not the whole gsudo.

Anyway pure root aka unsecure mode is actually the terms that hackers is usually using to gain full access to the victim devices - but that could also be used by the owner of the device itself if the owner wants to change something that Microsoft puts into the system without ability to change it except the Microsoft itself.

In short, Linux users can use root to access to literally anything on their device - any part of the rootfs and more and they can easly bypass any antivirus checks using root

The only thing that really checks and limits some users to execute even malware undetected is sudoers so that unauthorized users cannot access sudo and for the su command, the password is usually set by the owner of the device to be sure that no one will be able to access even if the owner can use sudo passwd -d root to disable password requirements for the root

Windows users is using UAC instead of root. UAC have more limited access to the device but it's still capable of giving high level permissions but kernel privileges UAC never gives - only the real root gives. UAC also even if the user disable the password needs to allow privileged execution using the button "Yes" instead for the root command "su" by Linux users when the Linux user disables the password for root.

For the Windows user to be able to completely bypass UAC prompt, it needs to completely turn off UAC or to move to the built-in Administrator account while Linux users can even set some executables to run as root without any prompts using some addons for their selected desktop GUI and command tricks

So if Microsoft allows the built-in root instead of having only UAC option as an elevation tool, yes users will get more options and control over their device and OS - but that could lead to the security issues and unauthorized bloatware removals and antivirus bypasses - that's why Microsoft will never add the real root aka unsecure mode to the users in their systems while Linux is more open-sourced and it's more often security-updated to avoid hackers to gain access easly on the Linux users

That is unsecure mode and due to it's privileges and freedom to their closed-source OS and also some security holes that could happen, Microsoft will never allow it

Yeah, that's why we need an at least unofficial/custom tool to add that wanted feature into Windows but what if this project can somehow implement this feature at least using the "plugin implementation" method to avoid being flagged as a malware but still to be able to give to it's power users full customization control over their device without anoying UAC prompts

p.s By the way, maybe it's better for me to not tell you how I found those informations on the .onion websites because that could lead to the Microsoft decision to research this case and patch the critical bug they didn't even notice that someone will be used like this 👀

[joeyoropesa-dev]

There is still no updates to this case... Could it be implemented? Or better to say, something like disabling UAC for only specified executable (gsudo) so that the target executable (gsudo.exe) can run with admin privileges without triggering UAC prompts while for other executables UAC prompt should work.