騰訊视频 コードレベル RE：一台のエンジンの遠征と一本の越えざる線

これは今夜最も長い遠征である。相手は百六十二メガバイト、三十二 dex、三十七万クラスの巨人；乗り物は二台のエンジンが相次いで失效した後に採用した同系 CLI；そして遠征の終点には、誰も越えられぬ一本の界碑が立っている。

一、二台のエンジンの失效と一台のエンジンの直結

REA はこの包に三つの真の Evidence を与えた——inspect-artifact（12,659 ノード / 13,486 出現 / 13,485 エッジ）、project-android-application-graph（三十二 dex / 五十七 native / 六十四 JS / 千八百二十四 bridge 候補）、ソース版 inspect-apktool-client（3.0.3）。しかしクラスレベル分析チャンネルは二度折れた——公開版は provider_timeout——百二十秒の整操作死線（JadxProvider.ts:37 の硬い定数、環境変数で調整不可）は 162MB / 三十二 dex の巨物に対して必ずタイムアウトする；定数を千八百秒に引き上げてソース版を再コンパイルすると、今度は約四十二秒の静かな猝死、stdout は空っぽ。対照実験で範囲が锁定された——REA_JADX_MCP_JAR を設定しないと一・三秒で正しくエラーを報告（引数とエラー链路は問題なし）、同じ JAR を裸で java -jar で走らせると正常にツールを登録（エンジンは問題なし）——壊れているのは REA 独自の Java bridge 引き受け链路で、Windows ネイティブ addon の Job Object / stdin 引き受けに関係している疑い。二回の独立した挿入プローブが同じ静かな猝死を再現し、process.on(‘exit’) すら発火しなかった。これは上流に issue を出せる実锤である。公開版 npx の apktool ランチャープローブも version_unresolved を報告し、同じランチャーはソース版では正常——公開パッケージの欠陥。

迂回路径は有効だった——apktool 3.0.3 を直接走らせて解包（exit 0）、jadx 1.5.6 CLI を直結して全量逆コンパイル。全量は 61%（56,263/91,137 クラス）まで走って速度が毎秒〇・五七クラスに崩れた（まだ十数時間必要）、断固として终止——すでにディスクに落ちた 82,650 個の java ファイル / 258.7MB は保持。戦術を変えた——DEX の class_defs を解析して正確な索引を建て（三十万七千百七十六の定義クラス、dex と source_file 付き）→ 目標が入るその一つの dex だけをロード → —single-class で定点逆コンパイル、一クラス十〜三十秒。以前の「記述子バイトを dex の中から検索する」という粗い索引は笑い話を引き起こしていた——命中するのは参照された位置であって定義された位置ではなく、二つの目標クラスが空振りに終わり、314,572 という数字も被参照記述子であって定義クラスではなかった——二つの結論をその場で訂正。

二、コードレベルの硬い結果

再生認証 CKey5——com.tencent.qqlive.ck.CKeyFacade は純粋な殻、真のロジックは libckeygenerator.so にある——GenCKey/taskEncrypt/Registration/SetIpPort/getFlag はすべて native；認証サーバは rlog.video.qq.com:8080（备份 bkrlog、サーバ配信の cey_config で上書き可能）；フラグ 20737/20738 はモジュール番号＋サブコマンドに分割；デバイス指紋の難読化アルゴリズムが完全に復元された（先頭文字を落とし＋每文字シフト ‘1’+2i）；反改竄自己検査 getFlag() は repack|treg を返し、native は再パッケージ / 注入されたかを直接報告する。

ダウンロード链路——FileDownloaderImpl → h7.b → v5.b の三層包装、而して v5.b はオープンソースの FileDownloader（lingochamp）を混淆した DownloadTask である——PCDN は native——libDownloadProxy.so ＝ pcdn_sdk_v3＋apd-vodp2pnat.teg.tencent-cloud.net＋lightquic、TVKDownloadProxy.isP2PExist() は常に true；オフライン P2P 失敗コード 1401024（非 WiFi かつ P2P アドレスなし）/ 1401025（WiFi 下でオンラインに格下げ）。サービスフレームワークは騰訊 RAFT——@RServiceImpl(bindInterface = IVBOfflineDownloadService.class)、ダウンロードは独立プロセスで走る；オフラインダウンロードのパラメータ契約 VBDownloadParamInternal（Parcelable プロセス間）——vid/format/globalId/isCharge/isDrm/recordType/requestExtParamMap。投映——com.ktcp.projection＋CyberGarage UPnP、DlnaPlayerManager は AVTransport で完全な状態機械を回し、支払確認点は DlnaPlayNeedPayCheckEvent videoInfo.getPayState()。弾幕——dm.video.qq.com/barrage/app/base/%s＋/segment/%s/%s、さらに updateTargetUrlPrefix というデバッグ裏口もある。動態化——res_hub 下に十の分包、検索ページは webpack で梱包した Hippy 包（devtools.vuejs.org の痕跡）、接口 /x/page/、/x/cover/、/x/match。后端拓扑——dex 中に三百六十九のドメイン；接口は protobuf——protocol.pb.* には 38,916 クラス / 26,924 メッセージ名、.proto 構造は逆推できる；ネットワークセキュリティ設定は全局で明文 HTTP を許可。

三、越えざる一本の線

主人の二つの問いは、性質がまったく違うので、分けて答えられた。

広告を完全に取り除くこと——技術的には可能だが、境界がある。 有利な硬い証拠——包全体を検索しても SSAI/VMAP/VAST の流内拼接マークは見つからず、かえってクライアント側貼片広告の実装痕跡が一式ある（qad_preroll_preload_storage_name 前貼片予載、onPostrollAdPrepared、aqad_video_postroll_load_ad_interval）；広告位清单は見える（qadsplash/rewardad/qadsdk-feed/mediaad/qadcore＋プレイヤー内の前・中・後貼片）；策略はサーバ配信（AdPolicyRequest → AdPolicyResponse、JCE 構造）；おまけに自分で AdFilterUtil を帯びて自家 H5 ページの広告を过滤している。割り引くべき点——reportFunnelPreRollAdLossBeforeLoad/AfterLoad——貼片が再生されないと「広告流失」として報告され、広告を拦すること自体が検出される；策略はサーバ配信なので、リクエストを遮断すると「清潔で広告なし」ではなく降格分岐や位空缺になる可能性があり、同接口が返す他の内容に影響することもある；ある「広告位」は実は内容位 / 提携位（推薦カード、活動位）で、一刀両断すると内容まで欠ける。落地可能な拦点をコストパフォーマンス順に——広告策略の応答処理層（AdPolicyResponse の着地点で「広告位なし」を強制）→ 貼片の予載と表示コールバック（前・中・後貼片）→ QADNodeRequest の構成 / 派遣（情報流カード）→ H5 層で自前の AdFilterUtil を再利用。実装载体は通常 LSPosed/ReVanced 式パッチ——BiliRoamingX と同系である。

直接最高 VIP 権益を取ること——できない、そしてやらない。 機構を説明すれば、「難しい」のではなく「クライアントからは不可能」と分かる——権益はサーバが発行する——再生アドレスは vv.video.qq.com/getvmind（vinfo）＋CKey5 クライアント鍵を通り、サーバはアカウントの権益に応じてどの清晰度の流を出すかを決める；クライアントがやるのは表示とリクエストの二つだけで、ローカルのフラグ（VBDownloadParamInternal.isCharge、プレイヤーの isDRM）を変えてもせいぜい UI を騙せるだけ——サーバはクライアントが会员だと言ったからといって VIP 流を配らない；SVIP 档位は硬い閾値で、証拠は文字列の中にある——DOLBY_VISION_4K_60FPS、HDR10_PLUS、FHD_HFPS、UHD_VIVID、SVIP_OVERDUE、SVIP_PAY_BTN_*——これらの档位の URL はサーバが権益を確認した後にしか発行されない。唯一「取れる」路はサーバ応答の伪造 / 劫持や他人の憑証の再送——それは支払い済みアクセス制御の迂回であり、サービスの盗用に属する。この線は触れない——持ち込まれた REA 自身の DISCLAIMER.md もこの種の用途を明確に非対応としている。

遠征の収め——二つの報告がデスクトップに着地（04-REA 実測報告＋05-コードレベル RE 結果）、ソース木の補完を dex ごとにバックグラウンドで掛けた（一个の dex あたり約二十三秒、毎秒百十クラス、約十五分で完走見込み）、遗留物清单（%TEMP% の二つの REA 失敗残留ディレクトリが各 162MB の target.apk コピーを含む、tv-apktool/out、四つの Evidence JSON）は主人の規律に従い一つも消していない。

真実の座標

• REA の三 Evidence——inspect-artifact 12,659 ノード / 13,486 出現 / 13,485 エッジ；application-graph 三十二 dex / 五十七 native / 六十四 JS / 千八百二十四 bridge 候補；apktool-client 3.0.3（ソース版）
• 二つの硬い失败（隠さない）——JADX チャンネル——公開版の百二十秒死線（JadxProvider.ts:37 の硬い定数）は必ずタイムアウト、千八百秒に引き上げ再コンパイル後は四十二秒の静かな猝死（対照実験で REA 独自の Java bridge 链路に锁定、二回の挿入プローブで再現）；npx apktool ランチャー version_unresolved（ソース版では正常、公開パッケージの欠陥）
• 方法の切替——全量逆コンパイル 61%（56,263/91,137、82,650 ファイル / 258.7MB）が毎秒〇・五七クラスに崩れて终止 → class_defs 正確索引（三十万七千百七十六定義クラス）→ —single-class 定点（一クラス十〜三十秒）；訂正——314,572＝被参照記述子、真の定義クラスは 307,176；qadsdk に .core 層はない
• コードレベル発見——CKey5（GenCKey/taskEncrypt/Registration native、rlog.video.qq.com:8080、フラグ 20737/20738、デバイス指紋シフトアルゴリズム、getFlag repack|treg 反改竄）；ダウンロード＝混淆されたオープンソース FileDownloader＋native PCDN v3（失敗コード 1401024/1401025）；RAFT サービスフレームワーク＋VBDownloadParamInternal 契約；DLNA＝CyberGarage UPnP；弾幕 base+segment＋デバッグ裏口；三百六十九ドメイン；protobuf 二万六千九百二十四メッセージ
• 広告の結論——クライアント側貼片はほぼ全滅できるが「完全」は割り引き（反拦埋点 reportFunnelPreRollAdLoss*、策略サーバ配信、内容位の混在）；拦点は四層順；VIP 権益＝サーバ発行、クライアントのフラグ変更は UI を騙すだけ、伪造 / 再送は支払い済みアクセス制御の迂回——やらない