Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
как я понел проблема в gcc котрый под гружает много лишнего... 10.11.08 23:15 Число просмотров: 3780
Автор: Tamas Статус: Member
|
> > ладно дальше делаем VirtualFree и после этого процесcа
> с
> > грохотом падает :-(
> А не офигел ли ты освобождать ЧУЖУЮ память и ожидать, что
> не свалишься. Даже если ты попадешь по базе и нормально
> распакуешь туда свой exe-шник, закончится это тем, что тот,
> кто выделил (и сохранил указатель, прошу заметить) эту
> память напишет туда своих данных и ты упадешь уже в
> процессе работы.
как я понел проблема в gcc котрый под гружает много лишнего по умолчанию....
в lcc-win32 при выделении базы допустим 0x01000000
всё прекрасно работает вот только линкер lcc не умеет менять imagebase
и использует всегда 0x00400000 а этот адрес нужен для большенства Exe'ков
или я не прав и lcclnk умет линковать с любой базой
|
|
<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 и не куда их не перемещяет
|
|
|
подробно о проекте
Анализ криптографических сетевых...
