[Feature Request] Integrate testing suite to ensure confidence and prevent bugs

[Speyedr]

Is your feature request related to a problem? Please describe.
Rockstar has a habit of introducing changes, features, or additions to GTA Online that end up breaking several other features.
Let's learn from this and do exactly not that by integrating a testing suite that can ensure filters are working as expected throughout updates and that any changes don't break the program.

Describe the solution you'd like
I'm still not quite sure on what testing suite should be used, but I'll probably go for the default python testing framework, unittest.

Describe alternatives you've considered
Now that this project is going to be relied upon by so many people, manual testing and re-testing of features just isn't an option anymore. Automated testing will help accelerate development and will allow updates to be completed sooner.

Additional context
Several people have reported that the program "just doesn't work", and automated testing may also reveal previously hidden bugs or edge cases that have been affecting those people.

[Speyedr]

This is just my room temperature take on this, but is it possible the issue relies on PEBCAK? When I used to do attacks, we'd have to deal with something like burp proxies in the way of sniffing the traffic and counter it. In several shit countries, their ISPs rely on things that sniff traffic for no-no words. Is it possible they're interfering with your filtering? Maybe obfuscating the client's gateway causing the program to fail?

OK cool but how is that PEBCAK?

A user who isn't smart enough to realize they're being spied on, shouldn't have their hand held like this. If you think running unit tests all day will catch this, you're sorely mistaken.

It's definitely possible that national firewalls such as those present in India or China (or perhaps even Russia now) are censoring or editing packets in ways which break heuristics. This sort of issue has already been discovered with VPNs that use WinDivert such as Cloudflare WARP, as they seem to encrypt the packets before SCBlocker can see them, meaning that obviously the packets look entirely different and don't match any known filters.

While I don't think that this project should provide support for packets being obfuscated or censored by national firewalls, I still think that adding test cases will at least help prove that any issue with the filter not working is "PEBCAK" instead of the program itself.

For example, the current content-matching filters don't account for fragmentation occurring "in the middle" of a pattern match, so if for some reason one segment contains the start of a pattern and the next segment contains the end of the pattern, both packets will be allowed through the filter, then the rest of the fragments will also get through and it's game over.

Even though it's unlikely that fragments are so small they break a 100-character match at least we'll have enough of a reason to automatically close any generic bug reports that don't explain the issue thoroughly enough seeing as any builds released are operating as expected during testing, indicating that it is indeed a problem with the user and not the program.

[Speyedr]

Wouldn't it be smarter to attack level 2 instead of just sticking some level 3 signaling Python nonsense? ARP poisoning comes to mind. It's a classic attack, one that's very hard to defend against. Since the script is only interested in just knowing who you're talking to and what port, it would make sense you don't really care about the contents too much if they're encrypted. It wouldn't be too hard to determine a crypted packet from an unencrypted packet with some simple heuristics. Also WinDivert is just a framework, you'd need to attack the implementation of it each VPN uses. But if you move to level 2, this won't matter.

I was considering using something like this for a MITM attack on the session traffic / in-game activity as part of a different and bigger project but I just don't have the experience to get this working at the moment. You bring up a good point though that at least determining encrypted packets should be easy.

I'll need to double-check this later but I'm pretty sure that SocialClub uses the same servers for different parts of the SocialClub Overlay, which is why blocking outbound packets to prs-gta5-prod.ros.rockstargames.com/gta5/11/gameservices/Presence.asmx/GetMessages by matching against the header seemed like the best choice at the time as blocking all communication broke too much of the overlay.

Once I get the 3rd filter complete and investigate what those payloads actually contain I'll start looking into TCP spoofing, and then I might try MITMing. The more I think about it the more I think it makes sense; You spoof the address of the server to some local address, then a service at that address impersonates as the server to the client and as the client to the server? To the real client and real server the MITM is invisible? Maybe once I get something working I'll understand a bit more about it.

[Speyedr]

As an absolute last resort, maybe I could resort to hooking something for debugging purposes but I don't think we'll ever get to that stage. As you've suggested, there is some point at which it's too much work for such a small project, however I really do appreciate your feedback and expertise in this field, and at some point I probably will need to do research on exactly how packets are handled and exactly what information can be exchanged and these techniques will likely come in handy. I have a couple of books on IDA and RE in general which I want to get through at some point so I can understand how to do this sort of research "properly" but I haven't really had the time to sit down and go through each book and their examples thoroughly yet.