Closed overkidding closed 5 days ago
Hi, I'm already using transactions in some of the checks, and I'm also currently recoding most of the verification for the upcoming releases of Sonar to include lag compensation to minimize false positives even further.
Hi, I'm already using transactions in some of the checks, and I'm also currently recoding most of the verification for the upcoming releases of Sonar to include lag compensation to minimize false positives even further.
Yea but you're not using them to check if the teleport has been confirmed and if it has been sent in the right order you could just check for this: (obviously you need to send the transaction packets when teleports are sent)
if(packet instanceof TransactionPacket && user.getProtocolVersion().lessThan(ProtocolVersion.MINECRAFT_1_9)){
TransactionPacket transaction = (TransactionPacket) packet;
checkState(!teleported, "duplicate teleport confirm");
checkState(transaction.getTransactionId() == expectedTeleportId, "expected TP ID " + expectedTeleportId + ", but got " + transaction.getTransactionId());
if (expectedTeleportId == FIRST_TELEPORT_ID) {
lastPositionPacket = null;
expectedTeleportId = SECOND_TELEPORT_ID;
} else {
// Enable the movement checks
teleported = true;
if (user.getProtocolVersion().greaterThanOrEquals(ProtocolVersion.MINECRAFT_1_21_2)) {
checkState(lastPositionPacket != null, "excepted position rotation but got teleport confirm.");
handleMovement(
lastPositionPacket.getX(), lastPositionPacket.getY(), lastPositionPacket.getZ(),
lastPositionPacket.isOnGround(), true);
}
}
Hi, I'm already using transactions in some of the checks, and I'm also currently recoding most of the verification for the upcoming releases of Sonar to include lag compensation to minimize false positives even further.
Yea but you're not using them to check if the teleport has been confirmed and if it has been sent in the right order you could just check for this: (obviously you need to send the transaction packets when teleports are sent)
if(packet instanceof TransactionPacket && user.getProtocolVersion().lessThan(ProtocolVersion.MINECRAFT_1_9)){ TransactionPacket transaction = (TransactionPacket) packet; checkState(!teleported, "duplicate teleport confirm"); checkState(transaction.getTransactionId() == expectedTeleportId, "expected TP ID " + expectedTeleportId + ", but got " + transaction.getTransactionId()); if (expectedTeleportId == FIRST_TELEPORT_ID) { lastPositionPacket = null; expectedTeleportId = SECOND_TELEPORT_ID; } else { // Enable the movement checks teleported = true; if (user.getProtocolVersion().greaterThanOrEquals(ProtocolVersion.MINECRAFT_1_21_2)) { checkState(lastPositionPacket != null, "excepted position rotation but got teleport confirm."); handleMovement( lastPositionPacket.getX(), lastPositionPacket.getY(), lastPositionPacket.getZ(), lastPositionPacket.isOnGround(), true); } }
How does it confirm anything and how does it help?
I also don't know where you got that code snipped from, but I cannot find it any official version of Sonar.
"excepted position"
I also don't know where you got that code snipped from, but I cannot find it any official version of Sonar.
As a temporary? patch for 1.21.2+. PositionAndLook
is sent before TeleportConfirm
. In reverse order to the previous version.
Yea but you're not using them to check if the teleport has been confirmed and if it has been sent in the right order you could just check for this: (obviously you need to send the transaction packets when teleports are sent)
I don't understand what you're trying exactly to say. Personally, for me. It's ridiculous.
Transaction is used most of the time to confirm that the client has received the packet that we want the client to know. Even without the TeleportConfirm
. The client will also always send PositionAndLook
.
For 1.8 clients. Send a teleport packet. And wait for the PositionAndLook
packet to be in the same location as the target location being sent.
Then mark client as teleported. I even don't understand why transaction is need on this position.
What if the client doesn't start processing the transaction until the next tick? To solve this problem. You may also need to confirm a transaction before sending the packet. But since we don't care when the client receives the teleport. And we can safely ignore all movement packets before the client completed teleport. I don't see any benefit in doing this other than being harder to maintain.
I'm currently recoding the verification to lag compensate teleports, abilities, and more. Transactions are already used in the bot checks.
Information
We all know that in 1.9+ there are teleport confirmation packets, but instead in 1.8 we could use transactions to check if the teleports have been executed correctly
(Like grim does for their setbacks)
Reason
This would prevent simple bots from joining the server.
Additional information
No response