spiralbl0ck/cabir_analysiscabin partial analysis
description: Bluetooth-Worm:SymbOS/Cabir Analysis
在你开始阅读之前，我必须先声明：请对你读到的一切持保留态度，因为我绝不是 SymbianOS 开发者，也完全不熟悉 SymbianOS 环境。
但为什么还要分析这么老的东西呢？因为这是进入远程攻击领域最简单的途径，如今这类事情动辄价值百万美元的 nday/0day 🤑🤑🤑。而且我还缺乏做那种攻击的专业能力。
好了，既然这些废话都说完了，我们开始吧。Cabir 是什么鬼？它是一个运行在 Symbian 手机上的蓝牙蠕虫。对于那些想知道 Symbian 手机是什么鬼的人来说，基本上它就是一款运行 ARM 处理器的手机，没什么新鲜的 :) 更简洁的信息（https://en.wikipedia.org/wiki/S60_(software_platform)）
我们很幸运，这个恶意软件的源代码在网上可以找到（感谢 vxug）（SymbianOS.Cabir.7z）。我们会把它作为参考，但说实话，去它的。我做这件事的另一个原因是我想要研究 ARM。所以我们会从源码/汇编/模拟器/调试/嗅探的角度来看待它。
好了，第一个问题：我们到底怎么编译这个源代码？
其实这并不复杂……
首先安装 carbide ++（http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file）（来自 https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284）
接下来安装任意 Perl 引擎
接着安装 Nokia PC Suite（https://www.usitility.com/nokia-pc-suite/）
安装 SDK（http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file ）
安装 C/C++ 插件（https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip）
然后瞧，环境就准备好了 :)
附注：最好使用 Windows 7，因为在 Windows 10 上很多东西会坏掉，无法正常工作。
真实环境感染
TBD
关于这部分，你需要知道的是，你必须越狱（是的，你没听错，越狱）你的手机。这是怎么做到的呢？
逆向工程分析
好了，那到底怎么编译这些东西呢？问得好。我做的第一件事是运行 caribe\group 文件夹里的 ABLT.BAT，如下所示
接下来，我们要进入 SDK 的安装目录，找到 platform 文件夹（我这里是 S60_3rd_fp1），然后找到 epoc32 文件夹，进入 buid 文件夹，选择 user 文件夹，再进入用户文件夹，然后还有两三个目录，最终你会看到一个类似这样的文件夹
这就是当前路径，应该和你所在的位置大致相似（C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group）
接下来，我们需要进入 caribe 文件夹（或者你给源代码起的名字），你会找到一个包含不同名称的文件夹，如下所示
这是什么意思呢？基本上，当我们第一次运行 ablt.bat（直到今天我都不太清楚它的作用，不过无所谓）时，我们会得到不同的平台选项，用来构建我们的 pkg 文件，之后我们会生成 sis 文件。在当前这个例子里，我们看到 GCCE 和 WINSCW。如果你默认运行 ablt.bat build 命令，它会为 WINSCW（这是模拟器平台的代号）构建。为了学习如何编译源代码，我们目前使用 GCCE，但如果你选择其他平台，比如 arm 平台以便上传到手机，过程也是一样的。所以基本上就是 ablt build arm_whatever，然后重复这里提到的步骤直到这一步。好了，现在我们进入 GCCE 文件夹
进入 urel 文件夹，里面应该有一个名为 caribe.app 的文件。在那里打开命令行并运行
这是干什么的呢？基本上我们运行了 makesis，它会生成一个 sis 文件，这样我们就能把它安装到手机上。为什么我们要从 caribe 源代码生成 sis 文件呢？因为我们需要指定 caribe.pkg 给 makesis。那为什么还要费那么多周折进入 build 之类的文件夹呢？因为你需要把它指定给 -d 参数，它才能生成 .sis 文件。
好了，这个方法只适用于这篇文章中提到的 SDK v3。显然，在我实验过程中，一位来自 Symbian 专门 Discord 服务器的开发者指出，Cabir 是为 SDK v2 编写的，所以我在这里介绍的内容将毫无用处……这有待解决，等我能联系上他再说……他最近在 Discord 上都不怎么上线……
那么如何逆向一个 .sis 文件呢？
简单来说，.sis 文件其实是一个压缩包。所以……我们用 siscontents 工具来解压，然后把 .app 文件丢进 IDA。
汇编视角
整个过程看起来是这样的
现在进入那个文件夹，接下来两步我们就能得到 app.app 文件。
好了，如果你把它丢进 IDA。
好吧，基本上就是一个 ARM exe。太酷了！下一个！嗯，好的，请继续～～～
文件里有符号，是的！好吧，因为出于某种奇怪的原因，我们用调试符号编译了二进制文件，所以我们运气好！
而且由于我们基本上有源代码，所以逆向工程的过程与源代码分析章节中描述的差不多 :)
嗅探视角
不幸的是，我无法完成这部分，因为我原本计划使用 Fts4bt，我觉得它很不错（https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf）
但似乎这个产品已经停止维护（EOL）。如果你碰巧能完成这部分，请私信我并提交 pull request 来完成这一章。
调试器视角
那么这一部分呢！>>~> 好吧，我的看法是：虽然通过 USB 连接调试器，直接在诺基亚手机上调试代码，对你（读者）和我来说都是很有价值的经验，但目前我要投入的时间和精力太多了（我已经很累了……抱歉，也许下次吧）。另一个原因是这没什么用，因为我们有源代码和一个专门的 Symbian IDE。所以接下来我们要做的是：使用 Carbide++ 的调试器简单调试一两个函数。读者完全可以自己完成，因为代码流程已经在源代码分析章节中解释过了，而且也没有加密或任何反分析手段来增加分析难度。那么……开始吧！
说实话
源代码分析
好了，让我们利用可以访问源代码这一点，把它用到极致。
我们的目录结构如下，组织得相当不错
让我们检查一下 src 文件夹
我们的旅程从 src 文件夹开始，确切地说是 caribe.cpp。但为什么呢？因为尽管组织得不错，有一个很显眼的地方就是存在 caribe.cpp 这个文件。它有什么特别之处吗？没有，但我凭经验猜测，29A（开发这个恶意软件的团队）采用了软件开发者常见的做法：应用的主要逻辑放在 项目名.扩展名 的文件里。好了，那它看起来像什么样呢？就像这样，年轻人。
酷，但这是什么？说实话我也不知道，但让我们猜一猜。仅凭名字，我猜 CApaApplication 是这个应用的主类。如果我们在谷歌上搜索，我们会看到：
好了，接下来呢？让我们继续深挖。我们去看看 CCaribeApplication。但等等，CCaribeApplication 在哪里？在 CaribeApplication.h 里。那又在哪里？在 inc 文件夹里，兄弟，看起来是这样的
好了，它长这样
酷，所以我们看到一个类继承了另一个类，还有一个名为 CreateDocumentL 的 protected 方法。挺酷，但没什么有趣的。好吧，这是我的错，老兄！！
这是什么错误啊！你还自称恶意软件分析师呢 =))) 冷静点，老兄！不过话说回来，我们说这个项目的作者可能表现得像一个普通软件开发者，所以自然而然地，我们应该检查 src 文件夹里的 caribeapplication.cpp。好了，开始吧 :)
好吧，一堆我们看不懂的单词，一堆莫名其妙的东西。让我们来梳理一下……
首先，我们来讨论那个常量（0x10005B91）。它有什么用？它的类型是 TUid，定义如下
好吧，基本上就是一个 ID。但为什么呢？说实话我也不知道，但当你构建一个应用时，你会得到一个 UUID。有趣的是，如果你在网上搜索，你会发现它总是被定义为一个所谓 .sis 应用的一部分，我们稍后会探讨。所以基本上这就是 SymbianOS 应用的经典头文件定义。好了，下一个。我们看到了我们感兴趣的函数：CreateDocumentL。
所以……
而我们调用的就是 CreateDocumentL
所以我们创建了一个 document……但为什么呢……？说实话我和你一样迷茫，但我的直觉是，当我们创建 document 时，基本上就是创建了一个类，它允许我们以某种方式与应用的用户界面交互，因为我们基本上是从 UI 框架派生出来的。
而既然我们调用了 CreateDocumentL（我想在这个例子里，我们用自定义实现覆盖了原来的定义），那它的定义在哪里呢？我猜是在 CaribeDocument.h 中。那这又是怎么回事呢？
好的，很酷，我们自然看到了我们感兴趣的函数 newL，所以让我们检查 CaribeDocument.cpp
正如我们看到的，我们最终调用了 newL，它又调用 newLC，newLC 再调用 constructL，就这样。但 CEikAppUi 的 CreateAppUiL 函数呢？好吧
让我们试着理解一下。基本上，当我们调用 CCaribeDocument 的构造函数时，我们实例化了一个 CEikApplication 作为 document。该 CEikApplication 定义如下
所以我认为这里发生的是，我们基本上试图访问 UI，然后我们定义了一个类，这个类之后可以通过 CreateAppUiL 来处理与 UI 的交互。好了，让我们检查一下 CCaribeAppUi.h/CCaribeAppUi.cpp
所以……除非我们检查它继承的类，也就是 CAknAppUi，否则我们无法理解这些。
所以我们看到
我们进一步检查以了解 CAknAppUi 长什么样
之后我们检查 ConstructL
这让我觉得这是一个辅助函数，只是完成了构造函数，因为构造函数是空的。好了，让我们深挖。
第一行，我们看到一个叫 ErrMessage 的函数，它在 general.h 中被定义为一个宏，用于显示包含指定文本的信息对话框。从 Cabir 行为的报告中我们知道，这个恶意软件总是弹出一个包含名称的弹窗。例如
接下来我们看到调用 User::After，这是干嘛的？我用这本书（http://staff.ustc.edu.cn/~dingqing/teach/project/mobile/(2006%20Wiley)Developing%20Software%20for%20Symbian%20OS%A3%BAAn%20Introduction%20to%20Creating%20Smartphone%20Applications%20in%20C%20Plus%20Plus.pdf）来更好地理解。如果你查找它的含义，它会说这基本上就是等待 n 秒，这里是 10 秒*10，也就是大约 100 秒（快速心算 =)) skrr ra）
接下来我们调用 BaseConstructL，它基本上是用 ENoAppResourceFile 作为参数来初始化 UI。如果我们稍微深挖一下
接下来我们声明了一个类型为 CaribeInstaller 的变量。好了，让我们看看这是怎么回事
我们检查 CaribeInstaller.cpp，发现它相当大（她也是这么说的 :))）总之，因为源代码很大，我会贴多张图片。
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.
.PNG)
好了，因为它太大了，我们先从简单的开始，也就是 DOCRC16。从名字和它有一个 subs 表等来看，我猜它只是做 crc16 校验……用来检查它写入内容的完整性。接下来
我们看到一堆带有预定义路径的 define，以及一堆对 _LIT 宏的调用？这个宏有什么用？_LIT() 宏使用 C++ 模板，因此它会为每种可能的字符串长度生成不同的类型。
哦，别忘了提一下，到目前为止我们掌握的 IOC```cpp "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\" "C:\SYSTEM\RECOGS\FLO.MDL" "C:\SYSTEM\RECOGS\" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.SIS"
接下来我们来分析 CopyMeToAutostartableDir 函数
所以，从恶意软件源代码中我们可以看到它执行 ```cpp
This function will copy the own dll of this application to
"C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP".
.mdl for autostart will start that application automaticly.
酷，所以它首先做的事情之一是获取应用的名称，在这种情况下，我认为它将是 CARIBE。接下来它声明一个 16 字节的缓冲区，该缓冲区将包含 字符串 ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
将应用名称转换为大写字母，然后比较这两个字符串。接下来我们看到一个类型为 `RFs` 的变量 `fs`。这个类型到底是什么？好吧，[https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) 中说道：所有应用都定义一个指向 `RFs` 类对象（用于访问文件服务器）的指针，然后框架会自动调用 `Connect()`，因此你无需创建自己的该对象实例即可开始使用它。这个调用是客户端 API 的一部分，该 API 以共享库的形式实现，并提供对服务器的访问权限。
（注意：如果上面这部分不够简洁，请参考这个链接，这是我后来才发现的：[https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs)）
基本上，这使我们能够通过远程连接访问文件系统文件；接下来我们看到我们执行了 ```cpp
User::LeaveIfError( .Connect());
如果我们无法连接。奇怪的是我们看到了 connect api 调用却没有 socket 类型的变量但我觉得这是这个蓝牙协议案例特有的（我们稍后会看到使用的是什么协议）/ 是这个应用设计方式特有的
我们随后创建 ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\
在远程连接的手机上，我们调用 BaflUtils::CopyFile([https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29)) 将程序本身复制到 ```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP
然后我们重复相同的过程，这次只将应用程序复制到 ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC
然后我们从函数返回。酷，但为什么要用到 C:\\\ 目录？为什么是 SYMBIANSECUREDATA？那 rsc 文件呢？好吧，显然如果我们查看 [https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/](https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/) 
我们会得到答案：‘SYMBIANSECUREDATA’ 目录下的文件默认对用户不可见，除非安装了文件管理器。
哈哈，但 rsc 文件呢？
嗯，在一本 Symbian OS 书中，这个图表向我们展示了：
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>
一个资源文件，它定义了应用程序的标题、图标数量及其他信息。如果我们搜索 .rsc 文件格式，就会发现这些 RSC 文件通常被归类为数据文件，其中包含从 RSS 格式编译为二进制格式的、机器可读的资源。它们由一个 APP 文件和一个已完成的 Symbian 应用程序组成，允许应用程序开发者在不重新编译 APP 的情况下修改程序资源。 
所以我倾向于认为，这里我猜会是图标或其他资源。
但为什么是 C:\\\ 驱动器呢？嗯，因为 Symbian OS 采用了类似 DOS 的约定，每个驱动器由一个字母标识。 
接下来是 InstallMDL
 它的目标 ```cpp
This function will install the mdl file to the recogs directory.
酷，所以我们从再次访问文件系统开始,获取当前运行应用的名称，创建一个保存这些字符串的变量 ```cpp C:\SYSTEM\RECOGS\FLO.MDL
然后我们会看到一个我们不熟悉的东西，它是一个类型为 `TParse` 的变量。
查阅文档后，我们得到：
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>
接下来```cpp
TParse parser;
parser.Set(OwnDllName,NULL,NULL);
TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
_LIT16(FLOMDL,"flo.mdl");
flodrivepath.Append(FLOMDL);
这里发生的是，它动态创建上层路径，我觉得解释它没有意义（如果你想进一步调查，请使用此链接 https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html）
我们随后创建此目录 ```cpp C:\SYSTEM\RECOGS\
最后，将动态创建的指向 flo.mdl 文件的字符串复制到 C:\\\SYSTEM\\\RECOGS\\\\ 
酷，那么 mdl 文件和 recogs 目录有什么有趣的呢？嗯，从 Fortinet 我们得知，"recogs" 文件夹通常存储被称为 "recognizers" 的程序。
那么什么是 recognizer 呢？老实说我不知道，我能找到的只有这个：在 Symbian OS 中，MIME 类型由 .mdl 识别器（存储在 \System\Recogs 文件夹中）来区分，这些识别器利用文件的扩展名和/或所包含数据的格式/布局。应用在安装时，会在其 .aif 文件的 datatype\_list 中，以作者指定的优先级级别注册对给定 MIME 类型的兴趣（参见 C++ 或 OPL SDK 文档中的 "Aiftool resource file format"）。系统会使用注册了最高优先级的应用来尝试打开任意给定 MIME 类型的文档。
还有这个：Symbian OS Recogniser 允许 MIDlet 被系统识别为 MIDlet。
所以基本上没什么……但我想既然它与 MIME 类型有关，我猜它涉及图标和 GUI 之类的东西（[https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source//guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework)）。那么 mdl 文件呢？从同一个链接我们可以得知，数据识别器是带有 `.mdl` 扩展名的插件 DLL，这基本上意味着这是一个加载媒体图像文件的插件。酷。
\=============================================
创建 sys 文件功能待定
\=============================================
现在我们理解了每个函数的作用，回到 caribeappui.cpp 继续分析执行流程。我们看到 ConstructL 中的最后一个函数是 ```cpp
CaribeBluetooth::NewL();
那么我们从 Cariblebt.cpp 开始我们的旅程。
所以 newL 调用 newLC，newLC 调用 constructorL，constructorL 调用 RunL 并将 iState 设置为 3。现在 runL 检查状态，在我们的场景中，由于默认将其设为 3，我们最终会运行 FindDevices 和 ManageDevicesFound。
FindDevices 长这样
说实话，它看起来和普通的 tcp 扫描没什么区别，但让我们深入看看。首先，因为我忘了，这是 Cariblebt.h
好，回到我们的函数，我们把 KL2Cap 设为 string 或 BTLinkManager 类型，接下来我们检查是否能与 socket server 建立一条 ipc 通信通道。好吧等等，你到底在说啥？说实话我也不知道，所以让我们调查一下。我们有一个 RsocketServ 类型的 socketServ。不错，然后呢？现在我们严格搜索这个类（https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html），得到的正是我说的：我们创建了一条 IPC 通道。但为什么？现在根据名字我猜测它和 socket 有关。如果我们检查 Rsocke（https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.html#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0），我们会发现它提供了协议的客户端端点，并提供了创建、读取、写入 socket 的函数。
再进一步，如果我们用这个（https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html），我们会看到这就是 Symbian 上查询远程设备的工作方式，也就是如何建立蓝牙连接。
有趣的是，紧接着的下一行正是上面那个协议所描述的操作，例如使用 RSocketServ::FindProtocol()
而且正如前面所说，我们完全按照上文文档中的描述操作：创建并初始化一个 RHostResolver 对象。
然后我们将 TInquirySockAddr 设置为常规发现模式，这样就能扫描设备。
接下来设置 socket 用于地址查询的参数，我们设置 KHostResInquiry 标志
然后我们使用 GetByAddress 开始查询，如果我们成功找到任何蓝牙设备，就会返回一个 48 位的唯一地址。所以这里本质上只是简单地检查一下周围是否有蓝牙设备。
Next we call ManageFoundDevices.
我们检查是否成功拿到了地址，如果是就调用 Cancle()。然后我们为这个蓝牙地址创建一个端点/“连接”（但实际上我们还没有真正连接），并进一步创建一个 TObexBluetoothProtocolInfo 类型的变量，它用于描述蓝牙特定的协议信息（https://docs.huihoo.com/symbian/s60-5th-edition-cpp-developers-library-v2.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/sdk/doc_source/reference/reference-cpp/OBEX_Protocol/TObexBluetoothProtocolInfoClass.html#%3a%3aTObexBluetoothProtocolInfo）。
现在，OBEX 服务器又是什么鬼？根据 Synopsis 的说明（https://www.synopsys.com/software-integrity/security-testing/fuzz-testing/defensics/protocols/bt-obexs.html），OBject EXchange（OBEX）（https://en.wikipedia.org/wiki/OBject_EXchange）是一种通信协议，用于在支持蓝牙的设备之间进行二进制传输。酷。在我们的场景中，由于 TObexBluetoothProtocolInfo 类继承自 TObexProtocolInfo，我们需要指定传输类型，这样 SymbianOS 才能知道该使用哪种协议——在我们这里就是 rfcomm。所以我们接下来要做的其实就是设置和谁通信、使用哪个端口。由于 rfcomm 端口是动态的，范围在 0x1-30 之间，而这里用的是 9。然后我们创建客户端连接并连接上去。好，那么接下来会发生什么？因为看不到任何迹象。所以……嗯……好吧。之后我们从那里返回，由于没有 while 循环，我猜之前的过程会再重复一次。只不过现在我们已经连上了那个设备，状态会变成 1，而且既然已经建立了连接，我们就调用 put。如果我们查看维基百科，它的作用是：
那么我们怎么知道 iCurrFile 是哪个文件呢？嗯，我的推测是：在文件开头有一个 CActive 函数，我认为它相当于一个钩子，每当我们调用 SetActive() 时都会被触发。
就这样，分析到此结束，感谢阅读！祝你黑客之旅愉快 :)