能力值：
( LV2，RANK：10 )
|
-
-
26 楼
感谢分享
|
能力值：
( LV1，RANK：0 )
|
-
-
27 楼
1
|
能力值：
( LV12，RANK：550 )
|
-
-
28 楼
不错
|
能力值：
( LV1，RANK：0 )
|
-
-
29 楼
666
|
能力值：
( LV2，RANK：10 )
|
-
-
30 楼
感谢分享
|
能力值：
( LV2，RANK：10 )
|
-
-
31 楼
6
|
能力值：
( LV2，RANK：10 )
|
-
-
32 楼
6666666666
|
能力值：
( LV1，RANK：0 )
|
-
-
33 楼
666
|
能力值：
( LV1，RANK：0 )
|
-
-
34 楼
不用这么麻烦，如果已经确定目标用的是极其不安全的crc32校验，可以直接crc碰撞，修改内存中可执行phdr最后4字节使其与原始文件crc32相同，耗时也就1毫秒
|
能力值：
( LV7，RANK：110 )
|
-
-
35 楼
Eirv
不用这么麻烦，如果已经确定目标用的是极其不安全的crc32校验，可以直接crc碰撞，修改内存中可执行phdr最后4字节使其与原始文件crc32相同，耗时也就1毫秒
看了你的回复，我有点疑问。1.你说的crc碰撞,基于目前的校验，基本都是自写的crc，并且有的还会魔改,既然我都去碰撞了，是不是前提得是我知道这个加密函数的地址，那我已经知道这个加密函数地址了，那我为什么还去碰撞，我直接解决这个校验点不就行了，像你说的去碰撞那不显得更麻烦。实现起来也更耗时。2.通常来说，对函数的hook至少也得需要改变函数头部的前8个字节吧，frida就是16个。你这边的只改变可执行段的后4个字节的操作我属实没看懂与函数hook的crc校验有什么关系。如果你想了解hook之后的crc校验什么东西，你可以尝试对我发的app进行一个libc的hook操作，查看下内存和本地文件的区别。相信你能更加理解到基于函数hook的crc校验。
|
能力值：
( LV1，RANK：0 )
|
-
-
36 楼
无私精神
|
能力值：
( LV2，RANK：10 )
|
-
-
37 楼
6666
|
能力值：
( LV1，RANK：0 )
|
-
-
38 楼
感谢分享
|
能力值：
( LV2，RANK：10 )
|
-
-
39 楼
6
|
能力值：
( LV1，RANK：0 )
|
-
-
40 楼
我忽然想到一种自身获取某个so基址的方法不知道可不可行，就是直接通过dlopen获取指定so的基址，这个接口走的不知道是不是soinfo那边的
最后于 2025-3-2 15:22
被安卓逆向test编辑
，原因：
|
能力值：
( LV8，RANK：134 )
|
-
-
41 楼
感谢分享
|
能力值：
( LV2，RANK：10 )
|
-
-
42 楼
666666
|
能力值：
( LV7，RANK：102 )
|
-
-
43 楼
依稀记得CRC都是提前算好的
|
能力值：
( LV1，RANK：0 )
|
-
-
44 楼
0666
|
能力值：
( LV1，RANK：0 )
|
-
-
45 楼
6666
|
能力值：
( LV2，RANK：10 )
|
-
-
46 楼
学习一下
|
能力值：
( LV3，RANK：30 )
|
-
-
47 楼
666
|
能力值：
( LV1，RANK：0 )
|
-
-
48 楼
看看大佬文章
|
能力值：
( LV2，RANK：10 )
|
-
-
49 楼
感谢分享
|
能力值：
( LV7，RANK：110 )
|
-
-
50 楼
安卓逆向test
我忽然想到一种自身获取某个so基址的方法不知道可不可行，就是直接通过dlopen获取指定so的基址，这个接口走的不知道是不是soinfo那边的
改soinfo里面的load bias参数就可以影响到dlopen返回的handle，但是会有崩溃的风险
|
|
|
|
