2010-05-31 06:28:55 +00:00
|
|
|
/*
|
2012-10-25 20:40:41 +00:00
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
* PROJECT: ReactOS Console Server DLL
|
|
|
|
* FILE: win32ss/user/consrv/conoutput.c
|
|
|
|
* PURPOSE: Console I/O functions
|
|
|
|
* PROGRAMMERS:
|
2010-05-31 06:28:55 +00:00
|
|
|
*/
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
/* INCLUDES *******************************************************************/
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-10-23 22:31:36 +00:00
|
|
|
#include "consrv.h"
|
|
|
|
#include "conio.h"
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
/* GLOBALS ********************************************************************/
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-30 22:59:47 +00:00
|
|
|
#define TAB_WIDTH 8
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
#define ConioInitRect(Rect, top, left, bottom, right) \
|
2012-11-17 15:41:31 +00:00
|
|
|
do { \
|
|
|
|
((Rect)->Top) = top; \
|
|
|
|
((Rect)->Left) = left; \
|
|
|
|
((Rect)->Bottom) = bottom; \
|
|
|
|
((Rect)->Right) = right; \
|
|
|
|
} while(0)
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
#define ConioIsRectEmpty(Rect) \
|
|
|
|
(((Rect)->Left > (Rect)->Right) || ((Rect)->Top > (Rect)->Bottom))
|
|
|
|
|
|
|
|
#define ConsoleUnicodeCharToAnsiChar(Console, dChar, sWChar) \
|
|
|
|
WideCharToMultiByte((Console)->OutputCodePage, 0, (sWChar), 1, (dChar), 1, NULL, NULL)
|
|
|
|
|
|
|
|
#define ConsoleAnsiCharToUnicodeChar(Console, dWChar, sChar) \
|
|
|
|
MultiByteToWideChar((Console)->OutputCodePage, 0, (sChar), 1, (dWChar), 1)
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
/* PRIVATE FUNCTIONS **********************************************************/
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
PBYTE FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioCoordToPointer(PCONSOLE_SCREEN_BUFFER Buff, ULONG X, ULONG Y)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
return &Buff->Buffer[2 * (((Y + Buff->VirtualY) % Buff->ScreenBufferSize.Y) * Buff->ScreenBufferSize.X + X)];
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static VOID FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ClearLineBuffer(PCONSOLE_SCREEN_BUFFER Buff)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
PBYTE Ptr = ConioCoordToPointer(Buff, 0, Buff->CursorPosition.Y);
|
2010-05-31 06:28:55 +00:00
|
|
|
UINT Pos;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
for (Pos = 0; Pos < Buff->ScreenBufferSize.X; Pos++)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
/* Fill the cell */
|
|
|
|
*Ptr++ = ' ';
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
*Ptr++ = Buff->ScreenDefaultAttrib;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS FASTCALL
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConSrvCreateScreenBuffer(IN OUT PCONSOLE Console,
|
|
|
|
OUT PCONSOLE_SCREEN_BUFFER* Buffer,
|
|
|
|
IN COORD ScreenBufferSize,
|
|
|
|
IN USHORT ScreenAttrib,
|
2013-03-09 01:39:49 +00:00
|
|
|
IN USHORT PopupAttrib,
|
|
|
|
IN BOOLEAN IsCursorVisible,
|
|
|
|
IN ULONG CursorSize)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Console == NULL || Buffer == NULL)
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
|
|
|
|
*Buffer = RtlAllocateHeap(ConSrvHeap, HEAP_ZERO_MEMORY, sizeof(CONSOLE_SCREEN_BUFFER));
|
|
|
|
if (NULL == *Buffer)
|
|
|
|
{
|
|
|
|
return STATUS_INSUFFICIENT_RESOURCES;
|
|
|
|
}
|
|
|
|
|
|
|
|
(*Buffer)->Header.Type = CONIO_SCREEN_BUFFER_MAGIC;
|
|
|
|
(*Buffer)->Header.Console = Console;
|
|
|
|
(*Buffer)->Header.HandleCount = 0;
|
|
|
|
(*Buffer)->ScreenBufferSize = ScreenBufferSize;
|
|
|
|
|
|
|
|
(*Buffer)->Buffer = RtlAllocateHeap(ConSrvHeap, HEAP_ZERO_MEMORY, (*Buffer)->ScreenBufferSize.X * (*Buffer)->ScreenBufferSize.Y * 2);
|
|
|
|
if (NULL == (*Buffer)->Buffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
RtlFreeHeap(ConSrvHeap, 0, *Buffer);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_INSUFFICIENT_RESOURCES;
|
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
|
|
|
(*Buffer)->ShowX = 0;
|
|
|
|
(*Buffer)->ShowY = 0;
|
|
|
|
(*Buffer)->VirtualY = 0;
|
|
|
|
|
2013-03-10 02:23:46 +00:00
|
|
|
(*Buffer)->CursorInfo.bVisible = (IsCursorVisible && (CursorSize != 0));
|
|
|
|
(*Buffer)->CursorInfo.dwSize = min(max(CursorSize, 0), 100);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
|
|
|
(*Buffer)->ScreenDefaultAttrib = ScreenAttrib;
|
|
|
|
(*Buffer)->PopupDefaultAttrib = PopupAttrib;
|
2010-05-31 06:28:55 +00:00
|
|
|
/* initialize buffer to be empty with default attributes */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
for ((*Buffer)->CursorPosition.Y = 0 ; (*Buffer)->CursorPosition.Y < (*Buffer)->ScreenBufferSize.Y; (*Buffer)->CursorPosition.Y++)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ClearLineBuffer(*Buffer);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
(*Buffer)->Mode = ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT;
|
|
|
|
(*Buffer)->CursorPosition = (COORD){0, 0};
|
2010-05-31 06:28:55 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
InsertHeadList(&Console->BufferList, &(*Buffer)->ListEntry);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static VOID FASTCALL
|
2013-01-13 19:50:52 +00:00
|
|
|
ConioNextLine(PCONSOLE_SCREEN_BUFFER Buff, SMALL_RECT* UpdateRect, UINT *ScrolledLines)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
/* If we hit bottom, slide the viewable screen */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (++Buff->CursorPosition.Y == Buff->ScreenBufferSize.Y)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.Y--;
|
|
|
|
if (++Buff->VirtualY == Buff->ScreenBufferSize.Y)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
Buff->VirtualY = 0;
|
|
|
|
}
|
|
|
|
(*ScrolledLines)++;
|
|
|
|
ClearLineBuffer(Buff);
|
|
|
|
if (UpdateRect->Top != 0)
|
|
|
|
{
|
|
|
|
UpdateRect->Top--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
UpdateRect->Left = 0;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect->Right = Buff->ScreenBufferSize.X - 1;
|
|
|
|
UpdateRect->Bottom = Buff->CursorPosition.Y;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioWriteConsole(PCONSOLE Console, PCONSOLE_SCREEN_BUFFER Buff,
|
2010-05-31 06:28:55 +00:00
|
|
|
CHAR *Buffer, DWORD Length, BOOL Attrib)
|
|
|
|
{
|
|
|
|
UINT i;
|
|
|
|
PBYTE Ptr;
|
|
|
|
SMALL_RECT UpdateRect;
|
|
|
|
LONG CursorStartX, CursorStartY;
|
|
|
|
UINT ScrolledLines;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
CursorStartX = Buff->CursorPosition.X;
|
|
|
|
CursorStartY = Buff->CursorPosition.Y;
|
|
|
|
UpdateRect.Left = Buff->ScreenBufferSize.X;
|
|
|
|
UpdateRect.Top = Buff->CursorPosition.Y;
|
2010-05-31 06:28:55 +00:00
|
|
|
UpdateRect.Right = -1;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect.Bottom = Buff->CursorPosition.Y;
|
2010-05-31 06:28:55 +00:00
|
|
|
ScrolledLines = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < Length; i++)
|
|
|
|
{
|
2013-01-30 22:59:47 +00:00
|
|
|
/*
|
|
|
|
* If we are in processed mode, interpret special characters and
|
|
|
|
* display them correctly. Otherwise, just put them into the buffer.
|
|
|
|
*/
|
2010-05-31 06:28:55 +00:00
|
|
|
if (Buff->Mode & ENABLE_PROCESSED_OUTPUT)
|
|
|
|
{
|
2013-01-30 22:59:47 +00:00
|
|
|
/* --- CR --- */
|
|
|
|
if (Buffer[i] == '\r')
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = 0;
|
|
|
|
UpdateRect.Left = min(UpdateRect.Left, (LONG)Buff->CursorPosition.X);
|
|
|
|
UpdateRect.Right = max(UpdateRect.Right, (LONG)Buff->CursorPosition.X);
|
2013-01-30 22:59:47 +00:00
|
|
|
continue;
|
|
|
|
}
|
2010-05-31 06:28:55 +00:00
|
|
|
/* --- LF --- */
|
2013-01-30 22:59:47 +00:00
|
|
|
else if (Buffer[i] == '\n')
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = 0;
|
2010-05-31 06:28:55 +00:00
|
|
|
ConioNextLine(Buff, &UpdateRect, &ScrolledLines);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* --- BS --- */
|
|
|
|
else if (Buffer[i] == '\b')
|
|
|
|
{
|
|
|
|
/* Only handle BS if we're not on the first pos of the first line */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (0 != Buff->CursorPosition.X || 0 != Buff->CursorPosition.Y)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (0 == Buff->CursorPosition.X)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
/* slide virtual position up */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = Buff->ScreenBufferSize.X - 1;
|
|
|
|
Buff->CursorPosition.Y--;
|
|
|
|
UpdateRect.Top = min(UpdateRect.Top, (LONG)Buff->CursorPosition.Y);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X--;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Ptr = ConioCoordToPointer(Buff, Buff->CursorPosition.X, Buff->CursorPosition.Y);
|
2010-05-31 06:28:55 +00:00
|
|
|
Ptr[0] = ' ';
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Ptr[1] = Buff->ScreenDefaultAttrib;
|
|
|
|
UpdateRect.Left = min(UpdateRect.Left, (LONG)Buff->CursorPosition.X);
|
|
|
|
UpdateRect.Right = max(UpdateRect.Right, (LONG)Buff->CursorPosition.X);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* --- TAB --- */
|
|
|
|
else if (Buffer[i] == '\t')
|
|
|
|
{
|
|
|
|
UINT EndX;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect.Left = min(UpdateRect.Left, (LONG)Buff->CursorPosition.X);
|
|
|
|
EndX = (Buff->CursorPosition.X + TAB_WIDTH) & ~(TAB_WIDTH - 1);
|
|
|
|
EndX = min(EndX, Buff->ScreenBufferSize.X);
|
|
|
|
Ptr = ConioCoordToPointer(Buff, Buff->CursorPosition.X, Buff->CursorPosition.Y);
|
|
|
|
while (Buff->CursorPosition.X < EndX)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
*Ptr++ = ' ';
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
*Ptr++ = Buff->ScreenDefaultAttrib;
|
|
|
|
Buff->CursorPosition.X++;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect.Right = max(UpdateRect.Right, (LONG)Buff->CursorPosition.X - 1);
|
|
|
|
if (Buff->CursorPosition.X == Buff->ScreenBufferSize.X)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
if (Buff->Mode & ENABLE_WRAP_AT_EOL_OUTPUT)
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = 0;
|
2010-05-31 06:28:55 +00:00
|
|
|
ConioNextLine(Buff, &UpdateRect, &ScrolledLines);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X--;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
2013-03-24 17:08:10 +00:00
|
|
|
// /* --- BEL ---*/
|
|
|
|
// else if (Buffer[i] == '\a')
|
|
|
|
// {
|
|
|
|
// // FIXME: This MUST BE moved to the terminal emulator frontend!!
|
|
|
|
// DPRINT1("Bell\n");
|
|
|
|
// // SendNotifyMessage(Console->hWindow, PM_CONSOLE_BEEP, 0, 0);
|
|
|
|
// continue;
|
|
|
|
// }
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect.Left = min(UpdateRect.Left, (LONG)Buff->CursorPosition.X);
|
|
|
|
UpdateRect.Right = max(UpdateRect.Right, (LONG)Buff->CursorPosition.X);
|
|
|
|
Ptr = ConioCoordToPointer(Buff, Buff->CursorPosition.X, Buff->CursorPosition.Y);
|
2010-05-31 06:28:55 +00:00
|
|
|
Ptr[0] = Buffer[i];
|
|
|
|
if (Attrib)
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Ptr[1] = Buff->ScreenDefaultAttrib;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X++;
|
|
|
|
if (Buff->CursorPosition.X == Buff->ScreenBufferSize.X)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
if (Buff->Mode & ENABLE_WRAP_AT_EOL_OUTPUT)
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = 0;
|
2010-05-31 06:28:55 +00:00
|
|
|
ConioNextLine(Buff, &UpdateRect, &ScrolledLines);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->CursorPosition.X = CursorStartX;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-19 21:48:22 +00:00
|
|
|
if (!ConioIsRectEmpty(&UpdateRect) && Buff == Console->ActiveBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
ConioWriteStream(Console, &UpdateRect, CursorStartX, CursorStartY, ScrolledLines,
|
|
|
|
Buffer, Length);
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
__inline BOOLEAN ConioGetIntersection(
|
2013-01-13 19:50:52 +00:00
|
|
|
SMALL_RECT* Intersection,
|
|
|
|
SMALL_RECT* Rect1,
|
|
|
|
SMALL_RECT* Rect2)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
if (ConioIsRectEmpty(Rect1) ||
|
|
|
|
(ConioIsRectEmpty(Rect2)) ||
|
|
|
|
(Rect1->Top > Rect2->Bottom) ||
|
|
|
|
(Rect1->Left > Rect2->Right) ||
|
|
|
|
(Rect1->Bottom < Rect2->Top) ||
|
|
|
|
(Rect1->Right < Rect2->Left))
|
|
|
|
{
|
|
|
|
/* The rectangles do not intersect */
|
|
|
|
ConioInitRect(Intersection, 0, -1, 0, -1);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
ConioInitRect(Intersection,
|
|
|
|
max(Rect1->Top, Rect2->Top),
|
|
|
|
max(Rect1->Left, Rect2->Left),
|
|
|
|
min(Rect1->Bottom, Rect2->Bottom),
|
|
|
|
min(Rect1->Right, Rect2->Right));
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
__inline BOOLEAN ConioGetUnion(
|
2013-01-13 19:50:52 +00:00
|
|
|
SMALL_RECT* Union,
|
|
|
|
SMALL_RECT* Rect1,
|
|
|
|
SMALL_RECT* Rect2)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
if (ConioIsRectEmpty(Rect1))
|
|
|
|
{
|
|
|
|
if (ConioIsRectEmpty(Rect2))
|
|
|
|
{
|
|
|
|
ConioInitRect(Union, 0, -1, 0, -1);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*Union = *Rect2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (ConioIsRectEmpty(Rect2))
|
|
|
|
{
|
|
|
|
*Union = *Rect1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ConioInitRect(Union,
|
|
|
|
min(Rect1->Top, Rect2->Top),
|
|
|
|
min(Rect1->Left, Rect2->Left),
|
|
|
|
max(Rect1->Bottom, Rect2->Bottom),
|
|
|
|
max(Rect1->Right, Rect2->Right));
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
/*
|
|
|
|
* Move from one rectangle to another. We must be careful about the order that
|
|
|
|
* this is done, to avoid overwriting parts of the source before they are moved.
|
|
|
|
*/
|
2010-05-31 06:28:55 +00:00
|
|
|
static VOID FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioMoveRegion(PCONSOLE_SCREEN_BUFFER ScreenBuffer,
|
2013-01-13 19:50:52 +00:00
|
|
|
SMALL_RECT* SrcRegion,
|
|
|
|
SMALL_RECT* DstRegion,
|
|
|
|
SMALL_RECT* ClipRegion,
|
2010-05-31 06:28:55 +00:00
|
|
|
WORD Fill)
|
|
|
|
{
|
|
|
|
int Width = ConioRectWidth(SrcRegion);
|
|
|
|
int Height = ConioRectHeight(SrcRegion);
|
|
|
|
int SX, SY;
|
|
|
|
int DX, DY;
|
|
|
|
int XDelta, YDelta;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
SY = SrcRegion->Top;
|
|
|
|
DY = DstRegion->Top;
|
|
|
|
YDelta = 1;
|
|
|
|
if (SY < DY)
|
|
|
|
{
|
|
|
|
/* Moving down: work from bottom up */
|
|
|
|
SY = SrcRegion->Bottom;
|
|
|
|
DY = DstRegion->Bottom;
|
|
|
|
YDelta = -1;
|
|
|
|
}
|
|
|
|
for (i = 0; i < Height; i++)
|
|
|
|
{
|
|
|
|
PWORD SRow = (PWORD)ConioCoordToPointer(ScreenBuffer, 0, SY);
|
|
|
|
PWORD DRow = (PWORD)ConioCoordToPointer(ScreenBuffer, 0, DY);
|
|
|
|
|
|
|
|
SX = SrcRegion->Left;
|
|
|
|
DX = DstRegion->Left;
|
|
|
|
XDelta = 1;
|
|
|
|
if (SX < DX)
|
|
|
|
{
|
|
|
|
/* Moving right: work from right to left */
|
|
|
|
SX = SrcRegion->Right;
|
|
|
|
DX = DstRegion->Right;
|
|
|
|
XDelta = -1;
|
|
|
|
}
|
|
|
|
for (j = 0; j < Width; j++)
|
|
|
|
{
|
|
|
|
WORD Cell = SRow[SX];
|
|
|
|
if (SX >= ClipRegion->Left && SX <= ClipRegion->Right
|
|
|
|
&& SY >= ClipRegion->Top && SY <= ClipRegion->Bottom)
|
|
|
|
{
|
|
|
|
SRow[SX] = Fill;
|
|
|
|
}
|
|
|
|
if (DX >= ClipRegion->Left && DX <= ClipRegion->Right
|
|
|
|
&& DY >= ClipRegion->Top && DY <= ClipRegion->Bottom)
|
|
|
|
{
|
|
|
|
DRow[DX] = Cell;
|
|
|
|
}
|
|
|
|
SX += XDelta;
|
|
|
|
DX += XDelta;
|
|
|
|
}
|
|
|
|
SY += YDelta;
|
|
|
|
DY += YDelta;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
VOID WINAPI
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioDeleteScreenBuffer(PCONSOLE_SCREEN_BUFFER Buffer)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console = Buffer->Header.Console;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
RemoveEntryList(&Buffer->ListEntry);
|
|
|
|
if (Buffer == Console->ActiveBuffer)
|
|
|
|
{
|
|
|
|
/* Deleted active buffer; switch to most recently created */
|
|
|
|
Console->ActiveBuffer = NULL;
|
|
|
|
if (!IsListEmpty(&Console->BufferList))
|
|
|
|
{
|
2013-01-05 23:37:04 +00:00
|
|
|
Console->ActiveBuffer = CONTAINING_RECORD(Console->BufferList.Flink, CONSOLE_SCREEN_BUFFER, ListEntry);
|
2012-11-17 15:41:31 +00:00
|
|
|
ConioDrawConsole(Console);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-13 19:18:54 +00:00
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Buffer->Buffer);
|
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Buffer);
|
2012-11-17 15:41:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioDrawConsole(PCONSOLE Console)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
SMALL_RECT Region;
|
|
|
|
|
2013-03-24 17:08:10 +00:00
|
|
|
ConioInitRect(&Region, 0, 0, Console->ConsoleSize.Y - 1, Console->ConsoleSize.X - 1);
|
2012-11-17 15:41:31 +00:00
|
|
|
ConioDrawRegion(Console, &Region);
|
|
|
|
}
|
|
|
|
|
|
|
|
static VOID FASTCALL
|
2013-01-13 19:50:52 +00:00
|
|
|
ConioComputeUpdateRect(PCONSOLE_SCREEN_BUFFER Buff, SMALL_RECT* UpdateRect, PCOORD Start, UINT Length)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Buff->ScreenBufferSize.X <= Start->X + Length)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
UpdateRect->Left = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
UpdateRect->Left = Start->X;
|
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Buff->ScreenBufferSize.X <= Start->X + Length)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect->Right = Buff->ScreenBufferSize.X - 1;
|
2012-11-17 15:41:31 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
UpdateRect->Right = Start->X + Length - 1;
|
|
|
|
}
|
|
|
|
UpdateRect->Top = Start->Y;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect->Bottom = Start->Y + (Start->X + Length - 1) / Buff->ScreenBufferSize.X;
|
|
|
|
if (Buff->ScreenBufferSize.Y <= UpdateRect->Bottom)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
UpdateRect->Bottom = Buff->ScreenBufferSize.Y - 1;
|
2012-11-17 15:41:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
DWORD FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
ConioEffectiveCursorSize(PCONSOLE Console, DWORD Scale)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
DWORD Size = (Console->ActiveBuffer->CursorInfo.dwSize * Scale + 99) / 100;
|
|
|
|
/* If line input in progress, perhaps adjust for insert toggle */
|
|
|
|
if (Console->LineBuffer && !Console->LineComplete && Console->LineInsertToggle)
|
|
|
|
return (Size * 2 <= Scale) ? (Size * 2) : (Size / 2);
|
|
|
|
return Size;
|
|
|
|
}
|
|
|
|
|
2012-12-08 16:13:16 +00:00
|
|
|
static NTSTATUS
|
|
|
|
DoWriteConsole(IN PCSR_API_MESSAGE ApiMessage,
|
|
|
|
IN PCSR_THREAD ClientThread,
|
|
|
|
IN BOOL CreateWaitBlock OPTIONAL);
|
|
|
|
|
|
|
|
// Wait function CSR_WAIT_FUNCTION
|
|
|
|
static BOOLEAN
|
|
|
|
WriteConsoleThread(IN PLIST_ENTRY WaitList,
|
|
|
|
IN PCSR_THREAD WaitThread,
|
|
|
|
IN PCSR_API_MESSAGE WaitApiMessage,
|
|
|
|
IN PVOID WaitContext,
|
|
|
|
IN PVOID WaitArgument1,
|
|
|
|
IN PVOID WaitArgument2,
|
|
|
|
IN ULONG WaitFlags)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
2013-01-24 20:48:42 +00:00
|
|
|
DPRINT1("WriteConsoleThread - WaitContext = 0x%p, WaitArgument1 = 0x%p, WaitArgument2 = 0x%p, WaitFlags = %lu\n", WaitContext, WaitArgument1, WaitArgument2, WaitFlags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are notified of the process termination via a call
|
|
|
|
* to CsrNotifyWaitBlock triggered by CsrDestroyProcess or
|
|
|
|
* CsrDestroyThread, just return.
|
|
|
|
*/
|
|
|
|
if (WaitFlags & CsrProcessTerminating)
|
|
|
|
{
|
|
|
|
Status = STATUS_THREAD_IS_TERMINATING;
|
|
|
|
goto Quit;
|
|
|
|
}
|
|
|
|
|
2012-12-08 16:13:16 +00:00
|
|
|
Status = DoWriteConsole(WaitApiMessage,
|
|
|
|
WaitThread,
|
|
|
|
FALSE);
|
|
|
|
|
2013-01-24 20:48:42 +00:00
|
|
|
Quit:
|
2012-12-08 16:13:16 +00:00
|
|
|
if (Status != STATUS_PENDING)
|
|
|
|
{
|
|
|
|
WaitApiMessage->Status = Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (Status == STATUS_PENDING ? FALSE : TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static NTSTATUS
|
|
|
|
DoWriteConsole(IN PCSR_API_MESSAGE ApiMessage,
|
|
|
|
IN PCSR_THREAD ClientThread,
|
|
|
|
IN BOOL CreateWaitBlock OPTIONAL)
|
|
|
|
{
|
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_WRITECONSOLE WriteConsoleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.WriteConsoleRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-12-08 16:13:16 +00:00
|
|
|
PCHAR Buffer;
|
|
|
|
DWORD Written = 0;
|
|
|
|
ULONG Length;
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(ClientThread->Process), WriteConsoleRequest->OutputHandle, &Buff, GENERIC_WRITE, FALSE);
|
2012-12-08 16:13:16 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
|
|
|
// if (Console->PauseFlags & (PAUSED_FROM_KEYBOARD | PAUSED_FROM_SCROLLBAR | PAUSED_FROM_SELECTION))
|
|
|
|
if (Console->PauseFlags && Console->UnpauseEvent != NULL)
|
|
|
|
{
|
|
|
|
if (CreateWaitBlock)
|
|
|
|
{
|
|
|
|
if (!CsrCreateWait(&Console->WriteWaitQueue,
|
|
|
|
WriteConsoleThread,
|
|
|
|
ClientThread,
|
|
|
|
ApiMessage,
|
|
|
|
NULL,
|
|
|
|
NULL))
|
|
|
|
{
|
2013-01-02 00:32:20 +00:00
|
|
|
/* Fail */
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, FALSE);
|
2012-12-08 16:13:16 +00:00
|
|
|
return STATUS_NO_MEMORY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wait until we un-pause the console */
|
2013-01-02 00:32:20 +00:00
|
|
|
Status = STATUS_PENDING;
|
2012-12-08 16:13:16 +00:00
|
|
|
}
|
2013-01-02 00:32:20 +00:00
|
|
|
else
|
2012-12-08 16:13:16 +00:00
|
|
|
{
|
2013-01-22 23:28:51 +00:00
|
|
|
if (WriteConsoleRequest->Unicode)
|
2012-12-08 16:13:16 +00:00
|
|
|
{
|
2013-01-02 00:32:20 +00:00
|
|
|
Length = WideCharToMultiByte(Console->OutputCodePage, 0,
|
|
|
|
(PWCHAR)WriteConsoleRequest->Buffer,
|
|
|
|
WriteConsoleRequest->NrCharactersToWrite,
|
|
|
|
NULL, 0, NULL, NULL);
|
2013-01-13 19:18:54 +00:00
|
|
|
Buffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, Length);
|
2013-01-02 00:32:20 +00:00
|
|
|
if (Buffer)
|
|
|
|
{
|
|
|
|
WideCharToMultiByte(Console->OutputCodePage, 0,
|
|
|
|
(PWCHAR)WriteConsoleRequest->Buffer,
|
|
|
|
WriteConsoleRequest->NrCharactersToWrite,
|
|
|
|
Buffer, Length, NULL, NULL);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
}
|
2012-12-08 16:13:16 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-01-02 00:32:20 +00:00
|
|
|
Buffer = (PCHAR)WriteConsoleRequest->Buffer;
|
2012-12-08 16:13:16 +00:00
|
|
|
}
|
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
if (Buffer)
|
2012-12-08 16:13:16 +00:00
|
|
|
{
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
2013-01-02 00:32:20 +00:00
|
|
|
Status = ConioWriteConsole(Console, Buff, Buffer,
|
|
|
|
WriteConsoleRequest->NrCharactersToWrite, TRUE);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
Written = WriteConsoleRequest->NrCharactersToWrite;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (WriteConsoleRequest->Unicode)
|
|
|
|
{
|
2013-01-13 19:18:54 +00:00
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, Buffer);
|
2012-12-08 16:13:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
WriteConsoleRequest->NrCharactersWritten = Written;
|
|
|
|
}
|
2012-12-08 16:13:16 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, FALSE);
|
2012-12-08 16:13:16 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-03-19 22:05:38 +00:00
|
|
|
/* PUBLIC SERVER APIS *********************************************************/
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
CSR_API(SrvReadConsoleOutput)
|
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_READOUTPUT ReadOutputRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ReadOutputRequest;
|
2012-11-17 21:39:41 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrGetClientThread()->Process);
|
2012-11-17 15:41:31 +00:00
|
|
|
PCHAR_INFO CharInfo;
|
|
|
|
PCHAR_INFO CurCharInfo;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-17 15:41:31 +00:00
|
|
|
DWORD SizeX, SizeY;
|
|
|
|
NTSTATUS Status;
|
|
|
|
COORD BufferSize;
|
|
|
|
COORD BufferCoord;
|
|
|
|
SMALL_RECT ReadRegion;
|
|
|
|
SMALL_RECT ScreenRect;
|
|
|
|
DWORD i;
|
|
|
|
PBYTE Ptr;
|
|
|
|
LONG X, Y;
|
|
|
|
UINT CodePage;
|
|
|
|
|
|
|
|
DPRINT("SrvReadConsoleOutput\n");
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
CharInfo = ReadOutputRequest->CharInfo;
|
|
|
|
ReadRegion = ReadOutputRequest->ReadRegion;
|
|
|
|
BufferSize = ReadOutputRequest->BufferSize;
|
|
|
|
BufferCoord = ReadOutputRequest->BufferCoord;
|
2012-11-19 23:26:36 +00:00
|
|
|
|
2012-11-17 21:39:41 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PVOID*)&ReadOutputRequest->CharInfo,
|
2012-11-17 21:39:41 +00:00
|
|
|
BufferSize.X * BufferSize.Y,
|
|
|
|
sizeof(CHAR_INFO)))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
2012-11-18 13:54:32 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ProcessData, ReadOutputRequest->OutputHandle, &Buff, GENERIC_READ, TRUE);
|
2012-11-18 13:54:32 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2012-11-17 21:39:41 +00:00
|
|
|
/* FIXME: Is this correct? */
|
|
|
|
CodePage = ProcessData->Console->OutputCodePage;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
SizeY = min(BufferSize.Y - BufferCoord.Y, ConioRectHeight(&ReadRegion));
|
|
|
|
SizeX = min(BufferSize.X - BufferCoord.X, ConioRectWidth(&ReadRegion));
|
|
|
|
ReadRegion.Bottom = ReadRegion.Top + SizeY;
|
|
|
|
ReadRegion.Right = ReadRegion.Left + SizeX;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConioInitRect(&ScreenRect, 0, 0, Buff->ScreenBufferSize.Y, Buff->ScreenBufferSize.X);
|
2012-11-17 21:39:41 +00:00
|
|
|
if (!ConioGetIntersection(&ReadRegion, &ScreenRect, &ReadRegion))
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0, Y = ReadRegion.Top; Y < ReadRegion.Bottom; ++i, ++Y)
|
|
|
|
{
|
|
|
|
CurCharInfo = CharInfo + (i * BufferSize.X);
|
|
|
|
|
|
|
|
Ptr = ConioCoordToPointer(Buff, ReadRegion.Left, Y);
|
|
|
|
for (X = ReadRegion.Left; X < ReadRegion.Right; ++X)
|
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
if (ReadOutputRequest->Unicode)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2012-11-17 21:39:41 +00:00
|
|
|
// ConsoleAnsiCharToUnicodeChar(ProcessData->Console, (PCHAR)Ptr++, &CurCharInfo->Char.UnicodeChar);
|
2012-11-17 15:41:31 +00:00
|
|
|
MultiByteToWideChar(CodePage, 0,
|
|
|
|
(PCHAR)Ptr++, 1,
|
|
|
|
&CurCharInfo->Char.UnicodeChar, 1);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
CurCharInfo->Char.AsciiChar = *Ptr++;
|
|
|
|
}
|
|
|
|
CurCharInfo->Attributes = *Ptr++;
|
|
|
|
++CurCharInfo;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
ReadOutputRequest->ReadRegion.Right = ReadRegion.Left + SizeX - 1;
|
|
|
|
ReadOutputRequest->ReadRegion.Bottom = ReadRegion.Top + SizeY - 1;
|
|
|
|
ReadOutputRequest->ReadRegion.Left = ReadRegion.Left;
|
|
|
|
ReadOutputRequest->ReadRegion.Top = ReadRegion.Top;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvWriteConsole)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_WRITECONSOLE WriteConsoleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.WriteConsoleRequest;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
DPRINT("SrvWriteConsole\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-19 21:48:22 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
|
|
|
(PVOID)&WriteConsoleRequest->Buffer,
|
|
|
|
WriteConsoleRequest->BufferSize,
|
|
|
|
sizeof(BYTE)))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2012-12-08 16:13:16 +00:00
|
|
|
Status = DoWriteConsole(ApiMessage,
|
|
|
|
CsrGetClientThread(),
|
|
|
|
TRUE);
|
2012-11-19 21:48:22 +00:00
|
|
|
|
2012-12-08 16:13:16 +00:00
|
|
|
if (Status == STATUS_PENDING)
|
|
|
|
*ReplyCode = CsrReplyPending;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
CSR_API(SrvWriteConsoleOutput)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_WRITEOUTPUT WriteOutputRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.WriteOutputRequest;
|
2012-11-18 13:54:32 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrGetClientThread()->Process);
|
2012-11-17 15:41:31 +00:00
|
|
|
SHORT i, X, Y, SizeX, SizeY;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-17 15:41:31 +00:00
|
|
|
SMALL_RECT ScreenBuffer;
|
|
|
|
CHAR_INFO* CurCharInfo;
|
|
|
|
SMALL_RECT WriteRegion;
|
|
|
|
CHAR_INFO* CharInfo;
|
|
|
|
COORD BufferCoord;
|
|
|
|
COORD BufferSize;
|
2010-05-31 06:28:55 +00:00
|
|
|
NTSTATUS Status;
|
2012-11-17 15:41:31 +00:00
|
|
|
PBYTE Ptr;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
DPRINT("SrvWriteConsoleOutput\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
BufferSize = WriteOutputRequest->BufferSize;
|
|
|
|
BufferCoord = WriteOutputRequest->BufferCoord;
|
|
|
|
CharInfo = WriteOutputRequest->CharInfo;
|
2012-11-19 23:26:36 +00:00
|
|
|
|
2012-11-18 13:54:32 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PVOID*)&WriteOutputRequest->CharInfo,
|
2012-11-18 13:54:32 +00:00
|
|
|
BufferSize.X * BufferSize.Y,
|
|
|
|
sizeof(CHAR_INFO)))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ProcessData,
|
2013-01-22 23:28:51 +00:00
|
|
|
WriteOutputRequest->OutputHandle,
|
|
|
|
&Buff,
|
|
|
|
GENERIC_WRITE,
|
|
|
|
TRUE);
|
2012-11-18 13:54:32 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
WriteRegion = WriteOutputRequest->WriteRegion;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
SizeY = min(BufferSize.Y - BufferCoord.Y, ConioRectHeight(&WriteRegion));
|
|
|
|
SizeX = min(BufferSize.X - BufferCoord.X, ConioRectWidth(&WriteRegion));
|
|
|
|
WriteRegion.Bottom = WriteRegion.Top + SizeY - 1;
|
|
|
|
WriteRegion.Right = WriteRegion.Left + SizeX - 1;
|
|
|
|
|
|
|
|
/* Make sure WriteRegion is inside the screen buffer */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConioInitRect(&ScreenBuffer, 0, 0, Buff->ScreenBufferSize.Y - 1, Buff->ScreenBufferSize.X - 1);
|
2012-11-18 13:54:32 +00:00
|
|
|
if (!ConioGetIntersection(&WriteRegion, &ScreenBuffer, &WriteRegion))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
/* It is okay to have a WriteRegion completely outside the screen buffer.
|
|
|
|
No data is written then. */
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0, Y = WriteRegion.Top; Y <= WriteRegion.Bottom; i++, Y++)
|
|
|
|
{
|
|
|
|
CurCharInfo = CharInfo + (i + BufferCoord.Y) * BufferSize.X + BufferCoord.X;
|
|
|
|
Ptr = ConioCoordToPointer(Buff, WriteRegion.Left, Y);
|
|
|
|
for (X = WriteRegion.Left; X <= WriteRegion.Right; X++)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 15:41:31 +00:00
|
|
|
CHAR AsciiChar;
|
2013-01-05 23:10:12 +00:00
|
|
|
if (WriteOutputRequest->Unicode)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
ConsoleUnicodeCharToAnsiChar(Console, &AsciiChar, &CurCharInfo->Char.UnicodeChar);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
AsciiChar = CurCharInfo->Char.AsciiChar;
|
|
|
|
}
|
|
|
|
*Ptr++ = AsciiChar;
|
|
|
|
*Ptr++ = CurCharInfo->Attributes;
|
|
|
|
CurCharInfo++;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
ConioDrawRegion(Console, &WriteRegion);
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
WriteOutputRequest->WriteRegion.Right = WriteRegion.Left + SizeX - 1;
|
|
|
|
WriteOutputRequest->WriteRegion.Bottom = WriteRegion.Top + SizeY - 1;
|
|
|
|
WriteOutputRequest->WriteRegion.Left = WriteRegion.Left;
|
|
|
|
WriteOutputRequest->WriteRegion.Top = WriteRegion.Top;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-11-17 21:39:41 +00:00
|
|
|
CSR_API(SrvReadConsoleOutputString)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 15:41:31 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_READOUTPUTCODE ReadOutputCodeRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ReadOutputCodeRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-17 21:39:41 +00:00
|
|
|
USHORT CodeType;
|
2012-11-17 15:41:31 +00:00
|
|
|
DWORD Xpos, Ypos;
|
2012-11-17 21:39:41 +00:00
|
|
|
PVOID ReadBuffer;
|
2012-11-17 15:41:31 +00:00
|
|
|
DWORD i;
|
2012-11-17 21:39:41 +00:00
|
|
|
ULONG CodeSize;
|
|
|
|
BYTE Code;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-17 21:39:41 +00:00
|
|
|
DPRINT("SrvReadConsoleOutputString\n");
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
CodeType = ReadOutputCodeRequest->CodeType;
|
2012-11-17 21:39:41 +00:00
|
|
|
switch (CodeType)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 21:39:41 +00:00
|
|
|
case CODE_ASCII:
|
|
|
|
CodeSize = sizeof(CHAR);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CODE_UNICODE:
|
|
|
|
CodeSize = sizeof(WCHAR);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CODE_ATTRIBUTE:
|
|
|
|
CodeSize = sizeof(WORD);
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PVOID*)&ReadOutputCodeRequest->pCode.pCode,
|
|
|
|
ReadOutputCodeRequest->NumCodesToRead,
|
2012-11-19 23:26:36 +00:00
|
|
|
CodeSize))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), ReadOutputCodeRequest->OutputHandle, &Buff, GENERIC_READ, TRUE);
|
2012-11-17 21:39:41 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-17 21:39:41 +00:00
|
|
|
Console = Buff->Header.Console;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
ReadBuffer = ReadOutputCodeRequest->pCode.pCode;
|
|
|
|
Xpos = ReadOutputCodeRequest->ReadCoord.X;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Ypos = (ReadOutputCodeRequest->ReadCoord.Y + Buff->VirtualY) % Buff->ScreenBufferSize.Y;
|
2012-11-17 21:39:41 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* MSDN (ReadConsoleOutputAttribute and ReadConsoleOutputCharacter) :
|
|
|
|
*
|
|
|
|
* If the number of attributes (resp. characters) to be read from extends
|
|
|
|
* beyond the end of the specified screen buffer row, attributes (resp.
|
|
|
|
* characters) are read from the next row. If the number of attributes
|
|
|
|
* (resp. characters) to be read from extends beyond the end of the console
|
|
|
|
* screen buffer, attributes (resp. characters) up to the end of the console
|
|
|
|
* screen buffer are read.
|
|
|
|
*
|
|
|
|
* TODO: Do NOT loop up to NumCodesToRead, but stop before
|
|
|
|
* if we are going to overflow...
|
|
|
|
*/
|
2013-01-05 23:10:12 +00:00
|
|
|
for (i = 0; i < ReadOutputCodeRequest->NumCodesToRead; ++i)
|
2012-11-17 21:39:41 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Code = Buff->Buffer[2 * (Xpos + Ypos * Buff->ScreenBufferSize.X) + (CodeType == CODE_ATTRIBUTE ? 1 : 0)];
|
2012-11-17 21:39:41 +00:00
|
|
|
|
|
|
|
switch (CodeType)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2012-11-17 21:39:41 +00:00
|
|
|
case CODE_UNICODE:
|
|
|
|
ConsoleAnsiCharToUnicodeChar(Console, (PWCHAR)ReadBuffer, (PCHAR)&Code);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CODE_ASCII:
|
|
|
|
*(PCHAR)ReadBuffer = (CHAR)Code;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CODE_ATTRIBUTE:
|
|
|
|
*(PWORD)ReadBuffer = (WORD)Code;
|
|
|
|
break;
|
2012-11-17 15:41:31 +00:00
|
|
|
}
|
2012-11-17 21:39:41 +00:00
|
|
|
ReadBuffer = (PVOID)((ULONG_PTR)ReadBuffer + CodeSize);
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
Xpos++;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Xpos == Buff->ScreenBufferSize.X)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
Xpos = 0;
|
|
|
|
Ypos++;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Ypos == Buff->ScreenBufferSize.Y)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
|
|
|
Ypos = 0;
|
|
|
|
}
|
|
|
|
}
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-26 19:07:59 +00:00
|
|
|
// switch (CodeType)
|
|
|
|
// {
|
|
|
|
// case CODE_UNICODE:
|
|
|
|
// *(PWCHAR)ReadBuffer = 0;
|
|
|
|
// break;
|
|
|
|
|
|
|
|
// case CODE_ASCII:
|
|
|
|
// *(PCHAR)ReadBuffer = 0;
|
|
|
|
// break;
|
|
|
|
|
|
|
|
// case CODE_ATTRIBUTE:
|
|
|
|
// *(PWORD)ReadBuffer = 0;
|
|
|
|
// break;
|
|
|
|
// }
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
ReadOutputCodeRequest->EndCoord.X = Xpos;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ReadOutputCodeRequest->EndCoord.Y = (Ypos - Buff->VirtualY + Buff->ScreenBufferSize.Y) % Buff->ScreenBufferSize.Y;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
ReadOutputCodeRequest->CodesRead = (DWORD)((ULONG_PTR)ReadBuffer - (ULONG_PTR)ReadOutputCodeRequest->pCode.pCode) / CodeSize;
|
|
|
|
// <= ReadOutputCodeRequest->NumCodesToRead
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
CSR_API(SrvWriteConsoleOutputString)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_WRITEOUTPUTCODE WriteOutputCodeRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.WriteOutputCodeRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-19 23:26:36 +00:00
|
|
|
USHORT CodeType;
|
|
|
|
PBYTE Buffer; // PUCHAR
|
|
|
|
PCHAR String, tmpString = NULL;
|
|
|
|
DWORD X, Y, Length; // , Written = 0;
|
|
|
|
ULONG CodeSize;
|
2010-05-31 06:28:55 +00:00
|
|
|
SMALL_RECT UpdateRect;
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
DPRINT("SrvWriteConsoleOutputString\n");
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
CodeType = WriteOutputCodeRequest->CodeType;
|
2012-11-19 23:26:36 +00:00
|
|
|
switch (CodeType)
|
|
|
|
{
|
|
|
|
case CODE_ASCII:
|
|
|
|
CodeSize = sizeof(CHAR);
|
|
|
|
break;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
case CODE_UNICODE:
|
|
|
|
CodeSize = sizeof(WCHAR);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CODE_ATTRIBUTE:
|
|
|
|
CodeSize = sizeof(WORD);
|
|
|
|
break;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
default:
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PVOID*)&WriteOutputCodeRequest->pCode.pCode,
|
|
|
|
WriteOutputCodeRequest->Length,
|
2012-11-19 23:26:36 +00:00
|
|
|
CodeSize))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process),
|
2013-01-22 23:28:51 +00:00
|
|
|
WriteOutputCodeRequest->OutputHandle,
|
|
|
|
&Buff,
|
|
|
|
GENERIC_WRITE,
|
|
|
|
TRUE);
|
2012-11-19 23:26:36 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
|
|
|
switch (CodeType)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-19 23:26:36 +00:00
|
|
|
case CODE_UNICODE:
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
Length = WideCharToMultiByte(Console->OutputCodePage, 0,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PWCHAR)WriteOutputCodeRequest->pCode.UnicodeChar,
|
|
|
|
WriteOutputCodeRequest->Length,
|
2010-05-31 06:28:55 +00:00
|
|
|
NULL, 0, NULL, NULL);
|
2013-01-13 19:18:54 +00:00
|
|
|
tmpString = String = RtlAllocateHeap(RtlGetProcessHeap(), 0, Length);
|
2010-05-31 06:28:55 +00:00
|
|
|
if (String)
|
|
|
|
{
|
|
|
|
WideCharToMultiByte(Console->OutputCodePage, 0,
|
2013-01-05 23:10:12 +00:00
|
|
|
(PWCHAR)WriteOutputCodeRequest->pCode.UnicodeChar,
|
|
|
|
WriteOutputCodeRequest->Length,
|
2010-05-31 06:28:55 +00:00
|
|
|
String, Length, NULL, NULL);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
}
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
break;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
case CODE_ASCII:
|
2013-01-05 23:10:12 +00:00
|
|
|
String = (PCHAR)WriteOutputCodeRequest->pCode.AsciiChar;
|
2012-11-19 23:26:36 +00:00
|
|
|
break;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
case CODE_ATTRIBUTE:
|
|
|
|
default:
|
|
|
|
// *(ReadBuffer++) = Code;
|
2013-01-05 23:10:12 +00:00
|
|
|
String = (PCHAR)WriteOutputCodeRequest->pCode.Attribute;
|
2012-11-19 23:26:36 +00:00
|
|
|
break;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
if (String && NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
X = WriteOutputCodeRequest->Coord.X;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Y = (WriteOutputCodeRequest->Coord.Y + Buff->VirtualY) % Buff->ScreenBufferSize.Y;
|
2013-01-05 23:10:12 +00:00
|
|
|
Length = WriteOutputCodeRequest->Length;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buffer = &Buff->Buffer[2 * (Y * Buff->ScreenBufferSize.X + X) + (CodeType == CODE_ATTRIBUTE ? 1 : 0)];
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
while (Length--)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-19 23:26:36 +00:00
|
|
|
*Buffer = *String++;
|
|
|
|
// ReadBuffer = (PVOID)((ULONG_PTR)ReadBuffer + CodeSize);
|
|
|
|
String = (PCHAR)((ULONG_PTR)String + CodeSize);
|
|
|
|
// Written++;
|
|
|
|
Buffer += 2;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (++X == Buff->ScreenBufferSize.X)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (++Y == Buff->ScreenBufferSize.Y)
|
2012-11-19 23:26:36 +00:00
|
|
|
{
|
|
|
|
Y = 0;
|
|
|
|
Buffer = Buff->Buffer + (CodeType == CODE_ATTRIBUTE ? 1 : 0);
|
|
|
|
}
|
|
|
|
X = 0;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
2012-11-19 23:26:36 +00:00
|
|
|
|
|
|
|
if (Buff == Console->ActiveBuffer)
|
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
ConioComputeUpdateRect(Buff, &UpdateRect, &WriteOutputCodeRequest->Coord,
|
|
|
|
WriteOutputCodeRequest->Length);
|
2012-11-19 23:26:36 +00:00
|
|
|
ConioDrawRegion(Console, &UpdateRect);
|
|
|
|
}
|
|
|
|
|
2013-03-09 01:39:49 +00:00
|
|
|
// WriteOutputCodeRequest->EndCoord.X = X;
|
|
|
|
// WriteOutputCodeRequest->EndCoord.Y = (Y + Buff->ScreenBufferSize.Y - Buff->VirtualY) % Buff->ScreenBufferSize.Y;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 23:26:36 +00:00
|
|
|
if (tmpString)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-13 19:18:54 +00:00
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, tmpString);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
// WriteOutputCodeRequest->NrCharactersWritten = Written;
|
2012-11-19 23:26:36 +00:00
|
|
|
return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
CSR_API(SrvFillConsoleOutput)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_FILLOUTPUTCODE FillOutputRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.FillOutputRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-19 23:26:36 +00:00
|
|
|
DWORD X, Y, Length; // , Written = 0;
|
2012-11-18 17:06:48 +00:00
|
|
|
USHORT CodeType;
|
|
|
|
BYTE Code;
|
2012-11-17 15:41:31 +00:00
|
|
|
PBYTE Buffer;
|
|
|
|
SMALL_RECT UpdateRect;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
DPRINT("SrvFillConsoleOutput\n");
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), FillOutputRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-18 17:06:48 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
CodeType = FillOutputRequest->CodeType;
|
|
|
|
|
|
|
|
X = FillOutputRequest->Coord.X;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Y = (FillOutputRequest->Coord.Y + Buff->VirtualY) % Buff->ScreenBufferSize.Y;
|
2012-11-17 15:41:31 +00:00
|
|
|
Length = FillOutputRequest->Length;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buffer = &Buff->Buffer[2 * (Y * Buff->ScreenBufferSize.X + X) + (CodeType == CODE_ATTRIBUTE ? 1 : 0)];
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
switch (CodeType)
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2012-11-18 17:06:48 +00:00
|
|
|
case CODE_ASCII:
|
|
|
|
Code = (BYTE)FillOutputRequest->Code.AsciiChar;
|
|
|
|
break;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
case CODE_UNICODE:
|
|
|
|
ConsoleUnicodeCharToAnsiChar(Console, (PCHAR)&Code, &FillOutputRequest->Code.UnicodeChar);
|
|
|
|
break;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
case CODE_ATTRIBUTE:
|
|
|
|
Code = (BYTE)FillOutputRequest->Code.Attribute;
|
|
|
|
break;
|
2012-11-17 15:41:31 +00:00
|
|
|
|
2012-11-18 17:06:48 +00:00
|
|
|
default:
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-18 17:06:48 +00:00
|
|
|
return STATUS_INVALID_PARAMETER;
|
2012-11-17 15:41:31 +00:00
|
|
|
}
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
while (Length--)
|
|
|
|
{
|
2012-11-18 17:06:48 +00:00
|
|
|
*Buffer = Code;
|
2010-05-31 06:28:55 +00:00
|
|
|
Buffer += 2;
|
2012-11-18 17:06:48 +00:00
|
|
|
// Written++;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (++X == Buff->ScreenBufferSize.X)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (++Y == Buff->ScreenBufferSize.Y)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
Y = 0;
|
2012-11-18 17:06:48 +00:00
|
|
|
Buffer = Buff->Buffer + (CodeType == CODE_ATTRIBUTE ? 1 : 0);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
X = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Buff == Console->ActiveBuffer)
|
|
|
|
{
|
2012-11-18 17:06:48 +00:00
|
|
|
ConioComputeUpdateRect(Buff, &UpdateRect, &FillOutputRequest->Coord,
|
|
|
|
FillOutputRequest->Length);
|
2010-05-31 06:28:55 +00:00
|
|
|
ConioDrawRegion(Console, &UpdateRect);
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-18 17:06:48 +00:00
|
|
|
/*
|
|
|
|
Length = FillOutputRequest->Length;
|
|
|
|
FillOutputRequest->NrCharactersWritten = Length;
|
|
|
|
*/
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleCursorInfo)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCURSORINFO CursorInfoRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.CursorInfoRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
DPRINT("SrvGetConsoleCursorInfo\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), CursorInfoRequest->OutputHandle, &Buff, GENERIC_READ, TRUE);
|
2012-11-17 23:29:53 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
|
|
|
CursorInfoRequest->Info.bVisible = Buff->CursorInfo.bVisible;
|
|
|
|
CursorInfoRequest->Info.dwSize = Buff->CursorInfo.dwSize;
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleCursorInfo)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 23:29:53 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCURSORINFO CursorInfoRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.CursorInfoRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
DWORD Size;
|
|
|
|
BOOL Visible;
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
DPRINT("SrvSetConsoleCursorInfo\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), CursorInfoRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-17 23:29:53 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2012-11-17 23:29:53 +00:00
|
|
|
Size = CursorInfoRequest->Info.dwSize;
|
|
|
|
Visible = CursorInfoRequest->Info.bVisible;
|
2010-05-31 06:28:55 +00:00
|
|
|
if (Size < 1)
|
|
|
|
{
|
|
|
|
Size = 1;
|
|
|
|
}
|
|
|
|
if (100 < Size)
|
|
|
|
{
|
|
|
|
Size = 100;
|
|
|
|
}
|
|
|
|
|
2012-11-17 23:29:53 +00:00
|
|
|
if ( (Size != Buff->CursorInfo.dwSize) ||
|
|
|
|
(Visible && ! Buff->CursorInfo.bVisible) ||
|
|
|
|
(! Visible && Buff->CursorInfo.bVisible) )
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
Buff->CursorInfo.dwSize = Size;
|
|
|
|
Buff->CursorInfo.bVisible = Visible;
|
|
|
|
|
2012-11-17 23:29:53 +00:00
|
|
|
if (!ConioSetCursorInfo(Console, Buff))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
CSR_API(SrvSetConsoleCursorPosition)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SETCURSORPOSITION SetCursorPositionRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.SetCursorPositionRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-17 15:41:31 +00:00
|
|
|
LONG OldCursorX, OldCursorY;
|
|
|
|
LONG NewCursorX, NewCursorY;
|
|
|
|
|
|
|
|
DPRINT("SrvSetConsoleCursorPosition\n");
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), SetCursorPositionRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-17 23:29:53 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2012-11-17 23:29:53 +00:00
|
|
|
NewCursorX = SetCursorPositionRequest->Position.X;
|
|
|
|
NewCursorY = SetCursorPositionRequest->Position.Y;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if ( NewCursorX < 0 || NewCursorX >= Buff->ScreenBufferSize.X ||
|
|
|
|
NewCursorY < 0 || NewCursorY >= Buff->ScreenBufferSize.Y )
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
OldCursorX = Buff->CursorPosition.X;
|
|
|
|
OldCursorY = Buff->CursorPosition.Y;
|
|
|
|
Buff->CursorPosition.X = NewCursorX;
|
|
|
|
Buff->CursorPosition.Y = NewCursorY;
|
2012-11-17 15:41:31 +00:00
|
|
|
if (Buff == Console->ActiveBuffer)
|
|
|
|
{
|
2013-01-22 23:28:51 +00:00
|
|
|
if (!ConioSetScreenInfo(Console, Buff, OldCursorX, OldCursorY))
|
2012-11-17 15:41:31 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-11-17 15:41:31 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-11-18 14:30:25 +00:00
|
|
|
CSR_API(SrvSetConsoleTextAttribute)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SETTEXTATTRIB SetTextAttribRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.SetTextAttribRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 14:30:25 +00:00
|
|
|
DPRINT("SrvSetConsoleTextAttribute\n");
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), SetTextAttribRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-18 14:30:25 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Buff->ScreenDefaultAttrib = SetTextAttribRequest->Attrib;
|
2010-05-31 06:28:55 +00:00
|
|
|
if (Buff == Console->ActiveBuffer)
|
|
|
|
{
|
2012-11-18 14:30:25 +00:00
|
|
|
if (!ConioUpdateScreenInfo(Console, Buff))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvCreateConsoleScreenBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 14:21:21 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_CREATESCREENBUFFER CreateScreenBufferRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.CreateScreenBufferRequest;
|
2012-11-18 14:21:21 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrGetClientThread()->Process);
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-03-09 01:39:49 +00:00
|
|
|
COORD ScreenBufferSize = (COORD){80, 25};
|
|
|
|
USHORT ScreenAttrib = DEFAULT_SCREEN_ATTRIB;
|
|
|
|
USHORT PopupAttrib = DEFAULT_POPUP_ATTRIB;
|
|
|
|
BOOLEAN IsCursorVisible = TRUE;
|
|
|
|
ULONG CursorSize = CSR_DEFAULT_CURSOR_SIZE;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
DPRINT("SrvCreateConsoleScreenBuffer\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
RtlEnterCriticalSection(&ProcessData->HandleTableLock);
|
2012-11-18 14:21:21 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ProcessData, &Console, TRUE);
|
2012-11-18 14:21:21 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 14:21:21 +00:00
|
|
|
RtlLeaveCriticalSection(&ProcessData->HandleTableLock);
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (Console->ActiveBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ScreenBufferSize = Console->ActiveBuffer->ScreenBufferSize;
|
|
|
|
if (ScreenBufferSize.X == 0) ScreenBufferSize.X = 80;
|
|
|
|
if (ScreenBufferSize.Y == 0) ScreenBufferSize.Y = 25;
|
|
|
|
|
|
|
|
ScreenAttrib = Console->ActiveBuffer->ScreenDefaultAttrib;
|
|
|
|
PopupAttrib = Console->ActiveBuffer->PopupDefaultAttrib;
|
2013-03-09 01:39:49 +00:00
|
|
|
|
|
|
|
IsCursorVisible = Console->ActiveBuffer->CursorInfo.bVisible;
|
|
|
|
CursorSize = Console->ActiveBuffer->CursorInfo.dwSize;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
|
|
|
Status = ConSrvCreateScreenBuffer(Console,
|
|
|
|
&Buff,
|
|
|
|
ScreenBufferSize,
|
|
|
|
ScreenAttrib,
|
2013-03-09 01:39:49 +00:00
|
|
|
PopupAttrib,
|
|
|
|
IsCursorVisible,
|
|
|
|
CursorSize);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Status = ConSrvInsertObject(ProcessData,
|
|
|
|
&CreateScreenBufferRequest->OutputHandle,
|
|
|
|
&Buff->Header,
|
|
|
|
CreateScreenBufferRequest->Access,
|
|
|
|
CreateScreenBufferRequest->Inheritable,
|
|
|
|
CreateScreenBufferRequest->ShareMode);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2012-11-18 14:21:21 +00:00
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
RtlLeaveCriticalSection(&ProcessData->HandleTableLock);
|
2012-11-18 14:21:21 +00:00
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-11-18 14:17:47 +00:00
|
|
|
CSR_API(SrvGetConsoleScreenBufferInfo)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSCREENBUFFERINFO ScreenBufferInfoRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ScreenBufferInfoRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2012-11-19 23:26:36 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER_INFO pInfo = &ScreenBufferInfoRequest->Info;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
DPRINT("SrvGetConsoleScreenBufferInfo\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), ScreenBufferInfoRequest->OutputHandle, &Buff, GENERIC_READ, TRUE);
|
2012-11-18 14:17:47 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Console = Buff->Header.Console;
|
2012-11-19 23:26:36 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
pInfo->dwSize = Buff->ScreenBufferSize;
|
|
|
|
pInfo->dwCursorPosition = Buff->CursorPosition;
|
|
|
|
pInfo->wAttributes = Buff->ScreenDefaultAttrib;
|
2012-11-17 15:41:31 +00:00
|
|
|
pInfo->srWindow.Left = Buff->ShowX;
|
2013-03-24 17:08:10 +00:00
|
|
|
pInfo->srWindow.Right = Buff->ShowX + Console->ConsoleSize.X - 1;
|
2012-11-17 15:41:31 +00:00
|
|
|
pInfo->srWindow.Top = Buff->ShowY;
|
2013-03-24 17:08:10 +00:00
|
|
|
pInfo->srWindow.Bottom = Buff->ShowY + Console->ConsoleSize.Y - 1;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
pInfo->dwMaximumWindowSize = Buff->ScreenBufferSize;
|
2012-11-19 23:26:36 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
CSR_API(SrvSetConsoleActiveScreenBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 15:41:31 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SETACTIVESCREENBUFFER SetScreenBufferRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.SetScreenBufferRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
DPRINT("SrvSetConsoleActiveScreenBuffer\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), SetScreenBufferRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-18 14:17:47 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
if (Buff == Console->ActiveBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
/* If old buffer has no handles, it's now unreferenced */
|
|
|
|
if (Console->ActiveBuffer->Header.HandleCount == 0)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 15:41:31 +00:00
|
|
|
ConioDeleteScreenBuffer(Console->ActiveBuffer);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2012-11-18 14:17:47 +00:00
|
|
|
|
|
|
|
/* Tie console to new buffer */
|
2012-11-17 15:41:31 +00:00
|
|
|
Console->ActiveBuffer = Buff;
|
2012-11-18 14:17:47 +00:00
|
|
|
|
2012-11-17 15:41:31 +00:00
|
|
|
/* Redraw the console */
|
|
|
|
ConioDrawConsole(Console);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvScrollConsoleScreenBuffer)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SCROLLSCREENBUFFER ScrollScreenBufferRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ScrollScreenBufferRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
SMALL_RECT ScreenBuffer;
|
|
|
|
SMALL_RECT SrcRegion;
|
|
|
|
SMALL_RECT DstRegion;
|
|
|
|
SMALL_RECT UpdateRegion;
|
|
|
|
SMALL_RECT ScrollRectangle;
|
|
|
|
SMALL_RECT ClipRectangle;
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
HANDLE OutputHandle;
|
2010-05-31 06:28:55 +00:00
|
|
|
BOOLEAN UseClipRectangle;
|
|
|
|
COORD DestinationOrigin;
|
|
|
|
CHAR_INFO Fill;
|
|
|
|
CHAR FillChar;
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
DPRINT("SrvScrollConsoleScreenBuffer\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
OutputHandle = ScrollScreenBufferRequest->OutputHandle;
|
|
|
|
UseClipRectangle = ScrollScreenBufferRequest->UseClipRectangle;
|
|
|
|
DestinationOrigin = ScrollScreenBufferRequest->DestinationOrigin;
|
|
|
|
Fill = ScrollScreenBufferRequest->Fill;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-18 14:17:47 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Console = Buff->Header.Console;
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
ScrollRectangle = ScrollScreenBufferRequest->ScrollRectangle;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
/* Make sure source rectangle is inside the screen buffer */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConioInitRect(&ScreenBuffer, 0, 0, Buff->ScreenBufferSize.Y - 1, Buff->ScreenBufferSize.X - 1);
|
2013-01-22 23:28:51 +00:00
|
|
|
if (!ConioGetIntersection(&SrcRegion, &ScreenBuffer, &ScrollRectangle))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the source was clipped on the left or top, adjust the destination accordingly */
|
|
|
|
if (ScrollRectangle.Left < 0)
|
|
|
|
{
|
|
|
|
DestinationOrigin.X -= ScrollRectangle.Left;
|
|
|
|
}
|
|
|
|
if (ScrollRectangle.Top < 0)
|
|
|
|
{
|
|
|
|
DestinationOrigin.Y -= ScrollRectangle.Top;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UseClipRectangle)
|
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
ClipRectangle = ScrollScreenBufferRequest->ClipRectangle;
|
2010-05-31 06:28:55 +00:00
|
|
|
if (!ConioGetIntersection(&ClipRectangle, &ClipRectangle, &ScreenBuffer))
|
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ClipRectangle = ScreenBuffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
ConioInitRect(&DstRegion,
|
|
|
|
DestinationOrigin.Y,
|
|
|
|
DestinationOrigin.X,
|
|
|
|
DestinationOrigin.Y + ConioRectHeight(&SrcRegion) - 1,
|
|
|
|
DestinationOrigin.X + ConioRectWidth(&SrcRegion) - 1);
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
if (ScrollScreenBufferRequest->Unicode)
|
2010-05-31 06:28:55 +00:00
|
|
|
ConsoleUnicodeCharToAnsiChar(Console, &FillChar, &Fill.Char.UnicodeChar);
|
|
|
|
else
|
|
|
|
FillChar = Fill.Char.AsciiChar;
|
|
|
|
|
|
|
|
ConioMoveRegion(Buff, &SrcRegion, &DstRegion, &ClipRectangle, Fill.Attributes << 8 | (BYTE)FillChar);
|
|
|
|
|
|
|
|
if (Buff == Console->ActiveBuffer)
|
|
|
|
{
|
|
|
|
ConioGetUnion(&UpdateRegion, &SrcRegion, &DstRegion);
|
|
|
|
if (ConioGetIntersection(&UpdateRegion, &UpdateRegion, &ClipRectangle))
|
|
|
|
{
|
|
|
|
/* Draw update region */
|
|
|
|
ConioDrawRegion(Console, &UpdateRegion);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleScreenBufferSize)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SETSCREENBUFFERSIZE SetScreenBufferSizeRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.SetScreenBufferSizeRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process), SetScreenBufferSizeRequest->OutputHandle, &Buff, GENERIC_WRITE, TRUE);
|
2012-11-18 14:17:47 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
Status = ConioResizeBuffer(Buff->Header.Console, Buff, SetScreenBufferSizeRequest->Size);
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|