search

GrimAnticheat / Grim

Fully async, multithreaded, predictive, open source, 3.01 reach, 1.005 timer, 0.01% speed, 99.99% antikb, "bypassable" 1.8-1.20 anticheat.
GNU General Public License v3.0
1.1k stars 329 forks source link

AutoBlock bypasses #1160

Open ghost opened 1 year ago

ghost commented 1 year ago

Describe the bypass and how to replicate it

Grim doesn't have autoblock checks, this causes some byasses, like NoSlow bypasses when attacking an entity (as shown in the secound video).

Adding them could include packet autoblock checks as well as interact autoblock checks, also mitigating the action.

Interact autoblock is a very rare check, the only anticheat that I know that used to check for this was AAC.

https://github.com/GrimAnticheat/Grim/assets/143915306/a1e77a24-6151-4adf-9ae7-c52169ab51bf

https://github.com/GrimAnticheat/Grim/assets/143915306/8bdc71aa-636f-440e-b19a-da07344233d7

Grim version

16f2e54

Server version

git-PaperSpigot-445 (MC: 1.8.8)

Plugins

Plugins (4): Citizens, WorldEdit, GrimAC, System

c0dingnoobi commented 1 year ago

one of them is covered by #1161 currently debugging the other one

c0dingnoobi commented 1 year ago

currently debugging the other one

update, the one which is currently not flagged by #1161 is the same logic described in #881

basically when player starts to attack (with the cheat) he sends placement and never sends release_use_item, hard to track since there are some scenarios where legits also dont send a release_use_item (f.e changing slot, server setting a slot in the tick when player blocks etc etc) it might be kind of possible to do this for 1.8 but it will be definitly too hard for any 1.9-latest due to missing flying

ManInMyVan commented 2 months ago

I think the desync is caused by the server sending a slot update (for durability, causes client to unblock) and the client releasing at the same time, which is weird, because I'm pretty sure we check for this.