Hide map-injection's interpreted return-path blocks from clients?
PR #4653 for #803 (closed) cross-arch injection changed the default injection method to use -early_inject_map, rather than the old thread injection which loaded the DR dll from the child.
The old default injection method, triggered by running "drrun -late", presented the target takeover point as the first block of app code to clients:
interp: start_pc = 0x00007fff20502630
0x00007fff20502630 48 83 ec 78 sub $0x0000000000000078 %rsp -> %rsp
wrote all 6 flags now!
0x00007fff20502634 4c 8b c9 mov %rcx -> %r9
0x00007fff20502637 48 8b 05 b2 79 11 00 mov <rel> 0x00007fff20619ff0[8byte] -> %rax
0x00007fff2050263e 48 85 c0 test %rax %rax
0x00007fff20502641 74 10 jz $0x00007fff20502653
end_pc = 0x00007fff20502643
Fragment 1, tag 0x00007fff20502630, flags 0x9000630, shared, size 41:
[ntdll.dll!RtlUserThreadStart]
But -early_inject_map, just like the app start/stop API, has a return path as part of the initial interpreted code. dynamorio_earliest_init_takeover_C calls dynamorio_app_take_over which takes over at the return address inside dynamorio_earliest_init_takeover_C, which then returns back to dynamorio_earliest_init_takeover in asm and does some GPR popping and then returns to the retaddr we've placed on the stack from the parent (RtlUserThreadStart by default):
interp: start_pc = 0x000000001502643b
check_thread_vm_area: pc = 0x000000001502643b
new shared vm area: 0x0000000015001000-0x0000000015420000 ---- module dynamorio.dll
checking thread vmareas against executable_areas
prepend_entry_to_fraglist: putting fragment @0x000000001502643b (shared) on vmarea 0x0000000015001000-0x0000000015420000
check_thread_vm_area: check_stop = 0x0000000015420000
0x000000001502643b 48 83 c4 48 add $0x0000000000000048 %rsp -> %rsp
wrote all 6 flags now!
0x000000001502643f c3 ret %rsp (%rsp)[8byte] -> %rsp
mbr exit target = 0x00007ff6fd73f7c0
end_pc = 0x0000000015026440
Fragment 1, tag 0x000000001502643b, flags 0x1000630, shared, size 19:
[dynamorio.dll~dynamorio_app_init_and_early_takeover+0x37b,~dr_persist_start-0x
interp: start_pc = 0x0000000015349c23
check_thread_vm_area: pc = 0x0000000015349c23
prepend_entry_to_fraglist: putting fragment @0x0000000015349c23 (shared) on vmarea 0x0000000015001000-0x0000000015420000
check_thread_vm_area: check_stop = 0x0000000015420000
0x0000000015349c23 48 8d 64 24 20 lea 0x20(%rsp) -> %rsp
0x0000000015349c28 5f pop %rsp (%rsp)[8byte] -> %rdi %rsp
0x0000000015349c29 5e pop %rsp (%rsp)[8byte] -> %rsi %rsp
0x0000000015349c2a 5d pop %rsp (%rsp)[8byte] -> %rbp %rsp
0x0000000015349c2b 5b pop %rsp (%rsp)[8byte] -> %rbx %rsp
0x0000000015349c2c 5b pop %rsp (%rsp)[8byte] -> %rbx %rsp
0x0000000015349c2d 5a pop %rsp (%rsp)[8byte] -> %rdx %rsp
0x0000000015349c2e 59 pop %rsp (%rsp)[8byte] -> %rcx %rsp
0x0000000015349c2f 58 pop %rsp (%rsp)[8byte] -> %rax %rsp
0x0000000015349c30 41 58 pop %rsp (%rsp)[8byte] -> %r8 %rsp
0x0000000015349c32 41 59 pop %rsp (%rsp)[8byte] -> %r9 %rsp
0x0000000015349c34 41 5a pop %rsp (%rsp)[8byte] -> %r10 %rsp
0x0000000015349c36 41 5b pop %rsp (%rsp)[8byte] -> %r11 %rsp
0x0000000015349c38 41 5c pop %rsp (%rsp)[8byte] -> %r12 %rsp
0x0000000015349c3a 41 5d pop %rsp (%rsp)[8byte] -> %r13 %rsp
0x0000000015349c3c 41 5e pop %rsp (%rsp)[8byte] -> %r14 %rsp
0x0000000015349c3e 41 5f pop %rsp (%rsp)[8byte] -> %r15 %rsp
0x0000000015349c40 c3 ret %rsp (%rsp)[8byte] -> %rsp
mbr exit target = 0x00007ff6fd73f7c0
end_pc = 0x0000000015349c41
Fragment 2, tag 0x0000000015349c23, flags 0x1000030, shared, size 44:
[dynamorio.dll~dynamorio_earliest_init_takeover+0x2d,~dr_virtual_query-0x24dfd]
interp: start_pc = 0x00007fff20502630
check_thread_vm_area: pc = 0x00007fff20502630
new shared vm area: 0x00007fff204b1000-0x00007fff205cc000 ---- module ntdll.dll
checking thread vmareas against executable_areas
prepend_entry_to_fraglist: putting fragment @0x00007fff20502630 (shared) on vmarea 0x00007fff204b1000-0x00007fff205cc000
check_thread_vm_area: check_stop = 0x00007fff205cc000
0x00007fff20502630 48 83 ec 78 sub $0x0000000000000078 %rsp -> %rsp
wrote all 6 flags now!
0x00007fff20502634 4c 8b c9 mov %rcx -> %r9
0x00007fff20502637 48 8b 05 b2 79 11 00 mov <rel> 0x00007fff20619ff0[8byte] -> %rax
0x00007fff2050263e 48 85 c0 test %rax %rax
end_pc = 0x00007fff20502643
Fragment 3, tag 0x00007fff20502630, flags 0x9000630, shared, size 34:
[ntdll.dll!RtlUserThreadStart]
Should DR hide these 1st 2 blocks from clients? Or try to re-arrange the initial context so the 1st block is the app target. A clean start avoids confusion and special cases in clients observing app code.