Overwatch/Spectate Tool Framework Outreach

Help and Feedback Game Design Support
, ,
#1

I’m making an attempt at developing a tool that administration/developers of games can use to actively and in real-time, catch cheaters/exploiters using Player/Humanoid ESP’s, Aimbot scripts, Hitbox Expansion, and other forms of illegitimate programs to enhance their game play in various combat-related games on ROBLOX. This should include swordfighting and gunfighting in all styles (FPS, 3rd person, mouselock, et cetera).

The point A to point B goal is to have this tool mimic the most analog form of input from, say, Player1 to Player2 and display it on Player2’s client. This isn’t meant to be a way of auto-banning people, as those systems can be tedious to tinker with and ultimately lead to false positives on extreme ends of their spectrums without some serious data analytics. The tool is meant to be similar to CS:GO’s Overwatch system, yet used by an administrator currently in-game with the person, not recorded.

The issue I’m wrestling with is how to best design the system itself. It appears that most clients’ systems can handle repeated RemoteEvent FireServers, sending lots of “JSON”-style information to the server on Heartbeat, but some clients lag and the information is pretty easily spoofable or just outright deniable (given you know what you’re doing). With that being the case, a person is the best kind of firewall to this issue, yet some limitations come with the software.

Server turn around time causes Camera CFrame lag, so CFrame:lerp() has to be used constantly to update, with it still not looking all that great. UserInputService:GetKeysPressed() and UserInputService:GetMouseButtonsPressed() make an awkward system of presenting what keys are being used by the “Suspect” at that current time and can be annoying, and depending on the system, laggy, to have a history of such things listed. Hitboxes, or the size of a client-sided part being sent to the server is hard to look-up because you’re unable to send mixed data-types across the client-server boundary, and the list goes on.

I suppose what my question would be is:

What would be a recommendation, framework-wise, if someone were to try and mimic the analog forms of input (ping, screen resolution, mouse’s position, buttons being pressed, keyboard keys being pressed, camera’s CFrame, other Character’s BodyPart Sizes) from one client to another and represent them in an accurate, efficient, and secure way?

I understand that ultimately, if someone knew what they were doing, they could very easily not partake in supplying information, or spoof the information. However, increasingly so, I’ve found it quite difficult to think of anyone who would be able to type out this information by hand that looks even relatively normal and fool a person with experience in these formats.

Examples of work currently done:

image
image1289×676 698 KB


https://i.gyazo.com/3012aab939bffe4f921a86dfe0953f80.mp4

Edit: Moved to a more proper topic sub-forum

2 Likes
#2

I have seen systems designed like this and like you say, they are very easy to spoof and pretend the exploiter is doing nothing wrong, essentially turning your system into an anti-pleb filter, that can bypassed with a bit of scripting knowledge.

Some features of your system, such as hitbox detection, can be done on the server without any client interaction. A client can manipulate anything it is sent and anything it sends to the server, so 100% secure transfer of mouse inputs and camera CFrame is not really possible to validate. An idea I was briefly looking into was sending the client a message telling it to send a false positive back or “fake” data (pre-defined data on the server). For example, the server would generate a random CFrame and expect it back through the same remote event that the normal data runs through, if it wasn’t recieved within a time it would consider it spoofed and handle it appropriately.

That’s the only way I could see it working; validating that your detection system works rather than validating the data the server is being sent.

#3

Turns out my thread was in the wrong sub-forum. Hopefully I’ll get more here.

I should emphasize what I’m asking is to get down to specifics of how someone with experience would in-depth, design such a system. Should I be sending JSON information every client-sided Heartbeat? RemoteEvents or RemoteFunctions? What efficient means could be used to cut down on the amount of unnecessary FireServers or FireClients made? How would the members of the forums design such a system themselves?

All suggestions are welcome.

1 Like