|
|
|---|---|
|
|
最后于 2024-4-3 12:30
被mb_eiaothcj编辑
，原因：
|
|
|
这个看010editor就能看出来大小为0x150  ，我看的时候还比较好奇，你dump出来的多了0x20是怎么修复回去的，不会多么
|
|
|
|
|
|
|
|
|
|
|
|
过于牛逼,无法阅读
|
|
|
|
|
|
|
|
|
|
|
|
重温经典 实际复现后 我感觉dlopen的交叉引用也许真的只有一个 理由如下: 1.so_fixer是基于动态段对节区进行重构
最后于 2024-6-12 17:42
被万里星河编辑
，原因：
|
|
|
|
|
|
这里使用的思路也是dump内存再修复，只是这个由自定义linker加载的so在dump下来之后因为program header table被加密的缘故，而解密后的pht又和被加载so所映射的内存是分离的，sofixer这种so修复工具没有办法正常解析so，所以得找到解密后的pht，我使用的办法是直接追函数执行流找到pht的解密函数，然后静态解密出来再patch回去，其实应该有更加通用的方法就是找到soinfo然后去读soinfo->phdr，重构program header table，我看到seeflower大佬的一篇blog https://blog.seeflower.dev/archives/299/ 中，是通过hook soinfo->call_constructors获取到soinfo指针的。我觉得或许只要拿到soinfo，通过对这个结构体的各个成员进行逆向解析，依次获取soinfo中记录的ELF文件各个字段所映射的地址，并读取相对应的内存，就能够重构出一个标准的so来？。 |
|
|
我也遇到过这个问题，program header table 他其实不是被加密，是抹掉了，我在sofixer里面跳过了 program header table的检测 ，就好了 。 不过你说的这个也是个办法。感谢分享 |
|
|
|
|
|
|
|
|
当时想看看后面还有没有其他的数据所以就dump的稍微多了一些 
|
|
|
之后如果有遇到的话会去分析一下滴 
|
|
|
北京时间app |
|
|
|
|
|
大神，能不能讲下i国网这个app怎么开启webview调试
|
|
|
|
|
|
|
|
|
|
|
|
确实，我也发现sofixer修复的有一些导入函数解析错了 |
|
|
不容易啊 快半年了 终于有人遇到和我一样的问题了 感动
最后于 2024-10-8 03:12
被万里星河编辑
，原因：
|
