iris的博客

本章对之前的网络流量分析与Android逆向做个小结。网络流量分析原理解析分析原理前之前先了解中间人攻击的概念：在中间人攻击中，攻击主机通常截断客户端和服务器的加密通信。攻击机以自己的证书替代服务器发给客户端的证书。通常，客户端不会验证该证书，直接接受该证书，从而建立起和攻击机的安全连接。这样，客户端发送的数据，都会被攻击机获取和解密。这里主要分析应用层抓包，应用层Https抓包原理有了Charles/burpsuite置于中间之后，本来C/S架构的通信过程会分裂为两个独立的通信过程，app本来

实验室最近想要分析下oppo软件商店的sign协议写爬虫，记录下分析的流程，比较简单。应用商店的搜索、详情页以及类别请求用的sign的构成与加密方式都相同：反编译搜索关键字段：可以看到最后的加密方法为HashUtil.md5Hex，那么参数肯定是加密前的明文了，对md5Hex进行hook：得到加密前的明文：Sign字段构成：标黄部分为固定值，绿色部分为GET请求Header中ocs字段，为设备信息不同设备不一样，蓝色部分为Header中t字段，固定部分。红色部分为Header中id字段，设备

**1.如何从海量的APP找出一个二次打包的应用呢**1.流量特征检测：首先二次打包应用仅仅是对原apk进行反编译修改了某些特征例如去掉广告或者加入自己的某些操作，流量数据和原apk应该是一样的，这是一种方法。2.代码相似度检测：检测代码相似度。3.UI界面相似度检测或者也可以从代码层面进行UI节点遍历检测相似度。2.Dex文件加载流程这里先好好学习一下dex文件的加载:app在启动的过程中创建了PathClassLoader加载dex文件，那么我们跟进PathClassLoader：/l

第一代加固第一代加固原理是基于 Dex 加载器的加固技术。基本步骤1、从 Apk 文件中获取原始的 dex 文件。2、对原始的 dex 文件进行加密，并将加密后的 dex 文件存放在 asset 目录。3、用脱壳 dex 文件替换原始 apk 文件的 dex 文件。脱壳 dex 文件的作用主要有两个：一是解密加密后的 dex 文件，二是动态加载解密后的 dex 文件。4、修改清单文件，将程序入口改为壳程序。5、打包签名。缺陷依赖 Java 的动态加载机制，解密后的 dex 文件必须解压到文

从看雪上面看了篇文章：https://bbs.pediy.com/thread-252520.htm于是自己动手写了一个简单的动态注册的app来实验一下：so层：mainactivity.java:直接找到了native注册函数的地址，如果jni_onload做了混淆的话非常有用。...

关键函数在securityCheck：放在了native层之前的解法就是先nop掉JNI_OnLoad中的反调试，然后再动态调试到securitycheck方法中获取相关寄存器的值。这里学习了frida之后，看看是否能有更加简洁的方式：将输入的字符串与v7进行比较，v7又来自于v6，v6的值等于off_628c;当然，我们已经知道这是错误的值，在动态运行的过程中会对其进行处理，但是我们...

和上篇文章一样，打开后会进行root检测：不同的是在进行root检测之前，调用了init函数进行初始化：而init函数是native层的：打开so文件看一下：主要逻辑在sub_93C函数，点击进去查看：显而易见，在程序逻辑开始执行之前，父进程fork出子进程并进行ptrace附加，即让子进程附加自己，这样其他进程就不能来调试自己了，是常见的反调试的一种保护手段：解决办法就是让...

前面已经对frida有了小小的理解，这次就拿ctf题进行练习：显而易见进行了root检测，可以通过Magisk进行隐藏。这里就用做练习不用工具绕过了：调用三个检测函数：对su文件等root后特有的特征进行检测。如果判断结果都为真则调用this.a(“Root detected!”)方法：点击ok后就退出。因此我们首先需要nop掉exit函数，这里有两种方法：1.hook Sys...

继续对frida进行学习，依旧是参考前一篇看雪前辈的帖子学习（https://bbs.pediy.com/thread-229597.htm）找到判断字符串是否正确的逻辑是解题关键。此apk采用了美团的热修复方案。...

刚接触了frida这个hook工具，因此利用ctf题进行进一步的学习，此处参考https://bbs.pediy.com/thread-227233.htm。首先分析题目逻辑：VERIFY按钮的逻辑为首先获取输入的license的值，将其与给定的url拼接向服务器进行请求，获得的回应如果为"LICENSEKEYOK",就将其与getMac的返回值进行xor运算，并运算的结果作为键值为"K...

登录密码使用AES加密，对于加固后应用可以通过context获得到壳的classloader，之后只需要用这个classloader就可以hook：hook代码如下：

对某新闻签名算法的一次分析：搜索sign很容易定位到关键位置：因为该软件采用多分dex，因此采用xposed作者给出的hook Application的attach方法：结果如下：但是不知道为什么没有打印出param2，很奇怪。。。另外也可以采用hook loadclass的方法如下：还是没有打印出param2，有点奇怪…...

接着前面一篇文章，当Android系统启动一个应用的时候，有一步是对dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第- -次加载dex文件的时候执行的。这个过程会生成一个odex文件，即Optimised Dex。生成可执行文件odex，保存到data/dalvik-cache目录，最后把apk文件中的dex文件删除。 紧接着解析odex...

接着上一篇文章对对某app通信协议加密字段的一次分析 - 1(IDA Pro动态调试和Frida)上一篇文章中

app动态分析主要分为动态跟踪以及动态调试两部分，前面提到了IDA以及smalidea都是属于动态调试。然而有的apk混淆比较严重，定位到关键代码部分比较困难,有的apk做了反调试会导致动态调试失败，因此动态跟踪方法就显得非常重要。目前我所学到的动态跟踪方法主要有两种：1.traceviewDDMS中比较好用的栈跟踪工具。可以得到执行某操作期间调用的所有方法的执行顺序，包括父方法和子方法...

如上图所示，请求包与返回的数据包均被加密，分析一波加密的方式看看能否得到plain text。先放进apk改之理里面，查看下其文件目录：没有lib文件夹，说明字段的加密都在java层完成，这样就减轻了分析的难度（所以开发时尽量加密方式放在so层。。。）。先搜索下key值：查看其java代码：根据函数名称显而易见，是对请求参数的加密，也就是对：的字段信息进行加密。跟进p2sD...

在对某app抓包的过程中发现请求报文里有密文字段，想知道下密文传输了什么信息：如上图所示，请求报文里协议的key为plaintext，但是value值却被加密，逆向分析一下。首先，用apk改之理打开apk搜索key值：很容易搜索到了，接着查看其java代码：同时发现apk做了混淆保护。如上图，最终str3也就是plaintext作为key,advara作为value放到了hash...

安装并打开apk之后，发现题目为爬到指定的楼层然后才能显示FLAG：先使用JEB2反编译apk查看逻辑：爬一层楼的点击事件：首先已爬楼层数+1并更新已爬楼层数，紧接着判断是否达到要爬楼层数，如果达到，就设置爬到了，看FLAG的点击结果为true。最终看到FLAG按钮的点击事件，可以看到最终的返回FLAG方法在native层实现。我们可以使用IDA进行分析。onCreate方法的实现...