информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
любой левософтовой длл в системе которая соизволила... 11.11.08 01:39  Число просмотров: 3532
Автор: Tamas Статус: Member
<"чистая" ссылка>
> память может быть занята:
> стеком потока
> кучей процесса, которую создают и используют системные длл,
> в тч kernel32.dll, user32.dll, ntdll,dll etc
> твоей собственной кучей
> любой левософтовой длл в системе которая соизволила
> загрузиться в твой процесс
> вообще КЕМ угодно. В корне ошибочно считать что ты
> полностью контролируешь весь исполняемый в процессе код, и
> что вообще это можно сделать. Не говоря уж о том что память
> могут выделить и извне.
> Память нужно резервировать когда процесс еще не начал
> исполняться

любой левософтовой длл в системе которая соизволила загрузиться в твой процесс
ну для этого кто то ещё должен подгрузить такой DLL к моему процессу а для этого он должен выполнить OpenProcess а для этого ему нужны сответствующии привелегии...

хотя вобщем ваши рассуждения верны... надо думать
<programming>
[Win32] проблема с VirtualAlloc 09.11.08 19:10  
Автор: Tamas Статус: Member
<"чистая" ссылка>
в общем так из своей программы с imagebase 0x10000000(устанавливаю в параметрах линкера gcc)
вызываю VirtualAlloc((void*)0x00400000,0x00004000,MEM_RESERVE,PAGE_NOACCESS);
всё в общем работает память выделяет... но через раз иногда VirtualAlloc слетает с ошибкой 487 ERROR_INVALID_ADDRESS ???

PS спросите зачем именно выделять память в 0x00400000 ??? а это для того чтобы загрузить туда образ Exe с imagebase 0x00400000
может потому что этот адрес был уже занят? хинт: кроме твоей... 09.11.08 20:26  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
может потому что этот адрес был уже занят? хинт: кроме твоей программы в твоем процессе еще туева хуча системного и не только кода длл которые могут выделять память для своих целей, и которая вполне может оказаться в нужном тебе диапазоне адресов.
как я понимаю виртуальная память как везде написано может... 09.11.08 23:00  
Автор: Tamas Статус: Member
<"чистая" ссылка>
> может потому что этот адрес был уже занят? хинт: кроме
> твоей программы в твоем процессе еще туева хуча системного
> и не только кода длл которые могут выделять память для
> своих целей, и которая вполне может оказаться в нужном тебе
> диапазоне адресов.

как я понимаю виртуальная память как везде написано может быть в 3 состояниях
1 свобдная
2 занетая
3 файл мапинг

если занетая вызываю VirtualFree((void*)0x00400000,0,MEM_RELEASE);
вызов заканчивается с темже 487

так ну значет мапинг вызываю UnmapViewOfFile((void*)0x00400000);
тоже самое 487

но иногда бывает что всё срабатывает и память выделяется....
так как всё таки выделить нужный мне кусок памяти ????

да кстати всё это происходит по Vista
Во первых, интересно зачем такой метод тыка? Не проще ли... 10.11.08 02:15  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> если занетая вызываю
> VirtualFree((void*)0x00400000,0,MEM_RELEASE);
> вызов заканчивается с темже 487
>
> так ну значет мапинг вызываю
> UnmapViewOfFile((void*)0x00400000);
> тоже самое 487
Во первых, интересно зачем такой метод тыка? Не проще ли сделать VirtualQuery и посмотреть в каком состоянии находится 0x00400000?
или !vprot в windbg..
Во вторых у меня такой подход работает в продукте без проблем, кстати примерно для таких же целей. Только память я выделяю в новосозданном и не resume'нутом процессе удаленно. Налету все равно это как рулетка ведь...
VirtualQuery делал встречется 3 состояния 10.11.08 02:28  
Автор: Tamas Статус: Member
Отредактировано 10.11.08 02:31  Количество правок: 1
<"чистая" ссылка>
> > если занетая вызываю
> > VirtualFree((void*)0x00400000,0,MEM_RELEASE);
> > вызов заканчивается с темже 487
> >
> > так ну значет мапинг вызываю
> > UnmapViewOfFile((void*)0x00400000);
> > тоже самое 487
> Во первых, интересно зачем такой метод тыка? Не проще ли
> сделать VirtualQuery и посмотреть в каком состоянии
> находится 0x00400000?
> или !vprot в windbg..
> Во вторых у меня такой подход работает в продукте без
> проблем, кстати примерно для таких же целей. Только память
> я выделяю в новосозданном и не resume'нутом процессе
> удаленно. Налету все равно это как рулетка ведь...

VirtualQuery делал встречется 3 состояния
1 свободно всё срабатывает
2 мапинг помогает вызов UnmapViewOfFile
3 что то не ясной этиалогии MSDN считает что это MEM_PRIVATE 0x20000
что это такое я не знаю Indicates that the memory pages within the region are private (that is, not shared by other processes).

ладно дальше делаем VirtualFree и после этого процесcа с грохотом падает :-(

делать всё это вдругом процесе я уже делал... это всё работает но у меня цель другая запустить Exe нужно в контексте именно одного процесса...
А не офигел ли ты освобождать чужую память и ожидать, что не... 10.11.08 22:10  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> ладно дальше делаем VirtualFree и после этого процесcа с
> грохотом падает :-(
А не офигел ли ты освобождать ЧУЖУЮ память и ожидать, что не свалишься. Даже если ты попадешь по базе и нормально распакуешь туда свой exe-шник, закончится это тем, что тот, кто выделил (и сохранил указатель, прошу заметить) эту память напишет туда своих данных и ты упадешь уже в процессе работы.
как я понел проблема в gcc котрый под гружает много лишнего... 10.11.08 23:15  
Автор: Tamas Статус: Member
<"чистая" ссылка>
> > ладно дальше делаем VirtualFree и после этого процесcа
> с
> > грохотом падает :-(
> А не офигел ли ты освобождать ЧУЖУЮ память и ожидать, что
> не свалишься. Даже если ты попадешь по базе и нормально
> распакуешь туда свой exe-шник, закончится это тем, что тот,
> кто выделил (и сохранил указатель, прошу заметить) эту
> память напишет туда своих данных и ты упадешь уже в
> процессе работы.

как я понел проблема в gcc котрый под гружает много лишнего по умолчанию....
в lcc-win32 при выделении базы допустим 0x01000000
всё прекрасно работает вот только линкер lcc не умеет менять imagebase
и использует всегда 0x00400000 а этот адрес нужен для большенства Exe'ков
или я не прав и lcclnk умет линковать с любой базой
Ты чего хочешь вообще? 11.11.08 00:54  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> как я понел проблема в gcc котрый под гружает много лишнего
> по умолчанию....
Нет

> в lcc-win32 при выделении базы допустим 0x01000000
> всё прекрасно работает вот только линкер lcc не умеет
> менять imagebase
> и использует всегда 0x00400000 а этот адрес нужен для
> большенства Exe'ков
> или я не прав и lcclnk умет линковать с любой базой

Я уже написал, что нормальный exe-пакер должен базировать запакованный бинарь по тому же адресу, что и исходный. Более того, если получившийся бинарь будет меньше исходного, то надо зарезирвировать себе память дополнительной BSS-секцией. В этом случае нужная тебе память будет уже выделена, если ты вообще запустился. В случае упакованной dll-ки надо по любому предусматривать настройку fixup-ов, потому что загрузить тебя могут вообще по любому адресу.

PS: И да, почему lcc, gcc при разработке под винду? Потому что это "против системы"?
PPS: grammar nazy внутри меня чуть отмодерил твой пост.
проблема в подходе 10.11.08 23:42  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 10.11.08 23:43  Количество правок: 1
<"чистая" ссылка>
память может быть занята:
стеком потока
кучей процесса, которую создают и используют системные длл, в тч kernel32.dll, user32.dll, ntdll,dll etc
твоей собственной кучей
любой левософтовой длл в системе которая соизволила загрузиться в твой процесс
вообще КЕМ угодно. В корне ошибочно считать что ты полностью контролируешь весь исполняемый в процессе код, и что вообще это можно сделать. Не говоря уж о том что память могут выделить и извне.
Память нужно резервировать когда процесс еще не начал исполняться
любой левософтовой длл в системе которая соизволила... 11.11.08 01:39  
Автор: Tamas Статус: Member
<"чистая" ссылка>
> память может быть занята:
> стеком потока
> кучей процесса, которую создают и используют системные длл,
> в тч kernel32.dll, user32.dll, ntdll,dll etc
> твоей собственной кучей
> любой левософтовой длл в системе которая соизволила
> загрузиться в твой процесс
> вообще КЕМ угодно. В корне ошибочно считать что ты
> полностью контролируешь весь исполняемый в процессе код, и
> что вообще это можно сделать. Не говоря уж о том что память
> могут выделить и извне.
> Память нужно резервировать когда процесс еще не начал
> исполняться

любой левософтовой длл в системе которая соизволила загрузиться в твой процесс
ну для этого кто то ещё должен подгрузить такой DLL к моему процессу а для этого он должен выполнить OpenProcess а для этого ему нужны сответствующии привелегии...

хотя вобщем ваши рассуждения верны... надо думать
С настройками безопасности по-умолчанию открывать процесс... 11.11.08 01:51  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> любой левософтовой длл в системе которая соизволила
> загрузиться в твой процесс
> ну для этого кто то ещё должен подгрузить такой DLL к моему
> процессу а для этого он должен выполнить OpenProcess а для
> этого ему нужны сответствующии привелегии...
> хотя вобщем ваши рассуждения верны... надо думать
С настройками безопасности по-умолчанию открывать процесс может любой другой процесс, принадлежащий тому же юзеру. И для этого никаких "привилегий" (SE_DEBUG_NAME полагаю?) не требуется. Кроме того такие трюки любят вытворять антивирусы, которые уж процесс открыть завсегда могут. Ну это просто как одна из многих потенциальных грабель такого подхода.
Афайр, по дефолту можно открывать только дочерний процесс, а не любой того же юзера 11.11.08 03:03  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> С настройками безопасности по-умолчанию открывать процесс
> может любой другой процесс, принадлежащий тому же юзеру. И
> для этого никаких "привилегий" (SE_DEBUG_NAME полагаю?) не
> требуется. Кроме того такие трюки любят вытворять
> антивирусы, которые уж процесс открыть завсегда могут. Ну
> это просто как одна из многих потенциальных грабель такого
> подхода.

Но есть гораздо более простой способ поиметь в своем процессе чужую длл-ину: SetWindowsHookEx внедрит нужную dll-ку во все win32 процессы.
А вообще способов много http://en.wikipedia.org/wiki/DLL_injection
http://www.google.com/search?client=opera&rls=en&q=dll+injection&sourceid=opera&ie=utf-8&oe=utf-8

И это только dll. А ведь память может быть выделена кем угодно (и системой в том числе).

А вообще я даже не верю в то, что мы тут сидим и всерьез обсуждаем возможные проблемы, возникающие при освобождении чужой памяти. Тамас, тебе стоит присмотреться к языкам с автоматическим управлением памятью. Я серьезно.
Это как ? 11.11.08 11:20  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
Процесс - объект. У объекта есть DACL. В DACL есть access mask'и для SID'ов. В том числе для текущего пользователя - разрешено все. У висты на это дело дополнительно накладывается проверка IL. Отношение parent-child тут вообще не причем
Ошибся 11.11.08 12:49  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Процесс - объект. У объекта есть DACL. В DACL есть access
> mask'и для SID'ов. В том числе для текущего пользователя -
> разрешено все. У висты на это дело дополнительно
Вообще то я думал, что как раз запрещено все. А хэндл на дочерний можно получить как раз при создании.

> накладывается проверка IL. Отношение parent-child тут
> вообще не причем
На самом деле не все так просто. Там ведь еще есть SecurityProcedure, которая дергается из того же ObGetObjectSecurity, если она есть у типа. Но с процессами - не тот случай, да и не это я имел в виду. Вот не помню когда я сталкивался с этим, но было такое, что я без SeDebugPrivilege не мог открыть ни один процесс, ну то есть не могу даже придебажиться к процессам, которые сам же и запустил. Почему то я решил, что это дефолтное поведение (ибо под рестриктед юзером больше толком и не работал, а у администратора всегда есть DebugPrivilege) - так оно в памяти и отложилось. Сейчас специально создал юзера в группе Users и проверил - действительно свой explorer.exe открывает запросто.
Ну это у тебя какой то нестандартный default dacl был на... 11.11.08 13:10  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> - не тот случай, да и не это я имел в виду. Вот не помню
> когда я сталкивался с этим, но было такое, что я без
> SeDebugPrivilege не мог открыть ни один процесс, ну то есть
> не могу даже придебажиться к процессам, которые сам же и
> запустил. Почему то я решил, что это дефолтное поведение
> (ибо под рестриктед юзером больше толком и не работал, а у
> администратора всегда есть DebugPrivilege)
Ну это у тебя какой то нестандартный default dacl был на токене наверно.
Вероятно все просто - адрес занят обычной памятью... 10.11.08 02:51  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 10.11.08 02:53  Количество правок: 1
<"чистая" ссылка>
> ладно дальше делаем VirtualFree и после этого процесcа с
> грохотом падает :-(
Вероятно все просто - адрес занят обычной памятью (VirtualAlloc'ом) которую ктото выделил до твоей попытки. Но VirtualFree не срабатывает потому что выделялся он не на этот базовый адрес, а на поменьше. Но регион захватывает и нужный тебе адрес. т.е. к примеру выделено больше 64кб начиная с 0x3f0000 А если ты таки начнешь искать что же освобождать, то я этого тебе не советую делать, тк это может быть чем угодно, включая твой собственный хип. И вообще выделенной ненужной памяти не бывает.
Значит работает Address Space Layout Randomization in Windows Vista 10.11.08 00:40  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
А грузить разве принципиально по 00400000h? Как я понимаю, это будет критично только для программ, использующих внутри себя фиксированные адреса из своего адресного пространства, что, по-моему, далеко не везде встречается...
upx-packed exe работают под vista? По крайней мере, я с тотальным падежом не сталкивался. Соответственно при "развороте" exe можно пересчитать адреса согласно доступному offset, который получается до разворота.
В теме плаваю, поправьте если не прав
Там просто получившийся exe имеет такой же base как и до упаковки 10.11.08 00:54  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
А сам образ разворачивается поверх того, что уже есть

> А грузить разве принципиально по 00400000h? Как я понимаю,
> это будет критично только для программ, использующих внутри
> себя фиксированные адреса из своего адресного пространства,
Все PE файлы имеют фиксированные адреса, но НЕКОТОРЫЕ при этом содержат fixup-таблицу. exe-шники по умолчанию такой таблицы не содержат и перебазировать их нельзя.
это критично для любого Exe который не имеет cекции .reloc 10.11.08 00:51  
Автор: Tamas Статус: Member
<"чистая" ссылка>
> А грузить разве принципиально по 00400000h? Как я понимаю,
> это будет критично только для программ, использующих внутри
> себя фиксированные адреса из своего адресного пространства,
> что, по-моему, далеко не везде встречается...
> upx-packed exe работают под vista? По крайней мере, я с
> тотальным падежом не сталкивался. Соответственно при
> "развороте" exe можно пересчитать адреса согласно
> доступному offset, который получается до разворота.
> В теме плаваю, поправьте если не прав

это критично для любого Exe который не имеет cекции .reloc
и сответствино является база зависимым....
UPX грузит такие exe по адресу из imagebase и не куда их не перемещяет
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach