前言

在分析某 Windows 应用的服务组件时，发现其创建的命名管道访问控制配置宽松，允许低权限用户连接并发送指令，从而触发高权限的终止任意进程操作（taskkill）。进一步分析发现，被终止的服务会自动重启，而其可执行文件的权限配置错误，允许 Everyone 组读写。结合这两个缺陷，可构造一条完整的本地提权利用链。

漏洞挖掘过程

命名管道

关于命名管道

命名管道（Named Pipe）是 Windows 操作系统提供的一种进程间通信（IPC）机制，允许不同进程（包括跨会话、跨权限级别）通过一个带名称的管道进行双向或单向数据交换。

命名管道具有全局可见的名称（通常位于 \pipe\ 命名空间下，如 \.\pipe\KeyServicePipe），支持多客户端连接，并可通过安全描述符（Security Descriptor） 设置访问控制列表（ACL），以限制哪些用户或组可以读取、写入或创建连接。

命名管道常被用作高权限服务与低权限客户端之间的通信通道。

然而，若开发者未正确配置管道的 ACL（例如允许 Everyone 或 Authenticated Users 具有写权限），攻击者就可以作为客户端向服务端发送消息，从而使得服务执行敏感操作（如启动/终止进程、读取文件等），以此构成权限提升或远程代码执行的风险。

发现命名管道

发现命名管道及查看其对应的 ACL 策略可以借助 Sysinternals Suite 内的 pipelist 和 accesschk。这里 0cat 向我推荐了一款可视化友好的工具：Pipetap。通过查看 Pipelist 发现存在一个 ACL 策略为 Everyone 可写的命名管道：KeyServicePipe。

该命名管道对应的进程也是以 System 权限运行着，完全符合我们挖掘提权的条件。

进程终止逻辑

根据命名管道服务进程定位到其可执行文件，接着通过 IDA 进行一键导出反编译代码。配合着 AI 进行分析，很容易就定位到相关信息。

首先是入口接收到信息并根据不同的偏移量解析客户端所发送过来的消息，根据这些偏移量得知消息包含 2 个部分：消息头和消息体，消息头为 12 个字节。

其次是消息头的逻辑，我们可以看见其有三个部分，每个部分刚好 4 字节（DWORD）。三个部分分别为：会话 ID、消息类型、消息体长度。这些信息也是基于后续的调试输出所得知。读到消息类型后，会判断消息类型的范围必须在 1-37 之间。

最后就进入消息分发，根据不同的消息类型进行分发。不同的消息类型对应不同的处理逻辑，在这里实际上踩了个坑，正常跟进向下的逻辑 Map 寻找，而实际上在服务创建的构造函数内就已经定义好了：sub_424FF0(v5, 消息类型, 消息处理函数)。

关键问题逻辑就是其作为命名管道服务端有一个消息接收分发机制，根据消息类型来进行消息的分发。如图所示，当消息类型为 24 时则进入消息进入 sub_4216B0 函数处理。

在 sub_4216B0 函数内本质上就是获取消息体进行处理，最重要的就行消息体的 +4 字节偏移位，其为 PID（这里做了强转换，因此无法进行命令注入）。

PID 首先用于 TASKLIST 命令进行命令查找。

只有当指定的 PID 进程存在时才会接着向下走，走到 TASKKILL 命令，根据 PID 强制关闭进程。至此，我们就发现了一条低权限进程通过命名管道以 System 权限进行 TASKKILL 任意进程的路径。

系统服务

关于系统服务

Windows 服务（Windows Service）是 Windows 操作系统中一种在后台持续运行的程序，无需用户交互即可执行特定任务。如果服务在配置时没有做好权限的 ACL 配置则会导致三类风险：可修改服务二进制文件、可修改服务注册表项、可修改服务本身，易被攻击者利用实现本地权限提升或恶意篡改服务配置与运行逻辑。

可修改服务二进制文件

这里直接借助 SharpUp来进行一键分析：SharpUp.exe check ModifiableServiceBinaries。发现有很多服务的可执行文件是可以修改的，但是要配合攻击链路，就需要满足被 TASKKILL 强制终止进程后，还会自动重启的。这里测试出来发现 KeyAgent 服务满足这一逻辑。

利用链构建

利用链构建比较简单，先启动独立的线程不断的循环尝试将恶意文件 EvilAgent.exe 替换目标服务的合法可执行文件 KeyAgent.exe，同时作为客户端连接命名管道 \.\pipe\KeyServicePipe 并发送构造好的 KillProcess 消息触发命名管道服务进程执行 TASKKILL 命令终止 KeyAgent.exe 进程，最后借助 KeyAgent.exe 服务自动重启特性加载恶意文件，完成本地权限提升的利用链构建。

EvilAgent.exe 是 SystemGap 项目里的 SystemGapAll。其同样也借助命名管道实现高低权限进程间的通信，低权限向高权限发送要执行的命令，高权限执行并把结果返回给低权限。

总结

本提权利用链的成功构建，关键在于命名管道访问控制配置不当与服务可执行文件权限配置错误这两个缺陷的组合利用，在实战过程中发现这也类似的问题也很多，是个值得关注的攻击面。最后，在此特别感谢 @倾旋 在漏洞挖掘过程中提供的协助。

原文链接

https://www.t00ls.com/articles-74973.html

记得2016年那会Android手机抓包还是很轻松的，配置一下证书就能愉快的查看接口数据了。

最近在Android上抓包的时候，突然发现Android机上小程序和APP的抓包出现一系列抓包不稳定，https接口流量不解析，图片资源不解析的问题，本来以为只是简单的抓包配置不合理，之后发现这涉及到一系列的问题：

一、Android 系统版本限制
二、ROOT 权限获取
三、Android 系统信任用户证书
四、绕过 APP SSL Pinning
五、代理工具的选择
六、APP 端流量拦截转发
七、总结
八、结语

顿时来了兴趣，开始一通折腾，终于断断续续，一步步查一次次尝试，彻底解决了Android的抓包问题，搬开堵在面前的大石，整个人都轻松通透了！在此要特别感谢AI技术，帮助我快速排查问题。

一、 Android系统版本限制

查看Android版本抓包相关的重大变革，两个最重要变化：

• • 最大分水岭：2016年8月22日发布的Android 7.0（Nougat） → 彻底改变了证书信任策略，导致传统HTTPS抓包失效，是最重大的一次改动。

• • 第二大限制：2018年发布的Android 9.0（Pie）→ 默认禁用明文HTTP。

• • 现代难点：Android 10+ TLS1.3、Android 13+QUIC/HTTP3，导致传统代理工具（Fiddler、Charles）基本废了。

上图总结引用自：Android证书安装大指南——看这一篇就够啦

二、ROOT 权限获取

Root的实现方式：无论是Magisk还是Kernel SU，都需要修改boot.img（或内核），如果Bootloader没有解锁，刷写的镜像会因签名不符而被拒绝，手机要么无法启动，要么自动恢复原厂镜像。

1.Bootloader 解锁

Bootloader 是手机开机最先运行的程序，负责验证并加载系统关键分区（boot、recovery、system、vendor等）。

默认情况下，它会强制校验签名（verified boot/AVB），拒绝加载被篡改的镜像。我使用的手机型号是红米手机（下图是手机当前的参数信息）：

解锁 BL 时还未更新成澎湃系统，具体用的是哪个版本的MIUI已经记不清了，估计就是 MIUI13 或者 MIUI14，据说澎湃系统现在获取 ROOT 权限的限制更为严格了。

在申请解锁Bootloader的过程中也是一番折腾，简单来说要先绕过内测5等级，再等168小时（即7天）才可以。

• • 绕过内测5等级的方法可以看这个B站视频：【小米澎湃OS】小米hyperOS解锁bl绕过社区验证绕过内测5等级绕过内测绑定解锁bl刷root降级

• • 进行BL解锁的过程很繁琐，网上有大量教程讲解详细，可以跟着一步步做，这里就不细说了，总之又是一番折腾，但好在解锁过程还算顺利，不懂就问所以折腾的过程中又增长了不少知识。这里放两张手机成功BL解锁的图片，BL解锁成功，开机！

2.root 权限获取

BL解锁后，推荐使用Magisk APP+boot.img（需要到手机官网查找对应的ROM提取boot.img文件）获取root权限，网上有大量教程都详细说明了：从BL解锁到获取root的整个过程，这里也不再详细说明。

三、Android 系统信任用户证书

从Android 7.0+之后，系统就不再信任用户证书，默认只信任系统证书，因此在抓包解密HTTPS流量时，就必须先将中间人证书（Charles、Fiddler等）安装到系统证书。

安装系统证书总体来说有以下两种方式，推荐第2种。

1.复制用户证书到系统证书

Android系统上的证书必须按其独有的安全规则对证书进行命名：

1.下载代理证书，例如下载Charles的证书CharlesCA.pem
2.按安卓系统证书命名规则，获取"CharlesCA.pem"的名称；
openssl x509 -inform PEM -subject_hash_old -in CharlesCA.pem | head -1
# 返回 b0ba53e2
3.修正证书名称
mv CharlesCA.pem b0ba53e2.0

将重命名好的证书，使用ADB推送至系统证书路径。

因为系统路径默认是只读的，还需要换取写权限，这也会需要root。

具体操作方法网上也有很多博文教程（例：小米手机安装charles证书到系统证书，安卓高版本安装系统证书 HTTPS 抓包 - 终极解决方案）。

在此只做简单说明记录。此方法比较麻烦且重启手机后自定义的CA证书注入操作就会失效，所以手机重启，就需要每次重新注入证书，进入android系统修改证书路径。

2.使用 Magisk TrustUserCertificates 信任用户证书

根据现在手机系统的换代升级，我安装的主要是 Magisk 的 AlwaysTrustUserCerts 模块。

先决条件（必须）

• • Bootloader已解锁（否则不能刷入Magisk）。

• • 已刷入Magisk v24+（支持Zygisk，抓包遇强制校验证书指纹的APP时必须用），并能获取root（Magisk Manager可用）。

• • 你对可能的数据清除/Warranty风险有心理准备（解锁通常会清数据并可能影响保修）。

之后安装对应的模块：AlwaysTrustUserCerts，若开启Zygisk，可一起安装：LSPosed。在GitHub搜索安装即可！

• • TrustUserCerts（Magisk 设置）：修改系统层，将你安装为“用户证书”的CA自动同步到系统证书区（system trust store），让Android 7+上的大多数APP也能信任这些代理/自签CA（比手动拷贝更稳妥、可回退），适用于普通HTTPS流量+代理证书。通常该模块在post-fs-data阶段运行并完成同步。

• • LSPosed：基于 Zygisk 的 Xposed 运行时，用来加载 Xposed 模块（比如TrustMeAlready）。

具体的安装步骤网上也有很多教程，可以自行百度也可以询问AI。Magisk 的配置与模块安装：

四、绕过 APP SSL Pinning

若APP强制钉死证书（常见于安全敏感APP，如微信、银行、直播、游戏等），Android 系统在本机信任“用户安装的证书（用户证书路径）”并 不能绕过 APP 的 SSL Pinning（跳过强制校验证书指纹）！ LSPosed 的 TrustMeAlready 模块是一个用于绕过APP的SSL Pinning的Hook模块。

想要绕过强校验APP，那么Magisk TrustUserCerts 与 TrustMeAlready（LSPosed模块）一起使用，才是最佳组合！

安装 TrustMeAlready步骤：

• • 开启Zygisk，Zygisk是Magisk v24+ 推出的 Zygote 进程级注入框架，使用 Zygisk 版 LSPosed + TrustMeAlready绕过APP SSL Pinning。

• • 安装LSPosed，基于 Zygisk 的 Xposed 运行时，用来加载 Xposed 模块（如TrustMeAlready）。

• • 安装 TrustMeAlready：一个常用的 Xposed 模块，用于绕过某些 Java 层的 SSL Pinning/检测（需要在 LSPosed 下安装并针对目标 APP 启用）。

• • 安装TrustMeAlready后，选中需要抓包的APP，用于绕过抓包时某些 Java 层的 SSL Pinning/检测。

LSPosed 中 TrustMeAlready 的安装与配置：

五、代理工具的选择

系统信任MIMT证书后，在我抓包小程序时就已经能正常解析数据接口，但依然无法正常解析图片接口，使用 TrustUserCertificates（Magisk模块）+ TrustMeAlready（LSPosed模块）+ Fiddler/Charles 图片依然无法正常解析，折腾很久终于弄明白其中原委，这里再次感谢AI！

原因是某些图片服务器会检测代理/MIMT（如七牛CDN、阿里云CDN、微信/腾讯云CDN）或者APP使用了Native层TLS，Fiddler/Charles无法伪造证书：

此前代理工具一直使用的是 Fiddler/Charles，从未想过更换代理工具，但面对这个问题也不得不尝试寻找最新的工具，然后发现HTTP Toolkit抓包瞬间通畅，真是山重水复疑无路，柳暗花明又一村。

原因是：

• • Fiddler/Charles 解析图片（兼容性差）：Fiddler 只支持 HTTP/1.1，许多 CDN 是 HTTP/2 / HTTP/3 → 握手会失败导致 403 或直接黑屏；Charles 支持更好，但仍然有兼容性不足。所以Charles/Fiddler 报 403 → 因为中间人证书失效或不支持 HTTP/2；CONNECT 200 只是隧道建立成功，不是服务器返回 200

• • HTTP Toolkit（推荐）：能抓取图片 → 说明 APP 图片走 Native TLS，它可以 hook native TLS，能穿透校验，最适合抓图片这类 CDN 内容。

HTK工具的成功使用，让研发同事也跑来询问点赞，也算是给自己的小小的成就感吧！

六、APP 端流量拦截转发

本以为小程序抓包畅通无阻后，APP也是一路绿灯，但使用了 Wifi/系统代理、Droy工具后依然经常出现抓不到任何流量的情况。原因是小程序依附微信有单独的网路通信，APP可能绕过了系统代理（非常常见），许多APP（特别是国产 App）会：

• • 使用 OkHttp 的 proxy = NO_PROXY

• • 使用 Socket / Native libssl

• • 使用 QUIC/HTTP3

• • 或强制直连

这类流量 Droy 抓不到，但 Clash 的 TUN 能抓。干脆一劳永逸，直接用 Clash 做流量转发，是最稳、最通用、最不容易被 APP 绕过的方案，因为 Clash（TUN 模式）有 2 个巨大优势：

优势 1：Clash TUN → 强制接管所有流量

优势 2：Clash 可以把所有流量转发给 Fiddler/Charles/HTTP Toolkit等

总之，不管你用什么抓包工具，先让 Clash 接管所有流量，再转发给 Fiddler/Charles/HTTP Toolkit等，是最稳定、兼容性最高的方案。

不过想要使用Clash需要能够科学上网，如果你连科学上网都不会，请出门左转先去百度吧！使用Clash还需要：

• • 自己配置代理文件yaml并导入Clash，可以百度一下，有现成的配置文件。

• • 针对APP抓包需要在【设置-网络-访问控制模式&访问控制应用包列表】指定需要抓包的APP

七、总结

1.iOS抓包与Android抓包的不同

iOS系统信任管理集中，允许用户手动安装并信任根证书，这就让像Charles/Fiddler/HTTP Toolkit 这样的工具能够成功解密HTTPS流量。
Android

• • Android 7.0+开始系统信任机制越来越严格，用户安装的CA证书不会被应用自动信任，默认只信任系统自带的根证书，需要ROOT。

• • 许多APP有证书固定，需要hook才行，抓包难度大。

• • Android APP可以绕过系统代理：Android 的代理是一种 可检测且可规避 的设置，APP可以轻易检查并选择是否使用。

2.小程序抓包与APP抓包的不同

小程序

• • 因为证书固定必须写在APP原生代码里，因此小程序的HTTPS默认没有“证书固定”，它们的网络请求都是通过平台容器（微信、支付宝APP本体）发出的，微信/支付宝容器本身是不做证书Pinning的，只会简单使用系统信任链，如果Android系统信任了抓包软件的CA证书，微信就会信任，然后所有小程序HTTPS都能被解密。因此：小程序 = 容器代发网络请求 = 容器不固定证书 = 容易抓包。

• • 小程序域名统一托管，APP则完全自由，可自行随便加okhttp.setCertificatePinner(...)

• • APP通常会证书固定（Certificate Pinning），机制一般为PIN 公钥或证书摘要 → 如果不是原始服务器证书则拒绝连接。因此：APP = 启用了证书固定 = 不信任抓包CA = 无法抓HTTPS。

3.小结

• • Android APP抓 HTTPS 的终极组合（100%）：

1.系统 ROOT（最关键）
2.TrustUserCertificates （Magisk配置，自定义 APP 也信任用户证书）
3.TrustMeAlready（LSPosed模块，自动绕过Java层证书固定）
4.Fiddler/Charles/HTTP Toolkit（MITM核心）
5.Clash（TUN强制接管所有流量）

ROOT 可以把代理的 CA 装到 /system/cacerts → 所有 APP 100% 信任。这一步让系统层面开启了完全的MITM。

你的APP没有SSL Pinning，但还是报证书错误 → 用 Magisk 的 TrustUserCertificates 即可
你的 APP 有 SSL Pinning，TrustUserCertificates 也没用 → 必须用 TrustMeAlready
最稳抓包 = 两者一起使用

ROOT是基础，TrustMeAlready是“杀手锏”，两者叠加：没有Java层的Pinning能逃得掉。

这套组合的实际能力：只剩应用层加密抓不到（emmm...新的任务已解锁！）

对于强防护 APP（如微信、银行 App）：

• • HTTPS 会彻底被解密（MITM）

• • 但内部 payload 会继续被三重 AES/RC4/SM4 加密

这是应用层加密，不属于 HTTPS 抓包范畴。要解这个，需要逆向协议，不是 MITM 的问题。

但你能看到加密前的 TLS 结构、中间件标记、序列号等，说明 MITM 已经 100% 成功。

八、结语

好奇心与探索欲是原动力，有时候神奇的技术就是一层窗户纸，解决的办法往往很简单，但解决的过程往往很曲折。这中间说不清道不明的吃透问题点的好奇心是坚持下来最重要的原因！

灵蛇圆满辞旧岁，骏马奔腾迎新春。乙巳蛇年的脚步声渐行渐远，丙午马年的钟声即将敲响。值此农历丙午春节来临之际，T00ls向所有T00lser以及网络安全行业的朋友们致以美好的新春祝福，给大家拜年啦！

马蹄声近，蛇影渐远。回首2025，我们以蛇之敏锐，洞察幽微，为T00ls的沉淀添砖加瓦。展望2026，愿我们如骏马般豪迈，以驰骋之姿，跨越技术的高峰，追逐梦想的旷野。愿每一位T00lser在新的一年里，事业如万马奔腾，势不可挡；生活似策马扬鞭，一日千里。让我们携手共进，以龙马精神，续写T00ls的辉煌篇章！

2025年概况

这一年我们吸纳优秀会员2033人;
这一年我们预警了48个知名厂商漏洞;
这一年T00ls产生了24486篇发帖，其中1632篇主题帖；

T00ls变化

论坛机制，持续优化，打造最优最安全的网络安全交流环境

T00ls 启用了论坛专属ai来进行回复！
T00ls 同时与多家src合作，引入新会员！

T00ls 成长

根据元旦的统计，这一年，我们的进步

主题帖：1632篇，平均每日4.5篇；
总发帖（含回复）：24486篇，平均每日67篇；
总会员：13136；
新增会员：2012；（以低权限注册为主，少数为投稿申请）
活跃会员：4496

2025年预警知名厂商或通用型漏洞超48个

其中包括：高德，百事中国，新东方，哈勃智能云，如视，国家电网，中金数据，联想，团车网，金科集团，上汽，贵州国台酒业，京东等实体公司与金融基建企业；同时还有清华大学，中国大学，中央民族大学，西安科技大学，上海科技大学等高等院校。

我们的期望

• • 搭建T00ls专属安全大模型。

• • 精简代码结构以及资产、合规化调整网站与服务功能。

Tubi红包来袭

即刻起（每个帐号只能领一次）：

在T00ls微信公众号输入100，即可领取TuBi红包奖励，数额从1-100随机。（若没绑定，请先输入2绑定T00ls帐号）

在T00ls电报机器人输入/hongbao，即可领取TuBi红包奖励，数额从1-100随机。（若没绑定，请先输入/start绑定T00ls帐号）

管理团队及版主还可以在论坛任务处领取额外TuBi红包奖励。

T00ls专属红包封面第二版来袭

T00ls社区专属定制红包封面 第二版 正式跟大家见面啦！

摘要：破茧成蝶，荣耀加冕。这份专属的新春礼物，送给每一位坚守初心的你。

这一年，辛苦了！

各位 T00ls 的兄弟们：

从指尖敲击的每一个字符，到深夜屏幕映出的每一行代码，感谢每一位 T00ls 会员在 2025 年的坚持与付出。是你们的热爱，构成了社区最坚固的防线。

成长的道路从来不易，风雨阻挡不了我们追逐梦想的决心。唯有坚持，才能破茧成蝶。

辞旧迎新之际，除了刚刚公布的 “第十三届年度风云榜” 和 “名人堂” 荣耀，管理团队还为大家准备了一份特别的“年货” —— T00ls 2026 马年特制红包封面！

🐎 T00ls 定制 · 极客专属

今年的红包封面设计，我们将 T00ls 的极客精神与 2026 马年“奔腾”的意象完美融合。

寓意新的一年：
漏洞全挖空，Shell 一把梭！
技术突飞猛进，生活一马平川！

既然是过年，就要有排面！换上这款专属封面，发出去的每一个红包，都带着 T00ls 独特的安全感与技术信仰。

🚀 立即领取方式

为感谢大家一年的努力，本次红包封面直接领取，无套路！数量有限，手慢无！

👇 点击下方卡片即可一键领取 👇

⚠️ 领取小贴士

1. 1. 拼手速：封面数量有限，领完即止，建议大家看到推文立即下手。

2. 2. 有效期：领取后请在 3 个月内使用，过期将失效。

3. 3. 分享喜悦：领到封面的兄弟，欢迎在朋友圈晒出你的“T00ls 专属年味”！

2026，我们继续并肩作战！
提前祝大家新春快乐，Code 0 Bug，挖洞必 0day！

Make Security Better.
T00ls 管理团队 敬上

成长的道路从来不易，风雨阻挡不了我们追逐梦想的决心，唯有坚持，才能破茧成蝶。T00ls管理团队继续感谢大家的热情付出，我们选择迎难而上，因为每一次努力，都在为未来的光芒积累力量。

“年度人物风云榜”评选的活动T00ls已经持续了13年，也为T00ls的历史上增添了一些让人留恋的印记。经过长达40天的激烈角逐与大家的踊跃投票，T00ls第十三届（2025）年度人物风云榜的评选现已圆满落下帷幕！

本届评选我们严格遵守了前期公布的硬性指标：

1. 1. 在技术版块发表过帖子；

2. 2. 2025年发帖总数大于120篇；

3. 3. 管理团队不参与竞选。

此外，特别感谢大家对今年新规的遵守：本次评选严格限定在最初公布的20名候选人名单内，任何人无破例入选资格。 这不仅维护了规则的严肃性，也让每一张选票都更加公平、纯粹。

根据最终的投票统计，以下12位师傅凭借过硬的技术实力、持续的优质输出以及极高的人气脱颖而出，正式当选 T00ls 第十三届（2025）年度风云人物！

🏆 第十三届年度风云人物 Top 12 榜单 🏆

• 让我们用热烈的掌声向以上12位师傅表示最诚挚的祝贺！感谢你们在过去一年为T00ls带来的精彩与贡献！

• • 👑 榜首：10907-没睡的风 —— 56票（15.77%）

• • 🥈 榜眼（并列）：16782-Xiaoyune —— 47票（13.24%）

• • 🥈 榜眼（并列）：5520-anlfi —— 47票（13.24%）

• • 🏅 第4名（并列）：16810-MrE404bug —— 24票（6.76%）

• • 🏅 第4名（并列）：13963-0verf1ows —— 24票（6.76%）

• • 🏅 第6名：16765-Bu0uCat —— 22票（6.20%）

• • 🏅 第7名：13648-cxaqhq —— 21票（5.92%）

• • 🏅 第8名：18229-Qiufen —— 18票（5.07%）

• • 🏅 第9名：17310-beiank —— 17票（4.79%）

• • 🏅 第10名：16408-AlyssaVV —— 16票（4.51%）

• • 🏅 第11名：17446-sasser —— 14票—— （3.95%）

• • 🏅 第12名：16677-jm33ng —— 10票—— （3.54%）

🌟 专属荣耀与奖励 🌟

按照惯例，以上所有获得本届风云榜的会员将获得以下专属荣誉：

1. 1. 授予荣誉勋章：彰显身份与技术贡献。

2. 2. 专属域名邮箱：获得 t00ls.net 域名邮箱的尊贵使用权！

3. 3. 入驻名人堂：永久载入T00ls名人堂！“T00ls名人堂”只收录元老核心、T00ls风云人物，这是社区赋予的最高荣誉。

📌 T00ls名人堂参观地址： https://www.t00ls.com/hof.html

🧧 贺岁迎新：T00ls马年特制红包封面即将放送！

金戈铁马，气吞万里如虎！借此年度盛典与新春佳节交汇之际，T00ls 管理团队也为全站会员准备了一份特别的新年福利——T00ls 专属马年特制红包封面！

今年的红包封面融入了满满的马年吉祥元素与 T00ls 的极客精神，祝愿大家在新的一年里“马到成功，技术精进”！

• • 发放规则：本次马年特制红包封面发放数量待定（明日开始发放）！

📚 历届T00ls风云榜回顾

历史的沉淀是T00ls最宝贵的财富，重温那些曾陪伴我们一路走来的技术大佬们：

• • 第十二届：https://www.t00ls.com/articles-73098.html

• • 第十一届：https://www.t00ls.com/articles-71253.html

• • 第十届：https://www.t00ls.com/articles-68318.html

• • 第九届：https://www.t00ls.com/articles-64465.html

• • 第八届：https://www.t00ls.com/articles-59708.html

• • 第七届：https://www.t00ls.com/articles-54844.html

• • 第六届：https://www.t00ls.com/articles-49781.html

• • 第五届：https://www.t00ls.com/articles-44217.html

• • 第四届：https://www.t00ls.com/articles-37949.html

• • 第三届：https://www.t00ls.com/articles-32992.html

• • 第二届：https://www.t00ls.com/articles-29289.html

• • 第一届：https://www.t00ls.com/articles-25335.html

再次感谢所有参与投票的会员，以及所有陪伴T00ls共同成长的朋友们。马年新征程，我们继续策马扬鞭，迎风前行！

双峰并峙，顶峰相见

在中国网络安全的发展历程中，有两个名字始终熠熠生辉，各自代表着一种极致。

🔵 360SRC：实战的角斗场

🔴 T00ls：技术的隐修地

作为国内历史悠久的老牌安全社区，T00ls 以低调求发展，潜心习安全为精神内核，T00ls 汇聚了大量资深安全专家与红队大牛，拥有极深厚的技术沉淀与原创氛围，同时拥有数万篇原创文章，是国内现今最大的安全社区之一。

十余年来，为了保持社区的纯粹性，始终实行严格的邀请注册制。

在这里，邀请码不仅仅是一个账号，更是一份“身份的象征”与“技术的认可”。

今天，我们要打破壁垒。

360SRC 正式携手 T00ls，开启重磅福利联动！

我们将把这份象征着技术荣耀的 “T00ls 邀请码”，作为最高级别的战利品，颁发给在 360SRC 表现最卓越的顶尖白帽。

核心玩法：凭实力，换荣耀

这是一场属于强者的游戏。
既然是两大平台的强强联合，门槛自然不低。我们要寻找的，是真正处于金字塔顶端的安全猎手。

01 / 长期荣耀：强者恒强

Long-term Glory

真正的黑客精神，在于持之以恒的探索。我们将目光投向了那些在 360SRC 长期深耕、持续输出的高级白帽。

🛡️ 兑换门槛

360SRC 个人成长等级达到 Lv3 及以上
(成长等级基于最近 720 天的贡献值计算)

首批开放名额：仅限 10 个！手慢无，强者先得。

02 / 专项突击：一击必杀

Special Operations

错过了日常积累？没关系，我们更欣赏在关键时刻力挽狂澜的英雄。
在后续举办的 专项漏洞收集活动 中，我们将不定期掉落 T00ls 邀请码作为额外奖励。

⚔️ 兑换门槛

• • 参与指定专项活动

• • 达到活动贡献标准 (具体以当期活动规则为准)

如果你擅长挖掘高质量漏洞，这就是你弯道超车、通过实战赢取“通行证”的最佳机会。

结语：致敬技术初心

T00ls 崇尚“低调、求实”，360SRC 尊重每一份提交的价值。
这次合作，是平台与社区的握手，更是对技术初心的回归。

如果你已经在 360SRC 战功赫赫，请立刻去领取属于你的荣耀；
如果你还在成长的路上，请握紧手中的键盘——

下一个 T00lser，或许就是你。

致各位白帽子：

为了进一步促进网络安全技术的深度交流，打通“实战挖掘”与“技术研究”的壁垒，我们非常荣幸地宣布：EDUSRC（教育漏洞报告平台） 与 T00ls（土司安全社区） 正式达成深度战略合作！

即日起，EDUSRC 礼品中心将上线 T00ls 注册邀请码 兑换通道。

🌟 关于合作双方

🛡️EDUSRC ( 教育漏洞报告平台)

作为国内教育行业网络安全的核心力量，EDUSRC 致力于通过众测模式收集高校及教育系统漏洞。它是白帽子进行合法合规实战演练的最佳场所，汇聚了国内最具活力的年轻安全力量，守护着亿万师生的数据安全。

🛡️ T00ls (土司安全社区)

T00ls 成立于 2008 年，是国内历史最悠久、门槛最高的非盈利安全技术社区之一。秉承“低调求发展，潜心习安全”的理念，T00ls 汇聚了大量资深安全专家与红队大牛，拥有极深厚的技术沉淀与原创氛围，同时拥有数万篇原创文章，是国内现今最大的安全社区之一。

📅 兑换规则与详情

本次合作旨在筛选和回馈真正具备高质量漏洞挖掘能力的研究员，具体规则如下：

本次所兑换邀请码为正式会员邀请码，注册后与申请投稿注册的权限完全相同。

1. 💎 兑换门槛与消耗

• • 身份要求： 仅面向 EDUSRC “高级白帽子” 及以上用户开放。

• • 积分消耗：80 金币 / 个。

2. 📦 数量与补货机制

• • 首期投放： 限量 100 个。

• • 持续补货： 我们将建立长期的持续补货机制，确保持续为优秀白帽提供通道，请勿恐慌性抢购。

• • 唯一机会： 每位符合条件的用户，终身仅限兑换 1 个。

⚠️ 特别声明：严格风控与绑定机制

为维护 T00ls 社区纯净的技术氛围，杜绝邀请码买卖行为，本次活动执行最严格的风控措施：

邀请码仅供本人注册使用。一经发现倒卖、转赠、代注册等行为将进行封禁论坛账号处理。

🔗 如何参与？

请登录 EDUSRC 平台，进入【礼品中心】板块查看。

让实战更有价值，让技术更有深度。EDUSRC 与 T00ls 期待您的加入！

随着安全越来越卷，越来越多的站点对报文做了加密处理，不努力下次测试连个包都改不了

以某站点为例，对前端报文加密绕过处理做下总结

通过抓包可以看到网站对报文进行了加密处理

针对这种前端报文加密的场景常考虑以下几种应对措施

1.分析加解密算法，流程，进行重写。密文=>解密=>加密
2.jshook，控制台操作
3.js rpc

以上三种方法，不可绕过的步骤都是前端加密逻辑分析。

加密逻辑分析

打开 F12 /开发者工具

浏览前端目录，一眼发现 security 目录，并且该目录下还存在 encrypt-sm.js /pnc-crypto-min.js 文件

（没法一眼看出来的场景那就只能搜索关键字了）

快速查看两个 js 文件，发现加解密调用逻辑主要就存在jsencrypt-sm.js文件中

在关键位置进行断点，点击网页的扫码登录功能，很明显的发现参数 r 为请求报文体明文，参数 t 为加密密钥

根据堆栈信息可以找到调用加密的位置，可以看到密钥是通过YT.Security.getEncryptKey()获取到的， 每次调用getEncryptKey 密钥都会发生改变，跟踪函数发现生成密钥的位置如下

下面分析jsencrypt-sm.js 中的加密过程。

下面是整个请求报文体的加密处理过程

将报文体转换为byte数组
计算byte数组的长度
补齐数组长度到16的倍数，用随机数进行补齐，随机数计算方法
第一位制定为29(做分隔符) 后续Math.round(150 * Math.random()) % 150 + 30;
String.fromCharCode(29))  =〉 \x1D
生成混淆数组Math.round(255 * Math.random()) % 255;
然后将补齐后的字节数组逐位与混淆数组进行异或运算
异或结果+混淆数组进行拼接成新的数组
将拼接结果转换为hex字符串
密钥转换为字节数组
将以上两项进行sm4
将sm4结果从byte转换为hexstr
将sm4密钥进行sm2
拼接明文请求报文+对称密钥+YTGSRCU 然后将拼接结果进行sm3
u：sm3结果byte数组
o：sm4结果hexstr
s：sm2结果
拼接return "#10" + [Code.bytes2hexStr(u), o, s].join(String.fromCharCode(29))
最终请求报文

修改报文方式一（做成工具，自动化操作）

通过上面的加密逻辑分析，可以确定以下几点

1. 1. 对称加密密钥是随机生成的 应对方法：固定密钥（修改 js 文件使对称加密密钥保持不变）

    a. 调用加密算法时传入写死的字符串作为密钥
    b. 修改生成密钥的函数，使函数的返回值保持不变

2. 2. 组合加密，数字信封，对称+非对称+摘要 a. 固定对称加密密钥后非对称加密部分不需要操作 b. 对称加密部分，需要根据分析出的加密逻辑进行逆运算，将加密后的报文解密得到明文，修改报文后，再重写加密逻辑将明文加密成密文 c. 将修改后的报文重新算摘要

整体实现难度较大，但实现后将其做成 burp 插件，或者在 burp 上再叠一层 mitmdump 处理加解密 ，后续可以很方便测试。

修改报文方式二（适用于简单测试，验证，不方便批量操作）

通过调试找到调用加密函数的位置，可以在开发者工具中对指定参数进行修改，大变量需要在 console 窗口中进行修改

修改报文方式三

可以看到报文的格式时 json，并且有调用的 JSON.stringify(r)，可以对JSON.stringify(r)进行 hook

每当调用JSON.stringify(r)时可以走入我们自定义的函数中，我们可以再此对传入的加密前的明文 body 进行修改

但此处不行，因为传入的 r 本身就是 string 类型走不到JSON.stringify(r)

跟对堆栈往前找

可以对YT.Security.encrypt 进行 hook，此时代码走入了我们的自定义逻辑中，同样可以修改加密前的明文 body

修改报文方式四

通过 jsrpc 的方式，主动调用 js 中的报文加密和解密函数，对报文进行加密或解密

但是此处可以响应报文的解密适用该方法，加密逻辑复杂，网站 js 代码中未提供可以解密请求报文的函数

此处同样需要提前对密钥进行固定

总结

其实针对用web端系统的前端加解密还是比较好解决的，可能难点在于js混淆，就是需要慢慢调试，理清逻辑后还是很好操作的，实在不行，前端代码都给了，直接上手改呗。

另：现在进入ai时代了，大不了扔给ai分析呗。

这里贴一段jsencrypt-sm.js 代码

define(function(require) {
require("js/security/pnc-crypto-min");
var r = YT.Security = {
encrypt: function(r, t) {
"string" != typeof r && (r = JSON.stringify(r));
var n = function(r, t) {
for (var n = r.length, e = t.length, o = newArray, s = function(r, t) {
for (var n = r.length, e = newArray, o = n / 16, s = 0; s < o; s++)
for (var u = 16 * s, i = 0; i < 16; i++)
                            e[u + i] = r[u + i] ^ t[i];
return e
                }(r, t), u = 0; u < s.length; u++)
                    u < n && o.push(s[u]);
for (var u = 0; u < t.length; u++)
                    u < e && o.push(t[u]);
return o
            }(function(r) {
var t = r.length
                  , n = t % 16;
                n = 16 - n;
var e = newArray;
                e[0] = 29;
for (var o = 1; o < n; o++)
                    e[o] = Math.round(150 * Math.random()) % 150 + 30;
var s = newArray;
                s = [].concat(r);
for (var o = 0; o < e.length; o++)
                    o < n && s.push(e[o]);
return s
            }(Code.str2bytes(r)), function(r) {
for (var t = newArray, n = 0; n < 16; n++)
                    t[n] = Math.round(255 * Math.random()) % 255;
return t
            }())
              , e = _Sm4.encode(Code.bytes2hexStr(n), Code.str2bytes(t))
              , o = Code.bytes2hexStr(e)
              , s = _Sm2.encode(t)
              , u = _Sm3.hash(Code.str2bytes(r + t + "YTGSRCU"));
return"#10" + [Code.bytes2hexStr(u), o, s].join(String.fromCharCode(29))
        },
decrypt: function(r, t) {
var n = r.substr(14)
              , e = parseInt(r.substring(3, 5), 16)
              , o = parseInt(r.substring(5, 7), 16)
              , s = parseInt(r.substring(7, 8), 16)
              , u = parseInt(r.substring(8, 14), 16)
              , i = n.substring(e, e + o)
              , a = i.length
              , h = [];
switch (h.push(n.substring(0, e)),
            s) {
case1:
                h.push(i.charAt(a - 1)),
                h.push(i.substring(1, a - 1)),
                h.push(i.charAt(0));
break;
case2:
for (var f = 2; f <= a; ++f)
                    f % 2 == 0 && (h.push(i.charAt(f - 1)),
                    h.push(i.charAt(f - 2)));
if (a % 2 != 0 && 0 < a) {
                    h.push(i.charAt(a - 1));
break
                }
            }
return0 != s && (h.push(n.substring(e + o)),
            n = h.join("")),
            n = n.substring(0, u),
function(r) {
for (var t = [], n = 0, e = r.length; n < e; n++)
240 <= r[n] && r[n] <= 247 ? (t.push(String.fromCodePoint(((7 & r[n]) << 18) + ((63 & r[n + 1]) << 12) + ((63 & r[n + 2]) << 6) + (63 & r[n + 3]))),
                    n += 3) : 224 <= r[n] && r[n] <= 239 ? (t.push(String.fromCodePoint(((15 & r[n]) << 12) + ((63 & r[n + 1]) << 6) + (63 & r[n + 2]))),
                    n += 2) : 192 <= r[n] && r[n] <= 223 ? (t.push(String.fromCodePoint(((31 & r[n]) << 6) + (63 & r[n + 1]))),
                    n++) : t.push(String.fromCodePoint(r[n]));
return t.join("")
            }(_Sm4.crypt(Code.hexStr2bytes(n), Code.str2bytes(t), 0))
        },
getEncryptKey: function() {
return r.uuid(32, 16)
        },
uuid: function(r, t) {
var n, e, o = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".split(""), s = [];
if (t = t || o.length,
            r)
for (n = 0; n < r; n++)
                    s[n] = o[0 | Math.random() * t];
else
for (s[8] = s[13] = s[18] = s[23] = "-",
                s[14] = "4",
                n = 0; n < 36; n++)
                    s[n] || (e = 0 | 16 * Math.random(),
                    s[n] = o[19 == n ? 3 & e | 8 : e]);
return s.join("")
        }
    };
String.fromCodePoint || function(u) {
var t = function(r) {
for (var t = [], n = "", e = 0, o = arguments.length; e !== o; ++e) {
var s = +arguments[e];
if (!(s < 1114111 && s >>> 0 === s))
throwRangeError("Invalid code point: " + s);
16383 <= (s <= 65535 ? t.push(s) : (s -= 65536,
                t.push(55296 + (s >> 10), s % 1024 + 56320))) && (n += u.apply(null, t),
                t.length = 0)
            }
return n + u.apply(null, t)
        };
try {
Object.defineProperty(String, "fromCodePoint", {
value: t,
configurable: !0,
writable: !0
            })
        } catch (r) {
String.fromCodePoint = t
        }
    }(String.fromCharCode)
});

原文链接

https://www.t00ls.com/articles-73345.html