-
Double fetch case 1
DOUBLE FETCH: cr3 0xa9774000, syscall 0x88 eip 0xfffff80179c9f8e1, user_address 0x13ee991bec8, user_data 0x7c000000, modrm 0x38, pc 0xfffff80179c9f9eb eip 0xfffff80179ca2b6e, user_address 0x13ee991bec8, user_data 0x7c000000, modrm 0x19, pc 0xfffff80179ca2bb8 DIFF EIP LAB_1404159c2 XREF[1]: 140415989(j) 1404159c2 4c 8b 8c MOV param_4,qword ptr [RSP + param_7] 24 90 01 00 00 1404159ca 4d 85 c9...
-
double fetch case 0
抓到的double fetch很多，只能一个一个看了。 留个记录。 DOUBLE FETCH: cr3 0x11067e000, syscall 0x88 eip 0xfffff80179ca0603, user_address 0xf5880ff360, user_data 0x1000, modrm 0x1, pc 0xfffff80179ca09c1 eip 0xfffff80179ca0603, user_address 0xf5880ff360, user_data 0x1000, modrm 0x1, pc 0xfffff80179ca09df LAB_1404169a5 XREF[1]: 140416ab1(j) 1404169a5 4d 85 c0 TEST param_3,param_3 1404169a8 0f 84 18 JZ LAB_140416ac6 01 00 00 1404169ae 49 8b...
-
接着搞double fetch
对qemu tcg了解的不够，env->eip并不是准确的当前指令的地址。 长的差不多的还有s->pc，s->pc_start，s->pc_next，GETPC()等等。 现在来看，pc_start有可能是。 之前我打印出了modrm的一个字节，发现env->eip和这个modrm总是不一一对应。这肯定不对，modrm是在指令里的。 用pc_start后，分析一条记录。 DOUBLE FETCH: cr3 0xa9774000, syscall 0x88 eip 0xfffff80179c9f8e1, user_address 0x13ee991bec8, user_data 0x7c000000, modrm 0x38, pc 0xfffff80179c9f9eb eip 0xfffff80179ca2b6e, user_address 0x13ee991bec8, user_data 0x7c000000, modrm 0x19, pc 0xfffff80179ca2bb8 DIFF EIP 在ghidra里搜memory，48 b8 38没有搜到，搜b8 38能搜到不少，是读32bit的。 然后在ghidra的搜索结果里面过滤9eb，只能按页面内偏移找了，说明x64上模块加载的基址和各个section的位值不能想当然的 认为会在64k或什么地方对齐。 LAB_1404159eb XREF[1]: 140415b0d(j) --> 1404159eb 8b 38 MOV EDI,dword ptr...