PDA

View Full Version : concerned that patcher requires administrative rights every time



madcap
10-25-2013, 06:41 PM
The HexPatch application requires administrative rights every time it is launched.

I'm playing on a surface pro which has windows 8. I installed the game yesterday.

Can anyone else confirm?

If at all possible you need to change this so that HexPatch does not require administrative privileges.

keroko
10-25-2013, 07:42 PM
good choice of system to play hex on.

it is running admin mode to avoid UAC issues encountered programatically? it can be bothersome.

also, so hex process runs under authority of account with access to other process information, a primary reason I have not done the following...

...i'd look at what its actually modifying but its currently forbidden.

would like to have understanding of what we can test without process monitoring by game tripping a switch on the server end, resulting in a ban.

madcap
10-25-2013, 07:49 PM
But just the patcher requires admin rights. Hex itself does not. Interestingly this means you can skip patching by answering no when windows asks for admin permissions. This causes hex to launch without being patched. I haven't tried it when a new version is available but I will next time a patch drops.

keroko
10-25-2013, 08:03 PM
its likely for file / registry mods then and the UAC avoidance? you could force it to not respect elevation:

get an elevated 'cmd.exe' (start, type"cmd", right click 'command prompt', choose "run as administrator")
at prompt you should see yourself in %windir%\system32

cd "c:\program files (x86)\Hex" << assuming you put it there

runas /showtrustlevels (ensure you see 0x20000 (basic user) )

runas /trustlevel:0x20000 hexpatch.exe


--- the patcher will load but will not proceed with patching, it'll freeze. it may have encountered an unhandled exception suppressed by the code before it bubbles up enough to kill the process.

(is this breaking the EULA...?)

Kami
10-26-2013, 12:41 AM
The reason HexPatch.exe requires administrative privileges is because it is writing to a 'secure' file location. Specifically, your Program Files\HEX or Program Files (x86)\HEX folder.

madcap
10-26-2013, 09:06 AM
I think you guys are missing my point. I don't really care why HexPatch needs admin rights. It should not require them just like steam does not need admin rights whenever it downloads an update. I would consider this a bug.

Marsden
10-26-2013, 09:33 AM
Complain to Microsoft then.

keroko
10-26-2013, 09:39 AM
there's likely more than just needing to write to those directories (I'd look but they'll ban me won't they - they're itching for someone to make example of in this regard, or could be. I'm not gonna be him).

it is good security practice to run a patcher elevated if needs be and then flip to a non-elevated one for game run.

Miwa
10-26-2013, 03:43 PM
They'll eventually need to follow modern windows best practices to get away from it, and that means not writing to the program files dir after install. The patcher will need an ask elevation dialog when it wants to write. User settings should be in the user dir, not in program files.

temporicide
10-26-2013, 09:18 PM
I installed Hex in C:\Hex\, specifically so I wouldn't have to run as administrator, and it still requests elevation for the launcher.

Kersed
10-27-2013, 10:35 AM
Why don't you just disable your UAC, problem solved.

bluehawk80
10-27-2013, 11:56 AM
If Hex is installed in a differnt folder and not in ProgramFiles it will not need elevated rights. And i am sure, they implement this in the patcher in the future. It should not even requiere Admin rights. But this is not a issue in alpha.


Why don't you just disable your UAC, problem solved.

This is just a workaround and the UAC is there for a reason. So i would not recommend disable the UAC.

keroko
10-27-2013, 05:04 PM
Why don't you just disable your UAC, problem solved.

its the closest thing we have to an 'su' command in windows... and folks don't have the sense to run in a non-admin account for their main profile instead of a full admin session.

some corporate policy (or home network policy if you feel like it, or locally implemented security policy) forces it on in a way users cannot disable (without being an admin).

UAC can be globally forced via external group policy to the point where disablement would only be temporary and immediately detected by HIDs software.

probably more reasons...