Support for 64 bits targets
andrese opened this issue · 11 comments
When the target is a 64 bits system there are some problems when sending and executing a file. For instance with a command like this: remcom \192.168.1.200 /user:midomain\miuser /pwd:mipwd /c miprogram.exe
The result is that the file is copied but it cannot be found when executed.
But as far as I have tested if you only execute a remote command (not transfer it it works fine).
The problem is that remcom first copies the exe to c:\windows\system32 and then executes it form the service that is a 32 bits program.
But 32 bits programs when tun in a 64 bits system by default CANNOT see c:\windows\system32. That is meant to be like that by windows design, see references:
http://support.microsoft.com/kb/942589
http://social.msdn.microsoft.com/Forums/sl-SI/netfx64bit/thread/cfdf4474-266b-4ef5-8992-7fbdc3147521
In short in 64 bits systems there are 2 system32 folders one for 64bits programs and another for 32 bits and remcom is storing the exe in the 64bits system32 and tries to execute it on the 32bits system32 folder.
So... I can think of 2 solutions:
-
keep remcom service as 32 bits and keep storing the exe file in regular (64bits) system32 folder and execute if forcing to use the 64bits folder. That is as easy as making the service to detect that it is running in a 64bits system and to execute the file under c:\windows\sysnative folder that is how 32bits software sees the 64bits system32 folder.
-
Compile remcom service as 64 bits too and distribute it in two flavours 32/64 bits. Then the client can chose what service to install for instance parsing a command line parameter...
This issue may be related (or not) with issue #10
BTW if there is a poor soul that needs to execute against a 64 bits target right now, there is a "poor man" solution:
Lets say you want to transfer the exe "uptime.exe" and execute it you can do it on 3 steps: 1) execute with transfer (/c option) it will fail but the file will be copied to c:\windows\sysnative, 2) execute the command at sysnative, 3) delete the file at sysnative
- remcom //192.168.1.44 /user:domain\user /pwd:thepassword /c uptime.exe
(it fails... ignore the error...)
- remcom //192.168.1.44 /user:domain\user /pwd:thepassword c:\windows\sysnative\uptime.exe
(if executes fine)
- remcom //192.168.1.44 /user:domain\user /pwd:thepassword del c:\windows\sysnative\uptime.exe
(cleanup, delete the exe)
Happy admin time :-)
Awesome, thanks for the info :)
This will get me further down the path of fixing this. I accept submissions if you decide to fix this on your own.
Well as I really needed this to work I finally made some code patching.
The patch makes remcom to transter comamnd to execute to %SYSTEMROOT% (p.e. c:\windows) instead of %SYSTEMROOT%\system32.
As %SYSTEMROOT% is the same dir when 32 or 64 bits the problem is solved.
I am sending patch right now
How do I go about compiling this to work from a 32 bit windows OS to a 64 bit windows OS, Ive tried compiling it with Visual C++ 2010 express edition, with the windows SDK7.1 installed, however no matter what I try it always seems to link to the MSVCR100.dll, and not MSVCR71.dll. I need it to link to MSCVR71.dll as that is available on both 32bit and 64bit windows in my environment. I was under the assumption that as the project is set to use windows sdk 7.1, it would have linked to MSVCR71.dll. I cannot seem to get this to work.
As a matter of fact, like it is now it should work from a 32 bits windows to a 64 bits windows (I am using it that way, and no problems so far).
The catch is that it is running as a 32 bits service in the target 64 bits machine... but if you only want to execute a command or you can just settle with sending a 32 bits binary and executing it in the 32 bits environment inside the 64 bits machine you will be ok.
BTW I have been using Visual Studio 2005 all the time I could not find a more modern version that I had a license to use or that i could it make work.
I think that kavika13 (or another contributor) my memory is really bad... made some "make" style scripts for 2010... maybe they know more about 2010...
Anyway i haven't touched this in a few months so I might be completely wrong about some things I would need to take a look back at it... but ohh surprise!!, worst week in the year to find a spare time slot...
I think perhaps the problem I am having is because I am using VS2010, which from my basic understanding of MS tooling brings along with it MSVCR100.dll. I dont have a copy of VS2005 unfortunately with which to compile it. Would you be attach a compiled binary to the project with the git revision number in the name or something?
About the compiled binary, the latest binary in git (https://github.com/kavika13/RemCom/tree/45e902f957c2d1bba519f5c2d47d1e6e8de648d0/bin/Release) from Feb 13, 2012 its the one I compiled with VS2005 with today's latest sources.
Give it a try with your 64 bits windows
BTW browsing the git I've seen that kavira13 made some modifications to the VS2010 build file so he may know more about VS2010 compiling.
Unfortunately that version still doesn't work between my 2 64 bit machines, the installed service on the remote machine has a 'path to executable' of C:\WINDOWS\system32\RemComSvc.exe. I was under the impression that this should now be C:\WINDOWS. RemCom reports:
Initiating Connection to Remote Service . . . Failed
Couldn't start remote service
The system cannot find the file specified.
If I copy the exe from C:\WINDOWS\system32 into C:\WINDOWS\SysWOW64 I can start the service.
Interestingly in RemCom.cpp there are still a number of references to system32, ie.
_stprintf( szSvcExePath, _T("%s\ADMIN$\System32%s"), lpszMachine, RemComSVCEXE );
// Copy binary file from resources to \\remote\ADMIN$\System32
HANDLE hFileSvcExecutable = CreateFile(
szSvcExePath,
....
and
hService = ::CreateService(
hSCM, SERVICENAME, LONGSERVICENAME,
SERVICE_ALL_ACCESS,
SERVICE_WIN32_OWN_PROCESS,
SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL,
_T("%SystemRoot%\system32")RemComSVCEXE,
NULL, NULL, NULL, NULL, NULL );
I have removed all references to system32 on my fork, the service is then installed in c:\windows as I would expect. Unfortunately Im having a few problems getting it to compile without a reference to MSVCR100.dll
I've managed to get this to compile in VS2010 without linking to MSVCR100.dll, I had to change some VS project file settings. On my fork it now compiles, and works between 32 and 64 bit machines.
Hello Simojenki
I'd be very interested to get your binary of RemCom as the one I could download from here does not work when I call it from a 32bit machine to be remotely executed on a 64bit machine.
Thanks for helping
Briac
Hi, I can confirm same issue as jenkalator on 64b w7 machines, it's pointing to the system32 folder.
A patched binary for this issue would be nice.
Thanks kavika13 ;)