Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "WinAPI";
Текущий архив: 2002.01.14;
Скачать: [xml.tar.bz2];

Вниз

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

 
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 есть.



Страницы: 1 вся ветка

Форум: "WinAPI";
Текущий архив: 2002.01.14;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.59 MB
Время: 0.021 c
4-42613
Karan
2001-11-14 14:19
2002.01.14
DLL<->Variant


3-42358
Aquarius
2001-12-11 15:55
2002.01.14
Чтение данных из XML и их запихивание в базу.


1-42423
vinni2000
2001-12-26 14:18
2002.01.14
У меня есть проблема.


4-42610
-=CrazyFish=-
2001-11-13 21:30
2002.01.14
перерисовка ScrollBar


4-42603
Русский
2001-11-09 10:29
2002.01.14
Форма





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский