Пробую этот эксплоит https://github.com/Re4son/KiTrapOD/blob/master/vdmexploit.c на виндовс хп для повышения прав.
Скачал уже собранный, на хп работает, все окей.
Решил из тех исходников собрать экзешник и либу, экзешник нормально собрал, а либу криво.
Хочу в ollydbg сравнить ту либу и которую собирал, чтобы найти ошибку.
Но почему-то при отладке этой либы под ollydbg в момент входа в ядро тут:
NtVdmControl(VdmStartExecution, NULL); в дебагере sysenter вываливается в синий экран, но без отладчика все норм.
А после она выходит из ядра и выполняет функцию VOID FirstStage()
Я хотел ее отлаживать, саму функцию нашел в отладчике, но из-за синего экрана до нее дойти не могу.


Пробовал в начало FirstStage() прописать MessageBoxA чтобы приаттачиться уже после выхода из ядра, но в этом случае она начинает и вне отладчика в синий экран кидать.
Может кто подскажет как обойти синий экран в отладчике.

| Сообщение посчитали полезным:

> в дебагере sysenter вываливается в синий экран, но без отладчика все норм.

А если под отладчиком запустить не крэшит ?

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
А если под отладчиком запустить не крэшит ?
Если запустить под отладчиком экзешник то не крашит.
Но я отлаживаю либу, которую сплоит пихает удаленным потоком в процесс ntvdm.exe из system32, в начало либы messageboxa поставил, чтобы аттачиться к этому ntvdm.exe пока висит сообщение.
Вот в этом случае хоть по шагам, хоть запустить падает в синий экран.
На вин хп сп2 х86 на виртуалке пробую.

| Сообщение посчитали полезным:

mazaxaker

Не понятно. То вы говорите что крэшит на сервисе, то процесс какой то левый и крэшит. Опишите понятно и крэшдамп тоже покажите.

-----
vx

| Сообщение посчитали полезным:

difexacaw, про сервис не говорил ведь. Экзешник через удаленный поток подсовывает либу в системный процесс винды ntvdm.exe и в нем ее запускает, я аттачусь к этому процессу и при отладке крешит в синий экран.

1200_05.01.2017_EXELAB.rU.tgz - Mini010517-14.dmp

| Сообщение посчитали полезным:

mazaxaker

Судя по виндбг крэшит fxsave в ядре, что не есть гуд, без отладки суть крэша узнать не получится. Впрочем не удивительно - LPE не отлаживается обычно через юзер дебаггер, юзайте виндбг.

-----
vx

| Сообщение посчитали полезным:

difexacaw, виндбг можно конечно, но мне по сути интересна функция юзермодная, в которую прога выходит из ядра.

| Сообщение посчитали полезным:

mazaxaker пишет:
по сути интересна функция юзермодная, в которую прога выходит из ядра

В юзермоде система синяки не показывает

| Сообщение посчитали полезным:

mazaxaker

Если бы оно крэшило как вы сразу сказали - при трассировке сервиса, то суть была бы ясна, отличие в обработке известно. Но оно крэшит в зависимости от фазы луны, так как отладчик воздействует на огромное число механизмов, может существовать совсем не очевидная цепочка причин в конце концов приводящая к крэшу, так как LPE которые робят через смещение стека - как этот являются анстаб и любой внешний фактор делает его не рабочим. По нормальному нужно или отлаживать или полностью разбирать дамп, для этого нужно много времени и ваше ядро.
Можно было бы что то предположить по вменяемому описанию, к примеру в какой именно момент происходит крэш, то что при отладки крэшит" это никакая не инфа.)
Да и семпл этот кривой, его весь ядерный кодес выполняется при замаскированных прерываниях, юзая при этом рандом - подкачиваемую памяти и даже сервисы, отдавая управление вникуда. Так что возможно крэшит сам семпл из за изменений рабочего набора отладчиком.

-----
vx

| Сообщение посчитали полезным:

difexacaw, вот добавил jmp на себя в ту функцию, которая после ядра идет. Теперь такой бсод вылетает, но после добавления jmp в нее теперь и без отладчика крешится.
Не пойму почему добавления jmp в ту функцию, которая уже юзермодная ее теперь крешит даже без отладчика.

cb64_05.01.2017_EXELAB.rU.tgz - Mini010517-17.dmp

| Сообщение посчитали полезным:

mazaxaker

На этот раз падение драйвера гуя(win32k). Говорю же это рандом события, семпл не рабочий.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
это рандом события
Да понимаю, но вот не пойму, почему начинает крешить, если либу патчу джампом на себя, чтобы ее зациклить и приаттачиться к ней. Именно падает без отладчика даже в этом случае.
По идее то на джампе должна зависнуть и ждать, но почему-то крешится.

| Сообщение посчитали полезным:

mazaxaker

Там обращение к выгружаемой памяти из под самого высокого IRQL, такая манипуляция - бсодогенератор на рандоме. Память непрерывно свопается, а это обращается к памяти, состояние которой в прямом смысле рандомно. Результат очевиден.

-----
vx

| Сообщение посчитали полезным:

difexacaw, да понял. Сейчас пробую либу собрать из сорцов. Саму либу собрал, но что-то в коде видать в сорцах ошибки, сейчас хочу ее скомпиленную сравнить через отладчик с той, которая собраная была и рабочая. Моя из сорцов чет не дает привелегии. Походу с указателями где-то напутал при сборке.

Добавлено спустя 5 минут
difexacaw, в аттаче мой исходник, собирал в студии 2010, а это оригинальные https://github.com/Re4son/KiTrapOD/blob/master/vdmexploit.c

В оригинальных сорцах прога не попадает на Exitthread этот. Это хорошо. А в моих сорцах попадает туда.
306 ExitThread('VTIB');

Оригинальная прога на выходе сюда попадает. Это хорошо.
ZwTerminateProcess(GetCurrentProcess(), 'w00t');
А моя на том экзите с параметром VTIB выходит, что плохо.

Можете глянуть так может увидете где косяк.

6f39_06.01.2017_EXELAB.rU.tgz - main.cpp

| Сообщение посчитали полезным:

Я еще заметил, что функция, в которую прога из ядра выходит, на эту функцию накинута пара cli/sti.
Вот пробую jmp пихнуть внутри там, но при остановке на jmp в этом блоке виснет комп намертво. А если ставлю jmp на себя до cli, то синий экран.
Как бы остановить прогу в этой функции без креша и приаттачиться туда ?

Кстати прога в этой функции для вывода текста в консоль использует DbgPrint, а ее адрес получает без помощи getprocaddress, а через таблицы по имени ищет. Если там ее имя подменить на MessageBox, такая идея, как думаете не крешнится ли она после такого или точнее найдет ли она в той таблице эту функцию.

| Сообщение посчитали полезным:

Запускайте пример в vmware с xp нужной версии, подключайтесь к vmware через связку windbg+ida (например) и спокойно отлаживайте ядро в любом месте

| Сообщение посчитали полезным:

mazaxaker пишет:
Пробовал в начало FirstStage() прописать MessageBoxA чтобы приаттачиться уже после выхода из ядра, но в этом случае она начинает и вне отладчика в синий экран кидать.

Прошу прощения, но вы чушь какую-то делаете. Посмотрел ваш исходник, какие-то MessageBox'ы в режиме ядра. Понятно, что крэшить все будет. И никакого выхода из ядра нету внутри FirstStage, это все код режима ядра. Кстати, сообщения в этом коде лучше выводить через DbgPrint, как в оригинальном исходнике. И если уж так хочется этот код отлаживать можно попробовать в начало этих функций вместо MessageBox поставить int 3, по идее, отладчик должен всплыть. Кроме того, вы видимо пытаетесь отлаживать локально (через Syser), а такие вещи лучше делать удаленно, подключаясь к виртуалке через тот же windbg, как в предыдущем посте написали.

| Сообщение посчитали полезным:

mazaxaker

> Я еще заметил, что функция, в которую прога из ядра выходит, на эту функцию накинута пара cli/sti.
Вот пробую jmp пихнуть внутри там, но при остановке на jmp в этом блоке виснет комп намертво.

Я это выше несколько раз вам повторил, но вы же не слушаете. cli там быть не должно, упоротый автор его туда вставил вообще не понимая зачем. Вообще же такие вещи методом тыка не делаются, если код это POC, то добиваться его работоспособности бессмысленно, он не для того нужен.

-----
vx

| Сообщение посчитали полезным: