Вопрос 2025 Защита сервера от nbt експлойтов (attack client)

[acv]

Приветствую! Не так давно наткнулся на так называемый attack client, который больше всего нацелен на использование разных exploit на сервере майнкрафт. Отсылая пакеты или спамя ими. Основные последствия в том, что сервер не ложиться, в привычном понимании, а просто нагружается сетевой обработчик самого сервера, от чего по всем ядрам подскакивает нагрузка или же взлетает пинг у игроков на сервере, и решается только, когда они перезайдут.
Помню, на ядрах 1.16.5 был такой екслойт от чита liquid bounce, сервер просто выключался, связанно было с nbt, ну и на 1.21.4 тоже что то подобное работает.
В общем как я понял это что то новое, потому что заставляют пинговать даже holly world и иностранные сервера.

Есть плагины которые могут срезать такие атаки? packetevents конечно тяжелые пакеты более 1мб отбрасывает но и пинг у игроков может взлететь.

При атаке, спамит что то подобное:

Спойлер: тык

[21:57:21] [Netty Epoll Server IO #3/WARN]: [com.github.retrooper.packetevents.PacketEventsAPI] PacketEvents caught an unhandled exception while calling your listener.
java.lang.IllegalArgumentException: NBT size limit reached (1048556/1048576)
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.NBTLimiter$2.increment(NBTLimiter.java:73) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.DefaultNBTSerializer.lambda$new$18(DefaultNBTSerializer.java:121) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.readTag(NBTSerializer.java:114) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.DefaultNBTSerializer.lambda$new$20(DefaultNBTSerializer.java:141) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.readTag(NBTSerializer.java:114) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.deserializeTag(NBTSerializer.java:62) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.codec.NBTCodec.readNBTFromBuffer(NBTCodec.java:161) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.codec.NBTCodec.readNBTFromBuffer(NBTCodec.java:154) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readNBTRaw(PacketWrapper.java:523) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.component.builtin.item.ItemRecipes.read(ItemRecipes.java:39) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.component.StaticComponentType.read(StaticComponentType.java:75) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.readModern(ItemStackSerialization.java:151) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.readModern(ItemStackSerialization.java:107) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.read(ItemStackSerialization.java:44) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readItemStack(PacketWrapper.java:494) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.play.client.WrapperPlayClientClickWindow.read(WrapperPlayClientClickWindow.java:130) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readEvent(PacketWrapper.java:287) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.<init>(PacketWrapper.java:169) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.<init>(PacketWrapper.java:159) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.play.client.WrapperPlayClientClickWindow.<init>(WrapperPlayClientClickWindow.java:68) ~[packetevents-spigot-2.9.5.jar:?]
at pvpclub-FasterCrystals-2.0.1.jar/xyz.reknown.fastercrystals.listeners.packet.LastPacketListener.getAnimPacket(LastPacketListener.java:75) ~[pvpclub-FasterCrystals-2.0.1.jar:?]
at pvpclub-FasterCrystals-2.0.1.jar/xyz.reknown.fastercrystals.listeners.packet.LastPacketListener.onPacketPlayReceive(LastPacketListener.java:49) ~[pvpclub-FasterCrystals-2.0.1.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.SimplePacketListenerAbstract.onPacketReceive(SimplePacketListenerAbstract.java:49) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.PacketReceiveEvent.call(PacketReceiveEvent.java:44) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.EventManager.callEvent(EventManager.java:84) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.util.PacketEventsImplHelper.handleServerBoundPacket(PacketEventsImplHelper.java:101) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.read(PacketEventsDecoder.java:59) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:76) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:42) ~[packetevents-spigot-2.9.5.jar:?]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flow.FlowControlHandler.dequeue(FlowControlHandler.java:202) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flow.FlowControlHandler.channelRead(FlowControlHandler.java:164) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:289) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flush.FlushConsolidationHandler.channelRead(FlushConsolidationHandler.java:152) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:799) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:501) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:399) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.115.Final.jar:4.1.115.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.115.Final.jar:4.1.115.Final]
at java.base/java.lang.Thread.run(Thread.java:1583) ~[?:?]
[21:57:21] [Netty Epoll Server IO #3/WARN]: [com.github.retrooper.packetevents.PacketEventsAPI] PacketEvents caught an unhandled exception while calling your listener.
java.lang.IllegalArgumentException: NBT size limit reached (1048556/1048576)
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.NBTLimiter$2.increment(NBTLimiter.java:73) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.DefaultNBTSerializer.lambda$new$18(DefaultNBTSerializer.java:121) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.readTag(NBTSerializer.java:114) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.DefaultNBTSerializer.lambda$new$20(DefaultNBTSerializer.java:141) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.readTag(NBTSerializer.java:114) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.serializer.NBTSerializer.deserializeTag(NBTSerializer.java:62) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.codec.NBTCodec.readNBTFromBuffer(NBTCodec.java:161) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.codec.NBTCodec.readNBTFromBuffer(NBTCodec.java:154) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readNBTRaw(PacketWrapper.java:523) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.component.builtin.item.ItemRecipes.read(ItemRecipes.java:39) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.component.StaticComponentType.read(StaticComponentType.java:75) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.readModern(ItemStackSerialization.java:151) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.readModern(ItemStackSerialization.java:107) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.item.ItemStackSerialization.read(ItemStackSerialization.java:44) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readItemStack(PacketWrapper.java:494) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.play.client.WrapperPlayClientClickWindow.read(WrapperPlayClientClickWindow.java:130) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.readEvent(PacketWrapper.java:287) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.<init>(PacketWrapper.java:169) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.PacketWrapper.<init>(PacketWrapper.java:159) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.wrapper.play.client.WrapperPlayClientClickWindow.<init>(WrapperPlayClientClickWindow.java:68) ~[packetevents-spigot-2.9.5.jar:?]
at pvpclub-FasterCrystals-2.0.1.jar/xyz.reknown.fastercrystals.listeners.packet.LastPacketListener.getAnimPacket(LastPacketListener.java:75) ~[pvpclub-FasterCrystals-2.0.1.jar:?]
at pvpclub-FasterCrystals-2.0.1.jar/xyz.reknown.fastercrystals.listeners.packet.LastPacketListener.onPacketPlayReceive(LastPacketListener.java:49) ~[pvpclub-FasterCrystals-2.0.1.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.SimplePacketListenerAbstract.onPacketReceive(SimplePacketListenerAbstract.java:49) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.PacketReceiveEvent.call(PacketReceiveEvent.java:44) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.event.EventManager.callEvent(EventManager.java:84) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.util.PacketEventsImplHelper.handleServerBoundPacket(PacketEventsImplHelper.java:101) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.read(PacketEventsDecoder.java:59) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:76) ~[packetevents-spigot-2.9.5.jar:?]
at packetevents-spigot-2.9.5.jar/io.github.retrooper.packetevents.injector.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:42) ~[packetevents-spigot-2.9.5.jar:?]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flow.FlowControlHandler.dequeue(FlowControlHandler.java:202) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flow.FlowControlHandler.channelRead(FlowControlHandler.java:164) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:107) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:333) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:455) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) ~[netty-codec-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:289) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.handler.flush.FlushConsolidationHandler.channelRead(FlushConsolidationHandler.java:152) ~[netty-handler-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) ~[netty-transport-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:799) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:501) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:399) ~[netty-transport-classes-epoll-4.1.115.Final.jar:4.1.115.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.115.Final.jar:4.1.115.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.115.Final.jar:4.1.115.Final]
at java.base/java.lang.Thread.run(Thread.java:1583) ~[?:?]

Хочу осветить данный вопрос, вот еще видео

You must be registered for see medias

 

[HomaPlus]

показывай фиксы крашей

offtop

Самый простой вариант обернуть вообще все в try-catch и в случае ошибки пройтись по стеку вызовов рефлектором и кикнуть "причину ошибки"

 

[NaulbiMIX]

Иногда нужно лучше вникать в проблему с которой мы имеем дело
Речь даже была не про плагин пакетивентс как таковой, skill issue, ну что поделать.


О да, ведь диванный эксперт прочитавший пару высеров от ттхрюкси точно знает что и как делается

offtop check

3.2. В целом о ядре.
offtop
Я в своё время занимался патчами, приводил фулл ядро к исходникам, да лазил под его капот.
Пробовал просто так менять куски кода, поэтому обзор проблем ядра и того чего надо апдейтить.

________________________

Иногда нужно лучше вникать в проблему с которой мы имеем дело

Тебе об этом я уже сказал, что просто пофикси обработчик в ядре.

Бонусом надо залить проверки по паттерну на NBT и корректно написать их, а не так, чтобы были аналоги SQL injection.

________________________

Чо ж сам ядро не сделаешь, раз ты у нас тут такой всезнайка?

Делал, но не паблик, никто не готов платить тонну бабла за самописное ядро.
К тому же ты забываешь про клиент, который написан на Java и требует netty, если client-side переписать, то можно и подумать о .proto, как это сделано в многих онлайн-играх Китайцев, в отличии от Valve, которые по-своему извернулись.

показывай фиксы крашей

А я тебе уже рассказал о том, как фиксилось netty eventloop, ты про это вообще промолчал, как будто не знал об этом, поэтому на тебя и была агрессия, что ты о самом интересном для многих не упоминаешь. Кто вообще знал об этом? Данный фикс за 5к ₽ продавали ещё с 2022 года в румк.

3.1. Пакетами спамили бот-системы типа ttProxy, которые кидали их в огромном количестве и из-за того как распределялись

Авторизуйтесь для просмотра ссылок.

то и игроки получали проблемы и дисконнекты (речь не о сервере ещё).

Спасает это по такой логике: не все каналы засрут и чтобы засрать все каналы пакетами понадобится время.

________________________

раз ты у нас тут такой всезнайка?

Я и сам не могу знать всё о ядре, даже учитывая его переписывания/привод к фулл SRC/патчи.
У меня у самого есть много вопросов и непоняток, прочитай внимательно мой монолог, а я процитирую мои сомнения:

не в курсах что с его сервером (работает или нет)

ведь на форумах его снесли вродь как.

Произошёл уже exit scam, если так можно сказать или автору чёт придумали в его Польше

Если я не ошибаюсь, то в Paper до сих пор не завезли это

в MultiPaper бы его (кстати, а он там юзается???).

Получается я тебе не эксперт во всём, но при этом знаю больше, чем другие раз могу поведать истории о том, как раньше ботили?

________________________
По поводу ttProxy

О да, ведь диванный эксперт прочитавший пару высеров от ттхрюкси точно знает что и как делается

я её покупал навсегда ELITE версию, брал с целью изучения атак, а не боттинга серверов (мне ботить не к чему).
Ещё в 2022 году ботил сервера которым помогал в существовании, на них испытывал ботов и собирал ISP/CIDRs проксей на ttProxy.

Мне было интересно как авторы ttProxy (expando - media, takin_tu - developer) реализовали всю эту систему.
Если ты считаешь высерами от ттпрокси её существование в целом, то почему же тогда в их ДСе было 100+ участников и куча купивших их подписки? А она так была популярна, что на ютубе снимали бот-атаки и падения с её помощью?
Люди платили через злотии (валюта Польши), а сам человек требовал оплату через PayPal, я тогда даже переплатил с обменником суммарно свыше 120 ₽ за доллар (спасибо тому времени), с учётом мировой ситуации.

Вот теперь тут AttackClient стало быть популярен, потому что насилует сервера, тему подняли из-за популярности.
Был бы 2022 год и в содержимом теме было бы другое.

Про ttProxy я упомянул как пример массовости отправки пакетов с разных аккаунтов чтобы засрать потоки netty

Пакетами спамили бот-системы типа ttProxy, которые кидали их в огромном количестве

о чём ты Overwrite говорил ранее

Там новых миллион, так что бывает.
Я думаю майнкрафт не может - apadtive & io_uring поможет, но увы... мне кажется даже они такой спам не вывезут

Причём тут было использование других обработчиков netty на неизвестные теме миллионы пакетов непонятно, ведь с AttackClient заходит с одного игрока и кидает парочку пакетов или же просто их закидывает через for-each (и др.) штук 100 за 5-10 тиков, но есть ещё ограничения в количестве обрабатываемых пакетов на стороне сервера. Да и LPX может лимитировать конкретно отправляемых пакеты к слову, но почему же тогда LPX не защищает?
Об этом говорит ещё один человек:

LPX не покрывает все векторы: при моей поддержке сервера я нашёл три эксплойта, сообщил разработчикам — патчи добавляли с задержкой до суток.

Немножко взял конфига LPX с его странички на BuiltByBit

flood:
    a:
      enabled: true
      punish: true
      max-vl: 3
      min-vl: 1
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. :<'
      options:
        max: 1100
    b:
      enabled: true
      punish: true
      max-vl: 6
      min-vl: 3
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. >:'
      options:
        # The following strings are represented by 2 or 3 parameters:
        # PacketName | Max packets | Interval(ms) | Periods | Warnings
        # "ANIMATION,50,500,5,2" Means this check will flag when a player sends 50 ANIMATION packets in an interval of 500ms for 2 times in a period of (5*500ms)
        limits:
          - "ANIMATION,50,500,5,2"
          - "USE_ITEM,60,1000,5,2"
          - "PLAYER_BLOCK_PLACEMENT,14,100,6,3"
          - "CLICK_WINDOW,20,200,10,4"
          - "CREATIVE_INVENTORY_ACTION,20,200,10,4"
          - "PLAYER_POSITION,40,100,5,3"
          - "PLAYER_ROTATION,40,100,5,3"
          - "PLAYER_POSITION_AND_ROTATION,40,100,5,3"
          - "CRAFT_RECIPE_REQUEST,15,1000,2,1"
          - "TAB_COMPLETE,40,1000,2,1"
          - "INTERACT_ENTITY,25,500,5,3"
          - "CHAT_COMMAND,5,500,5,2"
          - "PLAYER_DIGGING,40,500,6,3"
          - "UPDATE_SIGN,2,300,6,2"

Повторюсь, клиент отправляет именно парочку некорректных пакетов и сервер ложится (это их NBT Private краш), что можно понять по их каналу в ТГ закрытому.
Постам вот этим:

Авторизуйтесь для просмотра ссылок.

,

Авторизуйтесь для просмотра ссылок.

Хотя иногда и бывало множественное

Авторизуйтесь для просмотра ссылок.

(настройки packets = 500 шт. но size = 35 000), но какой толк в них, если сервер не обработает - ещё не понятно.

________________________

Хотя с другой стороны о чём говорить, если там человек на серьёзном ебале заявляет, что у нас тут ТТПРОКСИ виноват, когда тут очевидно аттак клиент

А где я тебе говорил, что виноват ttProxy, если в теме человек атакует AttackClient, ты вообще о чём говоришь?

Не так давно наткнулся на так называемый attack client, который больше всего нацелен на использование разных exploit на сервере майнкрафт. Отсылая пакеты или спамя ими.

Я ttProxy приводил как пример того, где ботами кидали много пакетов, а тут один игрок кидает некорректный пакет или ограниченное количество возможных на себя самого, которое сервер сможет обработать исходя из лимитов.

3.1. Пакетами спамили бот-системы типа ttProxy, которые кидали их в огромном количестве и из-за того как распределялись

Авторизуйтесь для просмотра ссылок.

то и игроки получали проблемы и дисконнекты (речь не о сервере ещё).

Короче, тут человек кидает конкретно хреновый пакет, а не количество пакетов. Ботов же вам не забрасывают, да?

Про ботов вообще вопрос оставил, на него так и не ответил автор темы.
________________________

точно знает что и как делается

Даже при моих знаниях достаточно понятно по каким коллекциям данных с GitHub ты собрал ядро ShieldSpigot.

Ах, да, твоё же ядро ShieldSpigot собрано из паблик фиксов разных версий ядер (Dionysus, Patina, Akarin etc.)

Надо просто признать, ядро написано исходя из опенсурсных патчей и в этом нет ничего плохого, кроме как нарушений их LICENSE, но да ладно... Кто же знает как

Авторизуйтесь для просмотра ссылок.

в румайне?)
________________________

Проблема ТОЛЬКО и ТОЛЬКО в том, что эта залупа спамит в консоль, в следствие чего сервер падает.

И в добавок отвечу на это.
Нет, ты не прав, сервер может не спамить, а просто лечь и высрать как я высказался:

paper don't crash report

________________________
Если ты хочешь по своей логике отрабатывать миллионы краш пакетов несмотря на их нагрузку, то изменение библиотек самый лучший вариант.

Там новых миллион, так что бывает.

Никаких ФАСТ ЖЫСОНАВ и ФАСТ НБТЫШЫК нам не нужно.

А сервер тебе с оптимизированными либами скажет только спасибо, каждый тик будет быстрее обрабатываться.
Да и saveData на даные в playerdata уже в асинхрон выпихнули, но тем не менее это не будет нагружать процессор, когда

Авторизуйтесь для просмотра ссылок.

)

 

[Marmok22]

offtop check


________________________

Тебе об этом я уже сказал, что просто пофикси обработчик в ядре.


________________________

Делал, но не паблик, никто не готов платить тонну бабла за самописное ядро.
К тому же ты забываешь про клиент, который написан на Java и требует netty, если client-side переписать, то можно и подумать о .proto, как это сделано в многих онлайн-играх Китайцев, в отличии от Valve, которые по-своему извернулись.


А я тебе уже рассказал о том, как фиксилось netty eventloop, ты про это вообще промолчал, как будто не знал об этом, поэтому на тебя и была агрессия, что ты о самом интересном для многих не упоминаешь. Кто вообще знал об этом? Данный фикс за 5к ₽ продавали ещё с 2022 года в румк.



________________________

Я и сам не могу знать всё о ядре, даже учитывая его переписывания/привод к фулл SRC/патчи.
У меня у самого есть много вопросов и непоняток, прочитай внимательно мой монолог, а я процитирую мои сомнения:





Получается я тебе не эксперт во всём, но при этом знаю больше, чем другие раз могу поведать истории о том, как раньше ботили?

________________________
По поводу ttProxy

я её покупал навсегда ELITE версию, брал с целью изучения атак, а не боттинга серверов (мне ботить не к чему).
Ещё в 2022 году ботил сервера которым помогал в существовании, на них испытывал ботов и собирал ISP/CIDRs проксей на ttProxy.

Мне было интересно как авторы ttProxy (expando - media, takin_tu - developer) реализовали всю эту систему.
Если ты считаешь высерами от ттпрокси её существование в целом, то почему же тогда в их ДСе было 100+ участников и куча купивших их подписки? А она так была популярна, что на ютубе снимали бот-атаки и падения с её помощью?
Люди платили через злотии (валюта Польши), а сам человек требовал оплату через PayPal, я тогда даже переплатил с обменником суммарно свыше 120 ₽ за доллар (спасибо тому времени), с учётом мировой ситуации.

Вот теперь тут AttackClient стало быть популярен, потому что насилует сервера, тему подняли из-за популярности.
Был бы 2022 год и в содержимом теме было бы другое.

Про ttProxy я упомянул как пример массовости отправки пакетов с разных аккаунтов чтобы засрать потоки netty

о чём ты Overwrite говорил ранее

Причём тут было использование других обработчиков netty на неизвестные теме миллионы пакетов непонятно, ведь с AttackClient заходит с одного игрока и кидает парочку пакетов или же просто их закидывает через for-each (и др.) штук 100 за 5-10 тиков, но есть ещё ограничения в количестве обрабатываемых пакетов на стороне сервера. Да и LPX может лимитировать конкретно отправляемых пакеты к слову, но почему же тогда LPX не защищает?
Об этом говорит ещё один человек:

Немножко взял конфига LPX с его странички на BuiltByBit

flood:
    a:
      enabled: true
      punish: true
      max-vl: 3
      min-vl: 1
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. :<'
      options:
        max: 1100
    b:
      enabled: true
      punish: true
      max-vl: 6
      min-vl: 3
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. >:'
      options:
        # The following strings are represented by 2 or 3 parameters:
        # PacketName | Max packets | Interval(ms) | Periods | Warnings
        # "ANIMATION,50,500,5,2" Means this check will flag when a player sends 50 ANIMATION packets in an interval of 500ms for 2 times in a period of (5*500ms)
        limits:
          - "ANIMATION,50,500,5,2"
          - "USE_ITEM,60,1000,5,2"
          - "PLAYER_BLOCK_PLACEMENT,14,100,6,3"
          - "CLICK_WINDOW,20,200,10,4"
          - "CREATIVE_INVENTORY_ACTION,20,200,10,4"
          - "PLAYER_POSITION,40,100,5,3"
          - "PLAYER_ROTATION,40,100,5,3"
          - "PLAYER_POSITION_AND_ROTATION,40,100,5,3"
          - "CRAFT_RECIPE_REQUEST,15,1000,2,1"
          - "TAB_COMPLETE,40,1000,2,1"
          - "INTERACT_ENTITY,25,500,5,3"
          - "CHAT_COMMAND,5,500,5,2"
          - "PLAYER_DIGGING,40,500,6,3"
          - "UPDATE_SIGN,2,300,6,2"

Повторюсь, клиент отправляет именно парочку некорректных пакетов и сервер ложится (это их NBT Private краш), что можно понять по их каналу в ТГ закрытому.
Постам вот этим:

Авторизуйтесь для просмотра ссылок.

,

Авторизуйтесь для просмотра ссылок.

Хотя иногда и бывало множественное

Авторизуйтесь для просмотра ссылок.

(настройки packets = 500 шт. но size = 35 000), но какой толк в них, если сервер не обработает - ещё не понятно.

________________________

А где я тебе говорил, что виноват ttProxy, если в теме человек атакует AttackClient, ты вообще о чём говоришь?


Я ttProxy приводил как пример того, где ботами кидали много пакетов, а тут один игрок кидает некорректный пакет или ограниченное количество возможных на себя самого, которое сервер сможет обработать исходя из лимитов.



Про ботов вообще вопрос оставил, на него так и не ответил автор темы.
________________________

Даже при моих знаниях достаточно понятно по каким коллекциям данных с GitHub ты собрал ядро ShieldSpigot.

Надо просто признать, ядро написано исходя из опенсурсных патчей и в этом нет ничего плохого, кроме как нарушений их LICENSE, но да ладно... Кто же знает как

Авторизуйтесь для просмотра ссылок.

в румайне?)
________________________

И в добавок отвечу на это.
Нет, ты не прав, сервер может не спамить, а просто лечь и высрать как я высказался:

________________________
Если ты хочешь по своей логике отрабатывать миллионы краш пакетов несмотря на их нагрузку, то изменение библиотек самый лучший вариант.


А сервер тебе с оптимизированными либами скажет только спасибо, каждый тик будет быстрее обрабатываться.
Да и saveData на даные в playerdata уже в асинхрон выпихнули, но тем не менее это не будет нагружать процессор, когда

Авторизуйтесь для просмотра ссылок.

)

ого ты выдал прям.

 

[NaulbiMIX]

Делал, но не паблик, никто не готов платить тонну бабла за самописное ядро.
К тому же ты забываешь про клиент, который написан на Java и требует netty, если client-side переписать, то можно и подумать о .proto, как это сделано в многих онлайн-играх Китайцев, в отличии от Valve, которые по-своему извернулись.

Бонусом у нас уже есть хорошие варианты ядер для майна, если не писать client-side & server-side с 0, которые лучше развёртывать на проектах, где сидят опытные люди повидавшие все приколы Bukkit API.

Речь о

Авторизуйтесь для просмотра ссылок.

- вот бы обновить его на ласт версии для народа и

Авторизуйтесь для просмотра ссылок.

- он чисто не bukkit api и форко-насилие.

offtop

cuberite пендосы очень сильно любят и даже в ИИшках юзают.
Буквально 27 ноября 2025 г. пендосы из cast ai проводили вебинары и рассказывали обо всём связанным с этим ядром. Прям вебинар по майнкрафту, о JVM приколах, о связке ИИ и всё в этом духе.

Они явно будут экспертами, которые имеют в портфолио по карьере на linkedin по 5+ medium/big-техов зарубежных и зарабатывают на нашей валюте минимально от 500к ₽/мес. Задроты Middle Java Developer ибаные и ИИ эксперты.
Да, только вот об этом никто в румайне и подавно знать не хочет.

Там люди сервера развёртывают, с веба заходят (no launcher) и тестируют свои ИИшные штучки на созвончиках.
Нам до этого как до китая

 

[Overwrite]

offtop check


________________________

Тебе об этом я уже сказал, что просто пофикси обработчик в ядре.


________________________

Делал, но не паблик, никто не готов платить тонну бабла за самописное ядро.
К тому же ты забываешь про клиент, который написан на Java и требует netty, если client-side переписать, то можно и подумать о .proto, как это сделано в многих онлайн-играх Китайцев, в отличии от Valve, которые по-своему извернулись.


А я тебе уже рассказал о том, как фиксилось netty eventloop, ты про это вообще промолчал, как будто не знал об этом, поэтому на тебя и была агрессия, что ты о самом интересном для многих не упоминаешь. Кто вообще знал об этом? Данный фикс за 5к ₽ продавали ещё с 2022 года в румк.



________________________

Я и сам не могу знать всё о ядре, даже учитывая его переписывания/привод к фулл SRC/патчи.
У меня у самого есть много вопросов и непоняток, прочитай внимательно мой монолог, а я процитирую мои сомнения:





Получается я тебе не эксперт во всём, но при этом знаю больше, чем другие раз могу поведать истории о том, как раньше ботили?

________________________
По поводу ttProxy

я её покупал навсегда ELITE версию, брал с целью изучения атак, а не боттинга серверов (мне ботить не к чему).
Ещё в 2022 году ботил сервера которым помогал в существовании, на них испытывал ботов и собирал ISP/CIDRs проксей на ttProxy.

Мне было интересно как авторы ttProxy (expando - media, takin_tu - developer) реализовали всю эту систему.
Если ты считаешь высерами от ттпрокси её существование в целом, то почему же тогда в их ДСе было 100+ участников и куча купивших их подписки? А она так была популярна, что на ютубе снимали бот-атаки и падения с её помощью?
Люди платили через злотии (валюта Польши), а сам человек требовал оплату через PayPal, я тогда даже переплатил с обменником суммарно свыше 120 ₽ за доллар (спасибо тому времени), с учётом мировой ситуации.

Вот теперь тут AttackClient стало быть популярен, потому что насилует сервера, тему подняли из-за популярности.
Был бы 2022 год и в содержимом теме было бы другое.

Про ttProxy я упомянул как пример массовости отправки пакетов с разных аккаунтов чтобы засрать потоки netty

о чём ты Overwrite говорил ранее

Причём тут было использование других обработчиков netty на неизвестные теме миллионы пакетов непонятно, ведь с AttackClient заходит с одного игрока и кидает парочку пакетов или же просто их закидывает через for-each (и др.) штук 100 за 5-10 тиков, но есть ещё ограничения в количестве обрабатываемых пакетов на стороне сервера. Да и LPX может лимитировать конкретно отправляемых пакеты к слову, но почему же тогда LPX не защищает?
Об этом говорит ещё один человек:

Немножко взял конфига LPX с его странички на BuiltByBit

flood:
    a:
      enabled: true
      punish: true
      max-vl: 3
      min-vl: 1
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. :<'
      options:
        max: 1100
    b:
      enabled: true
      punish: true
      max-vl: 6
      min-vl: 3
      punish-commands:
        - 'lpx kick %player% &cYou are sending too many packets. >:'
      options:
        # The following strings are represented by 2 or 3 parameters:
        # PacketName | Max packets | Interval(ms) | Periods | Warnings
        # "ANIMATION,50,500,5,2" Means this check will flag when a player sends 50 ANIMATION packets in an interval of 500ms for 2 times in a period of (5*500ms)
        limits:
          - "ANIMATION,50,500,5,2"
          - "USE_ITEM,60,1000,5,2"
          - "PLAYER_BLOCK_PLACEMENT,14,100,6,3"
          - "CLICK_WINDOW,20,200,10,4"
          - "CREATIVE_INVENTORY_ACTION,20,200,10,4"
          - "PLAYER_POSITION,40,100,5,3"
          - "PLAYER_ROTATION,40,100,5,3"
          - "PLAYER_POSITION_AND_ROTATION,40,100,5,3"
          - "CRAFT_RECIPE_REQUEST,15,1000,2,1"
          - "TAB_COMPLETE,40,1000,2,1"
          - "INTERACT_ENTITY,25,500,5,3"
          - "CHAT_COMMAND,5,500,5,2"
          - "PLAYER_DIGGING,40,500,6,3"
          - "UPDATE_SIGN,2,300,6,2"

Повторюсь, клиент отправляет именно парочку некорректных пакетов и сервер ложится (это их NBT Private краш), что можно понять по их каналу в ТГ закрытому.
Постам вот этим:

Авторизуйтесь для просмотра ссылок.

,

Авторизуйтесь для просмотра ссылок.

Хотя иногда и бывало множественное

Авторизуйтесь для просмотра ссылок.

(настройки packets = 500 шт. но size = 35 000), но какой толк в них, если сервер не обработает - ещё не понятно.

________________________

А где я тебе говорил, что виноват ttProxy, если в теме человек атакует AttackClient, ты вообще о чём говоришь?


Я ttProxy приводил как пример того, где ботами кидали много пакетов, а тут один игрок кидает некорректный пакет или ограниченное количество возможных на себя самого, которое сервер сможет обработать исходя из лимитов.



Про ботов вообще вопрос оставил, на него так и не ответил автор темы.
________________________

Даже при моих знаниях достаточно понятно по каким коллекциям данных с GitHub ты собрал ядро ShieldSpigot.

Надо просто признать, ядро написано исходя из опенсурсных патчей и в этом нет ничего плохого, кроме как нарушений их LICENSE, но да ладно... Кто же знает как

Авторизуйтесь для просмотра ссылок.

в румайне?)
________________________

И в добавок отвечу на это.
Нет, ты не прав, сервер может не спамить, а просто лечь и высрать как я высказался:

________________________
Если ты хочешь по своей логике отрабатывать миллионы краш пакетов несмотря на их нагрузку, то изменение библиотек самый лучший вариант.


А сервер тебе с оптимизированными либами скажет только спасибо, каждый тик будет быстрее обрабатываться.
Да и saveData на даные в playerdata уже в асинхрон выпихнули, но тем не менее это не будет нагружать процессор, когда

Авторизуйтесь для просмотра ссылок.

)

Ты языком то не чеши, а то горазд
Покажи действительный фикс прямо тут и прямо сейчас
Много теоретиков, мало практиков.

 

[Overwrite]

Ладно так уж и быть разберу

Тебе об этом я уже сказал, что просто пофикси обработчик в ядре.

При чём тут обработчик в ядре, когда проблема возникает исключительно в случае, когда у нас установлен плагин с packetevents-ом?
Что в таком случае тебе ядро то сделало, что ты его собираешься 'фиксить'?
Напоминаю как выглядит проблема:

java.lang.IllegalArgumentException: NBT size limit reached (1048556/1048576)
at packetevents-spigot-2.9.5.jar/com.github.retrooper.packetevents.protocol.nbt.NBTLimiter$2.increment(NBTLimiter.java:73) ~[packetevents-spigot-2.9.5.jar:?]

С ядром оно не связано в общем смысле.

Делал, но не паблик, никто не готов платить тонну бабла за самописное ядро.
К тому же ты забываешь про клиент, который написан на Java и требует netty, если client-side переписать, то можно и подумать о .proto, как это сделано в многих онлайн-играх Китайцев, в отличии от Valve, которые по-своему извернулись.

1) Ну сделай фикс хотя бы костылём на баките, казалось бы, люди тебе копеечку занесут даже.
2) А при чём тут клиент в нашей ситуации?

я её покупал навсегда ELITE версию, брал с целью изучения атак, а не боттинга серверов (мне ботить не к чему).
Ещё в 2022 году ботил сервера которым помогал в существовании, на них испытывал ботов и собирал ISP/CIDRs проксей на ttProxy.

Мне было интересно как авторы ttProxy (expando - media, takin_tu - developer) реализовали всю эту систему.
Если ты считаешь высерами от ттпрокси её существование в целом, то почему же тогда в их ДСе было 100+ участников и куча купивших их подписки? А она так была популярна, что на ютубе снимали бот-атаки и падения с её помощью?
Люди платили через злотии (валюта Польши), а сам человек требовал оплату через PayPal, я тогда даже переплатил с обменником суммарно свыше 120 ₽ за доллар (спасибо тому времени), с учётом мировой ситуации.

Вот теперь тут AttackClient стало быть популярен, потому что насилует сервера, тему подняли из-за популярности.
Был бы 2022 год и в содержимом теме было бы другое.

Про ttProxy я упомянул как пример массовости отправки пакетов с разных аккаунтов чтобы засрать потоки netty

Всегда удивляюсь этому невероятному ажиотажу вокруг всех этих "клиентов которые убивают всё". Как будто бы кто-то вам америку с ними открыл я не знаю. Заходят - видишь проблему - дебажишь - исправляешь. В чём заключается их величие? Не понять мне.
И ты задаёшь вопрос - почему оно было тааааааааааааак популярно? А почему популярен любой другой бот клиент или краш клиент? По тому что школьники всегда готовы пофаниться покрашив или поботив чужой сервак. Дай только повод и они с радостным лицом побегут покупать очередной краш/бот клиент, если он докажет свою маломальскую эффективность.
Ну и плюсом - я совершенно не понимаю, к чему тут сейчас упоминания 22 года и ТТпрокси в целом, когда он уже давно неактуален, а проблема заключается совершенно в другом.

Причём тут было использование других обработчиков netty на неизвестные теме миллионы пакетов непонятно, ведь с AttackClient заходит с одного игрока и кидает парочку пакетов или же просто их закидывает через for-each (и др.) штук 100 за 5-10 тиков

Плавали знаем (про проблему с pluginmessage тут скорее всего речь), но тут не тот случай, а потому - не валидно.

Повторюсь, клиент отправляет именно парочку некорректных пакетов и сервер ложится (это их NBT Private краш), что можно понять по их каналу в ТГ закрытому.
Постам вот этим:

Авторизуйтесь для просмотра ссылок.

,

Авторизуйтесь для просмотра ссылок.

Хотя иногда и бывало множественное

Авторизуйтесь для просмотра ссылок.

(настройки packets = 500 шт. но size = 35 000), но какой толк в них, если сервер не обработает - ещё не понятно.

Не парочку!
Мне были предоставлены логи
1 отправка пакета - 1 error

а и LPX может лимитировать конкретно отправляемых пакеты к слову, но почему же тогда LPX не защищает?
Об этом говорит ещё один человек:
Немножко взял конфига LPX с его странички на BuiltByBit

flood:
a:
enabled: true
punish: true
max-vl: 3
min-vl: 1
punish-commands:
- 'lpx kick %player% &cYou are sending too many packets. :<'
options:
max: 1100
b:
enabled: true
punish: true
max-vl: 6
min-vl: 3
punish-commands:
- 'lpx kick %player% &cYou are sending too many packets. >:'
options:
# The following strings are represented by 2 or 3 parameters:
# PacketName | Max packets | Interval(ms) | Periods | Warnings
# "ANIMATION,50,500,5,2" Means this check will flag when a player sends 50 ANIMATION packets in an interval of 500ms for 2 times in a period of (5*500ms)
limits:
- "ANIMATION,50,500,5,2"
- "USE_ITEM,60,1000,5,2"
- "PLAYER_BLOCK_PLACEMENT,14,100,6,3"
- "CLICK_WINDOW,20,200,10,4"
- "CREATIVE_INVENTORY_ACTION,20,200,10,4"
- "PLAYER_POSITION,40,100,5,3"
- "PLAYER_ROTATION,40,100,5,3"
- "PLAYER_POSITION_AND_ROTATION,40,100,5,3"
- "CRAFT_RECIPE_REQUEST,15,1000,2,1"
- "TAB_COMPLETE,40,1000,2,1"
- "INTERACT_ENTITY,25,500,5,3"
- "CHAT_COMMAND,5,500,5,2"
- "PLAYER_DIGGING,40,500,6,3"
- "UPDATE_SIGN,2,300,6,2"

Повторюсь, клиент отправляет именно парочку некорректных пакетов и сервер ложится (это их NBT Private краш), что можно понять по их каналу в ТГ закрытому.
Постам вот этим:

Авторизуйтесь для просмотра ссылок.

,

Авторизуйтесь для просмотра ссылок.

Хотя иногда и бывало множественное

Авторизуйтесь для просмотра ссылок.

(настройки packets = 500 шт. но size = 35 000), но какой толк в них, если сервер не обработает - ещё не понятно.

Почему же LPX не спасает?
Обращаем внимание на: - "CLICK_WINDOW,20,200,10,4"
Вычисляем игрок должен отправить 20 пакетов за 200 мс в течении 2 секунд (200*10) 4 раза
Что мешает в таком случае атакующему отправлять 19 пакетов, дабы обмануть дефолтные настройки LPX?
Вот и весь ответ

Я ttProxy приводил как пример того, где ботами кидали много пакетов, а тут один игрок кидает некорректный пакет или ограниченное количество возможных на себя самого, которое сервер сможет обработать исходя из лимитов.

Про ботов вообще вопрос оставил, на него так и не ответил автор темы.

Возвращаясь к теме ботов - я её ещё не понимаю откуда такие выводы взялись, кроме как исходя из реалий 3х летней давности.
Сейчас не 22
Хочешь скачать клиент, который был у человека -

Авторизуйтесь для просмотра ссылок.

Try and see.

Надо просто признать, ядро написано исходя из опенсурсных патчей и в этом нет ничего плохого, кроме как нарушений их LICENSE, но да ладно... Кто же знает как

Авторизуйтесь для просмотра ссылок.

в румайне?)

А мы всё продолжаем клеветать, говоря несуразицу.
Даже если парочкой патчей я вдохновился - это не означает, что ядро было целиком слизано с них.
Даже не близко.
Но конечно же увидеть функцию виртуальных потоков из лифа и с пафосным лицом говорить, что всё ядро - паста - самое простое, что можно сделать.

И в добавок отвечу на это.
Нет, ты не прав, сервер может не спамить, а просто лечь и высрать как я высказался:

А в нашем случае он именно что спамит эксепшнами.
Сказал ли я, что он не может спамить?
Я сказал, что именно в конкретно нашем случае - нам пакетивентс будет высирать спам. Всё, точка.

Тред дамп от вачдога он нам высрать вполне себе может. (Хотя только в случае с мейн тредом, но да ладно)
Суть остаётся неизменной.

________________________
Если ты хочешь по своей логике отрабатывать миллионы краш пакетов несмотря на их нагрузку, то изменение библиотек самый лучший вариант.

Про фому и про ярёму...
Проблема в нашей ситуации не в их кол-ве как таковом. А в том, что они в себе несут.
И в том, как на это реагирует пакетивентс.
Не было бы слушателя от ПЕ - не было бы и краша.
Напоминаю:

PacketEvents caught an unhandled exception while calling your listener.

Не было бы тотального высера эксепшнов - не было бы и той проблемы.

Ну ДОПУСТИМ проблема была бы другой, сервер бы упал от перегруза, пакеты волшебные, у нас там тонна итераций итд итп.
Что мешает кикать игрока в случае, если мы уловили подобный пакет - не понятно...

А сервер тебе с оптимизированными либами скажет только спасибо, каждый тик будет быстрее обрабатываться.
Да и saveData на даные в playerdata уже в асинхрон выпихнули, но тем не менее это не будет нагружать процессор, когда

Авторизуйтесь для просмотра ссылок.

)

Нет, надо городить быстрые нбтшки по тому что кумыс.
Каюсь, сам про иоюринг говорил, но теперь это уже невалидно.

 

[Overwrite]

когда

Авторизуйтесь для просмотра ссылок.

)

Математические операции работают быстрее? Да ты чтоооо)

@Warmup(iterations = 2, time = 4)
@Measurement(iterations = 3, time = 5)
@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class Main {
    
    private static final String uuidString = String.valueOf(UUID.randomUUID());

    public static void main(String[] args) throws Exception {
        Options options = new OptionsBuilder()
                .include(Main.class.getSimpleName())
                .build();
        new Runner(options).run();
    }

    @Benchmark
    public void testFastUUID(Blackhole bh) {
        bh.consume(FastUUID.parseUUID(uuidString));
    }

    @Benchmark
    public void testJavaUUID(Blackhole bh) {
        bh.consume(UUID.fromString(uuidString));
    }
}

Benchmark Mode Cnt Score Error Units
Main.testFastUUID avgt 3 28,219 ± 2,519 ns/op
Main.testJavaUUID avgt 3 21,320 ± 3,120 ns/op

Шутка такая? Или это у меня Java какая-то неправильная?

 

[arsa]

1) Обновляем плагины
2) Ставим LPX

Проблема решена

Тоже самое хотел написать)

 

[Overwrite]

Вы не поверите.
Вся проблема в том что разраб пакетивентов обскиллишьюился и поставил значение на мегабайт меньше, в следствие чего такой пакет вообще оказалось возможно отрпавить.

Авторизуйтесь для просмотра ссылок.

Да.

Объединено 13 Дек 2025

Вопрос закрывать можно