粉碎你的使用说明书

前几天被别人安利了这个玩意儿 ((制作你的说明书), 打算看看到底是什么货色

其实被各种社交网站刮风搞得有点谜了, 但是看巨佬 @xmcp 有一段时间一刮风就去挖人家老底的操作还是很羡慕的, 所以这次就跟一波风批判一下搞出这个使用书生成器的网易云音乐

网址链接中间有一个随机 ID, 多半是用来检测是谁分享的链接用的, 现在把一个 sample 挂在这里:https://st.music.163.com/c/m2-spec/1abCDEFghi/index.html

万年不变的 PC 歧视

首先是各种防止电脑用户登陆, 不过这里可以 override 一个 User-Agent 直接 bypass 掉:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Mobile Safari/537.36

(果然只是检测 User-Agent 呢)

(常规操作系列)

蜜汁响应式布局界面

这里多半是没考虑到窄屏用户 (没错, 说的就是你, 刘海屏) 或者宽屏用户的需求, 所以一旦把布局拉到立式宽屏之外的范围画面直接崩坏...... 当然, 有一个起码的响应式布局我们还是要称赞一发的 (雾)

另外顺便吐槽一下直接把文字嵌在图片里的操作 (不过这确实避免了不少布局问题)

Off-topic: 机智的 React 作者

在 vendor.ac146652.js 里面放的大概是 React 框架, 不过感觉 React 的开发组很皮 (不是我开玩笑, 是真的很皮)

// Lines 10442 - 10445
Vr = bn.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.ReactCurrentOwner,
zr = [],
Br = !0,
Wr = void 0,
// Lines 11355 - 11366
unstable_createPortal: yn,
unstable_batchedUpdates: Z,
unstable_deferredUpdates: ci.deferredUpdates,
flushSync: ci.flushSync,
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED: {
    EventPluginHub: rr,
    EventPluginRegistry: Xn,
    EventPropagators: cr,
    ReactControlledComponent: Nr,
    ReactDOMComponentTree: ur,
    ReactDOMEventListener: Kr
}
// Lines 11655 - 11660
isValidElement: l,
version: "16.2.0",
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED: {
    ReactCurrentOwner: M,
    assign: m
}

用了这个参数就会被炒鱿鱼吗......

探究测试的机理

业务代码一共有 23336 行, 我数过了, 但是感觉都是机器生成的...... 大概

1. vendor.ac146652.js
2. vendor.ac146652.deobfs.js
3. bundle.3f3bfd35.js
4. bundle.3f3bfd35.deobfs.js

提交名称

// Lines 12245 - 12291
value: function () {
    var e = this.props,
        t = e.handleNameChange,
        A = e.handleNextCard,
        n = this.state.userName;
    if (!n) return void(0, h.ShowToast)({
            key: "empty",
            type: "center",
            isOk: !1,
            text: "请先输入名字",
            autoClose: !0
        });
    for (var r = 0, i = 0; i < n.length; i++) g.test(n[i]) ? r += 2 : r++;
    if (r > 16) return void(0, h.ShowToast)({
            key: "empty",
            type: "center",
            isOk: !1,
            text: "请不要超过8个字哦",
            autoClose: !0
        });
    var o = (0, d.
    default)("/api/activity/antispam/keyword/nickname/check", {
            method: "post",
            async: !1,
            data: {
                content: n
            }
        });
    try {
            o = JSON.parse(o.request.responseText)
        } catch (e) {
            console.log(e)
        }
    o && o.data ? (t(n), A()) : o && 0 == o.data || o && 407 == o.code ? (0, h.ShowToast)({
            key: "empty",
            type: "center",
            isOk: !1,
            text: "换个昵称试试?",
            autoClose: !0
        }) : (0, h.ShowToast)({
            key: "empty",
            type: "center",
            isOk: !1,
            text: "操作失败，请重试",
            autoClose: !0
        })
}

你的名称会被提交到 /api/activity/antispam/keyword/nickname/check 以检查是否为恶意行为. 我们发现, 将名字提交的过程中, 个人信息是通过一个密钥加密的, 所以基本上可以认为避开了中间人攻击 (关键其实在于 SSL).

在线 / 离线

在分析网络活动的过程中我们也发现, 所有的资源都被分配到了网易的 CDN 上.

不过既然姓名要提交服务器审核那干嘛不顺带把结果也收回去, 至少在大数据时代多收集点信息, 可以优化一下服务质量广告推送啊......

↑ 其实那个是应该签隐私协议的, 所以还不如不收集这个信息

事实上, 添加完昵称以后, 包括最后的图片生成在内的的整个流程全部是在本地做的.

判定规则

在第 14312 到第 15103 行之间的代码描述了所有可能输出的判定, 并给了相应的规则.

然后依据直觉, 我们在第 13232 行找到了祖传的麦斯 · 兰敦姆 Math. random () 大法, 成功通过这名 20 世纪末诞生的伟大数学家的大名找到了程序的奥妙所在 (弥天大雾)

可以看出, 这里的规则和判定输出规则还是比较复杂的.

先试图定位到在函数中经常出现的一个邪恶家伙 H:

// Lines 15171 - 15181
    t.
default = {
            spec: n,
            l1: r,
            l2: i,
            qss: a,
            foodie: o
        },
    e.exports = t.
default
},

这段代码将刚才的判定内容定义为 H.default.spec, 之后看到这一组关键字直接找到这里就可以了.

// Lines 13224 - 13226
n.forEach(function (e) {
        e.a === t[e.q - 1].decent ? r++ : e.a === t[e.q - 1].foodie && i++
    });

上段代码直接表示了判分规则, 然后在下面找一下选取规则, 就有了下文的结论:

获取题目

抓包完了很快就能定位到资源列表, 然后跑一波正则表达式

直接上爬虫 (人力 OCR 是真的累)

import re
import requests


with open('po.txt', 'r', encoding='utf-8') as f:
    ls = f.read().split('\n')
for l in ls:
    num, sel = re.findall(r'answer/(\d+)/(.)\.', l)[0]
    r = requests.get(l)
    with open('./out/%s-%s.png' % (num, sel), 'wb') as f:
        f.write(r.content)
    print(num, sel)

结论

题目

一共有 16 道题, 每道题有一个正确答案 (大概是判定情商用的吧) 和一个吃货答案 (吃货答案选的数量超过一个值以后就会认为你是一个吃货), 具体在下表中呈现, 其中各列分别代表:

• index: 题目编号
• decent: 正确答案, 留空代表没有 (没有也是醉了)
• foodie: 吃货答案, 留空代表没有
• A, B, C: 分别代表三个选项的内容

判分规则

小程序会给你计算两个参数, 分别代表 6 道题目中正确答案的数量和吃货答案的数量. 不妨设:

• adec: 正确答案数量
• afoo: 吃货答案数量

输出内容

下表为所有的判定依据, 其中各列分别代表:

• index: 判定编号
• val: 最后输出的内容, XXX 用他或她代替
• level: 该类人群的情商级别
• tag: 有些判定只适用于特殊人群, 值为空 / 吃货 / 幽默
• fm: 选项适用的性别
• not: 该项判定不能和编号为 \(\{x | x \in not\}\) 的同时存在
• r, candi: 有 r 的概率第二项和第三项都会从 candi 里抽选

以上的判定被分为三类 (有交集), 分别为:

生成流程

第一条: 程序会从 L2 中不断随机选取判定直到满足以下两条件之中至少一个:

1. 当正确答案数 adec 不少于 5 个时, 判定标签为 “幽默” 的判定
2. 该项 fm 值为 1 且用户性别为女的判定

第二条: 程序会以一定的概率分配从以下分组中选取:

1. 若第一条的 candi 非空, 则有 r 的概率 (通常为 0. 3) 直接从 candi 中取
2. 当吃货答案数 afoo 不少于 1 个时, 有 0. 7 的概率从 Foodie 中取
3. 有 0. 2 的概率将从 L1 中取
4. 剩下的一定取自 L2

随机取出的判定应满足以下判定:

1. 和第一条天生不冲突 (互不在对方的 not 集合中), 也不相同的判定
2. 当正确答案数 adec 不少于 5 个时, 判定标签为 “幽默” 的判定
3. 该项 fm 值为 1 且用户性别为女的判定

第三条: 程序会以一定的概率分配从以下分组中选取:

1. 若第一条的 candi 非空, 则有 r 的概率 (通常为 0. 3) 直接从 candi 中取 (该事件与第二条的事件相互独立)
2. 有 0. 5 的概率将从 L1 中取
3. 剩下的一定取自 L2

随机取出的判定规则基本与第二条的规则相似.

最终输出

随机几个背景颜色然后堆一个 canvas 出来, 由本地生成一个 data blob 显示到屏幕上. 其中还需要做一点小小的替换, 不过都无所谓了.

吐槽

不得不说这个小程序写得还是比较有意思的. 但是其实这类分享类应用基本套路都一样, 后面是不是有批量生成器都不是很好说.

通过我们严密的分析, 发现在前面 6 道题内做的选择与最后具体的结果几乎没有关系. 于是并不像我们所预想之程序员真正兢兢业业地把每个性格的特点写在代码里, 反而是偷懒地使用麦斯 · 兰敦姆 Math. random () 大法来掩盖自己没好好写代码的事实 (笑).

另外代码里各种神奇的操作, 比如用 !0 代替 true 一类的, 抑或是用 for 或者 lazy evaluation 强行缩行...... 或许这些都是业界常态但是我太 naive 没看到吧.

之前看 @xmcp 分析的另一个朋友圈刮风小程序, 大抵也是相同的套路. 考虑到这次作者读代码读到吐的情况, 下次也许对这类事情我就敬而远之了吧.

总之, 占卜这种玩意儿, 顶多是学园祭的特色, 若是在日常生活中出现, 大家便也娱乐一下就好, 切勿当真~