LeviMC's blog

通过Patch修复BDS的空包刷屏问题

2024-08-11T09:51:07+08:00

Mojang已经在1.21.20.03中修复了此问题

本文将介绍我通过LeviLamina以及libhat通过Patch的方式解决Bedrock Dedicated Server(以下简称BDS)中服务端收到空包会在控制台刷ATTENTION! Received EMPTY UDP packet - potential UDP ports scanning.的问题。

起因

在BDS的早期版本中，存在着非常多的严重的远程崩服漏洞，空包崩服就是其中一种，自某个版本后Mojang便修复了此漏洞，但同时又在RakNet中拉了一坨printf来提醒使用者服务器收到了空包，但这又导致了另一个问题，就是攻击者可以通过频繁地发送空包来造成主线程堵塞。此问题已经由社区向反馈差不多一年时间了，Mojang仍然没有在公开的BDS版本中修复此问题，鉴于前些日子官方和MCC合作的活动服务器是由BDS+ScriptAPI驱动的，但活动服中并无此问题，由此可见Mojang早就知道BDS有这个问题，但却迟迟不修复。于是，我们只能自己动手来修复这一问题。

寻找`printf`函数所在位置

首先编写一个发送空包到BDS端口的脚本，这里选择使用Python。

Python

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
i = 0
while i < 10000: # 发送10000个空包到BDS
    s.sendto(
        "",
        ("127.0.0.1", 19132),
    )
    i = i + 1

将脚本保存为empty.py。
然后通过Visual Studio打开/挂载BDS进程，选用其它调试器例如x64dbg也可以。
运行此脚本：py empty.py
此时在控制台观察到大量的ATTENTION! Received EMPTY UDP packet - potential UDP ports scanning.输出，通过Visual Studio或其它调试器暂停主线程，我们可以看到如下堆栈：

C++

    ntdll.dll!NtWaitForSingleObject()
    KernelBase.dll!WaitForSingleObjectEx()
    bedrock_server.exe!RakNet::UpdateNetworkLoop(void *)
    ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>()
    kernel32.dll!BaseThreadInitThunk()
>	ntdll.dll!RtlUserThreadStart()

嗯？似乎没有看到任何有关输出流的调用？没关系，让我们再试一次。

C++

>	ntdll.dll!NtWriteFile()
    KernelBase.dll!WriteFile()
    ucrtbase.dll!write_text_ansi_nolock()
    ucrtbase.dll!_write_nolock()
    ucrtbase.dll!_write_internal()
    ucrtbase.dll!write_buffer_nolock<char>()
    ucrtbase.dll!common_flush_and_write_nolock<char>()
    ucrtbase.dll!__crt_stdio_output::stream_output_adapter<char>::write_character_without_count_update()
    ucrtbase.dll!__crt_stdio_output::output_processor<char,__crt_stdio_output::stream_output_adapter<char>,__crt_stdio_output::standard_base<char,__crt_stdio_output::stream_output_adapter<char>>>::process()
    ucrtbase.dll!<lambda>(void)()
    ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_d854c62834386a3b23916ad6dae2782d>,<lambda>(void) &,<lambda>(void)>()
    ucrtbase.dll!__stdio_common_vfprintf()
    bedrock_server.exe!printf()
    bedrock_server.exe!RakNet::RNS2_Berkley::RecvFromLoopInt(void)
    bedrock_server.exe!RakNet::RNS2_Berkley::RecvFromLoop(void *)
    ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>()
    kernel32.dll!BaseThreadInitThunk()
    ntdll.dll!RtlUserThreadStart()

这次我们得到了我们想要的东西，我们看到了我们期望的printf，以及printf在RakNet::RNS2_Berkley::RecvFromLoopInt(void)中调用的有效信息，现在，我们可以打开IDA或其它同类型的反编译软件来具体查看RakNet::RNS2_Berkley::RecvFromLoopInt(void)中printf的具体位置了。

C++

unsigned RakNet::RNS2_Berkley::RecvFromLoopInt(RakNet::RNS2_Berkley *this)
{
  // 略...
  while ( !*((_BYTE *)this + 260) )
  {
    v5 = *((_QWORD *)this + 30);
    if ( v5 )
    {
      v6 = (*(__int64 (__fastcall **)(__int64, const char *, __int64))(*(_QWORD *)v5 + 24i64))(
             v5,
             "D:\\a\\_work\\1\\s\\handheld\\src-deps\\raknet\\raknet\\RakNetSocket2.cpp",
             388i64);
      v7 = v6;
      if ( v6 )
      {
        // 略...
        if ( v12 <= 0 )
        {
          // 略...
          if ( v14 )
            (*(void (__fastcall **)(__int64, __int64, const char *, __int64))(*(_QWORD *)v14 + 16i64))(
              v14,
              v7,
              "D:\\a\\_work\\1\\s\\handheld\\src-deps\\raknet\\raknet\\RakNetSocket2.cpp",
              408i64);
          printf("\n\n  ATTENTION! Received EMPTY UDP packet - potential UDP ports scanning.\n\n"); // 找到Mojang拉的屎了
        }
        else
        {
          v13 = *((_QWORD *)this + 30);
          if ( v13 )
            (*(void (__fastcall **)(__int64, __int64))(*(_QWORD *)v13 + 8i64))(v13, v7);
        }
      }
    }
  }
  RakNet::LocklessUint32_t::Decrement((RakNet::RNS2_Berkley *)((char *)this + 256));
  if ( v18 )
  {
    if ( _InterlockedExchangeAdd(v18 + 2, 0xFFFFFFFF) == 1 )
    {
      (**(void (__fastcall ***)(volatile signed __int32 *))v18)(v18);
      if ( _InterlockedExchangeAdd(v18 + 3, 0xFFFFFFFF) == 1 )
        (*(void (__fastcall **)(volatile signed __int32 *))(*(_QWORD *)v18 + 8i64))(v18);
    }
  }
  return 0i64;
}

通过IDA伪代码，我们可以看到Mojang确确实实在RecvFromLoopInt里面拉了坨大的，现在我们要做的事就是Patch掉这坨了。
切换到IDA View，右键选择Synchrnoize with->Pseudocode-A，我们就可以看到罪魁祸首的汇编了：

GAS

loc_14232424B:
lea     rcx, aAttentionRecei ; "\n\n  ATTENTION! Received EMPTY UDP pac"...
call    printf
jmp     short loc_1423242B9

我们需要将lea和call给Patch为空字节，接下来切换到Hex View，同样右键选择Synchrnoize with->Pseudocode-A，我们就找到了罪魁祸首的16进制：

Text Only

48 8D 0D 9E DB B7 00 E8 D9 EB FD FF

通过LeviLamina和libhat进行Patch

现在就是我们通过LeviLamina和libhat来大展拳脚的时候了

C++

#include "libhat/Scanner.hpp"
#include "libhat/Signature.hpp"
#include "ll/api/memory/Memory.h"

void consoleSpamPatch() {
    std::byte*     funcBegin = (std::byte*)LL_RESOLVE_SYMBOL("?RecvFromLoopInt@RNS2_Berkley@RakNet@@IEAAIXZ");
    constexpr auto pattern   = hat::compile_signature<"48 8D 0D 9E DB B7 00 E8 D9 EB FD FF">();
    auto           result    = hat::find_pattern(funcBegin, funcBegin + 0x250, pattern);
    if (!result.has_result()) {
        std::cout << "Can't find signature for RecvFromLoopInt\n";
    }
    std::byte* patchLocation = (std::byte*)result.get();
    size_t     patchLength   = 12;
    ll::memory::modify(patchLocation, oatchLength, [&]() {
        std::memset(patchLocation, 0x90 /* nop */, oatchLength);
    });
}

我们也可以改用模糊匹配，将一些可能会变动的字节改为??

C++

#include "libhat/Scanner.hpp"
#include "libhat/Signature.hpp"
#include "ll/api/memory/Memory.h"

void consoleSpamPatch() {
    std::byte*     funcBegin = (std::byte*)LL_RESOLVE_SYMBOL("?RecvFromLoopInt@RNS2_Berkley@RakNet@@IEAAIXZ");
    constexpr auto pattern   = hat::compile_signature<"48 8D 0D ?? ?? ?? 00 E8 ?? ?? FD FF">();
    auto           result    = hat::find_pattern(funcBegin, funcBegin + 0x250, pattern);
    if (!result.has_result()) {
        std::cout << "Can't find signature for RecvFromLoopInt\n";
    }
    std::byte* patchLocation = (std::byte*)result.get();
    size_t     patchLength   = 12;
    ll::memory::modify(patchLocation, oatchLength, [&]() {
        std::memset(patchLocation, 0x90 /* nop */, oatchLength);
    });
}

将代码嵌入Mod中，然后将Mod安装进带有LeviLamina的服务端中。
重新执行发送空包的Python脚本，服务器的控制台无事发生，就证明我们的Patch已经生效了。

使用机器学习检测杀戮光环

2023-07-31T14:03:00+08:00

本文将介绍一种基于机器学习的反作弊思路，它利用玩家的行为数据来训练一个神经网络模型，从而有效地识别出作弊的玩家。

引言

杀戮光环简介

杀戮光环是一种外挂，它可以让玩家自动攻击周围的实体（其他玩家、怪物等）。杀戮光环的检测一直是一个难题，因为杀戮光环的行为和正常玩家的行为非常相似。
目前市面上的杀戮光环检测方法主要有以下几种：

基于行为的检测：分析玩家的攻击频率、攻击间隔等指标。
基于数据包的检测：分析玩家攻击数据包的间隔等特征。

传统方法有一些局限性，比如容易受到网络延迟的影响，或者被一些高级的外挂绕过。

特征分析

玩家行为

玩家攻击时，通常要先瞄准目标，再点击鼠标。
但杀戮光环不需要瞄准，它通过发送攻击数据包，来快速攻击周围的实体。
因此，分析玩家看的方向和玩家攻击的实体的方向，有多大的偏差，即可判断玩家是否用了杀戮光环。
在实战中，我们发现这个偏差与玩家的攻击距离有关，因此接下来我们将同时收集角度和距离的特征。

数据收集

借助LiteLoaderBDS SDK，使用以下代码，即可获取到玩家的视线向量：

C++

Event::PlayerAttackEvent::subscribe([](const Event::PlayerAttackEvent& ev) {
    Vec3 playerLookDir = ev.mPlayer->getHeadLookVector(1.0);
    return true;
});

随后使用以下代码计算玩家到实体的向量和距离：

C++

Event::PlayerAttackEvent::subscribe([](const Event::PlayerAttackEvent& ev) {
    Vec3 playerEyeLoc = ev.mPlayer->getCameraPos();
    Vec3 entityLoc = ev.mTarget->getPos();
    Vec3 playerEntityDir = entityLoc - playerEyeLoc;
    double playerEntityDist = playerEntityDir.length();
    return true;
});

接着，我们计算出夹角：

C++

double cosAngle = playerEntityDir.angle(playerLookDir);
double angle = acos(cosAngle);

至此，我们已经获得了关键数据。

数据可视化

将数据导入至MATLAB，使用以下代码，即可绘制出玩家攻击距离和玩家攻击角度的散点图：

Text Only

%% Read the csv files
vanillaData = readmatrix('data.desktop.vanilla.csv');
horionData = readmatrix('data.desktop.horion.csv');

%% Plot the data in a scatter plot
scatter(vanillaData, 'g');
scatter(horionData, 'r', 'x');

观察发现，两类数据有着较明显的区别。其中，原版客户端对应点分布于图像左下角；而杀戮光环对应点分布较散。

模型训练

神经网络的选择

在本次案例中，我们选择了DNN神经网络，原因如下：

DNN网络在大量数据的情况下表现较好。在Minecraft中，玩家攻击数据收集成本较低。
DNN网络可以较容易地移植到C++上，减小开发难度。

神经网络训练

读入数据后，我们使用以下MATLAB代码创建一个DNN神经网络：

Text Only

net = patternnet(hiddenLayerSize);

接着，开始训练：

Text Only

net = train(net, P_train, T_train);

在实战中，测试集报告的分类准确度达到了87%，符合预期。

实践

神经网络移植

使用MATLAB中的save函数，我们可以保存训练好的模型的权重等数据。
在C++中实现相关逻辑后，即可用于新数据的分类：

C++

double DNN(const std::vector<double>& X) {
    // ===== SIMULATION ========
    // Dimensions
    int Q = X[0].size();
    // Input 1
    std::vector<double> Xp1 = mapminmax_apply(X, x1_step1);
    // Layer 1
    double a1 = logsigApply(matlab::matrixAddition(matlab::repmat(b1, Q), matlab::matrixMultiply(LW1_1, Xp1)));
    
    return a1;
}

检测实现

使用 “特征分析”-“数据收集” 章节中，我们收集到玩家的攻击数据，即可进行分类：

C++

std::vector<double> playerData = {};
playerData.push_back(playerEntityDist);
playerData.push_back(angle);
double results = DNN(playerData);

神经网络返回数据分类为1的概率。

总结与展望

主要贡献

机器学习在游戏中的主要贡献如下：

我们只需要找到玩家行为的量化方法，即可进行异常检测。
如果外挂进行了升级，借助机器学习较高的灵活性与可扩展性，我们可以通过增加数据量或数据维度的方式，及时地做出应对。

未来的发展方向

反作弊作为一种保证玩家游戏公平的手段，能够帮助广大服主建立良好的游玩体验，提高用户的满意度和留存率。
但随着作弊手段的日益进步与玩家需求的变化，反作弊也面临着新的挑战与机遇，未来的发展方向主要有以下几个方面：

机器学习的引入。机器学习能带来更高的检测率与更低的误报率，并及时对新兴作弊手段进行响应。
更多判定角度。反作弊可引入更多的玩家特征信息进行判断，进一步增强反作弊能力。

致谢

感谢 LiteLDev 的各位，他们开发出的LiteLoaderBDS极大地简化了数据采集与分析的难度。
感谢 Futrime ，他对本实践提出了很多建设性的意见。
感谢 ShrBox 和 Dofes ，他们为本项目的推广提供了很大的帮助。
感谢 KawaiiNahida、Redbeanw44602和RimuruChan ，他们为我的开发给予了精神上的鼓励与支持。

蜂巢崩服问题的解决

2023-07-26T18:28:00+08:00

记录一下BDS有关BlockEventDispatcherToken::unregister的一个崩服问题

起因

当初有人反馈,大型服务器在长期运行的时候,在关服的时候会出现崩服问题(0xc0000005错误),而崩服很显然,会导致地图损失等问题, ~~再加上当初闲得无聊~~ ,就着手开展了对这个的研究.

研究

当时的崩服Log:

Bash

......
[2023-06-07 06:00:49.138] [info] 
[2023-06-07 06:00:49.138] [info] Last Assembly: 
[2023-06-07 06:00:49.138] [info]   0x7FF7CCAA92BE --> mov rax, [rcx+0x08]
[2023-06-07 06:00:49.138] [info] 
[2023-06-07 06:00:49.138] [info] Stacktrace: 
[2023-06-07 06:00:49.169] [info]   #0 at pc 0x7FF7CCAA9230 bedrock_server_mod.exe -> BlockEventDispatcherToken::unregister+0x8E
......

很明显的看到和BlockEventDispatcherToken有关, 所以显而易见的得去ida里看这个函数的问题
但是由于一系列问题,最初是并没有定位到出问题的本质的 ~~(菜)~~

后续,在多次定位后无果,尝试去探寻一下这个的复现方法,于是在调用堆栈里发现这个的调用和BlockBreakSensorComponent有关,而这个又和数据驱动的minecraft:block_sensor有关.
查阅可知,这个组件和蜜蜂,猪灵的攻击仇恨有关,具体就是蜂箱和金块之类的方块被破坏时,蜜蜂这些拥有该组件的实体会对破坏者产生敌意,并攻击破坏者.
那这个为什么又会导致崩服呢?问题来到了实体上面.
根据经验,这种情况一般是实体销毁导致的问题,于是,笔者便开始了测试,尝试在本地复现该问题.
经过多次测试,发现利用蜂蜜快速死亡+反复生成的情况下,stop可以导致崩服,而且复现概率很高.

在查阅ida的反汇编后,得到BlockEventDispatcherToken::unregister的逻辑如下:

C++

void __fastcall BlockEventDispatcherToken::unregister(BlockEventDispatcherToken *this)
{
  unsigned int v1; // r8d
  _QWORD *v3; // r9
  __int64 v4; // rdx
  __int64 *v5; // rcx
  __int64 v6; // rax
  __int64 v7; // rcx
  unsigned int v8; // [rsp+20h] [rbp-18h] BYREF

  v1 = *(_DWORD *)this;
  if ( *(_DWORD *)this == -1 )
    return;
  v3 = (_QWORD *)*((_QWORD *)this + 1);
  v8 = *(_DWORD *)this;
  v4 = v3[1];
  v5 = (__int64 *)(v3[3]
                 + 16
                 * ((0x100000001B3i64
                   * (((unsigned __int64)v1 >> 24) ^ (0x100000001B3i64
                                                    * (BYTE2(v1) ^ (0x100000001B3i64
                                                                  * ((0x100000001B3i64
                                                                    * ((unsigned __int8)v1 ^ 0xCBF29CE484222325ui64)) ^ BYTE1(v1))))))) & v3[6]));
  v6 = v5[1];
  if ( v6 == v4 )
    goto LABEL_7;
  v7 = *v5;
  if ( v1 != *(_DWORD *)(v6 + 16) )
  {
    while ( v6 != v7 )
    {
      v6 = *(_QWORD *)(v6 + 8);
      if ( v1 == *(_DWORD *)(v6 + 16) )
        goto LABEL_8;
    }
LABEL_7:
    v6 = 0i64;
  }
LABEL_8:
  if ( !v6 )
    v6 = v3[1];
  if ( v6 != v4 )
    std::_Hash<std::_Umap_traits<int,std::unique_ptr<ListenerInfo>,std::_Uhash_compare<int,std::hash<int>,std::equal_to<int>>,std::allocator<std::pair<int const,std::unique_ptr<ListenerInfo>>>,0>>::_Erase<int>(
      v3,
      &v8);
  *(_DWORD *)this = -1;
}

而问题出现在

C++

v6 = v3[1]

于是,很显然,这与v3有关

修复

在恢复了BlockEventDispatcherToken的结构后,发现其拥有两个成员

C++

class BlockEventDispatcherToken {
  ListenerHandle handle;  
  BlockEventDispatcher *dispatcher;
}

而BlockEventDispatcher也有一个成员

C++

class BlockEventDispatcher {
  std::unordered_map<int, std::unique_ptr<ListenerInfo>> listeners;
}

很明显,从v3上分析,崩服问题和umap逃不了关系.
于是,在unregister伪代码的研究下,我们得到了正常情况下,BlockEventDispatcherToken::unregister的大致逻辑

C++

void BlockEventDispatcherToken::unregister() {
  if (this->handle != -1){
    auto it = this->dispatcher->listeners.find(this->handle);
    if (it != this->dispatcher->listeners.end())
        this->dispatcher->listeners.erase(it);
    this->handle = -1;
  }
}

于是,我们大致知道了问题的所在,便可以着手修复工作了.

由于该问题的特殊性,引起该问题的本身就是内存回收和销毁的问题,而笔者并没有权限对源码进行阅读和查看,基于Windows平台本身在线程死亡后,便会自行清理,于是该问题的最容易解决的方案也就很明显了.
笔者采用了直接对BlockEventDispatcherToken::unregister进行hook,自行实现了上面的伪代码中的清理部分的功能, 并且为了方便和稳定,在关服状态下便不主动对listeners进行回收,防止因为关服回收内存时候dispatcher出现问题.

C++

TInstanceHook(void,"?unregister@BlockEventDispatcherToken@@QEAAXXZ",BlockEventDispatcherToken){
  if (this->handle != -1)
  {
    if(ll::globalRuntimeConfig.serverStatus == ll::LLServerStatus::Stopping){
      logger.debug("BlockEventDispatcherToken::unregister ignore unregister when server stopping");
      this->handle = -1;
      return;
    }
    auto it = this->dispatcher->listeners.find(this->handle);
    if (it != this->dispatcher->listeners.end())
        this->dispatcher->listeners.erase(it);
    this->handle = -1;
    return;
  }
}

总结

该问题的出现和修复其实并没有那么快速,前期因为经验不足而走错了方向.
但是,该问题的出现也让笔者对BDS的内存管理方面有了更深的认识,也算是有点收获了.

LeviMC's blog

通过Patch修复BDS的空包刷屏问题

起因

寻找printf函数所在位置

通过LeviLamina和libhat进行Patch

使用机器学习检测杀戮光环

引言

杀戮光环简介

特征分析

玩家行为

数据收集

数据可视化

模型训练

神经网络的选择

神经网络训练

实践

神经网络移植

检测实现

总结与展望

主要贡献

未来的发展方向

致谢

蜂巢崩服问题的解决

起因

研究

修复

总结

寻找`printf`函数所在位置