We Keep Coding

Changing the current working directory of cmd (from a child process)

So I am trying to write a cd -like program that can be executed using cmd and after it exits the working directory of the calling cmd process should be changed.
Now before this post is flagged as a duplicate: I am aware of this and this question that were asked for pretty much this exact problem but using Linux instead of Windows as well as being pretty broad and unspecific, and I am aware that similar limitations apply to Windows as well (changing the working directory of my process will not change the parent’s working directory).
There is actually is a working solution to this for linux. However it is using gdb for this, and I would like to achieve this task using only built-in Windows utilities (WinAPI, dotNET, etc.).
What I have tried so far
I did manage to use Cheat Engine and the OpenProcess() / WriteProcessMemory() WinAPI funtions to successfully override cmd's working directory. However this solution feels sloppy and doesn't work well (or at least requires more work to be put into.)
My question
Is there a different (maybe simpler?) way on Windows to achieve this? Like a way to invoke/inject code to the cmd process to execute cd whatever\directory\I\want directly without overriding its memory? I have seen the CreateRemoteThread() functions however I didn't manage to find a way to put them to use.
FYI: I am mainly using C# but C/C++ solutions should help too as long as they are based on the native Microsoft libraries.

This post describes a Windows implementation of a function that launches a child process, creates pipes to stdin and stdout from which a command is sent, and a response is returned. Finally, once all response is captured the child process is terminated. If this sounds familiar it is similar in concept to Linux's popen() function with the exception that this implementation was specifically created to capture the response into a buffer of any command that returns one. (Also included is a variant for use when no-response is expected or needed.)
The full source can be adapted for use within a standalone executable, or as an API. (.dll) Either way, the resulting functions accept and process any command using standard Windows CMD syntax. The function cmd_rsp(...) returns the Windows response via stdout into a self-sizing buffer.
The exported prototypes are:
int __declspec(dllexport) cmd_rsp(const char *command, char **chunk, unsigned int size);
int __declspec(dllexport) cmd_no_rsp(const char *command);
A simple use case when capturing a response:
#include "cmd_rsp.h"
int main(void)
{
char *buf = {0};
buf = calloc(100, 1);//initialize to some initial size
if(!buf)return 0;
cmd_rsp("dir /s", &buf, 100);//buffer will grow to accommodate response as needed.
printf("%s", buf);
free(buf);
return 0;
}
A simple use case when response is not needed:
#include "cmd_rsp.h"
int main(void)
{
cmd_no_rsp("cd C:\\dir1\\dir2");
return 0;
}
A detailed description of purpose and usage is described in the link provided above. To illustrate, here are a few sample command inputs, each in this case change the working directory, then execute a command from that directory:
A command to change to sqlite directory, then execute a query:
cd c:\\tempExtract\\sqlite\\Tools\\sqlite-tools-win32-x86-3250300 && sqlite3.exe .\\extract.db \"select * from event, eventdata where eventType=38 and eventdata .eventid=event.eventid\
A command to change to teraterm directory, then execute a script:
"c:\\Program Files (x86)\\teraterm\" && ttpmacro c:\\DevPhys\\LPCR_2\\play\\Play.ttl
A command to change directory then execute a command to send multiple digital acquisition channel settings.
cd C:\\Dir1\\Dir2\\Dir3\\support\\Exes\\WriteDigChannel && .\\WriteDigChannel.exe P1_CH0 1 && .\\WriteDigChannel.exe P1_C H0 0 && .\\WriteDigChannel.exe P1_CH0 1
A recursive directory search from a specified location:
cd C:\\dir1\\dir2 && dir /s /b

I got it working. As was suggested SendInput finally did the trick.
I used a combination of WinAPI calls to GetForegroundWindow() / SetForegroundWindow() and the Windows Forms System.Windows.Forms.SendKeys.SendWait() Method to achieve what I wanted:
Upon calling my cd-wrapper program (sd.exe) and providing my custom target directory (~/ home) it generates the corresponding command along with the "Enter-Pressed-Event" to be sent to it's parent cmd process.
Here's the complete C# code:
if (args.Length != 1)
{
Console.WriteLine(Directory.GetCurrentDirectory());
return;
}
string targetDirectory = args[0];
string command = string.Empty;
if (targetDirectory.Equals("~"))
{
command = #"pushd C:\Users\fred\Desktop";
}
else if (!Directory.Exists(targetDirectory))
{
Console.WriteLine("I/O Error: No such file or directory.");
return;
}
else
{
command = #"cd " + targetDirectory;
}
Target target = Target.Create(Process.GetCurrentProcess().GetParentProcess());
target.SendKeys(command + "{ENTER}", true);
Note that I kind of started to write a complete Framework for this and similar problems alongside this project that contains all my different approaches to this question and the low level WinAPI calls as well as the Extension methods to get the parent process :D
As it would be a bit overkill to paste all of it's code in this answer, here's the GitHub. If I can find the time I'll go ahead and optimize the code, but for now this'll do. Hope this helps anyone encountering a similar problem :)
Edit:
An even "cleaner" way is to use dll injection to directly make cmd switch it's working directory. While it is a lot harder to get working it has the advantage of not littering the cmd command history as compared to the approach described above. In addition to that cmd seems to be aware of any changes to it's current working directory, so it automatically updates the prompt text. Once I have a fully working example, that allows to dynamically specify the target directory I will post it here :)

What API does VBoxManage.exe use?

VBoxManage.exe is an Oracle VirtualBox companion utility, which allows to control VMs via command line. It can do numerous operations, including start/stop and screen capturing.
I am interested, which API it uses?
How can I capture VM screen or send keyboard or mouse commands there without this heavy commandline utility? Which language is better? Is is possible to access this API with Java?

One of the advantages to using an open source project is supposed to be that you can answer such questions by looking at the source.
VBoxManage is located in the source repository under /src/VBox/Frontends/VBoxManage. The code you're looking for is in VBoxManageControlVM.cpp under the condition if (!strcmp(a->argv[1], "screenshotpng")):
ComPtr<IDisplay> pDisplay;
CHECK_ERROR_BREAK(console, COMGETTER(Display)(pDisplay.asOutParam()));
ULONG width, height, bpp;
CHECK_ERROR_BREAK(pDisplay,
GetScreenResolution(displayIdx, &width, &height, &bpp));
com::SafeArray<BYTE> saScreenshot;
CHECK_ERROR_BREAK(pDisplay, TakeScreenShotPNGToArray(displayIdx,
width, height, ComSafeArrayAsOutParam(saScreenshot)));
RTFILE pngFile = NIL_RTFILE;
vrc = RTFileOpen(&pngFile, a->argv[2], RTFILE_O_OPEN_CREATE | RTFILE_O_WRITE |
RTFILE_O_TRUNCATE | RTFILE_O_DENY_ALL);
if (RT_FAILURE(vrc))
{
RTMsgError("Failed to create file '%s'. rc=%Rrc", a->argv[2], vrc);
rc = E_FAIL;
break;
}
vrc = RTFileWrite(pngFile, saScreenshot.raw(), saScreenshot.size(), NULL);
if (RT_FAILURE(vrc))
{
RTMsgError("Failed to write screenshot to file '%s'. rc=%Rrc",
a->argv[2], vrc);
rc = E_FAIL;
}
RTFileClose(pngFile);
So it's done via a COM API, and you can look at:
Is it possible to call a COM API from Java?
Googling for TakeScreenShotPNGToArray finds the display interface:
https://www.virtualbox.org/sdkref/interface_i_display.html
From there you can find the list of all the other things like mouse and keyboard:
https://www.virtualbox.org/sdkref/annotated.html

get itemtext from SysListView32

i am trying to get the text in SysListView32 from another app by C#.
i can get the LVM_GETITEMCOUNT well but LVM_GETITEMW = 0x1000 + 13 always returns -1. how can i get the text by C#? i am new. thanks very much!
ParenthWnd = FindWindow(ParentClass, ParentWindow);
if (!ParenthWnd.Equals(IntPtr.Zero))
{
zWnd = FindWindowEx(ParenthWnd, zWnd, zClass, zWindow);
if (!zWnd.Equals(IntPtr.Zero))
{
int user = SendMessage(zWnd, LVM_GETITEMCOUNT, 0, 0);
}

You need to work harder to read and write the LVITEM memory since you are working with a control owned by another process. You therefore need to read and write memory in that process. You can't do that without calling ReadProcessMemory, WriteProcessMemory etc.
The most commonly cited example of the techniques involved is this Code Project article: Stealing Program's Memory. Watch out for 32/64 bit gotchas.

how to convert this to C#

Hi i have the following code which i would like to convert to C#. Could you share some light here how can i convert those to C#? i am not well familiar with C++. Especially on the function DeviceIoControl which it is calling the WinBase API. In C#, what function should i use to replace DeviceIOCOntrol?
shareMode = FILE_SHARE_READ | FILE_SHARE_WRITE;
accessMode = GENERIC_READ | GENERIC_WRITE;
sprintf(ff, "\\\\.\\%s", device);
hFile = CreateFile(ff, accessMode, shareMode, NULL, OPEN_EXISTING, 0, NULL);
if(hFile == INVALID_HANDLE_VALUE) {
*response = -1;
sprintf((response + 1), "Failed to open device %s", device);
return;
}
status = DeviceIoControl(hFile,
IOCTL_SCSI_GET_ADDRESS,
NULL,
0,
inquiry_data,
sizeof(inquiry_data),
&returned,
FALSE);

You must use P/Invoke interop to access DeviceIoControl. Here is a link that has similar calls and should be a good starting point: Defrag API C# wrappers

This is retrieving the SCSI bus #, ID # on that bus, and LUN on that ID. You'll probably need to figure out what's being done with that to figure out how to translate/replace it meaningfully. If memory serves, you can retrieve some of the same information via WMI, but there's a pretty fair chance that won't do a lot of good -- the primary uses for this information is to pass it back when making other DeviceIoControl calls.

How determine application subsystem from executable file

I'm trying to detect console application from the list of the executables files installed on my computer.
How to implement it?
Every application has a "subsystem" (windows application, console application or library; specified to the linker as option, I think). How to detect it using only the executable file?
Are there alternative methods to detect the application characteristic? Additionally, are there any method for detecting the file is a really executable file?
Any issue for JAR executables?

Without any programming you receive this information from
dumpbin.exe /headers filename
Some information gives you GetBinaryType and SHGetFileInfo functions. All information which you needs you will find in the header of every executable file. See Microsoft Portable Executable and Common Object File Format Specification in http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx.
One can use also Debug Help Library API from DbgHelp.dll (see http://msdn.microsoft.com/en-us/library/ms679309(VS.85).aspx). IMAGE_DOS_HEADER, IMAGE_DOS_SIGNATURE and IMAGE_NT_HEADERS32 structures gives you full information.
UPDATED (add some code):
Or you can use only structures defined in WinNT.h. The corresponding code can start like following
// Open source file
hSrcFile = CreateFile (pszSrcFilename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if (hSrcFile == INVALID_HANDLE_VALUE)
__leave;
// Map the source file in memory
hMapSrcFile = CreateFileMapping (hSrcFile, NULL, PAGE_READONLY, 0, 0, NULL); // SEC_IMAGE
if (!hMapSrcFile || hMapSrcFile == INVALID_HANDLE_VALUE)
__leave;
// Map the entire of the source file is memory
pSrcFile = (PBYTE) MapViewOfFile (hMapSrcFile, FILE_MAP_READ, 0, 0, 0);
if (!pSrcFile)
__leave;
pDosHeader = (IMAGE_DOS_HEADER *)pSrcFile;
if (pDosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
printf ("it is not a EXE file.\n");
return 1;
}
printf ("IMAGE_DOS_HEADER size %d (0x%X) bytes\n", sizeof(IMAGE_DOS_HEADER), sizeof(IMAGE_DOS_HEADER));
DumpDosHeader (pDosHeader);
pDosExeStart = (PBYTE)pDosHeader + pDosHeader->e_cparhdr*16;
if (g_bDump)
HexDump (1, pDosExeStart, pDosHeader->e_lfanew - pDosHeader->e_cparhdr*16, (DWORD)pDosExeStart);
if (pDosHeader->e_lfanew) {
IMAGE_NT_HEADERS32 *pNtHeader = (IMAGE_NT_HEADERS32 *)((PBYTE)pDosHeader + pDosHeader->e_lfanew);
//IMAGE_NT_HEADERS64 *pNtHeader64 = (IMAGE_NT_HEADERS64 *)((PBYTE)pDosHeader + pDosHeader->e_lfanew);
IMAGE_SECTION_HEADER *pFirstSectionHeader = (IMAGE_SECTION_HEADER *)((PBYTE)&pNtHeader->OptionalHeader +
pNtHeader->FileHeader.SizeOfOptionalHeader);
if (pNtHeader->Signature == IMAGE_NT_SIGNATURE) {
int i;
printf ("\nPE signature\n");
printf ("\nIMAGE_FILE_HEADER: size %d (0x%X) bytes, offset from the begin of the file: %d (0x%X)\n",
sizeof(IMAGE_FILE_HEADER), sizeof(IMAGE_FILE_HEADER),
((PBYTE)&pNtHeader->FileHeader - (PBYTE)pDosHeader), ((PBYTE)&pNtHeader->FileHeader - (PBYTE)pDosHeader));
DumpFileHeader (1, &pNtHeader->FileHeader);
switch (pNtHeader->OptionalHeader.Magic) {
case IMAGE_NT_OPTIONAL_HDR32_MAGIC:
printf ("\nIMAGE_OPTIONAL_HEADER32: size %d (0x%X) bytes, offset from the begin of the file: %d (0x%X)\n",
sizeof(IMAGE_OPTIONAL_HEADER32), sizeof(IMAGE_OPTIONAL_HEADER32),
((PBYTE)&pNtHeader->OptionalHeader - (PBYTE)pDosHeader), ((PBYTE)&pNtHeader->OptionalHeader - (PBYTE)pDosHeader));
DumpOptionalHeader32 (1, &pNtHeader->OptionalHeader);
break;
case IMAGE_NT_OPTIONAL_HDR64_MAGIC:
break;
case IMAGE_ROM_OPTIONAL_HDR_MAGIC:
break;
}

To determine the subsystem you need to read the executable file and parse the PE-Header. A detailed article on how to do that is found here.
A JAR file is just a ZIP file with some specific files and folder structure so you can open it like a regular zip file and look for those files and folders that are always there.

Windows PE executables have a field in the header that specify the subsystem (Console, GUI, Posix, and so on). They also have fields that can be used to identify executables in general. Download the PE specification from msdn.com to get the details.

It's possible to detect subsystem type using PeNet library, for example change see:
using PeNet;
...
var file = new PeFile(<path>);
if (file.ImageNtHeaders.OptionalHeader.Subsystem == 2 /*PeNet.Header.Pe.SubsystemType.WindowsGui*/)
{
// This is UI executable...
}
See also similar commit.
Use 0.5.0 version to get less dependencies, or use latest to get latest version.