Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[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 и не куда их не перемещяет
|
|
|