Protected: Keep APP AES key decrypt
There is no excerpt because this is a protected post.
Category: CODE
记一次APP SSL pinnig 抓包
先了解下背景，APP证书校验的几种实现方式[1]： 不校验，只走Https流量 系统信任证书校验 Android7以后，系统不再信任用户级的证书，只信任系统级的证书，所以要抓包就需要把我们的代理程序证书安装至Android的系统目录中 公钥校验Public Key Pinning HTTPS网站防止攻击者利用数字证书认证机构（CA）错误签发的证书进行中间人攻击的一种安全机制，用于预防CA遭受入侵或其他会造成CA签发未授权证书的情况。采用公钥固定时，网站会提供已授权公钥的哈希列表，指示客户端在后续通讯中只接受列表上的公钥。 证书全内容校验 SSL Certificate Pinning 下面记录了一次抓包过程： 打开Charles, 启用ssl proxy，手机配好代理，开始如图所示，提示握手失败 看来有做证书校验，试试第二种系统证书校验，把charles证书装到手机上 手工安装的证书，只能装到用户证书区 要装到系统证书，有以下几种方式 Xposed 模块，Android 10可以使用太极 JustTrustMe TrustMeAlready Magisk 模块 Always Trust User Certificates No luck, 尝试第3种 公钥校验，这里用到 frida(手机需root), 手机端, 参考 官方文档 下载frida-server对应架构版本 手机用数据线连接到电脑 把二进制执行文件复制到手机 /data/local/tmp/ 手工执行: /data/local/tmp/frida-server & 如果使用了Magisk, 需要关闭MagiskHide 电脑端 安装 pip3 install frida 使用脚本 frida-multiple-unpinning, 可以绕过多种实现的公钥 […]
记一次Mybatis缓存踩坑
接口结果和预期的不一致，在本地Debug，便有了以上的截图 为啥按id查出来的对象id为空？ 为啥sql打印的结果 templateType为1，对象里确是 0？ 一脸懵逼🤔️ 原来，同一个查询，查了会缓存，后面直接命中了缓存，不再查数据库 一次数据库会话中，执行多次查询条件完全相同的SQL，MyBatis提供了一级缓存的方案优化这部分场景，如果是相同的SQL语句，会优先命中一级缓存，避免直接对数据库进行查询，提高性能。 对返回对象的修改，同时也是对缓存的对象的修改😂 MyBatis一级缓存的生命周期和SqlSession一致。 MyBatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，数据库写操作会引起数据脏读。 每次执行update前会清空localCache。 对Mybatis缓存的分析，有兴趣的可以看看这篇文章 聊聊MyBatis缓存机制