某云神秘的追踪参数

逆向复健一下

之前发现网易云的分享参数里有名为userid=xxxxxxx的参数，里面是分享者的用户 ID，但在某一次更新后取而代之的是uct2=xxxxx，像是加密的样子：

PC 端：https://music.163.com/playlist?id=8416733444&uct2=U2FsdGVkX18I0qiX738+CD1FdOh+w/CByAqGXtw/rt8=

手机端： http://163cn.tv/ByX1EOw

虽然网上已经有现成的工具：找到 TA

但因为其并未公布算法，也可能存在数据安全的问题，就想自己动手造一个平替（）

两者都是链接，但其加密算法不同，因此可以通过 uct2 的不同特征来确定对方的分享平台和用户 ID，下面将分别解析一下两端的 uct2 算法：

手机端#

手机端有时复制出来的是短链（http://163cn.tv/，会跳转，包含其他跟踪参数），而电脑端访问会跳转后地址栏闪过 uct2 后继续跳到没有 uct2 的网站，这里通过 curl 获取跳转目标：

1
$ curl -v http://163cn.tv/ByX1EOw
2
* Host 163cn.tv:80 was resolved.
3
* IPv6: (none)
4
* IPv4: 198.18.1.58
5
* Trying 198.18.1.58:80...
6
* Connected to 163cn.tv (198.18.1.58) port 80
7
* using HTTP/1.x
8
> GET /ByX1EOw HTTP/1.1
9
> Host: 163cn.tv
10
> User-Agent: curl/8.10.1
11
> Accept: */*
12
>
13
* Request completely sent off
14
< HTTP/1.1 302
15
< Server: nginx
16
< Date: Fri, 31 Jan 2025 07:58:59 GMT
17
< Content-Length: 0
18
< Connection: keep-alive
19
< Cache-Control: no-store
20
< Pragrma: no-cache
21
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
22
< Cache-Control: no-cache
23
< X-Application-Context: application:8888
24
< Location: https://y.music.163.com/m/song?id=2668595321&uct2=%2BhNMiP%2FRMJxgbE5ka%2FgRkw%3D%3D&fx-wechatnew=t1&fx-wxqd=c&fx-wordtest=t3&fx-listentest=t3&H5_DownloadVIPGift=&playerUIModeId=5623502&PlayerStyles_SynchronousSharing=t3&dlt=0846&app_version=9.2.45&sc=wm&tn=
25
< X-From-Src: 114.93.71.49
26
<
27
* Connection #0 to host 163cn.tv left intact

Location里的 uct2 就是我们要找的东西。

首先通过 Jadx（类似工具有 ReCaf 等）反编译网易云音乐客户端通过搜索 uct2 得到相关代码（部分代码已删除）：

1
   public static final void o(Context context, Program program, String platform, Function1<? super com.netease.cloudmusic.share.framework.e, Unit> callback) {
2
        String string;
3
        com.netease.cloudmusic.share.framework.e eVar = new com.netease.cloudmusic.share.framework.e();
4
        eVar.f120920a = String.valueOf(program.getId());
5
        eVar.f120922d = context.getString(ir1.j.f228957m3, program.getName());
6
        eVar.f120924f = (!program.needShowFeeTag() || TextUtils.isEmpty(program.getReason())) ? program.getBrand() : program.getReason();
7
        eVar.f120928j = program.getCoverUrl();
8
        eVar.f120921b = 1;
9
        eVar.f120937t = 3;
10
        eVar.f120934q = program;
11
        long u15 = ap.a.m().u(); // 返回用户ID
12
        String b15 = com.netease.cloudmusic.utils.d.INSTANCE.b(j() /* 生成加密密钥 */, String.valueOf(u15)); // 生成加密的用户ID b15
13
        if (b15 == null) {
14
        // 生成出错的话就 fallback 到原本的 userid ，机制不清
15
            string = Intrinsics.areEqual(platform, "sina") ? ApplicationWrapper.getInstance().getString(ir1.j.f228886a4, dp.f124165c, 17, Long.valueOf(program.getId()), Long.valueOf(u15), 0) : ((ILinkConfig) ServiceFacade.get(ILinkConfig.class)).urlStringForKey("program_share", "id", String.valueOf(program.getId()), "userid", String.valueOf(u15), "djId", String.valueOf(program.getDj().getUserId()));
16
        } else {
17
            string = Intrinsics.areEqual(platform, "sina") ? ApplicationWrapper.getInstance().getString(ir1.j.f228930i0, dp.f124165c, 17, Long.valueOf(program.getId()), URLEncoder.encode(b15, Charsets.UTF_8.name()), 0) : ((ILinkConfig) ServiceFacade.get(ILinkConfig.class)).urlStringForKey("program_share", "id", String.valueOf(program.getId()), "uct2", b15, "djId", String.valueOf(program.getDj().getUserId()));
18
            //将uct2作为分享链接的参数使用 (uct2=xxxxxx)
19
        }
20
        if (Intrinsics.areEqual(platform, "sina")) {
21
            eVar.f120924f = ApplicationWrapper.getInstance().getString(ir1.j.W3) + " " + string + " " + ApplicationWrapper.getInstance().getString(ir1.j.f228917g);
22
        }
23
        eVar.f120933p = string;
24
        eVar.f120929l = string;
25
        eVar.f120930m = com.netease.cloudmusic.module.spread.e.f(program.getMainSong().getId());
26
        if (!Intrinsics.areEqual(platform, "sina")) {
27
            String b16 = kp.b(NeteaseMusicApplication.getInstance());
28
            eVar.f120933p = eVar.f120933p + "&app_version=" + b16;
29
            eVar.f120929l = eVar.f120929l + "&app_version=" + b16;
30
        } else if (!com.netease.cloudmusic.share.framework.j.f120943a.c()) {
31
            eVar.f120926h = "";
32
            eVar.f120928j = "";
33
        }
34
        eVar.f120926h = "";
35
        callback.invoke(eVar);
36
    }

占掉我 30 多 G 内存，加上原本就已经红了的 D 盘里还要塞个分页文件

看到是 b15 赋值给了 uct2 ，u15 是咱的用户 id，所以就应该有办法从 uct2 转成原本的 id，先看加密部分，反编译得到 b 函数内部（代码经过处理）：

1
private final String encode(byte[] data) {
2
    return Base64.encodeToString(data, 2);
3
}
4

5
// 加密函数，AES/ECB算法
6
public final String b(String secretKey, String data) {
7
    try {
8
        byte[] bytes = secretKey.getBytes(Charsets.UTF_8);
9
        SecretKeySpec secretKeySpec = new SecretKeySpec(bytes, "AES");
10
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
11
        cipher.init(1, secretKeySpec);
12
        byte[] bytes2 = data.getBytes(Charsets.UTF_8);
13
        byte[] doFinal = cipher.doFinal(bytes2);
14
        return encode(doFinal);
15
    } catch (Exception e) {
16
        e.printStackTrace();
17
        return null;
18
    }
19
}

关于加密密钥的是 j 函数，其被调用时返回一个静态单例 Lazy 对象，内部存储的是加密的字符串：

1
private static final Lazy f298165f = LazyKt__LazyJVMKt.lazy(a.f298166a);
2

3
// KT生成的嵌套类
4
static final class a extends Lambda implements Function0<String> {
5
    public static final a f298166a = new a();
6
    a() {
7
        super(0);
8
    }
9

10
    @Override
11
    public final String invoke() {
12
        return (String) ((ICustomConfig) ServiceFacade.get(ICustomConfig.class)).getAppCustomConfig("IuRPVVmc3WWul9fT", "JwDUI7QfKebyIhZwcWAJu1172eV2CgCD", "share#id_encrypt_key"); // 返回加密的字符串，默认值为JwDUI7QfKebyIhZwcWAJu1172eV2CgCD
13
    }
14
}

一开始以为又是什么逆天加密算法，最后发现他们的配置名就是一串 base64 了的随机数

通过/assets/default_custom_config_IuRPVVmc3WWul9fT.json可以找到这个配置文件里的加密密钥也是JwDUI7QfKebyIhZwcWAJu1172eV2CgCD

那么理论存在，实验开始——

这里看到原本的 uct2 已经被成功解出来了~

电脑端#

通过观察电脑端的 uct2，b64 解出来均以Salted__开头，难不成手机电脑算法不一样？？

PS：Salted__ 是 crypto-js AES 加密加盐的特征本来想着还要碰反汇编，现在一点也不用（本人反汇编水平不咋）

下面通过 BetterNCM 打开控制台并搜索share#id_encrypt_key、uct2等字段，发现他们工程师直接把代码放在orpheus://orpheus/pub/hybrid/app~subApp.chunk.601020.js里边了，这边放上核心加密代码：

1
function share(e, t) {
2
  let { payload: n } = e,
3
    { select: i, call: o } = t;
4
  return (function* () {
5
    const {
6
        platform: e,
7
        type: t,
8
        title: a = "分享",
9
        id: s = 0,
10
        data: u,
11
        threadId: p,
12
      } = n,
13
      f = yield i((e) => e.host),
14
      v = y.a.configFromRequest$.getValue(),
15
      m =
16
        (null === v || void 0 === v ? void 0 : v["share#id_encrypt_key"]) || "", // 也是从配置文件里获取加密密钥，获取到的也是JwDUI7QfKebyIhZwcWAJu1172eV2CgCD
17
      b = f.uid || "", // 用户ID
18
      g = m && b ? d.a.encrypt(b, m, { mode: h.a }).toString() : b, // 加密用户ID，否则fallback
19
      Q = {
20
        [k.b.playlist]: "playlist",
21
        [k.b.audio]: "djradio",
22
        [k.b.album]: "album",
23
        [k.b.mv]: "mv",
24
        [k.b.user]: "user",
25
        [k.b.artist]: "artist",
26
        [k.b.article]: "topic",
27
        [k.b.video]: "video",
28
        [k.b.voice]: "dj",
29
        [k.b.track]: "song",
30
        [k.b.topic]: "activity",
31
      }; // 分享类型 // 生成分享链接
32
    let O = "";
33
    (O =
34
      g !== b
35
        ? "https://music.163.com/"
36
            .concat(Q[t], "?id=")
37
            .concat(s, "&uct2=")
38
            .concat(g)
39
        : "https://music.163.com/"
40
            .concat(Q[t], "?id=")
41
            .concat(s, "&userid=")
42
            .concat(g)), //fallback
43
      e;
44
    return !0;
45
  })();
46
}

可以看到流程与安卓端差不多，but 加密算法有点不一样！

通过动态分析在 encrypt 处下断点发现加密函数这里的 d 和 h 就是 CryptoJS 的实例，整理后加密算法是这样：

1
CryptoJS.AES.encrypt(userID, key, { mode: CryptoJS.mode.ECB }).toString();

相应的就能推出解密算法：

其实正常走流程的话要走 webpack 的老路，这边直接拿 CryptoJS 上了

1
CryptoJS.AES.decrypt(encryptedID, key, { mode: CryptoJS.mode.ECB }).toString(
2
  CryptoJS.enc.Utf8
3
);

某云两端加密算法不一样有点想笑，但这可能是检测的某种手段（？）而且发现了有关 config 云控的一些字段，会不会有那种情况的可能？

总结#

这种跟踪参数搞对称加密确实比较容易破，双端用的都是解释型语言，对技术的门槛确实比较低，希望大家新的一年天天被视奸手撕加密算法疯狂 deobf 万事如意！！！！