X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=1.3 required=5.0 	tests=AWL,BAYES_00,SPF_PASS,URI_BLOGSPOT
X-Spam-Check-By: sourceware.org
From: Barry Kelly <bkelly DOT ie AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: DOS programs under "screen"
Date: Fri, 01 May 2009 21:10:29 +0100
Message-ID: <qdkmv4t11uurvn74epv24vpgngtu8dkud0@4ax.com>
References: <C2163734F5AC6346B64F4DD53C7F7A2803155C5A AT rxsprimary DOT accessrxs DOT com> 	 <okjpu495u4a7ad3cupjt10nd4iv53pt2ni AT 4ax DOT com> 	 <q4uru498ltbhiqfl8vt877lk0va00pk3ih AT 4ax DOT com> <416096c60905011226j27e942bcrf7661fb1693b5df1 AT mail DOT gmail DOT com>
In-Reply-To: <416096c60905011226j27e942bcrf7661fb1693b5df1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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.
>=20
> 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:

http://en.wikipedia.org/wiki/Local_Procedure_Call

> 2009/4/21 Christopher Faylor:
> > It can be done using the same technique as Console2:
> >
> > http://console.sourceforge.net
>=20
> 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
debugging loop.

Doing all this could be fun, but I reckon it would amount to a stack of
hacks. It also requires overbearing privileges.

-- Barry

--=20
http://barrkel.blogspot.com/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/