Trash Bin for Chi

Poison Over Forwarders 攻击复现报告一、摘要本报告详细记录了对[USENIX Security 2020]《Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices》中所述攻击的复现过程。该攻击是一种针对 DNS 转发设备的新型缓存投毒技术，它巧妙地利用了IP协议层面的分片与重组机制，从而绕过了传统的、依赖于传输层（如源端口随机化）的DNS安全防御措施。 我们通过 Docker 构建了一个包含易受攻击的 DNS 转发器（dnsmasq）、攻击者控制的权威服务器和攻击者客户端的隔离网络环境。实验中，攻击者首先向转发器注入一个精心构造的、伪造的 IP 第二分片，然后触发一个对攻击者域名的查询，诱使其权威服务器返回一个超大的、会被合法分片的DNS响应(实验复现中采用的是超长CNAME链)。转发器在重组IP包时，错误地将合法的第一个分片与伪造的第二个分片结合，最终导致其 DNS 缓存被植入指向攻击者指定域名（例如victim.cn）的恶意 IP 地址 ...

Poison Over Forwarders评估说明评估脚本获取measure.py源码 1.漏洞说明来源[USENIX Security 2020]Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices 基本原理介绍该漏洞是一种针对DNS转发器的新型缓存投毒攻击。与传统攻击不同，它利用IP分片和由攻击者控制的权威DNS服务器来绕过常见的DNS安全防御机制（如端口随机化、0x20编码等）。 强制分片: 攻击者控制一个权威DNS服务器。当有DNS查询请求时，该服务器通过构造一个包含超长CNAME记录链的DNS响应，必须对该响应进行IP分片 分片注入: 一个被分片的DNS响应包，只有第一个分片包含UDP和DNS头部信息（如事务ID、端口号等）。攻击者利用这一点，在第一个合法分片到达前，向DNS转发器注入伪造的第二个分片 重组缓存: DNS转发器接收到合法的第一个分片和伪造的第二个分片后，会将它们重组。由于伪造的分片篡改了CNAME链的末尾，将其指向了受害者域名（ ...

kaminsky复现报告一、摘要本报告旨在记录并分析经典的 Kaminsky DNS 缓存投毒攻击的复现过程。我们通过 Docker 构建了一个包含易受攻击的递归DNS服务器、攻击者和合法权威服务器的隔离网络环境。实验中，攻击者通过向递归服务器查询一系列不存在的随机子域名，并抢在合法响应前发送大量伪造的DNS响应包，成功地在其缓存中植入了恶意的 NS 记录。实验结果表明，攻击成功后，所有对目标域名的查询均被重定向至攻击者指定的服务器，直观地验证了 Kaminsky 攻击的巨大危害性。 二、原理分析Kaminsky 攻击的核心并非直接猜测并伪造目标域名（如www.example.com）的 A 记录，而是通过污染其父域（example.com）的权威 NS 记录来获得整个域的解析控制权。其攻击逻辑如下： 攻击者向受害者递归服务器（10.10.0.6）查询一个随机且不存在的子域名，例如 random-string.example.com。由于缓存中没有该记录，递归服务器必须向外查询。 递归服务器会向其配置的根/权威服务器（本例中为被攻击者控制的10.10.0.8）发起请求。攻击者通过让1 ...

Linux主机物理屏与虚拟屏切换指南书接上文，虽然我们已经实现了Linux主机的虚拟屏设置，可以很好的使用该“无头”服务器，但是如果我们希望给他外接物理显示屏则必须删除虚拟驱动设置，然后再重启。主包觉得这样太过麻烦了，是不是可以让系统自动检测当前是否有显示屏接入，如果接入显示屏那我们采用真实显卡设置，否则采用DUMMY虚拟驱动？ 如何启动虚拟屏参见“无头”Linux主机远程桌面使用指南中“使用X11桌面协议”与“配置X.org服务器” 启动虚拟屏进阶对于上篇博文中提到的开机服务，可以设置为用户层面的服务，此时无需指定DISPLAY，这意味着鲁棒性更强vim ~/.config/systemd/user/x11vnc.service [Unit]Description=x11vnc server for the current graphical sessionAfter=graphical-session.target[Service]ExecStart=/usr/bin/x11vnc \ -remap /home/chi/.x11vnc_remap \ -xkb \ -fore ...

无显示器使用Linux主机(Ubuntu 24.04.2 LTS)实录前言五一的时候，主包拥有了自己第一台主机(mini版)。因为觉得有ssh控制就已经很满足了，所以并没有察觉到显示屏的重要性。直到卸载Win10安装Ubuntu后，由于联发科网卡反复出现网络问题（吐槽一嘴，Linux的联发科的驱动真的不太行，建议直接换Intel原生态的网卡），导致不得不需要显示屏才能控制主机（故琢磨一天，总结了几种方案） 视频采集卡 + OBS studio（推荐）懒人版，需要有一台可以使用HDMI或者DB线的笔记本电脑（？），总之就是一台宿主机 宿主机安装OBS studio软件，充当主机视频信号载体 主机接HDMI线连接视频采集卡，视频采集卡接入宿主机 OBS studio新增一个视频窗口，初始化部分应该是可以检测到视频采集卡的，然后就大功告成了 大致方案为，找到源，添加视频采集设备，然后按照识别到的视频采集卡设备进行设置，例如我是UGREEN HDMI Capture,其他配置一律默认即可 远程控制软件 + Xorg服务器(不推荐！！！)可能需要借用一个显示屏配置一下ToDesk（） 安 ...

ML 期末突击方差与偏差靶心与飞镖：一个绝佳的比喻想象一下你正在玩射飞镖，目标是靶心（Bullseye）。靶心就是我们想要预测的真实值。你射出的每一支飞镖，都是一次模型的预测。 我们用不同的训练数据子集训练出的不同模型，就像你一次次地投掷飞镖。 低偏差，低方差 (Low Bias, Low Variance) - 理想情况 表现：所有的飞镖都紧密地集中在靶心周围。 解读：模型既准确（低偏差）又稳定（低方差）。每次训练出的模型都能准确预测。这是我们的终极目标。 高偏差，低方差 (High Bias, Low Variance) - 欠拟合 表现：所有的飞镖都紧密地聚集在一起，但离靶心很远。 解读：模型很稳定，每次预测的结果都差不多（低方差），但它系统性地出错了，离真实值很远（高偏差）。模型太简单了，比如用一条直线去拟合一个二次曲线的数据。 低偏差，高方差 (Low Bias, High Variance) - 过拟合 表现：飞镖围绕着靶心散布得很开，没有聚集在一起。 解读：平均来看，预测是围绕真实值的（低偏差），但每次预测的结果都非常不稳定（高方差）。模型学到了太多训练数 ...

lab6-challenge shell要求总览 相对路径支持 环境变量管理 指令输入优化 无后缀指令支持 终端输入输出优化 历史指令支持 实现更多功能 追加重定向功能 注释功能 变量替换 反引号执行功能 指令条件执行功能 实现更多指令 内建指令篇 history cd pwd exit declare unset 正常指令篇 ls rm touch mkdir 1.相对路径支持首先需要实现工作目录，为每个进程加入属性env_cwd，并在env_alloc/sys_exofork时使得子进程继承父进程的工作目录struct Env { //... char env_cwd[MAXPATHLEN]; //...}// env_allocstrcpy(e->env_cwd, "/");// sys_exoforkstrcpy(e->env_cwd, curenv->env_cwd); 实现辅助函数normalize_path，协助转换为绝对路径，该函数支持传入路径相对或绝对 对于相对路径，将 ...

OS_RElec1 Introductionlec2 Bootlec3 Memory Managementlec4 Process/Thread进程与线程并发 若干个程序同时在系统中运行，这些程序在执行的时间上是重叠的 并行 多个程序，它们在同一时间度量下同时运行在不同的处理机上，则称两个程序是并行执行的 并行则一定并发，而并发不一定并行。因为并发只是在宏观维度下两个程序在执行时间上是重叠的，在这期间，它们可能是运行在同一处理机的不同时间段，，也可能运行在完全不同的处理机上。并行则要求两个程序运行在完全不同的处理机上。 竞争 多个程序读写同一个共享数据的结果依赖于它们的执行顺序 进程进程的定义 进程是对CPU资源的一种抽象 进程与程序不同。进程可以简单理解为程序运行的过程。同时其是系统进行资源分配与调度（线程发明前）的基本单位 进程包含程序、数据、进程控制块 进程的控制 就绪状态：进程获取除处理机外所有所需资源，等待分配处理机资源 执行状态：占用处理机资源。处于此状态下的进程数小于等于CPU数目 阻塞状态：正在执行的进程，由于发生某种事件而暂时无法执行，便放弃了处理机 ...

oo_u2总结第二单元终于结束力，电梯月结束了！！！ 第一次作业 薛定谔的电梯 第一次的电梯总是轻松愉快的，乘客指定了需要某部电梯来接送，这意味着我们不需要调度电梯，只需要关注电梯的运行。当然，今年较往年增加了乘客优先级的概念，最后性能分的计算中平均等待时间进化为加权平均等待时间。 整体思路 架构设计整体电梯系统依然采用生产者-消费者模型。主输入线程InputThread作为生产者，负责“生成”乘客请求，这里更准确地来说是“接收”我们输入的乘客请求，但是从电梯系统来看，乘客都是主输入线程产生的；电梯线程ElevatorThread作为消费者，负责“清理”乘客请求，也就是将乘客送到目的地；分配器线程DispatchThread作为盘子，接收主输入线程的乘客，同时可供电梯线程获取。不过与传统的生产者-消费者模型相比，我们需要分配器主动分配乘客请求给电梯线程，而不是等待电梯线程来获取。 这是考虑到电梯线程的逻辑复杂。一般的消费者线程只需要简单处理即可继续获取，但对于电梯线程而言，什么时候意味着处理完毕可以继续获取乘客请求？难道是等电梯运送完目前得到的所有乘客请求吗？这无疑会导致电梯错过携 ...