Latest Steam Beta Bypasses Steam Limiter

[frag...@gmail.com]

I'm on Vodafone (New Zealand) and it seems that Steam Limiter is no longer redirecting the downloads to the Vodafone server at all if using the latest Steam beta. Attempting to block all traffic doesn't seem to work as well.

[Nigel Bree]

On Wed, Dec 3, 2014 at 3:17 PM, <frag...@gmail.com> wrote:

I'm on Vodafone (New Zealand) and it seems that Steam Limiter is no longer redirecting the downloads to the Vodafone server at all if using the latest Steam beta. Attempting to block all traffic doesn't seem to work as well.

Ugh. First they sneakily break the way their distribution system works (they've been withholding patch data from a lot of games so that ISP-level proxies like Vodafone can't get it), and now this?

I'll take a look at the beta soon to see what it's doing; the only way it could bypass steam-limiter there's probably been some internal API switch-over from relatively plain BSD sockets to use some of the more advanced Windows networking APIs, since I wasn't catching all of those (the advanced Windows APIs are what Chrome browser embedded in Steam preferred to use, so leaving them alone meant I didn't have to have all that going through the filtering system).

I do have a lot of real-job work on the go at the moment, which doesn't help, but the major problem is that even if I fix the beta problem to catch the downloads again, because Valve have also broken their CDN configuration somewhat, I've also been struggling to come up with any kind of filtering methodology that would still let downloads work for new games and patches. The stuff they now keep private to their servers and don't let the ISP-level proxies get to doesn't look any different from regular content (the URLs are the same structure and whatever they did to break that side of things is all internal to their CDN system). This means I can't easily dynamically detect the situation... grr.

- Nigel

[Nigel Bree]

So, the deal here is that Valve have added some code that makes Steam harder to get at. Basically, in Windows a running process, like every else, has what's called an Access Control List that says exactly who can do what to it. The standard ACL for regular (non-elevated) Windows processes says that if they were started by the same users, then it's OK to let them see each other, modify each other, do all kinds of stuff, etc. Which is actually quite sane, but anyway...

With this update, the Steam client has some code - and this kind of ACL modification code isn't easy, so they Really Really intend to do this - to modify things so that the Steam process can't be looked at. Specifically, it modifies its own Access Control List to specifically deny anything looking at its memory, changing its memory, or a bunch of other things. One of the consequences of this is that with this beta, steam-limiter can't open the running Steam process and modify what it does - for that it needs the ability to read/write the filtering code into it.

Now, Valve almost certainly didn't intend for this to break steam-limiter - it's more effort to go to than you'd think for them to do this, and gives absolutely no real benefit to them. Most probably, it's something sorta-intended to be DRM-related with the new Video stuff they are adding; as part of the new streaming video capability in the beta, there's a video player there which can do a lot of stuff. Most likely, someone at Valve has thought ahead and gone "Hey, we have a Music Player!. Hey, we have a Video player! Let's think about selling music and video!" (that may even be why they broke the CDN, too, but who knows).

Of course, modifying the ACL in the way they did doesn't ACTUALLY really do diddly squat DRM-wise. The process that started Steam can always hang on to it in a way that lets it do anything, and with UAC elevation an elevated process can do what it likes too. So, it doesn't really stop any tools that if the end user wanted to scrape the things Steam was showing from doing that. It does make it more tedious, though, and steam-limiter is probably just collateral damage in that.

To fix this in the short term, just run the steam-limiter executable elevated: browse to the install folder, right-click on steamlimit.exe and set it to "Run as administrator".

Long term, well, I dunno. I do not want to have my stuff running as administrator; that's just generally bad for everyone's security. However, the only clean way - as opposed to not clean, virus-y things - to bypass this change *and* and the same time not have steam-limiter forced to run as administrator is for steam-limiter to be the thing that starts Steam up. Honestly, at this point in time I don't really have a good handle on the cost/benefit ratio here, especially when on Valve's side I don't know where they are going or for certain what they hope to achieve (and thus what the next move might be).

- Nigel

[Thermal Ions]

Thanks for the layman's explanation Nigel, it's always interesting to read your analysis when Valve do these sorts of things, rather than just get a "Valve broke it (again)" post.

Given it's so far only implemented in beta so the implementation could change, and as you say, their end game is unknown, I personally would be satisfied to run as admin for now and see how things progress. Please don't hack me now ;)

Having Steam Limiter start Steam seems (from the uneducated end user perspective) to be the best option based on your analysis, assuming they don't do something to impact this approach during their development cycle of this "enhancement". Staying away from virus-y workarounds seems wise given the hassles that could cause with differing and changing detection definitions in the popular virus scanners, let alone if including the more obtuse ones.

Oh well, off to elevate Steam Limiter on all the systems here, before I start Steam up tonight.

Cheers - Thermal

[frag...@gmail.com]

Looks like something got changed/fixed because it is now fully working again.