今天，一Py哥们为民除害爬取某色情网站的时候，遇到了一点点小问题，关于色色电影列表中视频封面数据的问题，我简单的看了一下，我也是第一次见到这种，挺有意思的封面图片渲染，所以单拉出来我们一起来看看！

图片地址SRC

简单逆向某色情网站图片加密

审查元素查看图片地址是 Base64 地址，并不是网络地址，不会被墙，根据用户网速加载，不占用服务器带宽，挺好的。控制台的数据是没有任何问题的，然后又看了一下源代码。

IMG标签中的Origanal数据

简单逆向某色情网站图片加密

我从源代码中查看 IMG 标签并没有发现 SRC 属性，但是看到了一个有意思的属性，data-origanal，直觉告诉我，这个数据并不简单，然后我分页加载了一下视频看到加载图片时会加载data-origanal对应的TXT文件。

简单逆向某色情网站图片加密

当我打开TXT文件看了一下其中的数据，第一眼的感觉就是Base64加密数据，呀，太简单了，肯定是图片的Base64地址，我立马和封面的Base64图片地址对比一看，一点都不一样！我又想了一下，难道是图片地址再Base64了一下？然后我继续Base64解密了一下。

简单逆向某色情网站图片加密

乱七八糟，这不是Base64数据，那肯定就是AES加密咯，一个色情网站怎么还花里胡哨！

JS文件简单剖析

简单逆向某色情网站图片加密

全局搜索了一下 data-origanal 和 origanal关键词，，发现了其中一个文件并找打了有关的函数，利用Ajax请求获取TXT文静中的数据，然后并传入一个函数进行解密。

简单逆向某色情网站图片加密

继续搜索关键词 desDecrypt 找到了一个eval加密JS文件。

简单逆向某色情网站图片加密

简单解密了一下，取到了原始函数,截取我们主要用到的两个函数，一个加密，一个解密，如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 秘钥
let asc_key = "jeH3O1VX";
let base_lv = "nHnsU4cX";
// 加密
function desEncrypt(a) {
  let tmpiv = CryptoJS.enc.Utf8.parse(base_lv);
  let key = CryptoJS.enc.Utf8.parse(asc_key);
  var b = CryptoJS.AES.encrypt(a, key, {
    iv: tmpiv,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7,
    formatter: CryptoJS.format.OpenSSL,
  });
  return b.ciphertext.toString(CryptoJS.enc.Base64);
}
// 解密
function desDecrypt(a) {
  a = a.replace(/\s*/g, "");
  let tmpiv = CryptoJS.enc.Utf8.parse(base_lv);
  var b = CryptoJS.enc.Utf8.parse(asc_key);
  var c = CryptoJS.DES.decrypt({ ciphertext: CryptoJS.enc.Base64.parse(a) }, b, {
    iv: tmpiv,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7,
    formatter: CryptoJS.format.OpenSSL,
  });
  return c.toString(CryptoJS.enc.Utf8);
}

简单逆向某色情网站图片加密

10.png

执行函数并调用了一下解密函数，手动传入了TXT文件中AES加密的数据，并取到了封面图片IMG标签的SRC地址。

个人看法

从文件数据的加密解密还是JS中关键函数的eval加密来说，整体流程走下来，没有任何难度，连麻烦都算不上，怎么说呢，他是用心了还是没用心，我也说不上来。但这个图片渲染的方式我还是第一次见。
如果这个加密如果是为了防爬，我个人认为简直太弱了。
从图片地址加密前后对比来说，加密后的图片地址，也就是TXT文件中的数据比原始图片地址数据大了好多，是挺鸡肋的。

总结

今天发现了一个挺有意思的小东西~