Случайно натолкнулся на твое сообщение про мороку с native.exe Я тоже давно пытаюсь запустить что-нибудь над голым ядром. Успехи такие : нашел текст проги с выводом на консоль через NtDisplayString. Перетранслировал ее и запустил. Сначала через ключ bootexecute, а потом стал использовать пропатченный smss.exe из ERD-Commander и запускать вместо AUTOCHK по команде chkdsk. Есть у меня текст программы с функцией ввода с клавиатуры, т.ч. можно в принципе файл-менеджер наваять.
Ты имеешь ввиду exe , которое я запускал без импорта на w2k ? Мои native знания ограничиваються только тем , что можна увидеть из ring3 отладчика , конкретно тогда я хотел как-нибудь сообщить юзеру , что прога работает , и самым простым это оказалось бипнуть через int2e . Но вывод сделал такой , что это всё не универсально , работает только на конкретной оси и вообще возможностей маловато , с одним ntdll "GUI" прогу лобать смысла не вижу . Хотя если делать не GUI , то конечно полезно бы знать о возможностях (универсальных для NT) , которые предоставляет ntdll .
Да, вспомнил я про драйвера и ring3. Тогда NtDisplayString не совсем подходит. Она выводит на "голубой экран". Понадобится еще куча функций. А меня собственно заинтересовал вопрос : если подгрузить kernel32.dll в голом ядре, можно ли запустить консольную программу. В моем эксперименте она подгрузилась, но получился экран смерти с ошибкой инициализации DLL. Теперь хочу подгрузить kernel32.dll сам ( до этого его грузила функция RtlCreateUserProcess) через LdrLoadDll и сравнить.
При создании обычного процесса , после проецирования всех модулей в память ntdll инициализирует длл-ки (вызывает их entrypoint) , то что происходит при инициализации kernel32.dll не вмещаеться в голове , очень много действий выполняеться , и именно kernel32.dll анализирует SUBSYSTEM PE заголовка главного модуля на предмет CONSOLE (03h) , показать её или нет (возможно ещё создаёт какое-то перенаправление ввода-вывода для консоли в CSRSS ) . Потом чтобы использовать окно консоли мы получаем хендл "invoke GetStdHandle,STD_OUTPUT_HANDLE" , этот код можно свести к такому : Код (Text): mov eax,[fs:18h] ; data block of main thread mov eax,[eax+30h] ; ptr PEB mov eax,[eax+10h] ; ptr RTL_USER_PROCESS_PARAMETERS mov eax,[eax+1Ch] ; StandardOutput А WriteConsole (WriteFile) сводиться к : Код (Text): ntdll.CsrClientCallServer ntdll.ZwRequestWaitReplyPort А как там в ядре х.з. , может быть и такое : http://www.phrack.org/show.php?p=62&a=6 Creating a full-fledged win32-process requires it's registration in the CSRSS subsystem. This is accomplished by using CsrClientCallServer(), which receives all necessary information about the process (handles, TID, PID, flags). The functions calls ZwRequestWaitReplyPort, which receives a handle of a pre-viously opened port for connection with CSRSS. This port is not open in the SYSTEM process context. Opening it never succeeded (ZwConnectPort returned STATUS_PORT_CONNECTION_REFUSED). Play-ing with SECURITY_QUALITY_OF_SERVICE didn't help. While disassembling ntdll.dll I saw that ZwConnectPort calls were preceded by ZwCreateSection. But there was no time and no desire to play with sections.
Это информация слишком крутая для меня. Похоже, что придется переписывать функции из kernel32.dll для обхода всяких проверок. Есть пример реализации GUI над ядром : Disk Commander от winternals. Сделан он с помощью ZINC - это набор библиотек и утилит для разработки embedded приложений. Этот ZINC у меня есть и там все достаточно прозрачно. Но в нем есть интерфейсные библиотеки только под WIN32. Все вроде все в текстах, т.ч. если напрячься то можно написать подобное под ntdll. Кроме того, никто не мешает детранслировать сам Disk Commander, хотя там придется выискивать родное GUI от ZINC, т.к. они не используют DLL и все внедрено в экзешник.
Тю , эту информацию видно в отладчике , как сам увидешь то становиться намного понятней . Например можешь загрузить в олли прогу из такого кода : Код (Text): ;===================================================================== buffer db 'test message' bsize = $-buffer count dd 0 ;===================================================================== start: invoke GetStdHandle,STD_OUTPUT_HANDLE invoke WriteFile,eax,buffer,bsize,count,0 invoke ExitProcess,0 ;===================================================================== Только предварительно выставить в Options\Event\ - Make first pause at "system breakpoint" . И вдруг вообще возможно обойтись без kernel32.dll , может нужно только уметь общаться с CSRSS .
valterg > Я как-то немного поискал это, и как понял, что бы его получить, нужно писать на мыло куда-то в psa-software ? ;( > afaik основа GUI лежит в ядре - win32k.sys - это системные вызовы с номерами >= 0x1000 туда идет всё: GDI/GDI+, DX.. Конечно MessageBox так не нарисуешь, придётся потрудиться.. IMHO если очень сильно "напрячься", то можно пойти ещё дальше - указатель на видеопамять под виндосом получить не проблема, и можно вообще всё самому рисовать ручками Это всё больше "ля-ля", т.к. когда-то совсем немного копал в этом направлении, а щас времени нету
S_T_A_S_ Это я уже усвоил. Но вот Disk Commander обходится без него. GUI у него конечно тормозной, но есть кнопки, есть список файлов. Я говорю про версию 1.1 В самом ZINC есть все стандартные элементы GUI. Вся реализация в коммандере вместе с аппаратом восстановления файлов - 540 Кб. Ну возможно еще что-то запрятано в запускалке на 200 Кб. Я же говорю есть все в текстах + простенькая интегрированная оболочка. Оболочку я не проверял. Еще я нашел доки на Zinc 6-й версии( у меня 5.3) и нового хозяина : Wind River. А вот psa-sofware использует это все для встроенных систем и как многие другие продает или раздает библиотеки под Zinc Application Framework (ZAF). Судя по ссылкам, ZINC for Desktop теперь действительно по мылу "раздает" psa-software, хотя недавно это делал Wind River ( не путать с Win Driver пакетом).
