--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/c9b109b8-a613-4d28-944e-4dba1f23933fn%40googlegroups.com.
There is some support for mixed-mode 32-bit-and-64-bit.
The core certainly supports it, labeling each block as 32-bit or 64-bit. You would have to use 64-bit DR and a 64-bit client, and set options like -inject_x64 to ensure 64-bit DR is injected into 32-bit children. The drrun launcher may not support this; you would have to use a 64-bit launcher process (e.g., bin64/drrun on bin64/create_process) to inject.
Adds an -inject_x64 option to inject a 64-bit DR lib into a 32-bitchild from a 64-bit parent, but this option is only sketched out andis not fully supported yet: #49 covers adding tests and officialsupport.
--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/98a2d9a5-0c7a-4492-8d23-3f4458f55548n%40googlegroups.com.
win32.mixedmode parameters are set.
--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/a7973409-6e91-4bf6-965c-266d2c01750an%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/5ccb15bc-46fa-49a6-ba2c-8bdaf4f46c3fn%40googlegroups.com.
RAW_INSERT_INT32(cur_local_pos, pre_jmp + far_jmp_len);pre_jmp being in x64 address space, RAW_INSERT can't be INT32, as it will trigger an ASSERT for address range. This has to be RAW_INSERT_INT64.
I think there is some error in the code but I'd need an information to fix it :
should a x64 client dll injected in a x86 process be hooking RtlUserThreadStart from ntdll64 or ntdll32?
Le lundi 14 juin 2021 à 17:35:31 UTC+2, QtK a écrit :From what I have read from inject_gencode_mapped_helper, it might be possible to allocate the "local_buffer" in the target process and do everything from there? The buffer seems to be written to the target process in the end anyway.
The only allocation that fails to have a result <2GB is the local allocation in current process.So I guess that a remote allocation of this buffer (with a bit of modification in the shellcode creation) would work?Le vendredi 11 juin 2021 à 18:24:44 UTC+2, QtK a écrit :I think I found the problem.The second allocate_remote_code_buffer call (https://github.com/DynamoRIO/dynamorio/blob/master/core/win32/inject.c#L1205) from inject_gencode_mapped_helper fails to find a low-address code to allocate.From the comments I have read in the code, this might be cause by my version of Windows, which is a win10~ish.Any idea about how we could get around this problem?Le vendredi 11 juin 2021 à 16:02:25 UTC+2, QtK a écrit :RAW_INSERT_INT32(cur_local_pos, pre_jmp + far_jmp_len);pre_jmp being in x64 address space, RAW_INSERT can't be INT32, as it will trigger an ASSERT for address range. This has to be RAW_INSERT_INT64.Nevermind this is impossible because jmp far 0x33:[64 bit] do not exist in intel arch. We have to do it some other way.
--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/e3a7f08e-1013-4849-8ae3-d32508ac3a82n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/146ff3f0-1fa8-4d69-8946-ad3b927262ebn%40googlegroups.com.
Thanks for your interesting answer.I've deleted my previous posts that are now irrelevant. I have understood the process injection routine now.The last thing that bugs me is finding when dynamo_earliest_init_takeover is going to pop the pushed value to transfer control to it.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/e204c803-ef51-481d-ac6d-afff51a1efd6n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/16ba4340-be82-47bf-a1bf-d55ff3e00d92n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/b5f2b2e0-c9fe-4e54-9e86-536f39a50130n%40googlegroups.com.
Injection seems to work, but RtlUserThreadCreate segfaults somehow. I suspect that I messed up with the stack, but I have no idea how.I have noticed that it takes its arguments from eax and ebx (in x86 which I'm calling). I'm not sure if EBX is getting restored after a call to dynamorio_earliest_init_takeover. You have a comment saying :* [...]So we instead only touch* xax here and we target an asm routine in DR that will preserve the* other regs, enabling returning to the hooked routine w/ the* original state (except xax which is scratch and xbx which kernel* isn't counting on of course).
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/1ff5ee6f-3ec7-4197-831e-ccbceb52a984n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/f75a3932-43d1-41b8-9e23-5e7877945158n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/0d1b4345-5e3d-41a5-96af-6013f18ce439n%40googlegroups.com.
Looking at dr_insert_clean_call should show how it works: e.g., insert_meta_call_vargs() for the actual call; {prepare_for,cleanup_after}_clean_call() (inlined) and emit_clean_call_{save,restore}() (out-of-line) for other setup.
--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/7d7995d0-59ca-4d8c-bfca-41a1bd083131n%40googlegroups.com.