Saving SteamGuard Authentication not working properly (Linux)

[awillinger]

I have applied the latest Commit for the Bot.cs to save the SteamGuard Machine Code in Visual Studio 2010 and after compiling it, it's working just fine (creates a sentryfile and doesn't prompt again for the Auth-Code).

However, trying to port it onto Debian Squeez (with Mono 2.10.8.1 compiled from Sources) fails, as it's prompting again for the Auth Code everytime I start the Program.

Oddly enough, the sentryfile is getting created, but somehow everytime when I lauch the Program, a new Auth Code is generated and the existing one ignored.

Is this a known Issue on Linux and was somebody able to get it working there? (without prompting for the Code everytime)

[cwhelchel]

See this comment.

I'm not really sure if this is something that has to be modified in SteamKit such as the Utils.GenerateMachineID method.

/cc @94m3k1n9

[94m3k1n9]

Here is the function to generate a machine ID, it just doesn't generate something for unix systems and returns null instead.

This could problem could be solved by calculating a hash based on the computers MAC address(es).

I didn't look into it but I think the problem is that it returns null and it gets saved as empty file, then in the next run it doesn't think it's a valid file.

[cwhelchel]

Looks like other platforms are TODO.

Is this something that should go upstream to SteamKit2? A *nix implementation shouldn't be too terribly difficult if Mono has some low-level stuff like the ManagementClass.

NOTE: MAC addresses can be spoofed and that could pose a security risk if that's all that's used to ID a machine.

[awillinger]

So there is actually no real method to get the Bot working on *nix with Steam Guard active?

[94m3k1n9]

The problem isn't that Mono doesn't have that ManagementClass, the problem is that the *nix kernel doesn't support e.g. processor IDs. MAC addresses would be the only way to get a somewhat system specific HWID. The only other solution I could think of at the moment would be generating a random string on first launch.

[awillinger]

Isn't the Code generated by the Steam Backend itself? I was experimenting a bit with PHP's cURL Extension and saved the Cookie after successful login, which contained a Cookie called steamMachineAuth.

[94m3k1n9]

I'm not 100% sure about that but I think it is generated from the user agent or some other browser variables.

It definitely works that the client generates it as it works on windows that the client generates the ID, sends it to the server and the server stores it. Otherwise it couldn't rely on a HWID for the steam client.

I could also imagine that the browser machine auth wouldn't work with a steam client as it could be stored with a flag to prevent logging in with the steam client.

[cwhelchel]

the problem is that the *nix kernel doesn't support e.g. processor IDs.

@94m3k1n9 Are you 100% positive that this is a true statement?

I found this and this that may help. In any case I think it's doable to get some sort of machine dependent hardware ID on Linux even without the Processor ID.

This seems like its a common enough problem to have a solution in *nix. The problem being that it may vary between flavors of Linux.

[94m3k1n9]

:o last time I tried to find something I somehow just found people saying it wouldn't work. I just found this, e.g. /sbin/udevadm info --query=property --name=sda works as non-root user.

[cwhelchel]

I also found this. Not sure if we expect people to be running as non-root users if they are compiling code and running a bot. I'm not very experienced with development for Linux platforms.

[94m3k1n9]

Lol. I personally wouldn't expect or suggest anyone to run the code as root. It's a high security risk to run software as root if it's not required. A small bug in the software can allow an attacker to take over the whole system.

I also found that link but I didn't look deeper into it. I think it needs some extra package to get installed as my debian box doesn't have it installed by default.

[lazy1]

Actually this bug is unrelated to Utils.GenerateMachineID. Its much simplier.

sentryFile vs sentryfile

The bot writes Sentryfile to:

File.WriteAllBytes (String.Format ("{0}.sentryFile", logOnDetails.Username), machineAuth.Data);

But reads from:

FileInfo fi = new FileInfo(String.Format("{0}.sentryfile", logOnDetails.Username));

In Windows file names are case insensitive, in Linux they are case sensitive. To fix the bug one just need to use the same sentryfile extension.

[94m3k1n9]

This would just result in creating a sentryfile with no content that would be used to really identify the machine - someone who steals the pass could just use an empty sentryfile on his own machine.

@lazy1 your suggestion is not a fix, it just is a temporary solution that increases the risk that someone can bypass steamguard on that account.

[lazy1]

@94m3k1n9 Technically speaking its the exact solution to the bug encountered by awillinger and described in the first post. Fixing Utils.GenerateMachineID is unrelated issue. Sentryfile is created(and can be used by the potential attacker) no matter if you apply my fix or not.