views:

17

answers:

1

It is a trivial matter of redirecting a console program's standard input/output, but what about if the program uses advanced console functions? Like outputting colored text, throwing the cursor around and manipulating the console buffer directly? Can that also be captured and redirected to my own program for processing?

Note: I'm talking about the scenario where my app (not necessarily a console app) runs a console app and redirects its input/output to itself.

Note 2: In the end I'll want C# code, but for now let's stick to bare Win32 API and C or C++. I don't think it will be possible without PInvoke anyway, so let's get the basic principle down first (if at all possible).

+2  A: 

Unlike Linux, all color IO is not going to be captured with simple redirecting, so the only way to capture it is to hook on WinAPI calls (i.e. you will need to intercept system calls), which require administrative privileges, fragile and suspicious.

BarsMonster
Not to mention probably failing on machines with DEP enabled. :P Are you **sure** that it's the only way?
Vilx-
IIRC, Windows NT doesn't really have an "advanced console API" beyond stdin/stdout/stderr, so an approximation of such is done by the `cmd.exe` "terminal emulator" - by the GUI frontend, so to speak. I recall that I was making an application like that, many moons ago, and that I was just as frustrated with the situation :(
Piskvor
Hooking API calls for a single process doesn't require administrative privileges unless your own app runs under a LUA and the target app is elevated.
snemarch
@Piskvor WiNT does have special API calls for color IO, cursor, e.t.c but this all does not go to stdout...
BarsMonster
@Vilx No, DEP should not cause issues here, yes I am sure there is no easy/proper way of doing this. You might want to consider change the application you want to capture output from (if that's possible).
BarsMonster
I'm no expert in hooking API calls, but if I recall correctly, it involved changing a few bytes in-memory of the executable code loaded from a system DLL. Shouldn't that be in a read-only memory page?Anyway, I really just wanted to be ready for any possibility. Yes, the applications I have currently in mind only use stdin/stdout AFAIK, but I had intended the "master app" to be universal.Btw - can I be sure that the loaded apps wil share the same DLLs that my master app uses, so that API hooking works?
Vilx-
That DLL is system one, so yes it will be the same. You can't guarantee for non-system DLLs. DEP is only about executing code from data segments. You still can write to code memory, if you have enough priveleges.
BarsMonster
Btw - does hooking all the Console API functions also automatically intercept stdin/stdout/stderr? That is, does writing to these "files" ultimately get translated to Console API calls?
Vilx-
@Vilx-: *global* hooking of a system call is sorta complicated, but if you only need to hook a specific instance it's no trouble. Yes, the call is in a "system DLL", but those are loaded per-process with copy-on-write memory, and are normal usermode components, so no problem. See http://easyhook.codeplex.com/ :)
snemarch
@Vilx-: No, WinAPI have separate calls for usual IO and "advanced" one. So you will ahve to do both.
BarsMonster
@senmarch - well, I would need to hook them in _another_ process. That sounds kinda tricky...
Vilx-
@snemarch - oops, mistyped your username. Sorry about that! See my comment above!
Vilx-
@vilx-: hooking in another process isn't bad, as long as that process doesn't run elevated while your own process doesn't. It's a far amount of trickery to do hooking manually, that's why we use detours or easyhook instead :)
snemarch