根據 WSL 跨文件系統配置 介紹中 Automount Settings章節的描述，WSL 會自動將 windows 檔案系統通過 DrfFS 檔案系統掛載到 /mnt 路徑下。 如需將 windows 檔案系統挂載到 WSL 的指定位置，首先需要停用自動掛載：編輯 /etc/wsl.conf 檔案，添加以下内容： [automount] enabled=false 然後，在 /etc/fstab 檔案中配置掛載： C: /mnt/c drvfs errors=remount-ro 0 1 F: /path/to/mount/point drvfs defaults,uid=<loginuid>,gid=<logingid> 0 0

$α$ − 1 ：ST-Tree 運作原理分析 ST-tree 主要參考 AVL tree 的平衡操作，并引入了 rbtree 的結構特點，相對於 AVL tree ，這一特點有助於對代碼運作原理的解讀。 ST-tree 的結構定義 tree 節點由 st_node 結構體定義，結合了 AVL tree 和 rbtree 的特點： parent、left 、right 指針來自 rbtree hint 來自 AVL tree ，根據注釋内容可知，hint 記錄的是一種近似值，不像 AVL tree 那樣需要準確記錄當前節點的 depth 。 struct st_node {

C++ Concurrency in Action 共享筆記, from mengyshen C++ Concurrency in Action (1/9) C++ Concurrency in Action (2/9) C++ Concurrency in Action (3/9) C++ Concurrency in Action (4/9) C++ Concurrency in Action (5/9) C++ Concurrency in Action (6/9) C++ Concurrency in Action (7/9)

红黑树 rbtree ：基本概念 tree 的旋转操作：BBST 保持平衡的关键 红黑树 rbtree ：插入操作 红黑树 rbtree ：删除操作 红黑树 rbtree ：删除后的平衡维护

Case 1 兄弟节点 (sibling node) S 为红色，则父节点 P 和侄节点 (nephew node) C 和 D 必为黑色（否则违反性质 3）。与插入后维护操作的 Case 5 类似，这种情况下无法通过直接的旋转或染色操作使其满足所有性质，因此通过前置操作优先保证部分结构满足性质，再进行后续维护即可。 这种情况的维护需要： 若待删除节点 N 为左子节点，左旋 P; 若为右子节点，右旋 P。 将 S 染黑，P 染红（保证 S 节点的父节点满足性质 4）。 此时只需根据结构对以当前 P 节点为根的子树进行维护即可（无需再考虑旋转染色后的 S 和 D 节点）。 参考视频

红黑树的插入操作与普通的 BST 类似，对于红黑树来说，新插入的节点初始为红色，完成插入后需根据插入节点及相关节点的状态进行修正，使之称为合法的红黑树。 结合维护操作，插入操作的平均时间复杂度为 $O(log \space n)$，n 为当前 tree 的最大高度 具体如何维护有六种情况，其中以下三种比较复杂： Case 1: 当前节点 N 的父节点 P 和叔节点 U 均为红色： 维护过程如下：将 P，U 节点染黑，将 G 节点染红（可以保证每条路径上黑色节点个数不发生改变）。 递归维护 G 节点（因为不确定 G 的父节点的状态，递归维护可以确保性质 3 成立）。

红黑树的删除操作情况繁多，较为复杂。 大多数红黑树的实现选择将节点的删除以及删除之后的维护写在同一个函数或逻辑块中（例如 Wikipedia 给出的 代码示例，linux 内核中的 rbtree 以及 GNU libstdc++ 中的 std::_Rb_tree 都使用了类似的写法）。这种实现方式并不利于对算法本身的理解，因此，本文给出的示例代码参考了 OpenJDK 中 [TreeMap] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java) 的实现，将删除操作本身与删除后的平衡维护操作解耦成两个独立的函数，并对这两部分的逻辑单独进行分析。 Case 0 若待删除节点为根节点的话，直接删除即可，这里不将其算作删除操作的 3 种基本情况中。 Case 1 若待删除节点 N 既有左子节点又有右子节点，则需找到它的前驱或后继节点进行替换（仅替换数据，不改变节点颜色和内部引用关系），则后续操作中只需要将节点 N 删除即可。这部分操作与普通 BST 完全相同，在此不再过多赘述。

在二叉搜索树章节中，我们提到了在多次插入和删除操作后，二叉搜索树可能退化为链表。这种情况下，所有操作的时间复杂度将从 $O(\log n)$ 恶化为 $O(n)$。 如下图所示，经过两次删除节点操作，这个二叉搜索树便会退化为链表。 再例如，在以下完美二叉树中插入两个节点后，树将严重向左倾斜，查找操作的时间复杂度也随之恶化。 G. M. Adelson-Velsky 和 E. M. Landis 在其 1962 年发表的论文 "An algorithm for the organization of information" 中提出了「AVL 树」。论文中详细描述了一系列操作，确保在持续添加和删除节点后，AVL 树不会退化，从而使得各种操作的时间复杂度保持在 $O(\log n)$ 级别。换句话说，在需要频繁进行增删查改操作的场景中，AVL 树能始终保持高效的数据操作性能，具有很好的应用价值。 二叉搜索树的「平衡」概念是指：平衡因子，也就是每一个结点的左子树和右子树高度差的绝对值最多为 1。当平衡因子大于 1 时，代表这颗 BST 失衡。

红黑树是一种自平衡的二叉搜索树。每个节点额外存储了一个 color 字段 ("RED" or "BLACK")，用于确保树在插入和删除时保持平衡。 性质 一棵合法的红黑树必须遵循以下四条性质： 节点为红色或黑色 NIL 节点（空叶子节点）为黑色 红色节点的子节点为黑色 从根节点到 NIL 节点的每条路径上的黑色节点数量相同

策略模式（Strategy Pattern）是一种比较简单的模式，也叫做政策模式（Policy Pattern）。其定义如下：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。（Define a family of algorithms,encapsulate each one,and make them interchangeable.） 策略模式的通用类图如下： Context 封装策略模块，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化，起承上启下作用， Strategy 策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。 ConcreteStrategy 具体策略角色：实现抽象策略中的操作，该类含有具体的算法。 举个例子，在比赛中，教练准备多个战术，会根据对手的不同，在比赛的不同时段，安排使用，举个例子：

装饰模式（Decorator Pattern）是一种比较常见的模式，动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活（Attach additional responsibilities to an object dynamically keeping the same interface.Decorators provide a flexible alternative to subclassing for extending functionality） 装饰模式的通用类图如图： Component 是一个接口或者是抽象类，就是定义我们最核心的对象，也就是最原始的对象 ConcreteComponent 是被装饰的对象，是最核心、最原始、最基本的接口或抽象类的实现 Decorator 装饰角色抽象类，实现或继承 Component，它里面不一定有抽象的方法，在它的属性里必然有一个 private 变量指向 Component 对象。 ConcreteDecorator 具体的装饰角色，可以用来在 Component 对象的基础上添加新的东西

责任链模式的定义是：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。（Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.Chain the receiving objects and pass the request along the chain until an object handles it.） 责任链模式的重点是在“链”上，由一条链去处理相似的请求在链中决定谁来处理这个请求，并返回相应的结果，其通用类图如图： 责任链模式的核心在“链”上，“链”是由多个处理者 ConcreteHandler 组成的，当请求来临时，则会走访这个“链”，根据 Client 的请求，要么找到合适的 ConcreteHandler ，要么找不到合适的 ConcreteHandler ，就当作异常处理。 例如，对于一个球员，他可能处于休赛期、赛季前、赛前、比赛中。对应的，在休赛期，会要求经纪人安排商业活动；在赛季前，会要求私人训练师安排恢复训练；在赛前被教练安排战术；在比赛中被队长安排场上位置等，可以用一个 Player 类来模拟运动员，这个运动员在休赛期和赛季前会要求经纪人和训练师安排今天的日程，在赛前和比赛中则要向教练和队长请示战术安排和场上位置安排，代码如下： interface IPlayer { // 获得当前状态

工厂方法通过定义中间层，只能将两个模块解耦，当一个业务需要至少三个相互依赖的模块互相调用才能运转时，就需要在这些模块之间定义中间人模块，这种设计就是中间人模式，也叫做中介者模式。 以进销存这样的常见业务为例： 销售部门要反馈销售情况，畅销就催促供应链多采购，滞销就不采购。 仓储管理部门要反馈库存情况，再畅销的产品，有货才能销售；如果库存太多要通知采购部门控制采购量，以及通知销售部门采取措施清库存。 供应链管理部门除了配合销售和仓储外，也要反馈上游供货信息，让销售和仓储部门指定自己的规划。 这样的业务模式就形成了相互依赖，如图：

模板方法模式的代码最终的效果就是将一系列组件（属性及方法）封装起来，至于如何组织、调用这些组件，以实现不同的需求，一方面直接交由 Client 来实现，不过更好的方式是使用使用建造者模式封装起来后，再由 Client 调用。 建造者模式的通用类图如下： 以下是标准的模板方法模式代码，通过 setSequence 传入不同的操作序列，可以定义不同的模板方法的调用顺序： abstract class CarModel { // 这个参数是各个基本方法执行的顺序 private ArrayList<String> sequence = new ArrayList<String>();

为什么要用工厂模式？ 工厂模式其实也称创建模式，是用于创建对象的一种方式。本质上就是用工厂方法来代替new实例化对象。 举个例子：我们在编写代码的时候，在一个 A 类中通过 new 的方式实例化了类 B，那么 A 类和 B 类之间就存在耦合，如果以后修改了 B 类的代码和使用方式，例如需要在构造函数中传入参数，那么 A 类也就需要跟着修改了，一个类的依赖可能影响不大，但若有多个类依赖了 B 类，那么这个工作量将会相当的大，这无疑是件非常痛苦的事。这种情况下，我们需要把创建实例的工作单独分离，与调用方解耦，也就是使用工厂方法创建实例的工作封装起来。这样我们在需要调用对象的时候就不需要关心那些复杂的实例化问题。 工厂模式 工厂模式可分为两类：简单工厂模式和工厂模式。 简单工厂模式 定义一个接口和实现类，建立一个工厂类这些实现类进行实例的创建。 我们用运动员来举例，定义一个基本的接口 Player，和一个抽象方法Play，

定义 单例模式是比较常见的一种设计模式，目的是保证一个类只能有一个实例，而且自行实例化并向整个系统提供这个实例，避免频繁创建对象，节约内存。 单例模式的应用场景很多， 比如我们电脑的操作系统的回收站就是一个很好的单例模式应用，电脑上的文件、视频、音乐等被删除后都会进入到回收站中；还有计算机中的打印机也是采用单例模式设计的，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；Web页面的计数器也是用单例模式实现的，可以不用把每次刷新都记录到数据库中。 通过回味这些应用场景，我们对单例模式的核心思想也就有了更清晰的认识，下面就开始用代码来实现。 在写单例模式的代码之前，我们先简单了解一下两个知识点，关于类的加载顺序和 static 关键字。 类加载顺序 类加载(classLoader)机制一般遵从下面的加载顺序 如果类还没有被加载：

定义 什么是代理模式？ 代理模式，也叫委托模式，其定义是给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。它包含了三个角色： Subject：抽象主题角色。可以是抽象类也可以是接口，是一个最普通的业务类型定义。 RealSubject：具体主题角色，也就是被代理的对象，是业务逻辑的具体执行者。 Proxy：代理主题角色。负责读具体主题角色的引用，通过真实角色的业务逻辑方法来实现抽象方法，并在前后可以附加自己的操作。 用类图来表示的话大概如下： 用举一个球员的例子，一般来说，球员最主要的工作就是参赛，其他的场外工作可以交给他的经纪人去做，例如谈球队，签代言等等，而负责这些场外工作的经纪人就相当于 Proxy ，而负责核心业务的球员就是 RealSubject 。

Hello VulnHub Mr.Rotot 任务简介 信息收集 先到处看看 Brute Forcing 获取 WordPress 管理员密码 使用 wpscan 扫描 WordPress 的漏洞 通过 WordPress 漏洞在目标主机上启动 shell 利用旧版本 nmap 漏洞提权到 root 权限 Mr.Rotot 任务通关总结

我们获取了三个 Key ，并对系统进行了 root 。 这个任务从获取 IP 地址开始，通过分析 WordPress 服务获取其泄漏的敏感信息，再到 Brute Forcing 获取管理员帐户信息，再通过管理员帐户植入的admin shell 进入到系统 shell ，从文件中获取到泄漏的敏感的用户信息（即使是加密的），最后通过设置了 SUID 的系统应用的漏洞将权限提升到 root ，从而控制了整个系统。 如果这是一次实战，我们将能够造成更大的破坏。 这一系列 Hack 技术的实践，我学到了系统安全相关的宝贵的经验。 我将继续完成更多 VulnHub 挑战。

接下来看看目标系统中有哪些程序文件设置了SUID（Set owner U ser ID up on execution）位： $ find / -perm -u=s -type f 2>/dev/null /bin/ping /bin/umount /bin/mount /bin/ping6 /bin/su /usr/bin/passwd /usr/bin/newgrp