spiderdemo T4 基本wasm

首先会跳转,我一开始不知道怎么解决这个跳转

但是可以在跳转前一瞬间打开view-source:去查看源代码:

然后找到加载代码,丢给ai分析一通,给了个大致流程:

逆向流程分析

  1. WASM 加密验证机制
    从代码中可以看到核心验证逻辑:

// 关键加密参数

const timestamp = Math.floor(window.get_timestamp() / 1000).toString();

const verifyString = ${type}_page_${page};

const wasmAuth = window.encrypt_simple(verifyString, timestamp);

// 请求参数

url += &wasm_auth=${encodeURIComponent(wasmAuth)};

headers['X-WASM-Timestamp'] = timestamp;

headers['X-WASM-Page'] = page.toString();

关键点:

verifyString 格式: {challenge_type}page {page}

encrypt_simple() - WASM导出的加密函数

get_timestamp() - WASM导出的时间戳函数

需要传递 wasm_auth、X-WASM-Timestamp、X-WASM-Page 三个参数

  1. 大致逆向步骤

步骤1: 下载并分析 wasm_anti.js

步骤2: 找到 .wasm 文件的加载逻辑

步骤3: 反编译 .wasm 文件 (使用 wasm2c 或 wabt)

步骤4: 定位 encrypt_simple 函数的算法实现

步骤5: 定位 get_timestamp 函数实现

步骤6: 用 Python 重写加密算法

步骤7: 爬取100页数据并求和

那么第一步就是下载js代码

下载了三个js

然后在anti.js里看到了加载wasm的地方,然后就直接下载了文件

那么下载好文件,要做的就两个事情了

py 复制代码
def encrypt_simple(verify_string, timestamp):
    # TODO: 从反编译的 WASM 中提取加密算法
    pass

def get_timestamp():
    # TODO: 从反编译的 WASM 中提取时间戳逻辑
    pass

由于我暂时还不是很会反编译wasm

我直接拿给ai分析一下

但是ai现在还是不能反编译wasm自动,所以不能一直依赖ai了。。

基于对你提供的 wasm_anti_bg.wasm 文件内容的静态分析(通过字符串和符号表),可以确定该 WASM 模块是使用 Rust 编写的,并且核心逻辑是 AES-128 加密

以下是对该文件的逆向分析结论及对应的 Python 代码实现。

1. 逆向分析结论

  • 编译语言 : Rust (依据: src/lib.rs, core::fmt, alloc::vec 等字符串特征)。

  • 加密算法 : AES-128

  • 文件包含 aes_128aes_encryptsub_bytesshift_rowsmix_columns 等 AES 算法的标准底层操作名称。这表明它可能包含了一个纯 Rust 实现的 AES 算法(而非调用外部 JS 库)。

  • 时间戳逻辑 : 字符串 js_sys::Date::now 表明它调用了 JavaScript 的 Date.now(),即返回 13位毫秒级时间戳

  • 加密模式推测:

  • 由于函数名为 encrypt_simple 且涉及反爬(anti_bg),通常这类 WASM 挑战会使用 AES-128-ECB (最简单,无需 IV)或者 AES-128-CBC(需要 IV)。

  • 密钥(Key)通常由 时间戳 衍生而来,或者是一个硬编码的静态字符串。


所以他还是不知道正常代码是什么样子的。

所以这个时候还是要去解决跳转问题

用插件hook一下跳转

代码被混淆了,做一个替换

拿着代码一通分析,发现关键逻辑在这里:

所以直接把这个函数滞空

滞空之后,可以正常翻页了


然后就去看代码

找到wasm的网络包,进栈

打个断点:

在加密位置打上断点,准备进入

在这里返回:

慢慢来,需要在wasm中单步跟一下,找到真正的加密:

跟到这个部分:

继续往下走:

继续跟到这里,在这里找密钥

在var 400里找到key

  1. 特征分析0xCC 是 C/C++ 编译器在 Debug 模式下填充未初始化栈内存 的经典标志("烫烫烫")。0xC03F... 这种结构看起来像是浮点数或位切片(Bitslice)算法的中间状态。
  2. 参数位置aes128_key_schedule 函数通常有两个参数:Context (输出)Key (输入)
  • 在汇编中:
wat 复制代码
local.get $var7
i32.const 44   ;; 参数 1: 很有可能是输出缓冲区 (Context)
i32.add
local.get $var7
i32.const 400  ;; 参数 2: 很有可能是输入密钥 (Raw Key)
i32.add
call ...key_schedule...
  • 你之前检查的是 44,那是输出结果(或者还没写的脏内存)。
  • 真正的 Key 藏在第二个参数 400 里!
  1. 代码证据
    在调用 key_schedule 之前的几行代码中,程序在疯狂地往 $var7 + 400403407... 写数据。这证明它正在现场拼装 Key

修正:提取真正的 Key

请保持断点在 call ...key_schedule... 不变,在 Console 中执行以下代码:

js 复制代码
// 1. 基地址 (请再次确认当前 Scope 中的 $var7 值,不要直接用旧的)
// 假设还是 1047712,如果变了请修改!
var base = 1047712; 

// 2. 查看偏移量 400 (这是真正的 Key 入口)
var realKeyPtr = base + 400;
var realKeyBytes = new Uint8Array(wasm.memory.buffer).slice(realKeyPtr, realKeyPtr + 16);

// 3. 打印结果
console.log("★ 真·AES Key (Hex):", Array.from(realKeyBytes).map(b => b.toString(16).padStart(2, '0')).join(''));
console.log("★ 真·AES Key (String):", new TextDecoder().decode(realKeyBytes));

最后确认是一个aes加密,有盐值和key

这里我只找到了key,iv推出来的

py 复制代码
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import binascii

# ==========================================
# 🕵️‍♂️ IV 逆向提取器
# ==========================================

# 1. 核心参数 (已通过你的 JS 验证)
KEY = b""

# 2. 浏览器的"正确答案" (以你之前截图的 Page 4 为例)
# 密文: 39d6...
browser_ciphertext_hex = "39d6129e89e5c92e4afc0c516993e35cde4564db0120473cb57be5aa94238b5d"
browser_ciphertext = binascii.unhexlify(browser_ciphertext_hex)

# 3. 对应的"正确明文" (Page 4)
# 截图里 timestamp 是 1768612656
page = 4
timestamp = "1768612656"
plaintext_str = f"wasm_challenge_page_{page}{timestamp}"
# 加上标准的 PKCS7 Padding
plaintext_bytes = pad(plaintext_str.encode(), 16)

print(f"[*] 尝试破解 IV...")
print(f"[*] 使用 Key: {KEY}")
print(f"[*] 明文 Block 1: {plaintext_bytes[:16]}")

# 4. 破解逻辑
# CBC 公式: Cipher = Enc(Plain XOR IV)
# 逆向公式: Dec(Cipher) = Plain XOR IV
# 最终推导: IV = Dec(Cipher) XOR Plain

# 先用 ECB 模式解密 (相当于只做 Dec 这一步)
cipher_ecb = AES.new(KEY, AES.MODE_ECB)
decrypted_intermediate = cipher_ecb.decrypt(browser_ciphertext)

# 取出第一块进行 XOR
block1_plain = plaintext_bytes[:16]
block1_dec = decrypted_intermediate[:16]

# 计算 IV
iv = bytes(a ^ b for a, b in zip(block1_plain, block1_dec))

print(f"\n🎉 成功捕获 IV!")
print(f"👉 IV (Hex): {iv.hex()}")
print(f"👉 IV (Str): {iv}")

# 5. 验证破解结果
print(f"\n[验证] 使用破解的 IV 重新加密...")
cipher_check = AES.new(KEY, AES.MODE_CBC, iv)
token_check = cipher_check.encrypt(plaintext_bytes).hex()
if token_check == browser_ciphertext_hex:
    print("✅ 验证通过!生成的 Token 与浏览器完全一致!")
else:
    print("❌ 验证失败...")
```
相关推荐
kvo7f2JTy4 天前
.NET 11 预览版1:CoreCLR 在 WebAssembly 上的全面集成与性能突破
服务器·.net·wasm
狗都不学爬虫_9 天前
JS逆向 - Akamai阿迪达斯(三次) 补环境、纯算
javascript·爬虫·python·网络爬虫·wasm
小陈工10 天前
2026年3月30日技术资讯洞察:AI算力突破、云原生优化与架构理性回归
开发语言·人工智能·python·云原生·架构·数据挖掘·wasm
小陈工13 天前
2026年3月26日技术资讯洞察:WebAssembly崛起、AI代码质量危机与开源安全新挑战
人工智能·python·安全·架构·开源·fastapi·wasm
七夜zippoe16 天前
WebAssembly与Python:在浏览器中运行Python
开发语言·python·wasm·webassembly·pyscript
爱学习的程序媛17 天前
【Web前端】WebAssembly详解
前端·web·wasm
爱学习的程序媛19 天前
【Web前端】WebAssembly实战项目
前端·web·wasm
REDcker20 天前
Wasm 软解 H.265 方案与原理
wasm·h.265
步步为营DotNet1 个月前
ASP.NET Core 10中的Blazor WebAssembly性能优化实践
性能优化·asp.net·wasm
前端之虎陈随易1 个月前
Vite 8正式发布,内置devtool,Wasm SSR 支持
前端·人工智能·typescript·npm·node.js·wasm