Писать в запрещенные адреса памяти.

← →
McSimm (2001-11-13 12:55) [0]

Желательно получить возможность писать в адресное пространство чужого кода. Это не в целях вредительства, а наоборот. (может кто-то помнит тему "соревнования программ"?)
Суть проблемы: пытаюсь подставить свой обработчик функции API вместо стандартного. Вот пробный код записи:
procedure TForm1.Button1Click(Sender: TObject); var P1, P2: PByteArray; B: Byte; begin P1 := @MessageBoxA;// адрес шлюза (jmp [ProcAdr]) if P1 <> nil then begin asm mov eax, P1 add eax, 2 // смещаемся на 2 байта (код jmp) mov eax, [eax] // получаем адрес адреса mov eax, [eax] // получаем адрес User32.MessageBoxA mov P2, eax end; if P2 <> nil then begin B := P2[0]; // читаем первый байт кода User32.MessageBoxA P2[0] := B // Пытаемся писать. end end end;
Как и ожидалось, запись не прошла. Однако говорят что такое возможно. Что уважаемые мастера могут сказать по этому вопросу?

Спасибо

← →
Digitman (2001-11-13 14:21) [1]

начнем с того, что непосредственная запись в сегмент кода запрещена на уровне механизма защиты.

← →
Алексей Петров (2001-11-13 14:27) [2]

И легко разрешается (по крайней мере под NT и 2K) вызовом функции VirtualProtect :)

← →
Digitman (2001-11-13 14:30) [3]

... но это уже - не непосредственная запись.

← →
McSimm (2001-11-13 14:44) [4]

Спасибо всем, попробую разобраться.

← →
paul_shmakov (2001-11-13 16:48) [5]

2 McSimm:
А зачем ты находишь адрес MessageBoxA таким способом? Дело в том, что этого шлюза (jmp XXXX) вообще быть там не может в некоторых случаях. Лучше
P1 := GetProcAddress(GetModuleHandle("kernel32.dll"), "MessageBoxA");

← →
paul_shmakov (2001-11-13 17:02) [6]

шлюз там этот, кстати, обычно бывает в случае запуска приложения под отладчиком. и имхо только в win9x (хотя здесь я могу ошибаться).
и опять же, если я не ошибаюсь, то VirtualProtect не сработает в win9x/me, если ты попытаешься изменить атрибут защиты на PAGE_READWRITE у одной из системных dll. т.к. они загружены в разделяемое адресное пространство.
для этого нужно обратиться в ring0.
asm push 020060000h // PC_WRITEABLE | PC_USER | PC_STATIC push 0FFFFFFFFh // Keep all previous bits push dword ptr [dwNumPages] // dword ptr [mbi+0Ch] # of pages push dword ptr [dwFirstPage] // dword ptr [ped] page # push 1000Dh // _PageModifyPermissions (win32_service_table #) call dword ptr [VxDCall] // VxDCall0 end;
согласись, что непросто. к тому же, все таки, перехватывать вызовы к GetProcAddress - бесполезно :( т.к. написать свой аналог GetProcAddress очень просто - это всего лишь 30-40 строк кода.

← →
McSimm (2001-11-13 17:49) [7]

>paul_shmakov ©
В этих вопросах чувствую себя чайником.
Насколько я заметил, шлюзы эти есть всегда. На самом деле код набросал на скорую руку с единственной целью посмотреть на реакцию Windows при записи в ее святая-святых, о тонкостях не думал.
Насчет особенностей VirtualProtect под Win9x меня уже предупредил Алексей Петров.

>обратиться в ring0
чур меня :)

>аналог GetProcAddress
Таких ударов судьбы Остап не испытывал никогда. А такой вопрос. Стоит ли вообще искать способ безопасно подгрузить DLL? Или способов навредить гораздо больше чем можно предусмотреть? Как там насчет использования прерываний с вредительской целью, например?

To all,
Может стоит все-таки попробовать загружать DLL в NT с правами, недостаточными для вредительства? Как вы оцените перспективность подобного способа?

← →
paul_shmakov (2001-11-13 18:05) [8]

права здесь ничем не помогут. "способов навредить гораздо больше чем можно предусмотреть". ты абсолютно прав. единственный вариант (в контексте "соревнования программ") - это вообще не позволять dll-кам обращаться никуда, грузить их не с помощью loadlibrary, а своей процедурой (как back orifice), запускать в режиме отладки и смотреть, чтобы код не обращался к адресам, к которым доступа быть не должно.
даже тот вариант, о котором мы с тобой по e-mail обсуждали (правка самих функий api) тоже можно обойти - dll подгружается, смотрит, что мы там напатчили, меняет все назад и спокойно работает.
так что лучше забей на это дело :(

← →
Алексей Петров (2001-11-14 09:11) [9]

> paul_shmakov © (13.11.01 18:05)
На счет "права не помогут" не согласен.

Предложи хоть один способ навредить из DLL, работающей под NT под учетной записью обычного пользователя, не имеющей права на запись ни где, кроме "MyDocuments". Или под гостем?
Ну и инет на период её работы если отключить?

Хотя есть конечно дыры и в NT-шной защите :(

Основной недостаток данного пути - у многих стоит win9x.

← →
paul_shmakov (2001-11-14 10:47) [10]

смотря, что считать вредительством. если говорить о "соревнованиях программ", то, например, одна из dll может навредить тем, что понизит приоритет потока dll-соперницы. ведь, несмотря на ограничение всех прав, почти все api доступны, а те, что даже запрещены, в некоторых случаях могут быть разрешены. еще недокументированное api есть.

Писать в запрещенные адреса памяти. Найти похожие ветки