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/console.c
|
|
|
|
* PURPOSE: Console I/O functions
|
|
|
|
* PROGRAMMERS:
|
2010-05-31 06:28:55 +00:00
|
|
|
*/
|
|
|
|
|
2013-03-19 22:05:38 +00:00
|
|
|
/* INCLUDES *******************************************************************/
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
#define COBJMACROS
|
|
|
|
#define NONAMELESSUNION
|
|
|
|
|
2012-10-23 22:31:36 +00:00
|
|
|
#include "consrv.h"
|
[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
|
|
|
#include "settings.h"
|
2012-10-23 22:31:36 +00:00
|
|
|
#include "guiconsole.h"
|
2013-03-08 23:37:11 +00:00
|
|
|
|
|
|
|
#ifdef TUI_CONSOLE
|
|
|
|
#include "tuiconsole.h"
|
|
|
|
#endif
|
2012-10-23 22:31:36 +00:00
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
#include <shlwapi.h>
|
|
|
|
#include <shlobj.h>
|
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
//#define NDEBUG
|
2010-05-31 06:28:55 +00:00
|
|
|
#include <debug.h>
|
|
|
|
|
2013-01-26 16:12:05 +00:00
|
|
|
|
2013-03-19 22:05:38 +00:00
|
|
|
/* PRIVATE FUNCTIONS **********************************************************/
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-03-19 23:40:20 +00:00
|
|
|
#ifdef TUI_CONSOLE
|
|
|
|
static BOOL
|
2012-10-23 22:31:36 +00:00
|
|
|
DtbgIsDesktopVisible(VOID)
|
|
|
|
{
|
2013-03-09 21:52:12 +00:00
|
|
|
return !((BOOL)NtUserCallNoParam(NOPARAM_ROUTINE_ISCONSOLEMODE));
|
2012-10-23 22:31:36 +00:00
|
|
|
}
|
2013-03-19 23:40:20 +00:00
|
|
|
#endif
|
2012-10-23 22:31:36 +00:00
|
|
|
|
2013-03-19 23:40:20 +00:00
|
|
|
static ULONG
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvConsoleCtrlEventTimeout(DWORD Event,
|
|
|
|
PCONSOLE_PROCESS_DATA ProcessData,
|
|
|
|
DWORD Timeout)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-03-19 23:40:20 +00:00
|
|
|
ULONG Status = ERROR_SUCCESS;
|
2010-05-31 06:28:55 +00:00
|
|
|
HANDLE Thread;
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
DPRINT("ConSrvConsoleCtrlEvent Parent ProcessId = %x\n", ProcessData->Process->ClientId.UniqueProcess);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
if (ProcessData->CtrlDispatcher)
|
|
|
|
{
|
2012-11-17 22:42:04 +00:00
|
|
|
Thread = CreateRemoteThread(ProcessData->Process->ProcessHandle, NULL, 0,
|
|
|
|
ProcessData->CtrlDispatcher,
|
2010-05-31 06:28:55 +00:00
|
|
|
UlongToPtr(Event), 0, NULL);
|
|
|
|
if (NULL == Thread)
|
|
|
|
{
|
2013-03-19 23:40:20 +00:00
|
|
|
Status = GetLastError();
|
|
|
|
DPRINT1("Failed thread creation (Error: 0x%x)\n", Status);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
DPRINT("We succeeded at creating ProcessData->CtrlDispatcher remote thread, ProcessId = %x, Process = 0x%p\n", ProcessData->Process->ClientId.UniqueProcess, ProcessData->Process);
|
|
|
|
WaitForSingleObject(Thread, Timeout);
|
|
|
|
CloseHandle(Thread);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-19 23:40:20 +00:00
|
|
|
|
|
|
|
return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-03-19 23:40:20 +00:00
|
|
|
static ULONG
|
|
|
|
ConSrvConsoleCtrlEvent(DWORD Event,
|
|
|
|
PCONSOLE_PROCESS_DATA ProcessData)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-03-19 23:40:20 +00:00
|
|
|
return ConSrvConsoleCtrlEventTimeout(Event, ProcessData, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
ULONG FASTCALL
|
|
|
|
ConSrvConsoleProcessCtrlEvent(PCONSOLE Console,
|
|
|
|
ULONG ProcessGroupId,
|
|
|
|
DWORD Event)
|
|
|
|
{
|
|
|
|
ULONG Status = ERROR_SUCCESS;
|
|
|
|
PLIST_ENTRY current_entry;
|
|
|
|
PCONSOLE_PROCESS_DATA current;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Loop through the process list, from the most recent process
|
|
|
|
* (the active one) to the oldest one (the first created, i.e.
|
|
|
|
* the console leader process), and for each, send an event
|
|
|
|
* (new processes are inserted at the head of the console process list).
|
|
|
|
*/
|
|
|
|
current_entry = Console->ProcessList.Flink;
|
|
|
|
while (current_entry != &Console->ProcessList)
|
|
|
|
{
|
|
|
|
current = CONTAINING_RECORD(current_entry, CONSOLE_PROCESS_DATA, ConsoleLink);
|
|
|
|
current_entry = current_entry->Flink;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only processes belonging to the same process group are signaled.
|
|
|
|
* If the process group ID is zero, then all the processes are signaled.
|
|
|
|
*/
|
|
|
|
if (ProcessGroupId == 0 || current->Process->ProcessGroupId == ProcessGroupId)
|
|
|
|
{
|
|
|
|
Status = ConSrvConsoleCtrlEvent(Event, current);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Status;
|
2013-01-24 22:41:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID FASTCALL
|
|
|
|
ConioPause(PCONSOLE Console, UINT Flags)
|
|
|
|
{
|
|
|
|
Console->PauseFlags |= Flags;
|
|
|
|
if (!Console->UnpauseEvent)
|
|
|
|
Console->UnpauseEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID FASTCALL
|
|
|
|
ConioUnpause(PCONSOLE Console, UINT Flags)
|
|
|
|
{
|
|
|
|
Console->PauseFlags &= ~Flags;
|
|
|
|
|
|
|
|
// if ((Console->PauseFlags & (PAUSED_FROM_KEYBOARD | PAUSED_FROM_SCROLLBAR | PAUSED_FROM_SELECTION)) == 0)
|
|
|
|
if (Console->PauseFlags == 0 && Console->UnpauseEvent)
|
|
|
|
{
|
|
|
|
SetEvent(Console->UnpauseEvent);
|
|
|
|
CloseHandle(Console->UnpauseEvent);
|
|
|
|
Console->UnpauseEvent = NULL;
|
|
|
|
|
|
|
|
CsrNotifyWait(&Console->WriteWaitQueue,
|
|
|
|
WaitAll,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
2013-01-26 16:12:05 +00:00
|
|
|
if (!IsListEmpty(&Console->WriteWaitQueue))
|
|
|
|
{
|
|
|
|
CsrDereferenceWait(&Console->WriteWaitQueue);
|
|
|
|
}
|
2013-01-24 22:41:33 +00:00
|
|
|
}
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
static BOOL
|
[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
|
|
|
LoadShellLinkConsoleInfo(IN OUT PCONSOLE_START_INFO ConsoleStartInfo,
|
|
|
|
OUT PCONSOLE_INFO ConsoleInfo,
|
|
|
|
OUT LPWSTR IconPath,
|
|
|
|
IN SIZE_T IconPathLength,
|
|
|
|
OUT PINT piIcon)
|
2013-02-10 12:36:57 +00:00
|
|
|
{
|
|
|
|
#define PATH_SEPARATOR L'\\'
|
|
|
|
|
[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
|
|
|
BOOL RetVal = FALSE;
|
2013-02-10 12:36:57 +00:00
|
|
|
LPWSTR LinkName = NULL;
|
|
|
|
SIZE_T Length = 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
|
|
|
if ((ConsoleStartInfo->dwStartupFlags & STARTF_TITLEISLINKNAME) == 0)
|
2013-02-10 12:36:57 +00:00
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
if (IconPath == NULL || piIcon == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
IconPath[0] = L'\0';
|
|
|
|
*piIcon = 0;
|
|
|
|
|
|
|
|
/* 1- Find the last path separator if any */
|
[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
|
|
|
LinkName = wcsrchr(ConsoleStartInfo->ConsoleTitle, PATH_SEPARATOR);
|
2013-02-10 12:36:57 +00:00
|
|
|
if (LinkName == NULL)
|
|
|
|
{
|
[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
|
|
|
LinkName = ConsoleStartInfo->ConsoleTitle;
|
2013-02-10 12:36:57 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Skip the path separator */
|
|
|
|
++LinkName;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 2- Check for the link extension. The name ".lnk" is considered invalid. */
|
|
|
|
Length = wcslen(LinkName);
|
|
|
|
if ( (Length <= 4) || (wcsicmp(LinkName + (Length - 4), L".lnk") != 0) )
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
/* 3- It may be a link. Try to retrieve some properties */
|
|
|
|
HRESULT hRes = CoInitialize(NULL);
|
|
|
|
if (SUCCEEDED(hRes))
|
|
|
|
{
|
[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
|
|
|
/* Get a pointer to the IShellLink interface */
|
2013-02-10 12:36:57 +00:00
|
|
|
IShellLinkW* pshl = NULL;
|
|
|
|
hRes = CoCreateInstance(&CLSID_ShellLink,
|
|
|
|
NULL,
|
|
|
|
CLSCTX_INPROC_SERVER,
|
|
|
|
&IID_IShellLinkW,
|
|
|
|
(LPVOID*)&pshl);
|
|
|
|
if (SUCCEEDED(hRes))
|
|
|
|
{
|
[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
|
|
|
/* Get a pointer to the IPersistFile interface */
|
2013-02-10 12:36:57 +00:00
|
|
|
IPersistFile* ppf = NULL;
|
|
|
|
hRes = IPersistFile_QueryInterface(pshl, &IID_IPersistFile, (LPVOID*)&ppf);
|
|
|
|
if (SUCCEEDED(hRes))
|
|
|
|
{
|
[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
|
|
|
/* Load the shortcut */
|
|
|
|
hRes = IPersistFile_Load(ppf, ConsoleStartInfo->ConsoleTitle, STGM_READ);
|
2013-02-10 12:36:57 +00:00
|
|
|
if (SUCCEEDED(hRes))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Finally we can get the properties !
|
|
|
|
* Update the old ones if needed.
|
|
|
|
*/
|
|
|
|
INT ShowCmd = 0;
|
|
|
|
// WORD HotKey = 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
|
|
|
/* Get the name of the shortcut */
|
2013-02-10 12:36:57 +00:00
|
|
|
Length = min(Length - 4,
|
[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
|
|
|
sizeof(ConsoleStartInfo->ConsoleTitle) / sizeof(ConsoleStartInfo->ConsoleTitle[0]) - 1);
|
|
|
|
wcsncpy(ConsoleStartInfo->ConsoleTitle, LinkName, Length);
|
|
|
|
ConsoleStartInfo->ConsoleTitle[Length] = L'\0';
|
2013-02-10 12:36:57 +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
|
|
|
// HACK: Copy also the name of the shortcut
|
|
|
|
Length = min(Length,
|
|
|
|
sizeof(ConsoleInfo->ConsoleTitle) / sizeof(ConsoleInfo->ConsoleTitle[0]) - 1);
|
|
|
|
wcsncpy(ConsoleInfo->ConsoleTitle, LinkName, Length);
|
|
|
|
ConsoleInfo->ConsoleTitle[Length] = L'\0';
|
|
|
|
|
|
|
|
/* Get the window showing command */
|
2013-02-10 12:36:57 +00:00
|
|
|
hRes = IShellLinkW_GetShowCmd(pshl, &ShowCmd);
|
[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 (SUCCEEDED(hRes)) ConsoleStartInfo->ShowWindow = (WORD)ShowCmd;
|
2013-02-10 12:36:57 +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
|
|
|
/* Get the hotkey */
|
2013-02-10 12:36:57 +00:00
|
|
|
// hRes = pshl->GetHotkey(&ShowCmd);
|
[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 (SUCCEEDED(hRes)) ConsoleStartInfo->HotKey = HotKey;
|
2013-02-10 12:36:57 +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
|
|
|
/* Get the icon location, if any */
|
2013-02-10 12:36:57 +00:00
|
|
|
hRes = IShellLinkW_GetIconLocation(pshl, IconPath, IconPathLength, piIcon);
|
|
|
|
if (!SUCCEEDED(hRes))
|
|
|
|
{
|
|
|
|
IconPath[0] = L'\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
|
|
|
|
|
|
|
// FIXME: Since we still don't load console properties from the shortcut,
|
|
|
|
// return false. When this will be done, we will return true instead.
|
|
|
|
RetVal = FALSE;
|
2013-02-10 12:36:57 +00:00
|
|
|
}
|
|
|
|
IPersistFile_Release(ppf);
|
|
|
|
}
|
|
|
|
IShellLinkW_Release(pshl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
CoUninitialize();
|
|
|
|
|
[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 RetVal;
|
2013-02-10 12:36:57 +00:00
|
|
|
}
|
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
NTSTATUS WINAPI
|
2013-02-10 12:36:57 +00:00
|
|
|
ConSrvInitConsole(OUT PCONSOLE* NewConsole,
|
|
|
|
IN LPCWSTR AppPath,
|
[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
|
|
|
IN OUT PCONSOLE_START_INFO ConsoleStartInfo,
|
2013-02-10 12:36:57 +00:00
|
|
|
IN PCSR_PROCESS ConsoleLeaderProcess)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
SECURITY_ATTRIBUTES SecurityAttributes;
|
[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
|
|
|
CONSOLE_INFO ConsoleInfo;
|
|
|
|
SIZE_T Length = 0;
|
|
|
|
DWORD ProcessId = HandleToUlong(ConsoleLeaderProcess->ClientId.UniqueProcess);
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
|
|
|
PCONSOLE_SCREEN_BUFFER NewBuffer;
|
2010-05-31 06:28:55 +00:00
|
|
|
BOOL GuiMode;
|
2013-02-10 12:36:57 +00:00
|
|
|
WCHAR Title[128];
|
|
|
|
WCHAR IconPath[MAX_PATH + 1] = L"";
|
|
|
|
INT iIcon = 0;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
if (NewConsole == NULL) return STATUS_INVALID_PARAMETER;
|
|
|
|
*NewConsole = NULL;
|
|
|
|
|
[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
|
|
|
/*
|
|
|
|
* Allocate a console structure
|
|
|
|
*/
|
2013-01-13 19:18:54 +00:00
|
|
|
Console = RtlAllocateHeap(ConSrvHeap, HEAP_ZERO_MEMORY, sizeof(CONSOLE));
|
2013-01-02 00:32:20 +00:00
|
|
|
if (NULL == Console)
|
|
|
|
{
|
|
|
|
DPRINT1("Not enough memory for console creation.\n");
|
|
|
|
return STATUS_NO_MEMORY;
|
|
|
|
}
|
|
|
|
|
2013-02-10 12:36:57 +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
|
|
|
* Load the console settings
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* 1. Load the default settings */
|
|
|
|
ConSrvGetDefaultSettings(&ConsoleInfo, ProcessId);
|
|
|
|
|
|
|
|
/* 2. Get the title of the console (initialize ConsoleInfo.ConsoleTitle) */
|
|
|
|
Length = min(wcslen(ConsoleStartInfo->ConsoleTitle),
|
|
|
|
sizeof(ConsoleInfo.ConsoleTitle) / sizeof(ConsoleInfo.ConsoleTitle[0]) - 1);
|
|
|
|
wcsncpy(ConsoleInfo.ConsoleTitle, ConsoleStartInfo->ConsoleTitle, Length);
|
|
|
|
ConsoleInfo.ConsoleTitle[Length] = L'\0';
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 3. Check whether the process creating the
|
|
|
|
* console was launched via a shell-link
|
|
|
|
* (ConsoleInfo.ConsoleTitle may be updated).
|
2013-02-10 12:36:57 +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 (ConsoleStartInfo->dwStartupFlags & STARTF_TITLEISLINKNAME)
|
2011-04-09 12:01: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
|
|
|
if (!LoadShellLinkConsoleInfo(ConsoleStartInfo,
|
|
|
|
&ConsoleInfo,
|
|
|
|
IconPath,
|
|
|
|
MAX_PATH,
|
|
|
|
&iIcon))
|
|
|
|
{
|
|
|
|
ConsoleStartInfo->dwStartupFlags &= ~STARTF_TITLEISLINKNAME;
|
|
|
|
}
|
|
|
|
}
|
2013-02-10 12:36:57 +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
|
|
|
/*
|
|
|
|
* 4. Load the remaining console settings via the registry.
|
|
|
|
*/
|
|
|
|
if ((ConsoleStartInfo->dwStartupFlags & STARTF_TITLEISLINKNAME) == 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Either we weren't created by an app launched via a shell-link,
|
|
|
|
* or we failed to load shell-link console properties.
|
|
|
|
* Therefore, load the console infos for the application from the registry.
|
|
|
|
*/
|
|
|
|
ConSrvReadUserSettings(&ConsoleInfo, ProcessId);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now, update them with the properties the user might gave to us
|
|
|
|
* via the STARTUPINFO structure before calling CreateProcess
|
|
|
|
* (and which was transmitted via the ConsoleStartInfo structure).
|
|
|
|
*/
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USEFILLATTRIBUTE)
|
|
|
|
{
|
|
|
|
ConsoleInfo.ScreenAttrib = ConsoleStartInfo->FillAttribute;
|
|
|
|
}
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USECOUNTCHARS)
|
|
|
|
{
|
|
|
|
ConsoleInfo.ScreenBufferSize = ConsoleStartInfo->ScreenBufferSize;
|
|
|
|
}
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USESHOWWINDOW)
|
|
|
|
{
|
|
|
|
ConsoleInfo.u.GuiInfo.ShowWindow = ConsoleStartInfo->ShowWindow;
|
|
|
|
}
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USEPOSITION)
|
|
|
|
{
|
|
|
|
ConsoleInfo.u.GuiInfo.AutoPosition = FALSE;
|
|
|
|
ConsoleInfo.u.GuiInfo.WindowOrigin = ConsoleStartInfo->ConsoleWindowOrigin;
|
|
|
|
}
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USESIZE)
|
|
|
|
{
|
|
|
|
// ConsoleInfo.ConsoleSize = ConsoleStartInfo->ConsoleWindowSize;
|
|
|
|
ConsoleInfo.ConsoleSize.X = (SHORT)ConsoleStartInfo->ConsoleWindowSize.cx;
|
|
|
|
ConsoleInfo.ConsoleSize.Y = (SHORT)ConsoleStartInfo->ConsoleWindowSize.cy;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_RUNFULLSCREEN)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
*/
|
2011-04-09 12:01:36 +00:00
|
|
|
}
|
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
|
|
|
/*
|
|
|
|
* Initialize the console
|
|
|
|
*/
|
2013-01-20 22:15:21 +00:00
|
|
|
InitializeCriticalSection(&Console->Lock);
|
2010-05-31 06:28:55 +00:00
|
|
|
Console->ReferenceCount = 0;
|
2013-01-02 00:32:20 +00:00
|
|
|
InitializeListHead(&Console->ProcessList);
|
[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
|
|
|
memcpy(Console->Colors, ConsoleInfo.Colors, sizeof(ConsoleInfo.Colors));
|
|
|
|
Console->Size = ConsoleInfo.ConsoleSize;
|
2013-01-18 22:31:16 +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
|
|
|
/*
|
|
|
|
* Initialize the input buffer
|
|
|
|
*/
|
2013-01-18 22:31:16 +00:00
|
|
|
Console->InputBuffer.Header.Type = CONIO_INPUT_BUFFER_MAGIC;
|
|
|
|
Console->InputBuffer.Header.Console = Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
SecurityAttributes.nLength = sizeof(SECURITY_ATTRIBUTES);
|
|
|
|
SecurityAttributes.lpSecurityDescriptor = NULL;
|
|
|
|
SecurityAttributes.bInheritHandle = TRUE;
|
2013-01-18 22:31:16 +00:00
|
|
|
Console->InputBuffer.ActiveEvent = CreateEventW(&SecurityAttributes, TRUE, FALSE, NULL);
|
|
|
|
if (NULL == Console->InputBuffer.ActiveEvent)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-20 22:15:21 +00:00
|
|
|
DeleteCriticalSection(&Console->Lock);
|
2013-01-13 19:18:54 +00:00
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Console);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
// TODO: Use the values from ConsoleInfo.
|
|
|
|
Console->InputBuffer.Mode = ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT |
|
|
|
|
ENABLE_PROCESSED_INPUT | ENABLE_MOUSE_INPUT;
|
|
|
|
Console->QuickEdit = ConsoleInfo.QuickEdit;
|
|
|
|
Console->InsertMode = ConsoleInfo.InsertMode;
|
|
|
|
InitializeListHead(&Console->InputBuffer.ReadWaitQueue);
|
|
|
|
InitializeListHead(&Console->InputBuffer.InputEvents);
|
|
|
|
Console->LineBuffer = NULL;
|
|
|
|
Console->CodePage = GetOEMCP();
|
|
|
|
Console->OutputCodePage = GetOEMCP();
|
|
|
|
|
|
|
|
/* Initialize a new screen buffer with default settings */
|
|
|
|
InitializeListHead(&Console->BufferList);
|
|
|
|
Status = ConSrvCreateScreenBuffer(Console,
|
|
|
|
&NewBuffer,
|
|
|
|
ConsoleInfo.ScreenBufferSize,
|
|
|
|
ConsoleInfo.ScreenAttrib,
|
2013-03-09 01:39:49 +00:00
|
|
|
ConsoleInfo.PopupAttrib,
|
|
|
|
TRUE,
|
|
|
|
ConsoleInfo.CursorSize);
|
2013-02-10 12:36:57 +00:00
|
|
|
if (!NT_SUCCESS(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
|
|
|
DPRINT1("ConSrvCreateScreenBuffer: failed, Status = 0x%08lx\n", Status);
|
2013-02-10 12:36:57 +00:00
|
|
|
CloseHandle(Console->InputBuffer.ActiveEvent);
|
[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
|
|
|
DeleteCriticalSection(&Console->Lock);
|
2013-02-10 12:36:57 +00:00
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Console);
|
|
|
|
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
|
|
|
/* Make the new screen buffer active */
|
|
|
|
Console->ActiveBuffer = NewBuffer;
|
|
|
|
Console->FullScreen = ConsoleInfo.FullScreen;
|
|
|
|
InitializeListHead(&Console->WriteWaitQueue);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the history buffers
|
|
|
|
*/
|
|
|
|
InitializeListHead(&Console->HistoryBuffers);
|
|
|
|
Console->HistoryBufferSize = ConsoleInfo.HistoryBufferSize;
|
|
|
|
Console->NumberOfHistoryBuffers = ConsoleInfo.NumberOfHistoryBuffers;
|
|
|
|
Console->HistoryNoDup = ConsoleInfo.HistoryNoDup;
|
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
/* Initialize the console title */
|
[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
|
|
|
RtlCreateUnicodeString(&Console->OriginalTitle, ConsoleStartInfo->ConsoleTitle);
|
|
|
|
if (ConsoleStartInfo->ConsoleTitle[0] == L'\0')
|
2013-02-10 12:36:57 +00:00
|
|
|
{
|
|
|
|
if (LoadStringW(ConSrvDllInstance, IDS_CONSOLE_TITLE, Title, sizeof(Title) / sizeof(Title[0])))
|
|
|
|
{
|
|
|
|
RtlCreateUnicodeString(&Console->Title, Title);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
RtlCreateUnicodeString(&Console->Title, L"ReactOS Console");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
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
|
|
|
RtlCreateUnicodeString(&Console->Title, ConsoleStartInfo->ConsoleTitle);
|
2013-02-10 12:36:57 +00:00
|
|
|
}
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-24 12:40:56 +00:00
|
|
|
/*
|
2013-03-08 23:37:11 +00:00
|
|
|
* If we are not in GUI-mode, start the text-mode terminal emulator.
|
|
|
|
* If we fail, try to start the GUI-mode terminal emulator.
|
2012-11-24 12:40:56 +00:00
|
|
|
*/
|
2013-03-08 23:37:11 +00:00
|
|
|
#ifdef TUI_CONSOLE
|
2013-02-10 12:36:57 +00:00
|
|
|
GuiMode = DtbgIsDesktopVisible();
|
2013-03-08 23:37:11 +00:00
|
|
|
#else
|
|
|
|
GuiMode = TRUE;
|
|
|
|
#endif
|
2013-02-10 12:36:57 +00:00
|
|
|
|
2013-03-08 23:37:11 +00:00
|
|
|
#ifdef TUI_CONSOLE
|
2012-11-17 22:42:04 +00:00
|
|
|
if (!GuiMode)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-03-08 23:37:11 +00:00
|
|
|
DPRINT1("CONSRV: Opening text-mode terminal emulator\n");
|
[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 = TuiInitConsole(Console, &ConsoleInfo);
|
2012-11-17 22:42:04 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-03-08 23:37:11 +00:00
|
|
|
DPRINT1("Failed to open text-mode terminal emulator, switching to gui-mode, Status = 0x%08lx\n", Status);
|
2010-05-31 06:28:55 +00:00
|
|
|
GuiMode = TRUE;
|
|
|
|
}
|
|
|
|
}
|
2013-03-08 23:37:11 +00:00
|
|
|
#endif
|
2012-11-24 12:40:56 +00:00
|
|
|
|
|
|
|
/*
|
2013-03-08 23:37:11 +00:00
|
|
|
* Try to open the GUI-mode terminal emulator. Two cases are possible:
|
2012-11-24 12:40:56 +00:00
|
|
|
* - We are in GUI-mode, therefore GuiMode == TRUE, the previous test-case
|
2013-03-08 23:37:11 +00:00
|
|
|
* failed and we start GUI-mode terminal emulator.
|
2012-11-24 12:40:56 +00:00
|
|
|
* - We are in text-mode, therefore GuiMode == FALSE, the previous test-case
|
2013-03-08 23:37:11 +00:00
|
|
|
* succeeded BUT we failed at starting text-mode terminal emulator.
|
|
|
|
* Then GuiMode was switched to TRUE in order to try to open the GUI-mode
|
|
|
|
* terminal emulator (win32k will automatically switch to graphical mode,
|
|
|
|
* therefore no additional code is needed).
|
2012-11-24 12:40:56 +00:00
|
|
|
*/
|
|
|
|
if (GuiMode)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-03-08 23:37:11 +00:00
|
|
|
DPRINT1("CONSRV: Opening GUI-mode terminal emulator\n");
|
2013-02-10 12:36:57 +00:00
|
|
|
Status = GuiInitConsole(Console,
|
|
|
|
AppPath,
|
[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
|
|
|
&ConsoleInfo,
|
2013-02-10 12:36:57 +00:00
|
|
|
IconPath,
|
|
|
|
iIcon);
|
2012-11-17 22:42:04 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-02-10 12:36:57 +00:00
|
|
|
DPRINT1("GuiInitConsole: failed, Status = 0x%08lx\n", Status);
|
2010-05-31 06:28:55 +00:00
|
|
|
RtlFreeUnicodeString(&Console->Title);
|
[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
|
|
|
RtlFreeUnicodeString(&Console->OriginalTitle);
|
|
|
|
ConioDeleteScreenBuffer(NewBuffer);
|
2013-01-18 22:31:16 +00:00
|
|
|
CloseHandle(Console->InputBuffer.ActiveEvent);
|
[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
|
|
|
DeleteCriticalSection(&Console->Lock);
|
2013-01-13 19:18:54 +00:00
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Console);
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
/* Copy buffer contents to screen */
|
2010-05-31 06:28:55 +00:00
|
|
|
ConioDrawConsole(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
|
|
|
/* Return the newly created console to the caller and a success code too */
|
2013-01-02 00:32:20 +00:00
|
|
|
*NewConsole = Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
VOID WINAPI
|
|
|
|
ConSrvInitConsoleSupport(VOID)
|
|
|
|
{
|
|
|
|
DPRINT("CONSRV: ConSrvInitConsoleSupport()\n");
|
|
|
|
|
|
|
|
/* Should call LoadKeyboardLayout */
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID WINAPI
|
|
|
|
ConSrvDeleteConsole(PCONSOLE Console)
|
|
|
|
{
|
|
|
|
ConsoleInput *Event;
|
|
|
|
|
|
|
|
DPRINT("ConSrvDeleteConsole\n");
|
|
|
|
|
|
|
|
/* Drain input event queue */
|
|
|
|
while (Console->InputBuffer.InputEvents.Flink != &Console->InputBuffer.InputEvents)
|
|
|
|
{
|
|
|
|
Event = (ConsoleInput *) Console->InputBuffer.InputEvents.Flink;
|
|
|
|
Console->InputBuffer.InputEvents.Flink = Console->InputBuffer.InputEvents.Flink->Flink;
|
|
|
|
Console->InputBuffer.InputEvents.Flink->Flink->Blink = &Console->InputBuffer.InputEvents;
|
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Event);
|
|
|
|
}
|
|
|
|
|
|
|
|
ConioCleanupConsole(Console);
|
|
|
|
if (Console->LineBuffer)
|
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Console->LineBuffer);
|
|
|
|
while (!IsListEmpty(&Console->HistoryBuffers))
|
|
|
|
HistoryDeleteBuffer((struct _HISTORY_BUFFER *)Console->HistoryBuffers.Flink);
|
|
|
|
|
|
|
|
ConioDeleteScreenBuffer(Console->ActiveBuffer);
|
|
|
|
if (!IsListEmpty(&Console->BufferList))
|
|
|
|
{
|
|
|
|
DPRINT1("BUG: screen buffer list not empty\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
CloseHandle(Console->InputBuffer.ActiveEvent);
|
|
|
|
if (Console->UnpauseEvent) CloseHandle(Console->UnpauseEvent);
|
|
|
|
DeleteCriticalSection(&Console->Lock);
|
2013-02-10 12:36:57 +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
|
|
|
RtlFreeUnicodeString(&Console->OriginalTitle);
|
2013-01-24 22:41:33 +00:00
|
|
|
RtlFreeUnicodeString(&Console->Title);
|
|
|
|
IntDeleteAllAliases(Console->Aliases);
|
|
|
|
RtlFreeHeap(ConSrvHeap, 0, Console);
|
|
|
|
}
|
|
|
|
|
2013-03-19 22:05:38 +00:00
|
|
|
|
|
|
|
/* PUBLIC SERVER APIS *********************************************************/
|
|
|
|
|
2012-11-17 22:42:04 +00:00
|
|
|
CSR_API(SrvOpenConsole)
|
|
|
|
{
|
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_OPENCONSOLE OpenConsoleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.OpenConsoleRequest;
|
2012-11-17 22:42:04 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrGetClientThread()->Process);
|
|
|
|
|
2013-01-05 23:10:12 +00:00
|
|
|
OpenConsoleRequest->ConsoleHandle = INVALID_HANDLE_VALUE;
|
2012-11-17 22:42:04 +00:00
|
|
|
|
|
|
|
RtlEnterCriticalSection(&ProcessData->HandleTableLock);
|
|
|
|
|
|
|
|
if (ProcessData->Console)
|
|
|
|
{
|
|
|
|
DWORD DesiredAccess = OpenConsoleRequest->Access;
|
|
|
|
DWORD ShareMode = OpenConsoleRequest->ShareMode;
|
|
|
|
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console = ProcessData->Console;
|
2012-11-17 22:42:04 +00:00
|
|
|
Object_t *Object;
|
|
|
|
|
|
|
|
EnterCriticalSection(&Console->Lock);
|
|
|
|
|
|
|
|
if (OpenConsoleRequest->HandleType == HANDLE_OUTPUT)
|
2013-01-18 22:31:16 +00:00
|
|
|
{
|
2012-11-17 22:42:04 +00:00
|
|
|
Object = &Console->ActiveBuffer->Header;
|
2013-01-18 22:31:16 +00:00
|
|
|
}
|
2012-11-17 22:42:04 +00:00
|
|
|
else // HANDLE_INPUT
|
2013-01-18 22:31:16 +00:00
|
|
|
{
|
|
|
|
Object = &Console->InputBuffer.Header;
|
|
|
|
}
|
2012-11-17 22:42:04 +00:00
|
|
|
|
|
|
|
if (((DesiredAccess & GENERIC_READ) && Object->ExclusiveRead != 0) ||
|
|
|
|
((DesiredAccess & GENERIC_WRITE) && Object->ExclusiveWrite != 0) ||
|
|
|
|
(!(ShareMode & FILE_SHARE_READ) && Object->AccessRead != 0) ||
|
|
|
|
(!(ShareMode & FILE_SHARE_WRITE) && Object->AccessWrite != 0))
|
|
|
|
{
|
|
|
|
DPRINT1("Sharing violation\n");
|
|
|
|
Status = STATUS_SHARING_VIOLATION;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvInsertObject(ProcessData,
|
[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
|
|
|
&OpenConsoleRequest->ConsoleHandle,
|
|
|
|
Object,
|
|
|
|
DesiredAccess,
|
|
|
|
OpenConsoleRequest->Inheritable,
|
|
|
|
ShareMode);
|
2012-11-17 22:42:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
LeaveCriticalSection(&Console->Lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
RtlLeaveCriticalSection(&ProcessData->HandleTableLock);
|
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvAllocConsole)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_ALLOCCONSOLE AllocConsoleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.AllocConsoleRequest;
|
2013-02-10 12:36:57 +00:00
|
|
|
PCSR_PROCESS CsrProcess = CsrGetClientThread()->Process;
|
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrProcess);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
if (ProcessData->Console != NULL)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Process already has a console\n");
|
2013-01-13 17:07:25 +00:00
|
|
|
return STATUS_ACCESS_DENIED;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
if ( !CsrValidateMessageBuffer(ApiMessage,
|
[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
|
|
|
(PVOID*)&AllocConsoleRequest->ConsoleStartInfo,
|
2013-02-10 12:36:57 +00:00
|
|
|
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
|
|
|
sizeof(CONSOLE_START_INFO)) ||
|
2013-02-10 12:36:57 +00:00
|
|
|
!CsrValidateMessageBuffer(ApiMessage,
|
|
|
|
(PVOID*)&AllocConsoleRequest->AppPath,
|
|
|
|
MAX_PATH + 1,
|
|
|
|
sizeof(WCHAR)) )
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2013-01-13 17:07:25 +00:00
|
|
|
/*
|
2013-01-24 22:41:33 +00:00
|
|
|
* We are about to create a new console. However when ConSrvNewProcess
|
2013-01-13 17:07:25 +00:00
|
|
|
* was called, we didn't know that we wanted to create a new console and
|
|
|
|
* therefore, we by default inherited the handles table from our parent
|
|
|
|
* process. It's only now that we notice that in fact we do not need
|
|
|
|
* them, because we've created a new console and thus we must use it.
|
|
|
|
*
|
|
|
|
* Therefore, free the console we can have and our handles table,
|
|
|
|
* and recreate a new one later on.
|
|
|
|
*/
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvRemoveConsole(ProcessData);
|
2013-01-13 17:07:25 +00:00
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
/* Initialize a new Console owned by the Console Leader Process */
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvAllocateConsole(ProcessData,
|
2013-02-10 12:36:57 +00:00
|
|
|
AllocConsoleRequest->AppPath,
|
2013-02-01 23:36:23 +00:00
|
|
|
&AllocConsoleRequest->InputHandle,
|
|
|
|
&AllocConsoleRequest->OutputHandle,
|
|
|
|
&AllocConsoleRequest->ErrorHandle,
|
[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
|
|
|
AllocConsoleRequest->ConsoleStartInfo);
|
2013-01-02 00:32:20 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-16 22:25:12 +00:00
|
|
|
DPRINT1("Console allocation failed\n");
|
2013-01-02 00:32:20 +00:00
|
|
|
return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-01-16 22:25:12 +00:00
|
|
|
/* Return it to the caller */
|
|
|
|
AllocConsoleRequest->Console = ProcessData->Console;
|
|
|
|
|
2013-01-02 00:32:20 +00:00
|
|
|
/* Input Wait Handle */
|
|
|
|
AllocConsoleRequest->InputWaitHandle = ProcessData->ConsoleEvent;
|
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
|
|
|
/* Set the Property Dialog Handler */
|
|
|
|
ProcessData->PropDispatcher = AllocConsoleRequest->PropDispatcher;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
/* Set the Ctrl Dispatcher */
|
2012-10-23 22:31:36 +00:00
|
|
|
ProcessData->CtrlDispatcher = AllocConsoleRequest->CtrlDispatcher;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2013-01-13 17:07:25 +00:00
|
|
|
CSR_API(SrvAttachConsole)
|
|
|
|
{
|
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
|
|
|
PCONSOLE_ATTACHCONSOLE AttachConsoleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.AttachConsoleRequest;
|
|
|
|
PCSR_PROCESS SourceProcess = NULL; // The parent process.
|
|
|
|
PCSR_PROCESS TargetProcess = CsrGetClientThread()->Process; // Ourselves.
|
|
|
|
HANDLE ProcessId = ULongToHandle(AttachConsoleRequest->ProcessId);
|
|
|
|
PCONSOLE_PROCESS_DATA SourceProcessData, TargetProcessData;
|
|
|
|
|
|
|
|
TargetProcessData = ConsoleGetPerProcessData(TargetProcess);
|
|
|
|
|
|
|
|
if (TargetProcessData->Console != NULL)
|
|
|
|
{
|
|
|
|
DPRINT1("Process already has a console\n");
|
|
|
|
return STATUS_ACCESS_DENIED;
|
|
|
|
}
|
|
|
|
|
2013-02-01 23:36:23 +00:00
|
|
|
/* Check whether we try to attach to the parent's console */
|
2013-01-13 17:07:25 +00:00
|
|
|
if (ProcessId == ULongToHandle(ATTACH_PARENT_PROCESS))
|
|
|
|
{
|
|
|
|
PROCESS_BASIC_INFORMATION ProcessInfo;
|
|
|
|
ULONG Length = sizeof(ProcessInfo);
|
|
|
|
|
|
|
|
/* Get the real parent's ID */
|
|
|
|
|
|
|
|
Status = NtQueryInformationProcess(TargetProcess->ProcessHandle,
|
|
|
|
ProcessBasicInformation,
|
|
|
|
&ProcessInfo,
|
|
|
|
Length, &Length);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("SrvAttachConsole - Cannot retrieve basic process info, Status = %lu\n", Status);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
ProcessId = ULongToHandle(ProcessInfo.InheritedFromUniqueProcessId);
|
|
|
|
}
|
|
|
|
|
2013-02-01 23:36:23 +00:00
|
|
|
/* Lock the source process via its PID */
|
2013-01-13 17:07:25 +00:00
|
|
|
Status = CsrLockProcessByClientId(ProcessId, &SourceProcess);
|
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
|
|
|
SourceProcessData = ConsoleGetPerProcessData(SourceProcess);
|
|
|
|
|
2013-02-01 23:36:23 +00:00
|
|
|
if (SourceProcessData->Console == NULL)
|
|
|
|
{
|
|
|
|
Status = STATUS_INVALID_HANDLE;
|
|
|
|
goto Quit;
|
|
|
|
}
|
|
|
|
|
2013-01-16 22:25:12 +00:00
|
|
|
/*
|
2013-01-24 22:41:33 +00:00
|
|
|
* We are about to create a new console. However when ConSrvNewProcess
|
2013-01-16 22:25:12 +00:00
|
|
|
* was called, we didn't know that we wanted to create a new console and
|
|
|
|
* therefore, we by default inherited the handles table from our parent
|
|
|
|
* process. It's only now that we notice that in fact we do not need
|
|
|
|
* them, because we've created a new console and thus we must use it.
|
|
|
|
*
|
|
|
|
* Therefore, free the console we can have and our handles table,
|
|
|
|
* and recreate a new one later on.
|
|
|
|
*/
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvRemoveConsole(TargetProcessData);
|
2013-01-16 22:25:12 +00:00
|
|
|
|
2013-01-13 17:07:25 +00:00
|
|
|
/*
|
|
|
|
* Inherit the console from the parent,
|
|
|
|
* if any, otherwise return an error.
|
|
|
|
*/
|
2013-02-01 23:36:23 +00:00
|
|
|
Status = ConSrvInheritConsole(TargetProcessData,
|
|
|
|
SourceProcessData->Console,
|
|
|
|
TRUE,
|
|
|
|
&AttachConsoleRequest->InputHandle,
|
|
|
|
&AttachConsoleRequest->OutputHandle,
|
|
|
|
&AttachConsoleRequest->ErrorHandle);
|
2013-01-13 17:07:25 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2013-02-01 23:36:23 +00:00
|
|
|
DPRINT1("Console inheritance failed\n");
|
2013-01-13 17:07:25 +00:00
|
|
|
goto Quit;
|
|
|
|
}
|
2013-01-16 22:25:12 +00:00
|
|
|
|
|
|
|
/* Return it to the caller */
|
|
|
|
AttachConsoleRequest->Console = TargetProcessData->Console;
|
|
|
|
|
2013-01-13 17:07:25 +00:00
|
|
|
/* Input Wait Handle */
|
|
|
|
AttachConsoleRequest->InputWaitHandle = TargetProcessData->ConsoleEvent;
|
|
|
|
|
[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
|
|
|
/* Set the Property Dialog Handler */
|
|
|
|
TargetProcessData->PropDispatcher = AttachConsoleRequest->PropDispatcher;
|
|
|
|
|
2013-01-13 17:07:25 +00:00
|
|
|
/* Set the Ctrl Dispatcher */
|
|
|
|
TargetProcessData->CtrlDispatcher = AttachConsoleRequest->CtrlDispatcher;
|
|
|
|
|
|
|
|
Status = STATUS_SUCCESS;
|
|
|
|
|
|
|
|
Quit:
|
2013-02-01 23:36:23 +00:00
|
|
|
/* Unlock the "source" process and exit */
|
2013-01-13 17:07:25 +00:00
|
|
|
CsrUnlockProcess(SourceProcess);
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvFreeConsole)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-02 00:32:20 +00:00
|
|
|
DPRINT1("SrvFreeConsole\n");
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvRemoveConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process));
|
2012-02-19 06:44:09 +00:00
|
|
|
return STATUS_SUCCESS;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleMode)
|
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
|
|
|
#define CONSOLE_INPUT_MODE_VALID ( ENABLE_PROCESSED_INPUT | ENABLE_LINE_INPUT | \
|
|
|
|
ENABLE_ECHO_INPUT | ENABLE_WINDOW_INPUT | \
|
|
|
|
ENABLE_MOUSE_INPUT | \
|
|
|
|
ENABLE_INSERT_MODE | ENABLE_QUICK_EDIT_MODE | ENABLE_EXTENDED_FLAGS )
|
|
|
|
#define CONSOLE_OUTPUT_MODE_VALID ( ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT )
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCONSOLEMODE ConsoleModeRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ConsoleModeRequest;
|
2013-01-18 22:31:16 +00:00
|
|
|
Object_t* Object = NULL;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetObject(ConsoleGetPerProcessData(CsrGetClientThread()->Process),
|
2012-11-17 23:07:59 +00:00
|
|
|
ConsoleModeRequest->ConsoleHandle,
|
2013-01-24 20:48:42 +00:00
|
|
|
&Object, NULL, GENERIC_WRITE, TRUE, 0);
|
2012-11-17 23:07:59 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-18 22:31:16 +00:00
|
|
|
Status = STATUS_SUCCESS;
|
2012-11-17 23:07:59 +00:00
|
|
|
|
2013-01-18 22:31:16 +00:00
|
|
|
if (CONIO_INPUT_BUFFER_MAGIC == Object->Type)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 20:48:42 +00:00
|
|
|
PCONSOLE_INPUT_BUFFER InputBuffer = (PCONSOLE_INPUT_BUFFER)Object;
|
|
|
|
InputBuffer->Mode = ConsoleModeRequest->ConsoleMode & CONSOLE_INPUT_MODE_VALID;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2013-01-18 22:31:16 +00:00
|
|
|
else if (CONIO_SCREEN_BUFFER_MAGIC == Object->Type)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 20:48:42 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buffer = (PCONSOLE_SCREEN_BUFFER)Object;
|
|
|
|
Buffer->Mode = ConsoleModeRequest->ConsoleMode & CONSOLE_OUTPUT_MODE_VALID;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Status = STATUS_INVALID_HANDLE;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseObject(Object, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleMode)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCONSOLEMODE ConsoleModeRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ConsoleModeRequest;
|
2013-01-18 22:31:16 +00:00
|
|
|
Object_t* Object = NULL;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetObject(ConsoleGetPerProcessData(CsrGetClientThread()->Process),
|
2012-11-17 23:07:59 +00:00
|
|
|
ConsoleModeRequest->ConsoleHandle,
|
2013-01-24 20:48:42 +00:00
|
|
|
&Object, NULL, GENERIC_READ, TRUE, 0);
|
2012-11-17 23:07:59 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
Status = STATUS_SUCCESS;
|
2012-11-17 23:07:59 +00:00
|
|
|
|
2013-01-18 22:31:16 +00:00
|
|
|
if (CONIO_INPUT_BUFFER_MAGIC == Object->Type)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 20:48:42 +00:00
|
|
|
PCONSOLE_INPUT_BUFFER InputBuffer = (PCONSOLE_INPUT_BUFFER)Object;
|
|
|
|
ConsoleModeRequest->ConsoleMode = InputBuffer->Mode;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2013-01-18 22:31:16 +00:00
|
|
|
else if (CONIO_SCREEN_BUFFER_MAGIC == Object->Type)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-01-24 20:48:42 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buffer = (PCONSOLE_SCREEN_BUFFER)Object;
|
|
|
|
ConsoleModeRequest->ConsoleMode = Buffer->Mode;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Status = STATUS_INVALID_HANDLE;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseObject(Object, TRUE);
|
2013-01-18 22:31:16 +00:00
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleTitle)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCONSOLETITLE TitleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.TitleRequest;
|
2012-11-18 13:10:03 +00:00
|
|
|
// PCSR_PROCESS Process = CsrGetClientThread()->Process;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
PWCHAR Buffer;
|
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
|
|
|
(PVOID)&TitleRequest->Title,
|
|
|
|
TitleRequest->Length,
|
|
|
|
sizeof(BYTE)))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2013-02-10 12:36:57 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2013-02-10 12:36:57 +00:00
|
|
|
DPRINT1("Can't get console\n");
|
|
|
|
return Status;
|
|
|
|
}
|
2012-11-18 13:10:03 +00:00
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
/* Allocate a new buffer to hold the new title (NULL-terminated) */
|
|
|
|
Buffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, TitleRequest->Length + sizeof(WCHAR));
|
|
|
|
if (Buffer)
|
|
|
|
{
|
|
|
|
/* Free the old title */
|
|
|
|
RtlFreeUnicodeString(&Console->Title);
|
2012-11-18 13:10:03 +00:00
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
/* Copy title to console */
|
|
|
|
Console->Title.Buffer = Buffer;
|
|
|
|
Console->Title.Length = TitleRequest->Length;
|
|
|
|
Console->Title.MaximumLength = Console->Title.Length + sizeof(WCHAR);
|
|
|
|
RtlCopyMemory(Console->Title.Buffer,
|
|
|
|
TitleRequest->Title,
|
|
|
|
Console->Title.Length);
|
|
|
|
Console->Title.Buffer[Console->Title.Length / sizeof(WCHAR)] = L'\0';
|
|
|
|
|
|
|
|
ConioChangeTitle(Console);
|
|
|
|
Status = STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Status = STATUS_NO_MEMORY;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleTitle)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETCONSOLETITLE TitleRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.TitleRequest;
|
2012-11-18 13:10:03 +00:00
|
|
|
// PCSR_PROCESS Process = CsrGetClientThread()->Process;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
DWORD Length;
|
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
|
|
|
(PVOID)&TitleRequest->Title,
|
|
|
|
TitleRequest->Length,
|
|
|
|
sizeof(BYTE)))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
2010-06-04 06:36:12 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Can't get console\n");
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Copy title of the console to the user title buffer */
|
2012-11-18 13:10:03 +00:00
|
|
|
if (TitleRequest->Length >= sizeof(WCHAR))
|
2010-06-04 06:36:12 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
Length = min(TitleRequest->Length - sizeof(WCHAR), Console->Title.Length);
|
|
|
|
memcpy(TitleRequest->Title, Console->Title.Buffer, Length);
|
|
|
|
TitleRequest->Title[Length / sizeof(WCHAR)] = L'\0';
|
2010-06-04 06:36:12 +00:00
|
|
|
}
|
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
TitleRequest->Length = Console->Title.Length;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**********************************************************************
|
2012-11-17 23:07:59 +00:00
|
|
|
* HardwareStateProperty
|
2010-05-31 06:28:55 +00:00
|
|
|
*
|
2012-11-17 23:07:59 +00:00
|
|
|
* DESCRIPTION
|
|
|
|
* Set/Get the value of the HardwareState and switch
|
|
|
|
* between direct video buffer ouput and GDI windowed
|
|
|
|
* output.
|
|
|
|
* ARGUMENTS
|
2013-01-05 23:37:04 +00:00
|
|
|
* Client hands us a CONSOLE_GETSETHWSTATE object.
|
|
|
|
* We use the same object to Request.
|
2012-11-17 23:07:59 +00:00
|
|
|
* NOTE
|
|
|
|
* ConsoleHwState has the correct size to be compatible
|
|
|
|
* with NT's, but values are not.
|
2010-05-31 06:28:55 +00:00
|
|
|
*/
|
|
|
|
static NTSTATUS FASTCALL
|
2013-01-05 23:37:04 +00:00
|
|
|
SetConsoleHardwareState(PCONSOLE Console, DWORD ConsoleHwState)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Console Hardware State: %d\n", ConsoleHwState);
|
|
|
|
|
|
|
|
if ((CONSOLE_HARDWARE_STATE_GDI_MANAGED == ConsoleHwState)
|
|
|
|
||(CONSOLE_HARDWARE_STATE_DIRECT == ConsoleHwState))
|
|
|
|
{
|
|
|
|
if (Console->HardwareState != ConsoleHwState)
|
|
|
|
{
|
|
|
|
/* TODO: implement switching from full screen to windowed mode */
|
|
|
|
/* TODO: or back; now simply store the hardware state */
|
|
|
|
Console->HardwareState = ConsoleHwState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_INVALID_PARAMETER_3; /* Client: (handle, set_get, [mode]) */
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleHardwareState)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETHWSTATE HardwareStateRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.HardwareStateRequest;
|
2013-01-18 22:31:16 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process),
|
2013-01-22 23:28:51 +00:00
|
|
|
HardwareStateRequest->OutputHandle,
|
|
|
|
&Buff,
|
|
|
|
GENERIC_READ,
|
|
|
|
TRUE);
|
2012-11-17 23:07:59 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-17 23:07:59 +00:00
|
|
|
DPRINT1("Failed to get console handle in SrvGetConsoleHardwareState\n");
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2013-01-18 22:31:16 +00:00
|
|
|
Console = Buff->Header.Console;
|
2013-01-05 23:10:12 +00:00
|
|
|
HardwareStateRequest->State = Console->HardwareState;
|
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;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleHardwareState)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETHWSTATE HardwareStateRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.HardwareStateRequest;
|
2013-01-18 22:31:16 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER Buff;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetScreenBuffer(ConsoleGetPerProcessData(CsrGetClientThread()->Process),
|
2013-01-22 23:28:51 +00:00
|
|
|
HardwareStateRequest->OutputHandle,
|
|
|
|
&Buff,
|
|
|
|
GENERIC_READ,
|
|
|
|
TRUE);
|
2012-11-17 23:07:59 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2012-10-22 23:55:51 +00:00
|
|
|
{
|
2012-11-17 23:07:59 +00:00
|
|
|
DPRINT1("Failed to get console handle in SrvSetConsoleHardwareState\n");
|
2012-10-22 23:55:51 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-11-17 23:07:59 +00:00
|
|
|
DPRINT("Setting console hardware state.\n");
|
2013-01-18 22:31:16 +00:00
|
|
|
Console = Buff->Header.Console;
|
2013-01-05 23:10:12 +00:00
|
|
|
Status = SetConsoleHardwareState(Console, HardwareStateRequest->State);
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseScreenBuffer(Buff, TRUE);
|
2012-10-22 23:55:51 +00:00
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
CSR_API(SrvGetConsoleWindow)
|
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETWINDOW GetWindowRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.GetWindowRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-03-20 00:41:47 +00:00
|
|
|
GetWindowRequest->WindowHandle = ConioGetConsoleWindowHandle(Console);
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleIcon)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_SETICON SetIconRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.SetIconRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +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 = (ConioChangeIcon(Console, SetIconRequest->WindowIcon)
|
2012-11-18 13:10:03 +00:00
|
|
|
? STATUS_SUCCESS
|
|
|
|
: STATUS_UNSUCCESSFUL);
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleCP)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETINPUTOUTPUTCP ConsoleCPRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ConsoleCPRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
DPRINT("SrvGetConsoleCP, getting %s Code Page\n",
|
|
|
|
ConsoleCPRequest->InputCP ? "Input" : "Output");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
ConsoleCPRequest->CodePage = (ConsoleCPRequest->InputCP ? Console->CodePage
|
|
|
|
: Console->OutputCodePage);
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2012-10-22 23:55:51 +00:00
|
|
|
return STATUS_SUCCESS;
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvSetConsoleCP)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSETINPUTOUTPUTCP ConsoleCPRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.ConsoleCPRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
DPRINT("SrvSetConsoleCP, setting %s Code Page\n",
|
|
|
|
ConsoleCPRequest->InputCP ? "Input" : "Output");
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
if (IsValidCodePage(ConsoleCPRequest->CodePage))
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
if (ConsoleCPRequest->InputCP)
|
|
|
|
Console->CodePage = ConsoleCPRequest->CodePage;
|
|
|
|
else
|
|
|
|
Console->OutputCodePage = ConsoleCPRequest->CodePage;
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleProcessList)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETPROCESSLIST GetProcessListRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.GetProcessListRequest;
|
2010-05-31 06:28:55 +00:00
|
|
|
PDWORD Buffer;
|
2012-11-18 13:10:03 +00:00
|
|
|
// PCSR_PROCESS Process = CsrGetClientThread()->Process;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2012-11-18 13:10:03 +00:00
|
|
|
PCONSOLE_PROCESS_DATA current;
|
2010-05-31 06:28:55 +00:00
|
|
|
PLIST_ENTRY current_entry;
|
|
|
|
ULONG nItems = 0;
|
|
|
|
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!CsrValidateMessageBuffer(ApiMessage,
|
|
|
|
(PVOID)&GetProcessListRequest->pProcessIds,
|
|
|
|
GetProcessListRequest->nMaxIds,
|
|
|
|
sizeof(DWORD)))
|
|
|
|
{
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
Buffer = GetProcessListRequest->pProcessIds;
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
|
|
|
for (current_entry = Console->ProcessList.Flink;
|
|
|
|
current_entry != &Console->ProcessList;
|
|
|
|
current_entry = current_entry->Flink)
|
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
current = CONTAINING_RECORD(current_entry, CONSOLE_PROCESS_DATA, ConsoleLink);
|
2012-10-25 21:37:52 +00:00
|
|
|
if (++nItems <= GetProcessListRequest->nMaxIds)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
*Buffer++ = HandleToUlong(current->Process->ClientId.UniqueProcess);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2012-10-25 21:37:52 +00:00
|
|
|
GetProcessListRequest->nProcessIdsTotal = nItems;
|
2010-05-31 06:28:55 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGenerateConsoleCtrlEvent)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
2012-11-18 13:10:03 +00:00
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GENERATECTRLEVENT GenerateCtrlEventRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.GenerateCtrlEventRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2012-11-18 13:10:03 +00:00
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-03-19 23:40:20 +00:00
|
|
|
Status = ConSrvConsoleProcessCtrlEvent(Console,
|
|
|
|
GenerateCtrlEventRequest->ProcessGroup,
|
|
|
|
GenerateCtrlEventRequest->Event);
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_API(SrvGetConsoleSelectionInfo)
|
2010-05-31 06:28:55 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
2013-01-05 23:10:12 +00:00
|
|
|
PCONSOLE_GETSELECTIONINFO GetSelectionInfoRequest = &((PCONSOLE_API_MESSAGE)ApiMessage)->Data.GetSelectionInfoRequest;
|
2013-01-05 23:37:04 +00:00
|
|
|
PCONSOLE Console;
|
2010-05-31 06:28:55 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
Status = ConSrvGetConsole(ConsoleGetPerProcessData(CsrGetClientThread()->Process), &Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
2013-01-05 23:10:12 +00:00
|
|
|
memset(&GetSelectionInfoRequest->Info, 0, sizeof(CONSOLE_SELECTION_INFO));
|
2010-05-31 06:28:55 +00:00
|
|
|
if (Console->Selection.dwFlags != 0)
|
2013-01-05 23:10:12 +00:00
|
|
|
GetSelectionInfoRequest->Info = Console->Selection;
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvReleaseConsole(Console, TRUE);
|
2010-05-31 06:28:55 +00:00
|
|
|
}
|
2012-11-18 13:10:03 +00:00
|
|
|
|
2010-05-31 06:28:55 +00:00
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|