ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

my-tv 央视频请求加密解析:你每换一次台,都在偷偷算签名

my-tv 央视频请求加密解析:你每换一次台,都在偷偷算签名 my-tv 央视频请求加密解析你每换一次台都在偷偷算签名【免费下载链接】my-tv我的电视 电视直播软件安装即可使用项目地址: https://gitcode.com/GitHub_Trending/my/my-tv你在 my-tv 上按下换台的瞬间应用已经在本地算好加密签名再塞进发给央视频服务器的请求里。这套流程平时看不见却是整个 App 能不能正常出画面的关键。它到底在帮你解决什么如果你打开过抓包工具会注意到一个现象my-tv 并不是把频道地址直接甩给服务器而是每次都带上一串 cKey、signature 这样的字段。说白了央视频这套接口是有验货环节的——请求里少一个字段、或者签名对不上服务端就直接不给你流地址。Encryptor 负责的那块就是替应用把这些防伪凭证算好的人。背后是怎么跑起来的这块其实没你想的复杂拆开看就三层。第一层算法为什么藏在 .so 里Kotlin 这边的 Encryptor 其实是个空壳init、encrypt、hash、hash2 四个方法全标了 external真正干活的是 cpp 目录里按架构分好的 libnative.so。你可以把它理解成算法本体用 C 写死、编译进二进制库Kotlin 只负责喊一声帮我算。这样即使有人反编译 APK也只能看到一串调用翻不到里面的具体运算。第二层cKey 和 signature 是怎么拼出来的每次换台YSP 先备齐几个原料频道号 cnlid、当前时间、版本号、设备 guid、平台号再随手造一个 10 位的 rand_str。这些原料先喂给 encrypt 生成 cKey同时把全部字段按固定顺序拼成一个查询串交给 hash 得到 signature。换句话说cKey 说明我要看哪个台signature 说明这个请求没被中间人改过。// 换台请求里这两个字段全靠 Encryptor 算出来 val cKey encryptor.encrypt(cnlid, timeStr, appVer, guid, platform) val signature encryptor.hash(按固定顺序拼好的字段串)第三层guid 和 rand_str 这两个防伪细节guid 是应用生成的设备指纹首次写入 SP 后一直复用让服务器认得这是同一台电视。而 rand_str 和 timeStr 每次请求都换新作用就是防重放——有人就算截获了一次请求隔段时间重发也会因为对不上被拒。跟着走一遍打开 my-tv进到一个央视频频道。按遥控器上的下一频道应用读到新的 cnlid。本地调用 encrypt 和 hash当场算出 cKey 与 signature。连同 guid、rand_str 一起打包成 JSON 发给服务端。验签通过返回流地址画面就出来了。几个值得留意的细节它并不是密码锁。单看 Encryptor 这个名字很容易联想到应用锁、存密码但 SP 里实际只存了频道设置和设备 guid没有任何密码字段——这层真正干的是给央视频请求做加密和签名。加密底座大概率是 OpenSSL。cpp 目录里躺着 libcrypto、libssl 的 .so 和一整套头文件应用基本是拿现成的 OpenSSL 来算而不是自己手写算法。两套 hash 各管一摊。hash 负责换台主请求的 signaturehash2 负责那串更短的鉴权签名职责不混用。算法本体看不到源码。到底是哪种哈希、encrypt 走的哪套密钥都封在二进制里只能从调用处反推用途。想看清这套签名到底怎么算的与其读文章不如把 YSP.kt 从头到尾捋一遍那里是整套逻辑的总开关。【免费下载链接】my-tv我的电视 电视直播软件安装即可使用项目地址: https://gitcode.com/GitHub_Trending/my/my-tv创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表