知乎x-zse-96逆向-webpack与浏览器补环境加密定位直接控制台搜索 x-zse-96 再看一下ed方法 signature: (0,tJ(ti).encrypt)(ty()(tp)) ， ty方法应该是一个md5加密 然后再看一下 tJ(ti).encrypt 方法 webpack加载器再往下走一步，具体的加密应该就在这个 te.O 方法中，这里是一大段控制流， 函数的开头是一个 1514的数字，说明这里就是用了webpack打包 我们再搜一下 1514 看一下加载器的位置，来到这里后 打上断点，重新刷新一下，断点进来，这里就是加载器的位置了 我们把代码复制下来，顺便把我们加密的代码整个复制下来，就是所谓的模块代码，补上window，以及 我们在用个全局变量来接受 加载器函数，然后顺便打印一下，我们需要那几个模块函数 运行后会报错，记得将self去掉，用window来接收 webpackChunkheifetz 对象 没有报错后，会发现打印成功，调用了 1514 和 74185 两个模块函数 我们只需要保留这两个函数就可以了，其它的都可以删掉 ...

小黑盒 hook pthread_create 过frida检测小黑盒抓包的时候，想用自吐加密算法查看用的是什么加密，发现frida做了检测，启动frida脚本就会提示程序终止 目前使用的frida版本是16.0.19，未作任何特征隐藏 常见的frida检测就那么几种，进程和端口检测等，我们先看下是否是在so中进行检测，这里我们尝试通过hook dlopen 函数，查看一下so加载流程，结果发现，加载到 libmsaoaidsec.so 时，frida被终止 12345678910111213141516171819202122232425262728293031Java.perform(function () { // 通过查找dlopen，dlopen时打开so文件的通用方法 var dlopen = Module.findExportByName(null, "dlopen"); var android_dlopen_ext = Module.findExportByName(null, "android_dlopen ...

Bilibili app 给视频增加播放量版本：v6.24.0 请求体里面应该是做了二进制加密 请求头，请求头内容在变更视频的时候 貌似没有变化 打开jadx反编译搜索 接下来我们要找到 reportClick 方法在哪实现，点击查找用例 能看到这里实现了一个很标准的retrofit请求，请求体就是 c0 create，看上去里面有很多参数 1234c0 create = c0.create(w.d(com.hpplay.sdk.source.protocol.h.E), d.this.H7(this.b.a(), this.b.b(), this.b.h(), i, j2, this.b.n(), this.b.m(), this.b.k(), this.b.c(), this.b.e(), this.b.l(), this.b.f())); 先看一下这个d.this.H7方法，hook一下，hook到之后可以发现 ，传入的参数在这里组成了一个字典，将其组合成字符串后又进行了 t3.a.i.a.a.a.b.e.b 方法加密，我们再看一下这个加密方法 sign两个 ...

jd app ep和sign参数获取解析版本：v11.6.4 GET中传递的参数： functionId， "functionId": "backupKeywords" ep，需逆向 sign，需逆向 st，看似时间戳 sv，看似固定值 eid，删除后不影响（忽略） “ep”:12{"hdid":"JM9F1ywUPwflvMIpYPok0tt5k9kW4ArJEU3lfLhxBqw=","ts":1716949561010,"ridx":-1, "cipher":{"area":"CV83Cv8yDzu5XzK=","d_model":"UQv4ZWmzYG==","wifiBssid":"dW5hbw93bq==","osVersion":"EG==",&q ...

脱ob混淆123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201 ...

AST（Abstract Syntax Tree），中文抽象语法树，简称语法树（Syntax Tree），是源代码的抽象语法结构的树状表现形式，树上的每个节点都表示源代码中的一种结构。语法树不是某一种编程语言独有的，JavaScript、Python、Java、Golang 等几乎所有编程语言都有语法树 AST 有一个在线解析网站：https://astexplorer.net/ 语法树没有单一的格式，选择不同的语言、不同的编译器，得到的结果也是不一样的，在 JavaScript 中，编译器有 Acorn、Espree、Esprima、Recast、Uglify-JS 等，使用最多的是 Babel AST 在编译中的位置在编译原理中，编译器转换代码通常要经过三个步骤：词法分析（Lexical Analysis）、语法分析（Syntax Analysis）、代码生成（Code Generation） 词法分析词法分析阶段是编译过程的第一个阶段，这个阶段的任务是从左到右一个字符一个字符地读入源程序，然后根据构词规则识别单词，生成 token 符号流，比如 isPanda('� ...

JustTruestMe SSL-pinning有两种方式： 证书锁定（Certificate Pinning） 和公钥锁定（ Public Key Pinning）。 JustTrustMe ：将各种已知的的HTTP请求库中用于校验证书的API都进行Hook，使无论是否是可信证书的情况，校验结果返回都为正常状态，从而实现绕过证书检查的效果 证书锁定 需要在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端（例如API网关）之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在 证书续期后需要将证书重新内置到APP中。 公钥锁定 提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。 123456789101112131415161718192021222324252627282930313233343 ...

下载与安装12345678910111213141516171819pip install fridapip install frida-tools# 查看frida 版本frida --version# 手机安装frida 服务端getprop ro.product.cpu.abi # 查看手机cpu架构# 跟着frida版本和cpu架构下载对应的frida-serverhttps://github.com/frida/frida/releases# 下载完成之后 可以重命名为frida-server64，随后push到手机，最后启动frida服务adb push frida-server64 /data/local/tmpadb forward tcp:27042 tcp:27042adb forward tcp:27043 tcp:27043adb shellsucd /data/local/tmp/chmod 755 frida-server64./frida-server64# 远程和自定义端口启动./frida-server -l 192.168.0.1:6666 脚本 ...

检测frida-server文件名检测有没有叫做frida-server的文件或进程存在。比如： 123456789101112131415public boolean checkRunningProcesses() { boolean returnValue = false; // Get currently running application processes List<RunningServiceInfo> list = manager.getRunningServices(300); if(list != null){ String tempName; for(int i=0;i<list.size();++i){ tempName = list.get(i).process; if(tempName.contains("frida-server")) { returnValue = true; } } ...

解析流程：绿色表示客户端消息发给服务器，红色表示服务器下发数据给客户端 从第一个堆栈开始看起，下面的四个方法，onError(e)，onMessage(e)，onOpen(e)，onClose(e)分别对应着websocket的四个触发事件，分别是 连接错误，接受数据，连接成功，连接关闭 我们直接在 onOpen 打上断点，查看上一个调用堆栈，看一下绑定的方法 onOpen方法里面都是一些赋值操作，我们直接看 ping方法，我们可以看到关键字 serializeBinary 很明显在这里做了序列化操作 我们看一下 e.serializeBinary() 方法，我们在这一块能看到下面是序列化操作，上面是反序列化操作，后面要跟着写proto文件 接着我们看一下第二个堆栈fetchSocketServer 这个方法处理数据接收，这里同样绑定四个事件，我们直接看 bindClientMessage 方法 这里就是websocket的消息处理部分了，我们看下代码 12345678const a = p.PushFrame.deserializeBinary(e.data) //反 ...