只有这里可以点开
审底下的代码
调用lila的use方法加载table模块,这里的AI辅助审代码时，这个layui框架让我很注意，接下来查一下。
然后就是交互功能，监听点击事件（domo元素）与弹窗
这段Layui代码中，导航点击的监听是通过Layui的 element 模块提供的事件接口实现的，具体步骤是：
- 指定监听的目标
element.on('nav(demo)', ...) 中的 nav(demo) 是"事件类型+组件标识"：
-
nav ：表示监听的是导航组件的点击事件（这是Layui element 模块预定义的事件类型）；
-
demo ：是导航容器对应的 lay-filter 属性值（需要在HTML的导航标签上设置 lay-filter="demo" ，用来标识要监听的导航组件）。
- 绑定点击后的回调函数
element.on 的第二个参数是回调函数：当用户点击了 lay-filter="demo" 对应的导航项时，这个函数会被自动触发。
函数里的 elem 参数，是被点击的导航项对应的DOM元素，通过 elem.text() 可以获取该导航项显示的文本内容。
- 执行点击后的反馈逻辑
回调函数中调用 layer.msg(elem.text()) ，是点击后的具体操作：弹出一个提示框，显示被点击导航项的文本内容，完成点击后的交互反馈。
先查找一下domo标识，看一下有什么东西。
好吧，原来是监听整个页面的数据，然后弹窗。
那就抓个包看看。
发现奇怪的东西。
下面有回显 ，可控！
其实我还挺好奇有没有模板注入类似的东西的。
好吧，只是静态展示
想试试目录扫描，但网卡实在扫不了，看wP
我前面想的居然是对了一点点，可以用伪协议读取源代码，然后看一下写的什么东西，有思路了。接着做。
但具体原理是什么啊...，如果是文件包含，那为什么改了之后还会显示页面，而不是报错呢？
当前 page=inde 的请求在文件包含场景下"没事"，是因为后端可能做了容错/过滤处理，常见原因有3类：
- 后端存在"默认值/容错逻辑"
若后端的文件包含代码是类似这样的设计：
php
// 假设后端逻辑
page = _GET['page'] ?? 'index'; // 若page参数为空，默认用index
// 或对不存在的文件做兜底
if (!file_exists("{$page}.php")) {
$page = 'index'; // 若page对应的文件不存在，自动切换为index
}
include("{$page}.php");
此时即使传了 page=inde （对应 inde.php 不存在），后端会自动加载默认的 index.php ，所以页面仍能正常显示框架内容。
- 目标文件实际存在
后端可能确实有 inde.php 这个文件（比如文件名拼写错误、测试文件），此时 include("inde.php") 会正常加载该文件的内容，页面自然不会报错（你看到的"inde"文字，可能就是 inde.php 里的内容）。
- 后端做了"白名单过滤"
若后端对 page 参数做了白名单校验（仅允许指定的合法值），比如：
php
$allow_pages = ['index', 'device', 'log']; // 允许的页面列表
page = in_array(_GET['page'], allow_pages) ? _GET['page'] : 'index';
include("{$page}.php");
此时传 page=inde （不在白名单内），后端会自动替换为默认的 index ，因此页面仍能正常加载。
简言之，文件包含场景下"传错参数没报错"，本质是后端做了参数容错、文件兜底或白名单过滤，避免了非法/错误参数导致的页面崩溃。
这是**"设备维护中心"网页的源代码**，基于Layui前端框架开发，核心信息与功能如下：
- 页面基础信息
-
访问方式：通过 view-source: 协议查看源代码，URL为 index.php?page=index ------说明这是一个PHP页面，通过 page 参数传递内容标识（典型的"文件包含"类参数，用于加载对应模块的内容）。
-
页面定位：标题为"设备维护中心"，是一个面向设备管理的后台页面。
- 核心功能模块
-
导航栏：通过Layui的 layui-nav 组件实现，导航项链接带 ?page=index 参数，与URL的 page 参数对应，用于切换页面模块。
-
设备列表表格：使用Layui的 table 模块渲染，通过 url: '/something.json' 接口加载设备数据（如设备ID、名称、区域、维护状态等），同时包含"设备开关"的Layui Switch组件（用于控制设备状态）。
- 潜在的技术逻辑
URL中的 page=index 参数，通常对应PHP的文件包含功能（如 include($_GET['page'].php) ）------即后端通过 page 参数的值，加载对应的功能文件（如 index.php 对应的模块文件）。这也是这类页面中"伪协议利用"的典型场景（若后端未对 page 参数做严格过滤，可能被注入伪协议实现文件读取等操作）。
简言之，这是一个基于Layui的设备管理后台页面，通过 page 参数实现模块切换，同时包含设备数据展示、状态控制等功能。
点击这个按钮加载对应的页面。
我懂这个静态页面显示什么意思了，回显东
西，难怪有些函数它给我过滤了，不是好玩。
我好蠢啊。
if ($_SERVER['HTTP_X_FORWARDED_FOR'] === '127.0.0.1') {
echo "<br >Welcome My Admin ! <br >";
pattern = _GET[pat];
replacement = _GET[rep];
subject = _GET[sub];
if (isset(pattern) \&\& isset(replacement) && isset($subject)) {
preg_replace(pattern, replacement, $subject);
}else{
die();
}
开审。
首先传入的得是127.0.0.1才行，这让我想到了xff。（注：这个东西放在最后一排无效）
成功进入。
接下来就是正则替换。
preg_replace(
mixed $pattern, // 正则表达式模式（支持数组）
mixed $replacement, // 替换的内容（支持数组）
mixed $subject, // 待处理的目标字符串（支持数组）
int $limit = -1, // 可选：最大替换次数（-1表示无限制）
int &$count = null // 可选：引用变量，记录实际替换的次数
): mixed
到这里就真不懂了，接着看WP
了解了e漏洞：
/e 修正符使 preg_replace() 将 replacement 参数当作 PHP 代码（在适当的逆向
引用替换完之后）。
提示：要确保 replacement 构成一个合法的 PHP 代码字符串，
否则 PHP 会在报告在包含 preg_replace() 的行中出现语法解析错误。
这个场景对应的是PHP中 preg_replace 函数的代码执行漏洞，其核心原理是利用了 preg_replace 的 /e 修饰符（或类似的代码执行逻辑），将替换内容作为PHP代码执行，从而实现了服务器命令执行，具体过程如下：
- 漏洞触发的核心条件
preg_replace 函数在使用** /e 修饰符**时，会将"替换内容（ replacement 参数）"当作PHP代码执行（注：PHP 7.0及以上版本已移除 /e 修饰符，但旧版本或特定环境仍可能存在类似风险）。
在这个请求中，URL参数对应的是 preg_replace 的三个核心参数：
-
pat=abc ：对应 preg_replace 的正则模式（$pattern），即匹配字符串中的"abc"；
-
rep=system("ls") ：对应替换内容（$replacement），这里构造了系统命令执行函数 system("ls") ；
-
sub=def abc ：对应目标字符串（$subject），其中包含了"abc"（用于触发正则匹配）。
- 漏洞执行的流程
当后端执行 preg_replace("/{pat}/e", rep, $sub) 时：
-
正则模式 /abc/e 匹配到目标字符串 sub 中的"abc"；
-
由于 /e 修饰符的存在，替换内容 system("ls") 会被当作PHP代码执行；
-
system("ls") 是PHP的系统命令执行函数，会在服务器上执行 ls （列出当前目录文件）的系统命令；
-
命令执行的结果（文件列表，如 index.html 、 start.sh 等）被返回并显示在响应中。
-
响应结果的对应性
响应红框中的 index.html 、 index.php 等内容，正是 ls 命令执行后返回的服务器当前目录的文件列表，证明了攻击者成功通过 preg_replace 的代码执行漏洞，获取了服务器的文件信息（甚至可以进一步执行其他系统命令）。
简言之，这个场景的原理是利用 preg_replace 的 /e 修饰符漏洞，将替换内容构造为系统命令函数，触发服务器端代码执行，从而获取服务器资源或执行恶意操作。
发现可疑文件。
由于浏览器会自动帮你编码，而包不行，所以包还要额外编码。
这靶场好像有点问题。
总而言之就是利用/e传参。