In my assembly program I called AllocConsole from the kernel32 library, however I do not know how to get input from the allocated console.
Is there any function that the winapi contains that will get input from the allocated console in the current program?
CALL AllocConsole
All of the functions such as ReadConsole require an input buffer, and I do not know how to get the input buffer for my allocated console, let alone whether the function even does what I need.
To summarize, is there a function in the winapi that can get input from the allocated console in a program?
Thanks
All of the functions such as ReadConsole require an input buffer, and I do not know how to get the input buffer
The functions you have to call are the same in C and in assembly language. So your problem is not assembly language specific.
You can get the standard input and standard output handles using the GetStdHandle function.
To get the input handle you must pass the constant STD_INPUT_HANDLE (-10 = 0xFFFFFFF6 in the case of a 32-bit program) as argument to the function.
Related
I want to generate shellcode using the following NASM code:
global _start
extern exit
section .text
_start:
xor rcx, rcx
or rcx, 10
call exit
The problem here is that I cannot use this because the address of exit function cannot be hard coded. So, how do I go about using library functions without having to re-implement them using system calls?
One way that I can think of, is to retrieve the address of exit function in a pre-processing program using GetProcAddress and substitute it in the shellcode at the appropriate place.
However, this method does not generate shellcode that can be run as it is. I'm sure there must be a better way to do it.
I am not an expert on writing shellcode, but you could try to find the import address table (IAT) of your target program and use the stored function pointers to call windows functions.
Note that you would be limited to the functions the target program uses.
Also you would have to let your shellcode calculate IAT's position relative to the process's base address due to relocations. Of course you could rely on Windows not relocating, but this might result in errors in a few cases.
Another issue is that you would have to find the target process's base address from outside.
A totally different attempt would be using syscalls, but they are really hard to use, not talking about the danger using them.
Information on PE file structure:
https://msdn.microsoft.com/en-us/library/ms809762.aspx
Hello I am writing a minifilter driver for intercepting all the irp packets from a certain process say a.exe .
So , in the driver code it can be done by applying a check on the command line arguments that started the process.
Does anyone know how can i retrieve the command line argument ??
Thanks in advance .
There's no supported way to do this from within kernel-mode. In fact, trying to access user-mode process information from the kernel is a pain in general. I would suggest firing up a request to a user-mode service, which can then find that information and pass it back down to your kernel component.
However, there an undocumented method to do it. If you can get a handle to an EPROCESS struct for the target process, you can get at a pointer to the PEB (process environment block) struct within it, which then has a pointer to an RTL_USER_PROCESS_PARAMETERS structure, which has a member called CommandLine.
Example:
UNICODE_STRING* commandLine = epProcess->Peb->ProcessParameters->CommandLine;
The downside to this is that EPROCESS is almost entirely opaque and PEB is semi-opaque too, meaning that it may change in future versions of Windows. I certainly wouldn't advocate trying this in production code.
Try using the NtQueryInformationProcess or ZwQueryInformationProcess function with the PROCESSINFOCLASS parameter as ProcessBasicInformation. The output parameter, ProcessInformation, will be a struct of type PROCESS_BASIC_INFORMATION. As Polynomial mentioned, this struct has a pointer to the process's PEB struct, which contains the information you are looking for in its ProcessParameters field.
I am trying to link a user space library into a windows kernel driver. It has a reference to __iob_func which is part of "libcmt.lib" (user space library).
I don't have access to this function in winddk. So, I am planning to define a stub for __iob_func which will try to emulate the same functionality as done in user space library.
Does anyone know what __iob_func do? I found the declaration of the function in the header files. But I am not sure what functionality it exactly does.
__iob_func() returns a pointer to the array of FILE descriptors that holds stdin, stdout, stderr and any FILE objects opened through the C runtime library. See the MSVC runtime library source _file.c.
If your user-space library code actually tries to do much with the C runtime, you'll probably run into a lot of headaches linking it into your kernel driver. Good luck.
Disassemble the following c code. cl /Fa mycode.c
fflush (stdin) ;
fflush (stdout) ;
fflush (stderr) ;
This is basically what the assembly file output with the /Fa switch on the c file will look like:
call ___iob_func ; invoke the c function __iob_func
push eax ; invoke fflush with 1 parameter
call _fflush
add esp, 04h ; realign the stack adding 4 bytes to
; the stack pointer (esp).
So, apparently the __iob_func returns a pointer to array or structure of input output buffer information; hence the iob acronym followed by func (__iob_func). i stands for input, o for output, b for buffer, etc......
That's just the fflush(stdin) function. fflush(stdout) repeats the same 4 lines with the only difference for stdout in the second line:
push eax + 020h
So, apparently each array member is composed of 32 bytes or 8 double words.
For stderr the assembler posted push eax + 040h or eax + 64 bytes
Microsoft Developer Network (MSDN) doesn't document the __iob_func function. But it's declaration probably would be something like the following: lpReturn __iob_func ( void )
32 bit assembly usually returns the value of a function in the eax register. And when the input parameter value of a function is described as an addition to a register (e.g. eax + 020h), it usually means that its referring to a structure or array of some type. So eax would be the starting address of the structure or array. And eax + 020h would be a location in that structure where information for stdout begins. eax + 040h would be the location where stderr begins.
So basically, if you want to use the __iob_func in your c program, you would have to prototype the function, and then perhaps create your own personal lib
mylib.def
LIBRARY msvcrt.dll
EXPORTS
__iob_func
And then run lib on that file.
LIB /def:mylib.def /machine:x86
That should create a 32 bit library called mylib.lib which you can use to link into your program.
I'm trying to execute a function in a running (old) Win32 Borland application (Window has class OLW_WINDOW). By using OllyDbg I've found out that the function has one parameter which is a memory address. One variable/value used by the function is stored at an offset of that address. My idea is to find that memory address (which is at an constant offset in a memory block), change the variable/value to what I want and then execute the function. To use WriteProcessMemory and CreateRemoteThread to execute is okey, but the problem is how to find the memory address/block? When opening "Memory map" in OllyDbg the memory block has no owner, section or contains. Is it possible to get a list of memory blocks created by a specified thread? Or could I get it from the application somehow? Btw: the function is normally executed when a button is clicked and the variable/value I want to set is a database ID listed (by name) in a listview (or equivalent).
The best thing to do is just call the function.
As an example here is a function which prints output to a console:
void ConsoleOutput(char* text);
To call it, we would find the address of this function in the target binary. Let's say it's found at 0xDEADC0DE.
We would form a typedef for a function pointer:
typedef void(__cdecl* tConsoleOutput)(char* text);
We would create an instance of that function pointer type
tConsoleOutput ConsoleOutput = (ConsoleOutput)0xDEADC0DE;
To call the function we would simply do:
ConsoleOutput("Hello");
Likewise for your project, you would input whatever argument you required.
Is it possible to somehow change standart I/O functions handle on Windows? Language preffered is C++. If I understand it right, by selecting console project, compiler just pre-allocate console for you, and operates all standart I/O functions to work with its handle. So, what I want to do is to let one Console app actually write into another app Console buffer. I though that I could get first´s Console handle, than pass it to second app by a file (I don´t know much about interprocess comunication, and this seems easy) and than somehow use for example prinf with the first app handle. Can this be done? I know how to get console handle, but I have no idea how to redirect printf to that handle. Its just study-purpose project to more understand of OS work behind this. I am interested in how printf knows what Console it is assiciated with.
If I understand you correctly, it sounds like you want the Windows API function AttachConsole(pid), which attaches the current process to the console owned by the process whose PID is pid.
If I understand you correct you can find the source code of application which you want to write in http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx. This example show how to write in stdin of another application and read it's stdout.
For general understanding. Compiler don't "pre-allocate console for you". Compiler use standard C/C++ libraries which write in the output. So if you use for example printf() the following code will be executed at the end will look like:
void Output (PCWSTR pszwText, UINT uTextLenght) // uTextLenght is Lenght in charakters
{
DWORD n;
UINT uCodePage = GetOEMCP(); // CP_OEMCP, CP_THREAD_ACP, CP_ACP
PSTR pszText = _alloca (uTextLenght);
// in the console are typically not used UNICODE, so
if (WideCharToMultiByte (uCodePage, 0, pszwText, uTextLenght,
pszText, uTextLenght, NULL, NULL) != (int)uTextLenght)
return;
WriteFile (GetStdHandle (STD_OUTPUT_HANDLE), pszText, uTextLenght, &n, NULL);
//_tprintf (TEXT("%.*ls"), uTextLenght, pszText);
//_puttchar();
//fwrite (pszText, sizeof(TCHAR), uTextLenght, stdout);
//_write (
}
So if one changes the value of STD_OUTPUT_HANDLE all output will be go to a file/pipe and so on. If instead of WriteFile the program use WriteConsole function such redirection will not works, but standard C/C++ library don't do this.
If you want redirect of stdout not from the child process but from the current process you can call SetStdHandle() directly (see http://msdn.microsoft.com/en-us/library/ms686244%28VS.85%29.aspx).
The "allocating of console" do a loader of operation system. It looks the word of binary EXE file (in the Subsystem part of IMAGE_OPTIONAL_HEADER see http://msdn.microsoft.com/en-us/library/ms680339%28VS.85%29.aspx) and if the EXE has 3 on this place (IMAGE_SUBSYSTEM_WINDOWS_CUI), than it use console of the parent process or create a new one. One can change a little this behavior in parameters of CreateProcess call (but only if you start child process in your code). This Subsystem flag of the EXE you define with respect of linker switch /subsystem (see http://msdn.microsoft.com/en-us/library/fcc1zstk%28VS.80%29.aspx).
If you want to redirect printf to a handle (FILE*), just do
fprintf(handle, "...");
For example replicating printf with fprintf
fprintf(stdout, "...");
Or error reporting
fprintf(stderr, "FATAL: %s fails", "smurf");
This is also how you write to files. fprintf(file, "Blah.");