gimkit-bot
gimkit-bot copied to clipboard
ecc521
Players Kicked due to rapid answering, selector errors
Now that Gimkit placed this filter - almost all of the hacks on Github have failed to work. This filter checks your progress over the questions and your speed.
do you know what the threshold is, like how fast can we answer questions and still fly under the radar?
I haven't been putting much effort into maintaining this project, so no, I am not aware of what the limit is, and even if I was, it can always change. You can iteratively increase the delays to figure out what the limit is, and (hopefully) submit a PR incorporating the increased delays.
On Tue, Apr 28, 2020, 4:51 PM ObviousNoise [email protected] wrote:
do you know what the threshold is, like how fast can we answer questions and still fly under the radar?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ecc521/gimkit-bot/issues/8#issuecomment-620847874, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDVOG4YWUTRR2PH5TWXVVDRO46V5ANCNFSM4KGCDDVQ .
I'm going to take another look at this and see if adjusting the delays works. As stated previously, any help on this project would be extremely useful.
Simply pasting the bot code into the console and doing nothing triggers this message. It must be a targeted detection system that is easy to bypass.
It is likely that there are two systems here - the one that tracks rate of progress, and a specific one for this bot, detecting our global declarations.
We should be able to use an IIFE to prevent this issue. Preliminary changes seem to work, however the bot is not fully functional. Currently I am having trouble with the GimKit website, with it causing my CPU to spin at full speed.
They track "Exploit" from SnowLord's script, and "clickElement" from yours.
If you want to solve the issue, wrap the entire code inside of a
(function() {
//Insertcode
// All variables will stay local
})()
I believe zr is kind of like sendPacket and Ht.redboat is the redboat packet type which will be sent to the server so that the server can kick. This hack checker loop occurs every 10 seconds, on a setInterval loop.
The .post you see above tracks this data:
{
r: "clickElement", // script type
n: "name", // will appear as "" if not ingame
s: "classic" // type of gamemode
}
As for the rate limiting thing inside of the server, just click one answer wrong every 10 times or so, that should solve it.
The IIFE fix had already been implemented into a separate branch, around the time of my previous comment. Those changes are being merged now.
There were some additional issues given our use of the DevTools API, so your proposed fix would not have worked exactly as prescribed.
It looks like GimKit has changed some design aspects, as I am encountering errors in the script. I'll need to do a few more fixes before I can figure out what is going on with the rate limiting.
Sounds great, I'm going to release a PR to neaten up the code and fix some minor bugs later today aswell
I am no longer receiving the cheating detected message, however am receiving the "Answering too quickly". Luckily, there is a big difference in how the two are handled by GimKit.
The IIFE is really annoying from a debugging point of view. No good way around that though.
I can confirm that the CSS selectors need to be adjusted. The current ones are broken.
Something like this would work.
Object.defineProperty(window,"clickElement", {
get: ()=> false,
set: function(selector) { // Parameters could be expanded with ...{objects}
document.querySelector(selector).click();
this.value = false; // I don't know if this is necessary
}
})
When Gimkit checks if it is set by typing something like window["clickElement"] they will get false - therefore unset, but you could call the function by actually setting it. Weird idea, but it would work.
window.clickElement = "#type"
Fancy idea, but I'd rather not. GimKit could change their code to detect this, as they did previously. An IIFE is much better.
On Sun, May 17, 2020, 3:38 PM FloppyT [email protected] wrote:
Something like this would work.
Object.defineProperty(window,"clickElement", { get: ()=> false, set: function(selector) { document.querySelector(selector).click(); this.value = false; // I don't know if this is necessary }})
When Gimkit checks if it is set by typing something like window["clickElement"] they will get false - therefore unset, but you could call the function by actually setting it. Weird idea, but it would work.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ecc521/gimkit-bot/issues/8#issuecomment-629849353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDVOG7VIVKSLLSJ5OVPLLLRSA4MFANCNFSM4KGCDDVQ .
UPDATE: GimKit has started dropping perma-bans on IP Addresses, including mine, which has made development work quite difficult. I do not expect this to last very long however, as many schools utilize shared devices, where a single ban could easily impact large numbers of users and cause havoc.
Reset your IP, I can walk you through that if you dont know how
Edit: spelling
I'm probably going to end up using a VPN. Getting public IPs reassigned is ISP dependent. What were you going to say?
As I said, I suspect this is going to slowly build up as an issue for GimKit. Perma-banning IPs is absolutely the wrong move in this context. Alert the teacher and let them make the choice.
Well, they are most likely dropping these bans because they don't want to deal with this annoying stuff, they are working on a new thing called Ink apparently - so they are probably busy with that.
The SS I shared with you is how they got your IP...
The SS? Screen Shot? That is a GitHub URL. I suspect it has to be related to triggering these "Cheating Detected" and similar things an awful lot.
Easy solution to this is to walk into the front office of a school, ask for WIFI info, join WIFI, and get their whole network perma-banned from GimKit. Repeat, and GimKit will be forced to lift these.
Above I thought I sent a screen shot of the code where they log your IP... Ill resend. Also, what does it show when you got IP Banned? Could you show a picture? or does it just not connect?
No. There is no reason to IP log client side. They know your IP on the server.
I agree, that is what I meant, that is the section of the code that sends off an alert though. They would probably use both Redboat and the request to log you and your ip onto a database.
Whatever they do with IP logging, we can do nothing about it. All we can do is fix the bot so it doesn't get users kicked (which probably triggers bans), and put a bit of pressure on them to remove this.
There are always ways, but I believe what I've been saying along, bots are going to have to get weaker.
The last two actions I have seen from them are going to be painful. For them. Answer rate limiting has kicked out many legitimate players, and this is going to cause absolutely havoc when an entire school gets banned.
Yes, bots will get weaker. But the only way to remove the advantage of bots is to make everyone the same. And that would destroy the entire game.
It is going to take a while before the impact of this change is felt. But I'm confident it will be.
lmfao. They say you're permanently banned from playing games, but there's a button to join a new game.
