This is the mail archive of the
mailing list for the Cygwin project.
Re: DOS programs under "screen"
- From: Barry Kelly <bkelly dot ie at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 01 May 2009 21:10:29 +0100
- Subject: Re: DOS programs under "screen"
- References: <C2163734F5AC6346B64F4DD53C7F7A2803155C5A@rxsprimary.accessrxs.com> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Andy Koppe wrote:
> 2009/4/21 Barry Kelly:
> > Windows implements console mode as a client-server protocol between the
> > executable (ntvdm.exe for DOS apps) and winsrv.dll (hosted in
> > csrss.exe), but the protocol isn't easily hookable. I guess one would
> > have to hijack the console APIs, perhaps by stepping into the
> > application using debugging APIs and overwriting the DLL imports, but it
> > would be pretty painful.
> Hi Barry, have you got any pointers to documentation or reverse
> engineering attempts for that console protocol?
It is not just the console. It's a substantial fraction of the Win32
API. The NT kernel transfers the data (LPCs, local/lightweight procedure
calls) across a bit like a microkernel OS design; at least that's the
theory, in practice it's all pretty monolithic.
You can read a little bit more about it here:
> 2009/4/21 Christopher Faylor:
> > It can be done using the same technique as Console2:
> > http://console.sourceforge.net
> I don't understand how. ReadConsoleOutput() on the hidden console only
> gives you the cooked output in terms of character cell contents and
> attributes, whereas the raw output as it came from the console app
> would need to be sent to the pty to be displayed by the likes of
> screen. As far as I can see, recreating the raw output from the cooked
> one isn't possible in general.
You could intercept the calls to the console APIs by finding out where
the imports resolve to using GetProcAddress etc. (i.e. somewhere inside
where kernel32.dll is mapped to in the process), then adjusting the page
permissions (VirtualProtect etc.) and rewriting the entrypoint code
(save original 5 bytes of code, insert JMP <your-stub-here>, and at
<your-stub-here> save the parameters, update your stuff, execute the
missing code (the code you skipped - may need adjustment owing to
code-relative addressing modes in e.g. Jcc instructions), then JMP back.
That's all assuming you have access to the innards of the process, most
likely with debugging APIs like CreateRemoteThread, DebugActiveProcess /
CreateProcess w/ debug, and WaitForDebugEvent / ContinueDebugEvent
Doing all this could be fun, but I reckon it would amount to a stack of
hacks. It also requires overbearing privileges.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html