声明：案例分析仅供学习交流使用，勿用于任何非法用途。如学习者进一步逆向并对版权方造成损失，请自行承担法律后果，本人概不负责。
简介
本次逆向的apk拥有较为简单的加固和JavaScript源码加密，分析起来并不困难，旨在分享心得——当逆向分析遇到“死胡同”的时候，换个思路也许能拨云见日。
目标
获取apk中有关“91kds播放逻辑”的信息。
逆向流程
首先用jadx分析apk文件，发现其拥有360加固。
尝试使用drizzleDumper获取内存中真正的dex，成功。
再次用jadx分析真正的dex，没有找到与字符串“91kds”相关的有用信息，陷入僵局。
突破口——JavaScript文件
无意间翻看其官网，发现这个应用同时拥有Android版和IOS网页版，以此推测其安卓版有可能使用了JavaScript做混合开发。
于是猛然回想起之前分析apk data目录文件时看到的一堆*.js，当时不以为然，现在想起来它们兴许就是突破口，立马导出。
jquery-2.1.1.min.js库不多赘述，native_layer.js提供了大量工具方法，并由方法名中的片段yk（优酷），bst（百事通）等推测这是播放逻辑需要用到的方法。
但是当打开其他js文件时，发现被加密了。如encrypt_root.js。
回到dex中找线索，发现在apk初始化数据时，会解压下载的js.zip。
找到解密函数
顺藤摸瓜即可找到其读取js并解密的入口。
解密逻辑大致如下。
读取文件用的是java.util.Scanner的方法，不用担心是继承、重载做过手脚的类，也就不用再深入分析。
小插曲：将代码复制到java项目中运行，报错。
猜测为AES加密方法的平台兼容性导致，经过多次修改仍旧报错。
再次换个思路，将代码放入Android项目运行，正常获得解密js文件。encrypt_root.js即为url处理入口。
在encrypt_other_live.js中可以找到最关键的sign字段生成方式，至此就完成了对91kds播放逻辑的逆向分析。
