最近看美女主页的时候发现突然多了个参数X-Dynosaur，后面测试了下目前还没有检测，但是可以提前分析看看难度，具体加密感觉跟xg差不多，大部分是ai分析的简单来给大家分享一下。
目标网址 "aHR0cHM6Ly93d3cudGlrdG9rLmNvbS9AYW5uaWlld29yYnkK"

X-Dynosaur 最开始看就是一串很长的字符，直接盯着成品看基本没什么用。我当时主要看了三样东西：请求从哪发、生成前后的长度，还有每次只改一个输入后，哪几段数据跟着变化。

这篇就简单记一下当时的排查过程，细节不全部展开。

页面打开后进开发者工具，在 Network 里过滤 item_list，作品列表走的是：

找到请求后先看 Initiator，再到 Sources 里加一个 XHR/fetch breakpoint，关键字填 item_list。刷新或者重新触发作品列表，请求发出前就会停下来。

这里不用一直跟到网络层。顺着调用栈往上找，看到 query 开始追加 X-Dynosaur 的位置就差不多了。再往前退一层，把输入长度、中间 Buffer 长度和最终结果长度记到 Console。

第一轮日志大概是这样：

这次请求的 base query 有 41 个参数，拼起来 1447 个字符；UA 是 117 个字符，GET 请求的 body 为空。日志里先把三块输入各自的 4-byte 结果记下来，后面做对照时就不用一直看整条 query。

再往下是字段区、加密层和外层封装。这里的 rounds=13、insert_at=43 只是这一次运行的值，换一组 key 会变；243、48、292 和 392 这些长度相对稳定。

接下来把 243 bytes 从头扫一遍。日志里多留了几列：

开头几段是这种走法：

拿第一行看会直观一点。off=0，header 是 20 00 06，后面跟 6 bytes 内容，所以这一段结束后落在 offset 9。第二行正好从 9 开始，header 变成 21 00 06，再往后走到 18。

照这个方式一直往后走，中间也能看到 0x27 这种 12-byte 内容，以及 0x2b、0x2e、0x30 这种 4-byte 内容。最后一行是 tag=0x38、off=236、len=4，加上三个 header 字节以后，next 正好是 243。

这张表的 idx 从 00 到 24，刚好 25 行，最后的 cursor 和 Buffer 长度也都是 243。每一段都是编号、保留字节、长度、内容这个排法，后面就按 TLV 往下分析了。

[招生]科锐逆向工程师培训(2026年7月3日实地，远程教学同时开班, 第56期)！