创建: 2024-06-30 16:27
更新: 2024-06-30 19:16
https://scz.617.cn/web/202406301627.txt

WEB前端逆向初学者的若干备忘。

m3u8+ts是视频网站常见套路。大致是混淆js，隐藏m3u8的实际构造过程，下载加密过的m3u8，解密，下载异化过的ts，js还原ts，播放。中间可能动用wasm，也可能不动用，当它是个动态链接库好了，不影响整体流程。下载m3u8的URL可能并无m3u8字样，下载wasm的URL可能并无wasm字样，这些都是常见套路。但Network面板会暴露这些蝇营狗苟，不管下载ts的URL有无ts字样，你看它扑棱扑棱地下，这本身就是强特征，太扎眼，那前面大概率有m3u8下载。从Initiator的调用栈回溯看过去，若没有混淆就放过，谁有混淆谁就是嫌犯，甭管是不是下载m3u8，反混淆调一拨，必有所获。从逆向工程角度看，扎眼的保护措施是逆向目标强指示。

大部分时候对m3u8的保护最强，对ts和wasm的保护一般。若ts经私有异化处理，即便猜中反异化套路，好奇心强的也不大满意，总想看到实实在在的反异化处理代码，用人话说，想在下载ts后调试跟踪到ts后处理代码所在。

参看

《WEB前端逆向随笔》

https://scz.617.cn/web/202406251509.txt

常规套路是拦截XHR或Fetch，拦请求。若是Fetch，直接在代码下方找then之类的块。若是XHR，假设是h.send()，在h中找onreadystatechange之类的，设断，命中。这两种情形对于调试者无需区分什么，后面只说XHR的情形，就从onreadystatechange说起。从这儿开始单步，就比较扯淡了，有些复杂的，基本绕晕。但我们只关注ts后处理不是？而且你碰到的，是不是大概率用到HLS的某个js？假设叫hls.js吧。

在HLS (HTTP Live Streaming)中，demux是demultiplexing(解复用)的缩写。解复用是指将多路复用的媒体流(包含视频、音频、字幕等不同的媒体轨道)分离成独立的轨道，以便进行进一步处理或播放。这GPT忽悠我的，要点是，demux与ts后处理相关。

在hls.js中直接搜"demux"，可能有多个命中，找一个形如这种的:

x.postMessage({
    cmd: "demux",
    /*
     * data是加密状态的ts
     */
    data: t,
    /*
     * decryptdata这种key名很扎眼
     */
    decryptdata: m,
    ...
})

形如这种的命中应该只有一个，这就是要开始处理ts了。在这儿设断，命中，调用栈回溯，有些复杂的，离onreadystatechange可远了，中间某些帧不是单步可以抓住要点的。在postMessage处F11 Step into，之后在Page中能看到一个新增的blob，在Network面板Name列会看到:

blob:https://…

blob的名字是个uuid，刷新后会变，其Type列是"text/javascript"，这种是从内存动态加载的js，不走网络，ts后处理代码就在这种blob中。blob的源一般在hls.js中，但执行的是blob中的副本，而不是hls.js中的源。可在blob创建之前修改hls.js中的源，间接修改blob中的副本。拦截"URL.createObjectURL"，查看调用栈回溯，定位blob创建代码。

Network面板看到blob，其前面那个请求一般是下载第0号ts。

可以调试blob中的代码。但没必要傻单步。在blob中继续搜"demux"，会有个命中:

case "demux":

这个对应前面的

cmd: "demux"

在case处设断，执行，命中，从case处单步，这个时候就简单多了，不太可能绕晕。一般单步一会儿就能找到ts后处理代码，比如ts伪装成png时，去png头，比如ts经AES加密过，需要AES解密。找到ts后处理代码时，可以查看下载回来的原始ts数据，可以查看用于AES的key、iv等数据。它用的AES解密代码不一定是外部js库提供，可能就是blob中内置的完整的AES算法函数，可查看in/out，与"CyberChef/AES Decrypt"对一下。其他形式的ts后处理代码，理论上也能用这个办法快速定位，没碰上过，不好说。

我第一次碰上"demux"，是ts伪装png头，虽然我找到了ts后处理代码，当时并不知道换一种ts异化处理该如何快速定位ts后处理代码，对HLS这些完全不了解。不过我有个记录调试过程的习惯，并不只记录调试结论，所以当时一些单步经过的点、一些调用栈回溯，我都记在TXT中。过了些日子，在另一个测试案例中碰上AES加密ts，我就合理推测，可能当时记录的内容中，有些关键点在新案例中同样存在。搜了搜postMessage，有好几个命中，当时没有意识到那只是不同cmd的postMessage，但在肉眼遍历时看到cmd为"demux"的postMessage，这就新旧对上了。接下来就好办了，设断，验证一下调用栈回溯，是不是大体类似。快速找到AES解密代码后，问GPT，demux有啥特殊，GPT给我一通忽悠，进一步对上。

逆向工程的许多东西，说穿了就两句话，说穿后一钱不值，没说穿前，难者不会。但有些东西，你说穿了千百遍，看客也未必明白真正的要点在哪里。上面这段，我说的不是ts后处理的事儿，我说的是方法论。