So... what's next?

[Speyedr]

Now that the dust is settling and Rockstar has finally addressed the current spectator exploit I think it would be a good time to make my intentions clear on the future of this project, including what we've learned so far and where to go from here.

First, I want to thank everyone-and I mean everyone--who used this project over the past few days. This is the first project I've ever released to the public and I'm still trying to get my head around knowing that it's already in the hands of tens of thousands of people. I couldn't have dreamed of a more successful launch for my open-source career, and even just having people using the app and knowing it was keeping them safe is all I could really ask for.

Secondly, an even bigger thank you to those who donated. It doesn't matter how much you donated, I wish I could personally thank all of you in person for supporting my work. You're helping fund future developments and improvements for this project, as well as any of my future projects in general.

Which leads in to the main purpose of this announcement:

Where do we go from here?

The question most people will have is "Will you continue developing this program?" to which the answer is YES, absolutely.

It's fairly obvious now that the SocialClub Overlay is a security flaw, and I think it will only be a matter of time before more administrative features or exploits are revealed. All of us have a right to prevent vulnerable software from running on our computers, and there is nothing wrong with blocking suspicious behaviour with a firewall. The fact that the SocialClub Overlay is still required to play in Singleplayer and cannot be disabled is ridiculous, and I think that everybody should be able to block SocialClub from running in a legal and ethical manner.

Let me reiterate that there is NO reason as to why R* should ban people for using this program. It falls under fair use, does not modify the game in any way, and does not violate R* / T2's rights. R* would be killing off their most devoted fans for no good reason if they did. That being said, remember that R* has clauses in their EULA that say they can terminate any account from using Online services and any time and for any reason. However, it just doesn't make sense to terminate accounts for blocking SocialClub access. I wouldn't be surprised if some countries' laws could challenge that kind of act as well.

Getting back on track, this app in its' current state is not as good as it could be.

• Now, considering that this is literally my first program ever released to the public, with just 24 hours of developer time behind it, and it worked for most people around the world and across thousands of different systems, I would say this went better than I could have ever expected.
  • At the moment I'm just a part-time university student studying two degrees at university with a couple years of self-study behind me as well. I don't work in software development at the moment, and I currently don't develop software for any company.
• There have been reports that some programs conflict with the blocker, which I am developing checks for right now.
• There are also several improvements that can be made with how the blocker actually drops packets. Currently it's very simple; it just never re-injects the packet into the stream and the packet will eventually get garabge-collected (deleted from memory). However, doing this when the SocialClub Overlay is expecting to receive certain data may cause crashes, and some people have reported that this can happen. It seems to be fine if you're just vibing in freeroam, but consistently switching between jobs or interiors can apparently cause issues.
  • On the note of jobs, some people have reported that Quick Jobs and other similar functionality don't work when the blocker is enabled. Currently, I am not sure why this is the case but it will eventually be looked into.
• Lastly, more filtering options should be available to give everyone the flexibility of blocking what they want and when they want. I have a couple of ideas on how to do this, but this is probably the biggest challenge and will require some significant updates to the project.

Hopefully this program is significantly more powerful and feature-rich by the time a new exploit is discovered, and when that does happen, even more people will be able to enjoy the game safely.

Finally, even if Rockstar fully overhaul SocialClub and redesign it to be safe and secure, I still have several other projects that I can develop in a similar fashion to this one, so even if this project becomes obsolete I'll still have other things to work on and share.

I'll be using my previously inactive Twitter account for further announcements. You can ask any questions in this thread or through Twitter if you like: https://twitter.com/speyedr_au

Thank you,
Speyedr.

[sfinktah]

Take it from someone who is still being sued by Take-Two. They care, they care a lot. Any program that can be used to fix an exploit can also be used to cause an exploit -- or at least, that will be their logic.

If you are in Australia as your handle implies, they have already set precedents, some of which occurred in my case.

[Speyedr]

Although it wouldn't surprise me if they did, I'd be interested to see how they can spin a firewall that drops packets as being able to cause an exploit. Not only that, but them attempting to prevent people from using firewalls to block spam or malicious attacks would likely reach worldwide news as they could be claiming that you can't protect yourself when using your own computer.

I'm sorry that you're having to deal with this, but I believe your case was relating to a paid mod menu, correct? Mod menus violate Take-Two's copyright and Rockstar's Terms of Service, not to mention they can cause financial losses. SCBlocker doesn't violate copyright because it doesn't contain nor modify any code which is owned by Rockstar / Take-two, it doesn't violate the Terms of Service because no reverse-engineering was undertaken to create SCBlocker (and it also does not modify the game), and it does not take away any revenue streams from Take-Two.

One final note is that this is just a workaround, and not the "actual" fix. If I modified how the SocialClub overlay works to actually fix the problem, then I think I could definitely be in big trouble for modifying copyrighted works. But again, I'm not doing that. This is an entirely separate program that does not directly modify anything and cannot be used to gain an advantage.

[sfinktah]

Perhaps you have not noticed the number of open-source projects taken down by Take-Two over the last 6 months? You will also note that their EULA disallows running unauthorised program in conjunction with their games, that would be you.

Anyway, I'm not saying you'll get in trouble for this project -- you won't -- I'm just suggesting that you might want be to careful with those "other things to work on and share." :)

[Speyedr]

There's a few different things here that I think need to be separated in order to fully understand which risks I'm taking by developing and distributing this program, as well as the potential consequences.

Just because a program is open-source doesn't mean it won't violate Rockstar Games / Take-Two Interactive's copyrights. This is why several open-source reverse-engineering projects relating to R*'s older games were taken down; they violated copyright by distributing reverse-engineered code which was derived from code owned by R* / T2. Had they properly followed and enforced clean-room development (if I remember correctly, they accepted re-formatted IDA de-compiled code--which ultimately proved that they were not creating the code being submitted for the project), then things may have turned out different for them.

I am completely confident that this program does not infringe on R* / T2's copyright, not only because I have never seen a single piece of code in either assembly or de-compiled by IDA (or similar debugging programs) that belongs to R* / T2, but also because there is no "copying" occurring in the first place. The code hosted in this repository is my work which I wrote from an empty project and, technically speaking, does not actually require any part of R* / T2 services or IP to function. It's just a packet-based firewall which has been set up to function in a way which blocks R* / T2 services, and ultimately could be set up to act as a firewall for any other purpose or behavior.

Ultimately, this means that R* cannot legally take down this project via a DMCA takedown request because they would also need to demonstrate that this program contains some sort of IP which is owned by R* (which they shouldn't be able to). Will they attempt it anyways and threaten to take me to court if I challenge the takedown request? Probably. Will I be game enough to fight R* / T2 in court? I can't answer that at the moment.

Now, even if this program is completely legal, that does not mean that it will also comply with Rockstar Games' EULA, which you quoted in your reply, specifically condition 'L' in the EULA, which is also paralleled by condition '(8)' in Rockstar Games' Code of Conduct. Although I think the intention of these conditions are to stop automatic bots and data scraping from SocialClub, it is possible that in a court battle, R* / T2 could argue that these conditions also happen to satisfy my program, and i.e. that my program does in fact violate the terms in their license. And so, even if they can't DMCA this project, they could simply claim it violates EULA and that anyone who uses it risks losing their license / getting banned from GTA Online.

However, if that were the case, this would suggest that R* have the ability to prohibit any sort of defensive network setups which may happen to prevent parts of SocialClub from functioning properly. I could recreate this solution as a set of rules for Snort and deploy them within pfSense that is installed on my router. Is that also violating R*'s EULA? Is this still a "program in connection with the Online Services"? In fact, I would argue that this program is not connected to any Online Services. There is no part of this program which 'connects' to any part of GTA Online or SocialClub. The program operates entirely separately and continues to function as a firewall without the need for any Online Service as defined in the Rockstar Games Terms of Service / EULA. It just happens that I added certain heuristics to this firewall which will block certain parts of SocialClub from functioning correctly. I think this distinction needs to be made very clear as many similar approaches to solving this issue definitely could violate ToS and / or EULA (such as modifying R*-owned code).

All this talk about EULA is fairly inconsequential as R* / T2 are well within their own rights to simply terminate my license at any time and without any reason. They could also do this to anyone else who happens to use SCBlocker. Even if this program does not violate EULA, they can still just as easily ban people who use it. At the end of the day, I think that is the biggest risk I face developing this program. While I cannot defend against R* / T2's own rights as a private company, I think that's about as far as it goes. They can terminate my license(s) at any time and of course prevent me from using their services ever again, but I don't think they can go any further.

With all this being said, I do appreciate you bringing forward your concerns, and I want to clarify that I am and will continue to take Rockstar Games / Take-Two Interactive's copyrights and EULAs very seriously as a part of this project, as well as any other works I decide to share in the future. I understand that I'm walking a knife-edge, but I also have never had any intention on violating copyright or EULA. If I believed my work(s) did this, I would take them down myself. I have no intention on developing or sharing works which violate copyright or EULA.

If an employee of Rockstar Games / Take-Two Interactive is reading this, I am more than happy to discuss the finer points of your company's Terms of Service and EULAs directly in an attempt to clarify whether my work violates the agreements and / or conditions included within.

[sfinktah]

Well, I certainly appreciate the amount of research you have done ... 99% of paid mod menu operators have never even read the EULA let alone the TOS.

FWIW, if you are Australian, I believe that the EULA and TOS both represent "unfair contract terms under the ACL" though that defense did not serve me well in court.

Rest assured that Take-Two don't give a flying duck about the law, and will present misleading and false evidence if sufficiently motivated, though I am sure they are not so motivated against you. Against me however -- well, their last witness thoroughly perjured himself by claiming our mod menu copied code from single player (giving no explanation as to what he meant, though likely he was alluding to the singleplayer cheat_controller.ysc) then said we circumvented access-control mechanisms of an undisclosable nature, but which he illustrated by pasting a screenshot of the ALERT message you get when you attempt to use a DINPUT8 based loader.

But don't take my word for it, here's a copy: https://nt4.com/gta5/da-5-affidavit.pdf

That was in response to the courts last judgement, which determined their claim for AC TPM circumvention was somewhat lacking.

Here's a copy of that judgement, which as you can see, did not go well for me. https://www.judgments.fedcourt.gov.au/judgments/Judgments/fca/single/2021/2021fca1024

However I am still actively fighting this AC TPM issue because I feel strongly that this country (and the world) needs some precedents set down to curtail abuse by large corporations claiming everything is a "Technical Protection Measure" and that anything they don't like is clearly circumventing it. My rebuttal is currently with my lawyer and will shortly be lodged with the court, I would post a preview copy but I'm not sure if that's strictly kosher.

With regards DMCA takedown notices, you have an encouraging precedent with the youtube-dl github takedown notice and how the EFF successfully responded and were supported by github (microsoft).

[ghost]

Sorry to necro an old discussion. I've been glancing at this program and your fork of guardian on gitlab. Do you intend to combine these projects into a single program, SCBlocker and GuardianFF?

I also see you've worked with wes0617 some. I was curious why you both have separate firewalls. Any chance on you two collaborating together on a single project, whether that's furthering your fork of guardian or their securosurf firewall? It appears that you both manage your respective firewalls alone and, I don't know, seems like you'd both be great together.

[Speyedr]

Do you intend to combine these projects into a single program, SCBlocker and GuardianFF?

Probably eventually. How both programs are operated are fundamentally different, mainly because I didn't originally develop Guardian but did have that luxury when developing SCBlocker, and their filter heuristics are entirely separated from each other (for example Guardian filters on UDP, SCBlocker on TCP). I do have a lot of ideas on how to improve Guardian, but any plans are currently roadblocked due to the new certificate exchange that was added to prevent remote crashing, which somewhat frustratingly does have a perfect solution, but properly implementing it without violating reverse engineering laws is making things difficult. If I can get that fix implemented then there's a lot of things I would want to add to Guardian, including merging features from SCBlocker into it.

I also see you've worked with wes0617 some. I was curious why you both have separate firewalls. Any chance on you two collaborating together on a single project, whether that's furthering your fork of guardian or their securosurf firewall? It appears that you both manage your respective firewalls alone and, I don't know, seems like you'd both be great together.

I'm unsure whether the visions for each of our projects would be compatible, but I appreciate the suggestion. One thing to note is that my versions of Guardian are intended to only be necessary for the Session Host (clients don't need a copy), whereas Wes0617's solution requires all parties involved to use it, and thanks to some new discoveries I'll probably end up doing another rework of the heuristics used. As for collaborative work in general, the original Guardian's lead developer "Ruben" has been acting as a project advisor, and I've also been accepting some code contributions from "TheMythologist"'s fork.

Overall the project is evolving pretty quickly, it's just stuck on implementing a proper fix for the new certificate exchange.