/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
1. 项目概述：从登录框到加密黑盒
最近在分析一些高校系统的自动化流程时，遇到了重庆大学统一身份认证的登录接口。乍一看，就是一个常见的用户名密码登录页面，但当你尝试用常规的 requests 库模拟登录时，会发现提交的表单数据里，密码字段是一串完全看不懂的、每次请求都不同的长字符串。这显然不是简单的Base64或MD5，而是前端JavaScript进行了实时加密处理。对于需要实现自动登录、数据采集或系统集成的开发者来说，理解并逆向这个加密过程就成了一个绕不开的“门槛”。今天，我就以一个实际逆向者的视角，带大家完整走一遍重庆大学登录加密的逆向分析流程，不仅还原加密逻辑，更重要的是分享在类似场景下的通用分析思路和避坑技巧。
这个实战的目标很明确：找到网页上点击“登录”按钮时，密码从明文到密文的完整转换链条，并用Python代码复现这一过程，最终实现稳定的自动化登录。整个过程会涉及浏览器开发者工具的使用、JavaScript关键代码定位、加密算法识别、以及Python的模拟实现。无论你是对Web逆向感兴趣的新手，还是遇到过类似加密困扰的同行，相信这篇详尽的记录都能给你带来直接的帮助。
2. 逆向环境准备与初步抓包
工欲善其事，必先利其器。在开始逆向之前，准备好趁手的工具和环境是成功的第一步。对于Web端的加密逆向，我们主要依靠浏览器和配套的调试工具。
2.1 核心工具链选择
我的主力浏览器是Chrome，其内置的开发者工具（DevTools）功能强大且更新及时。对于加密逆向，以下几个面板是关键：
- Network（网络） ：记录所有网络请求，这是我们分析的起点，用于定位登录的API接口和查看提交的数据。
- Sources（源代码） ：查看和调试页面加载的所有JavaScript文件。
- Console（控制台） ：执行JavaScript代码片段，用于测试我们的解密函数或调用特定的加密方法。
除了浏览器，一个代码编辑器（如VSCode）用于编写Python复现代码，以及一个可以方便发送HTTP请求的工具（如Postman或Hoppscotch）用于测试，就构成了基础环境。
注意：有些网站会检测开发者工具，打开后页面行为异常或加密逻辑改变。如果遇到这种情况，可以尝试使用无头浏览器模式（如Puppeteer）直接执行页面JS来获取加密结果，或者寻找检测逻辑并绕过。幸运的是，在此次分析中，重庆大学的登录页面没有这类反调试机制。
2.2 关键请求的定位与捕获
打开重庆大学的统一身份认证登录页面，按F12打开开发者工具，并切换到Network面板。记得勾选上“Preserve log”（保留日志），防止页面跳转后请求记录被清空。
在页面的用户名和密码框输入测试信息（例如，用户： test ， 密码： 123456 ），然后点击登录按钮。此时，Network面板会刷出一系列新的请求。我们需要从中找到那个真正提交登录凭证的请求。
通常，这个请求会有以下特征：
快速浏览后，我找到了目标请求：一个指向 /auth/login 路径的POST请求。点击该请求，查看其“Headers”和“Payload”。
在“Payload”标签页下，我们看到表单数据类似这样：
username: test
password: U2FsdGVkX19vBwQ8p4sVZ5J7K9mN…（一长串字符）
这里， username 是明文的，而 password 正是我们想要破解的密文。同时，在“Headers”中，注意查看 Content-Type ，通常是 application/x-www-form-urlencoded ，这决定了我们后续模拟提交的数据格式。
初步观察，这个密文长度较长，且含有 / 、 + 等字符，很可能是Base64编码后的结果。但Base64只是一种编码方式，并非加密算法，其原始内容才是加密后的二进制数据。我们的核心任务，就是找到生成这串密文的JavaScript代码。
3. 加密逻辑的定位与静态分析
找到加密发生的位置，是整个逆向过程中最具技巧性的环节。我们需要从数以万计的JavaScript代码行中，定位到那几行关键的加密函数。
3.1 搜索与断点追踪策略
在Sources面板中，我们可以使用全局搜索（Ctrl+Shift+F）来查找可能的关键字。搜索“password”、“encrypt”、“encode”、“Crypto”、“AES”、“RSA”等词汇。在这次分析中，搜索“password”在某个压缩过的JS文件里找到了多处匹配，但代码可读性极差。
