Здравствуйте, reversecode, Вы писали:


R>вы дебагером когда нибудь пользовались ?
R>в нём это хорошо видно

Как-то не догадывался запоминать и сравнивать адреса модулей в процессе отладки. А пруфа в печатном виде нет, случаем?

Но всё равно не верится, что это возможно. К примеру, возьмём среднестатический бинарик со статическим, опять же, объектом. И ссылку на него (ака адрес).
Если система вдруг вздумает переместить модуль по другому адресу в памяти, то адрес объекта станет недействительным.

Здравствуйте, reversecode, Вы писали:

CF>>В итоге я попробовал взять исходный проблемный файл, в котором и динамическая база, и релоков нет, и флага об отсутствии релоков нет, и просто воткнуть прямо в заголовок скомпилированного файла этот флаг (IMAGE_FILE_RELOCS_STRIPPED). Сделал это уже давно (не меньше месяца назад)

R>это отключает ASLR
R>а падало потому что винда в процессе работы может образ файла двигать в памяти

А каким макаром ASLR к отсутствию релоков? Казалось бы, наоборот, ничего релоцировать не надо, хочешь — двигай. Собственно, оно и двигало, только забывало известить вторую свою же половину о собственных движениях.

F>Как-то не догадывался запоминать и сравнивать адреса модулей в процессе отладки. А пруфа в печатном виде нет, случаем?

какой пруф ? те кто пользуются к примеру IDA, могут видеть это как частый rebase модулей или самого приложения

на форуме новички которые любят чего то подламать в приложениях, приходят и плачут как у них ничего не выходит
и им часто раньше советовали отключать ASLR

F>Но всё равно не верится, что это возможно. К примеру, возьмём среднестатический бинарик со статическим, опять же, объектом. И ссылку на него (ака адрес).
F>Если система вдруг вздумает переместить модуль по другому адресу в памяти, то адрес объекта станет недействительным.

я здесь не для того что бы тратить время на доказательства

CF>А каким макаром ASLR к отсутствию релоков? Казалось бы, наоборот, ничего релоцировать не надо, хочешь — двигай. Собственно, оно и двигало, только забывало известить вторую свою же половину о собственных движениях.

изучите вопрос
https://stackoverflow.com/questions/39189477/how-do-i-determine-if-an-exe-or-dll-participate-in-aslr-i-e-is-relocatable

Здравствуйте, reversecode, Вы писали:

CF>>А каким макаром ASLR к отсутствию релоков? Казалось бы, наоборот, ничего релоцировать не надо, хочешь — двигай. Собственно, оно и двигало, только забывало известить вторую свою же половину о собственных движениях.

R>изучите вопрос
R>https://stackoverflow.com/questions/39189477/how-do-i-determine-if-an-exe-or-dll-participate-in-aslr-i-e-is-relocatable

Изучил, ответа на вопрос не нашёл. Просто повторяется то же самое: нет ножек релоков — нет ASLR.
В моём представлении релокации в файле отсутствуют в двух случаях:
а) fixed base, код завязан на конкретный адрес и не умеет релоцироваться в принципе;
б) PIC (position-independent code), релоки не нужны, потому что везде используется только относительная адресация.
Я полагал, что флаг IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE как раз и служит для различения этих ситуаций. А получается, он тупо дублирует IMAGE_FILE_RELOCS_STRIPPED. Как вообще тогда объяснить системе, что вот в этом конкретном файле релоков нет, потому что они просто не нужны, и код можно спокойно перемещать?
Или винда в принципе не признаёт понятия PIC?

Здравствуйте, reversecode, Вы писали:

R>а падало потому что винда в процессе работы может образ файла двигать в памяти

R>частый rebase модулей или самого приложения

Звучит как ересь

O>Звучит как ересь
O>

или вам пора на переквалификацию

Здравствуйте, reversecode, Вы писали:


O>>Звучит как ересь
O>>

R>или вам пора на переквалификацию

Может быть.

Но перемещение исполняемого модуля в а.п. пространстве процесса прямо во время его выполнения у меня не укладывается в голове и
за несколько лет я такого ни разу не видел. А что происходит тогда с указателями на функции, которые уже кто-нибудь успел вычислить
(GetProcAddress/static import)? А с базой модуля (HMODULE/HINSTANCE)? А с секцией (дисковая проекция исполняемого файла)? Она тоже
вдруг отмапливается и замапливается обратно по другому адресу? А потоки, которые выполняют код внутри exe/dll — они останавливаются и
их Rip/Eip двигаются на другие адреса? И в какой версии Windows это появилось? Ну дайте больше деталей (или ссылку на достаточно
авторитетный источник), где это было бы описано. А еще лучше — код, который подтверждает эту м-м... гипотезу. В источниках, которым я
доверяю (MSDN/TechNet, Windows Internals и т.д.) сказано, что ASLR для модулей работает во время загрузки, после этого адрес не меняется.
А для системных dll адрес сохраняется постоянным до следующей загрузки компьютера. Что я и наблюдаю в отладчике еще со времен Windows Vista.

Пока могу представить только один кейс: FreeLibrary/LoadLibrary модуля, скомпиленного с поддержкой reloc/ASLR.
Но это совсем другая ситуация, чем "двигание" модуля в памяти уже после его загрузки.

А то сначала порвать шаблон, а затем сразу давать задний ход в стиле "я здесь не для того что бы тратить время на
доказательства" — это как-то не очень...

Здравствуйте, reversecode, Вы писали:

R>на форуме новички которые любят чего то подламать в приложениях, приходят и плачут как у них ничего не выходит
R>и им часто раньше советовали отключать ASLR

ASLR — это перемещение модулей в процессе их загрузки в АП процесса, но не в процессе работы. Видимо, речь об этом, всё же.

Здравствуйте, flаt, Вы писали:

F>Здравствуйте, reversecode, Вы писали:

R>>на форуме новички которые любят чего то подламать в приложениях, приходят и плачут как у них ничего не выходит
R>>и им часто раньше советовали отключать ASLR

F>ASLR — это перемещение модулей в процессе их загрузки в АП процесса, но не в процессе работы. Видимо, речь об этом, всё же.

советую по чаще пользоваться дебагером что бы знать не только теорию но и практику
в процессе работы винда может двигать модули
до введения ASLR этих движений не было по моим наблюдениям

R>советую по чаще пользоваться дебагером что бы знать не только теорию но и практику
R>в процессе работы винда может двигать модули
R>до введения ASLR этих движений не было по моим наблюдениям
Винда не может двигать уже загруженный модуль. ASLR влияет на базу загрузки модуля, после загрузки — все остается где было до выгрузки. Если у вас изза включения ASLR для дллки чтото начинает глючить, значит или у вас гдето есть чтото типа:

DLL = LoadLibrary("foo.dll");
SomeFunction = GetProcAddress(DLL, "SomeFunction");
..blablabla...
FreeLibrary(DLL)
DLL = LoadLibrary("foo.dll");
..blablabla...
SomeFunction()

В этом случае на последней строчке с включенным ASLR вероятность крэша на много порядков выше чем с выключенным. Но, всеже, с выключенным она тоже будет ненулевая.

Или же у вас код который не умеет толком работать с void *, например

DLL = LoadLibrary("foo.dll");
int CastedPointer = (int)GetProcAddress(DLL, "SomeFunction");
...
SomeFunctionT SomeFunction = (SomeFunctionT)CastedPointer;
SomeFunction();

в этом случае тоже вероятность свалиься с ASLR сильно выше чем без оного. Потому что с ASLR вероятность того что модуль загрузится выше первых 4 гиг очень высока (оно вроде вообще только туда и грузит ASLR'ед дллки), а без оного — система попытается промапить модуль по его preferred base. Что обычно находится в нижних адресах.
А тайпкаст в 32х битную переменную (int) ломает поинтеры указываюшие выше 4 гиг.


Но в данном случае имеем дело не с длл, а с апликухой, в которой даже релоков нет. И вероятно это в самом деле баг загрузчика, т.к. такие минималистичные апликухи нынче редкость, а микрософт индусами полнится. Или же у ТС троянчик сидит, или антивирь. С глючным инжектором. Потому хотелось бы увидеть лог windbg о том какие длл в процесс и в каком порядке загружаются.

Здравствуйте, ononim, Вы писали:

O> Или же у ТС троянчик сидит, или антивирь. С глючным инжектором. Потому хотелось бы увидеть лог windbg о том какие длл в процесс и в каком порядке загружаются.

К сожалению, у меня сейчас пошёл основательный загруз сразу по нескольким направлениям, так что времени на академические исследования в ближайшем будущем точно не найдётся. Если достаточно просто загрузить и выдать лог, это ещё могу сделать (только желательно с инструкциями, а то я в windbg не очень, а тратить время ещё и на поиск инфы не хочется). Если же надо конкретно в сценарии с воспроизведением падения — тогда вряд ли получится.

Но всё же, что касается трояна или антивиря, вероятность с моей точки зрения крайне невелика. Две разных машины, с разными антивирями от разных производителей, у обоих воспроизводится в отключённом без перезагрузки виде. То есть они оба должны одинаково ломать загрузчик, причём делая это именно теми компонентами, которые остаются загруженными в память при выключении проверочной функциональности. Не исключено, но всё же сомнительно.
Троян… Опять же, одинаковый на обеих системах, живущий на них незамеченным не менее двух лет, и ни разу не пойманный ни мной (а я несколько раз основательно шуршал по системе, заметив что-то, показавшееся подозрительным), ни теми же антивирями? Точно так же, не исключено, но как-то не верится.

Как вариант кстати баг возможно даже не лоадера, а линкера. Лоадер, к примеру, может ожидать, что раз нету флага IMAGE_FILE_RELOCS_STRIPPED — значит релоки есть. А линкер этот флаг не выставляет, несмотря на отсутствие релоков в имаже. Все зависит от того растусована ли както такая ситуация в спецификации.

А про глючные инжекторы секуритисьютов я неспроста писал. Я сам писал такие инжекторы, которые, бывало, глючили