Sign in to follow this  
b1gjo3

Code Injection... 32-bit and 64-bit

Recommended Posts

b1gjo3    213
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

Share this post


Link to post
Share on other sites
Xest    140
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?

Share this post


Link to post
Share on other sites
Evil Steve    2017
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.

Share this post


Link to post
Share on other sites
b1gjo3    213
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...


32bitdll
64bitdll

while(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

Share this post


Link to post
Share on other sites
Rycross    584
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.

Share this post


Link to post
Share on other sites
mattd    1078
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!

Share this post


Link to post
Share on other sites
b1gjo3    213
Quote:
Original post by Rycross
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.


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

Share this post


Link to post
Share on other sites
b1gjo3    213
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

Share this post


Link to post
Share on other sites
Codeka    1239
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this