• 1 Post
  • 36 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • Cheats running at ring0 aren’t invisible

    Every rootkit ever disagrees with that statement.

    Clarification, to the game client, the cheat has to interact with the actual game process at some point. Rootkits try to interact with other processes as little as possible until instructed otherwise

    I’m not deep enough in the topic to be able to judge this, but i would guess the needed extra hardware is simple not worth it. especially in games with many players or complex physics i would guess that could lead to considerable load on the servers.

    Nope, the servers are already beefed up to just handle the players and physics as-is, adding detection routines to determine “Hey, this player is flying 100s of feet in the air and there’s no flying in this game” would be like a drop in the bucket

    Plus, server side is not able to catch things the client manipulates on his side. e.g. graphical data to make walls transparent. The server could at most catch the player abusing this knowledge, but if he is smart about it, the server has no way to ever notice.

    Do you realize how much cheating just some server-side checks would cut down? The most egregious ones are the ones people complain about, and hate, the most. The ones who instakill you or fling you far above the map or shoves you underground. The “smart ones” can be taken care of manually based on reports.

    There will never ever be a 100% cheat proof game kernel AC or not. Nothing is unhackable.

    It’s all about doing it as cheaply as possible and offloading to a third party to handle so they can wash their hands




  • https://en.wikipedia.org/wiki/BattlEye

    Interacts with the game at the kernel level.

    Fuck cheaters, but also FUCK kernel level shit, it’s possible to make a good AC without fucking around in the kernel.

    I don’t even install third party Antivirus’ that hook into the kernel because of all the issues it causes. 80% of all BSODs I’ve traced back have always had a root cause because of some shit piece of software fucking around in the kernel. 15% is shitty drivers.

    Kernel AVs and ACs actually act like malware in of itself with the types of hooks and interactions it performs. Anything operating at the kernel level can basically see just about everything you or your computer is doing

    Fuck kernel level AC







  • Actually, no. Phones don’t always broadcast their IMSI. Most of the time they broadcast a Temporary Mobile Subscriber Identity (TMSI) and only on a location update (For power conservation). Your cell provider knows your IMSI already and uses a TMSI for updates for the express purpose of privacy and security for these exact scenarios

    It is part of the initial work flow of a Stingray device to attempt to force your device to disconnect from the network and get it to rebroadcast its actual IMSI. But it is not floating around in the air all the time and it certainly isn’t trivial to grab.

    BT is really the only viable option, and even that can vary wildly depending on manufacturer.


  • Yea, no, the most likely route is to pickup a MAC address and associate it with an existing assigned IP address (If that device is connected to the public WiFi, but who even does that these days lol), but modern day Android and iOS randomize MAC addresses on every connection these days by default.

    And then you’d still need to correlate that to the physical world, most likely route would be detecting Bluetooth hostname, but it’s by no means guaranteed that the device hostname in the public WiFi DHCP table matches the BT one (phones can have different names for each). And again is dependent on the person being connected to store WiFi to begin with. Would also be entirely thwarted of a person’s BT is off which is highly likely

    It’s possible, but would be a useless feature to develop and maintain as it would probably actually work out in the real world like maybe 30% of the time.

    Unless they shoved a full stingray unit in it or something (extremely unlikely), this is just a statement from someone parroting a sales brochure that they didn’t entirely understand





  • Gaming is one thing, a lot is GPU bound anyways, probably the same with “physical modeling”

    But you cannot tell me your “data processing” would not be greatly sped up by using a newer proc (assuming it’s not also GPU bound). Does it work, sure, but if it takes you 2 hours for it to process now but <30 minutes on something newer that’s just a waste of time, resources and money. It’s incredibly inefficient.

    On the flip side, if all your work is GPU bound no wonder a 3rd gen proc from 2012 is keeping up lol


  • The R5 2600 is not only newer than my old i5 and faster, it also has a LOT more threads (12 vs 4) and an extra 2 full cores

    Making it excellent for the multi threaded workloads (VMs) and leaving room for non-multithreaded optimized workloads

    I have an RTSP client program running all the time displaying a handful of camera feeds. It had a ~45-55% average CPU usage even with GPU decoding/encoding enabled on it.

    That same piece of software on my much newer 7600 changing absolutely nothing else software wise (I just dropped in the SSD from my old build) that same software barely cracks 5%

    iCUE (for Corsair RGB control (yes I know there’s open source versions I just never got around to it lol)) had a similar story with ~30-40% before and barely 4% now