-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MoreKnockback #1780
Comments
patched by #1678 |
i just tested it, and nah |
did you put "PacketOrder" in your punishments.yml? |
Yes |
did you enable experimental checks? |
Yes |
did you enable verbose? |
Yes |
try using this jar https://github.com/ManInMyVan/Grim/actions/runs/11761716232/artifacts/2167594681 |
tested it |
The code you provided above is only supposed to actually run when you're sprinting though no? |
this function sends a sprint packet to make a pushback attack even without movement |
it doesn't look like you have that enabled |
I'm not checking stationary players on 1.9+ because of tick skipping |
As far as I can tell this is literally just an auto w-tap that only works when you're standing still. When would this be useful as hack? This would only be useful if you can use it while moving... Please correct me if I'm wrong or misunderstanding |
No, this is not an auto hit. This hack sends 2 packets when hitting - start_sprint and stop_sprint, thus, the target entity is pushed back more than with a normal hit without the hack. This works even when the hacker is not moving. This is an abuse of the mechanics of Minecraft |
That is not what I'm saying. As the debug statement in the code you copy pasted literally says, all this is a packet w-tap cheat. It's detected by BadPacketsF as soon as this is used during an attack while a player resprints (and they're moving), which happens every so often in actual fights. If you don't want to get detected (and therefore simply hold w in a fight with this cheat module on) against a player who actually knows what they're doing you will lose. The point I was trying to make is because of the reasons I have explained above this is a very low priority "bypass." This can definitely be better detected through heuristics but obviously Grim 2.0 has none of them unlike Grim Premium/3.0 because the moment you make such a check open source it becomes worthless. We may however be able to design a better logic check for this. |
This may not be the right approach but |
"Gap between packages?" |
delay between packets |
@SamB440 Can I please copy your Pharus check into here to just completely fix this for now? |
@SamB440 you said you'd port a new version of the Pharus check, how's that going? |
Describe the bypass and how to replicate it
@eventhandler
public void onSendPacket(PacketEvent.Send event) {
if ((!MovementUtility.isMoving() || inMove.getValue())
&& event.getPacket() instanceof PlayerInteractEntityC2SPacket
&& getInteractType(event.getPacket()) == Criticals.InteractType.ATTACK
&& !(getEntity(event.getPacket()) instanceof EndCrystalEntity)
&& getEntity(event.getPacket()) instanceof LivingEntity lent
&& lent.hurtTime <= hurtTime.getValue()
&& MathUtility.random(0, 100) >= (100 - chance.getValue())
&& !canCrit()) {
Grim version
latest
Server version
1.19.4
Plugins
grim, packetevents, LP
The text was updated successfully, but these errors were encountered: