Code Injection... 32-bit and 64-bit
Author
Hello
Earlier this summer i learned that in using windows hooks you cannot inject 32-bit dll into a 64-bit process, and vice versa. I have been searching for sources explaining why this is not possible. Most sources i come across simply state that it isnt possible without giving any insight as to why.
Can someone help me find what im looking for, or share some insight?
Thanks
It's just a guess, because I'll admit I really don't know too much about what the real differences in 64 and 32 bit code are, but I'd imagine it's because 32bit dlls are compiled with 32bit memory references or some data types, whilst 64bit processes expect 64bits for memory references or some data types.
If a 32 bit process read a 64 bit memory reference it'd only get the first 32 bits of the reference meaning it wouldn't know the correct address in memory to reference.
I could be wrong of course- I don't know if Windows employs some kind of automatic method of handling the differences here or something and it's a different reason, but it seems a plausible explanation- I mean, how would a 32 bit process handle a 64 bit memory address for example when the maximum it can understand is a memory address of 32 bits in length?
If a 32 bit process read a 64 bit memory reference it'd only get the first 32 bits of the reference meaning it wouldn't know the correct address in memory to reference.
I could be wrong of course- I don't know if Windows employs some kind of automatic method of handling the differences here or something and it's a different reason, but it seems a plausible explanation- I mean, how would a 32 bit process handle a 64 bit memory address for example when the maximum it can understand is a memory address of 32 bits in length?
The assembly code is also different; x64 assembly has more registers available than x86. If you were able to load 32-bit DLLs in a 64-bit process, the OS would have to marshal every single function call between 32 and 64 bits, and as Xest said, pointers would be unusable.
I suppose it might be theoretically possible, but it'd be a hell of a lot of work for the OS team.
I suppose it might be theoretically possible, but it'd be a hell of a lot of work for the OS team.
Author
Would there be much overhead if i used IsWow64 to determine whether the process is 32-bit/64-bit... and depending on which one it is unload the incorrect dll ver and load the correct one.
Here is some pseudocode...
would this even be possible whether or not there's a lot of overhead?
thanks again
Here is some pseudocode...
32bitdll64bitdllwhile(true){ if process iswow64 { unload 64bitdll load 32bitdll } else { unload 32bitdll load 64bitdll }}would this even be possible whether or not there's a lot of overhead?
thanks again
Quote:Original post by b1gjo3
Would there be much overhead if i used IsWow64 to determine whether the process is 32-bit/64-bit... and depending on which one it is unload the incorrect dll ver and load the correct one.
Here is some pseudocode...
*** Source Snippet Removed ***
would this even be possible whether or not there's a lot of overhead?
thanks again
I'm not exactly sure why you'd want to do that. If you want to distribute your program in both 64-bit and 32-bit, you'd want to compile it twice and only install the appropriate executable/libraries.
Quote:Original post by b1gjo3
Would there be much overhead if i used IsWow64 to determine whether the process is 32-bit/64-bit... and depending on which one it is unload the incorrect dll ver and load the correct one.
Why not make your injector process 32-bit, so it runs on both platforms, and have separate 32/64-bit DLLs for injection?
Don't forget to handle the case where you're running on a native 32-bit system that doesn't have WOW64!
Author
Quote:Original post by RycrossQuote:Original post by b1gjo3
Would there be much overhead if i used IsWow64 to determine whether the process is 32-bit/64-bit... and depending on which one it is unload the incorrect dll ver and load the correct one.
Here is some pseudocode...
*** Source Snippet Removed ***
would this even be possible whether or not there's a lot of overhead?
thanks again
I'm not exactly sure why you'd want to do that. If you want to distribute your program in both 64-bit and 32-bit, you'd want to compile it twice and only install the appropriate executable/libraries.
Because there are still 32-bit applications that are running on 64-bit systems and if you only choose to run one of the versions, it wont work on the other processes
Author
Just realized my pseudocode was not possible. I believe the solution to the problem requires 3 executables, and 2 dlls.
1 32-bit/64-bit exe to delegate whether the process is 32-bit or 64-bit and depending on which it will load and unload 1 of the other 2 executables
1 32-bit exe to load the 32-bit dll for injection
1 64-bit exe to load the 64-bit dll for injection
1 32-bit/64-bit exe to delegate whether the process is 32-bit or 64-bit and depending on which it will load and unload 1 of the other 2 executables
1 32-bit exe to load the 32-bit dll for injection
1 64-bit exe to load the 64-bit dll for injection
I'm not sure what the purpose of injecting the DLLs is in this particular case, so I'm going to guess that you've got an application which wants to inject DLLs into other process and then it communicates with that DLL in various ways.
Now, it's true that on a 64-bit system, you will need both a 64-bit DLL and a 32-bit DLL. This is so you can inject the 64-bit DLL into 64-bit processes and the 32-bit DLL into 32-bit processes. But your main application doesn't have to be 64-bit. Your application can be 32-bit and you can still inject a 64-bit DLL into other processes. That should simplify your life somewhat.
So you just need to write one EXE and compile two version of your DLL. Your 32-bit EXE can communicate with the 32- or 64-bit DLL via named syncronization objects, named pipes, sockets or whatever other mechanism you need.
Now, it's true that on a 64-bit system, you will need both a 64-bit DLL and a 32-bit DLL. This is so you can inject the 64-bit DLL into 64-bit processes and the 32-bit DLL into 32-bit processes. But your main application doesn't have to be 64-bit. Your application can be 32-bit and you can still inject a 64-bit DLL into other processes. That should simplify your life somewhat.
So you just need to write one EXE and compile two version of your DLL. Your 32-bit EXE can communicate with the 32- or 64-bit DLL via named syncronization objects, named pipes, sockets or whatever other mechanism you need.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
