VirtualAlloc и Vista

Приветствую
Делаю PE загрузчик EXE, на хп работает норм
А вот на висте VirtualAlloc(0x400000, ....) возвращает 0, GetLastError ERROR_INVALID_ADDRESS
хотя адрес кратен 64k.

Что можно сделать? Для ехе надо выделить память по ImageBase.
Сам загрузчик находится по адресу 0x700000 и адрес 0x400000 на момент выделения свободен
Подозреваю, что на вин7 будет такая же ошибка

сам загрузчик с сорцами тут http://blackninja2000.narod.ru/files/peldr.zip

 

что-то у тебя в 0x400000 есть, так как у меня на семёрке твой код работает.

Освободи на всякий случай память

Код (Text):

1.     DWORD p = peo->ImageBase, max = peo->ImageBase + len;
2.    
3.     while ( p <= max) {
4.         UnmapViewOfFile((LPVOID)p);
5.         VirtualFree((LPVOID)p, 0, MEM_RELEASE);
6.         VirtualAlloc((LPVOID)p, 0x10000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE );
7.         p += 0x10000;
8.     }

 

ну да, освобождать чужую память это круто
скорей всего места не хватает 0x400000+size. Дебюгер, и глядеть память.

 

лол)))

 

Лоадер статически привязанный к одному ImageBase есть Г.

 

d2k9
Релоки себе добавить не проблема

 

посмотреть какая память выделена, атрибуты и под что. не исключено, что память ниже образа выделяется под стек или кучу. даже длл-и и кернел дату может туда напихать (с вислы ж и основным либам можно куда хошь мапиться)

 

d2k9
Хренасе, умник.. а как ты собираешься грузить файлы без релоков?

 

Посмотрел, В висле память 0х400000 выделена кем то.....Поэтому и ошибка
Либо освобождать память самому, либо хз

 

>Либо освобождать память самому, либо хз
Ваш образ загрузчика должен располагаться по тому же адресу что и распаковываемый файл, и загрузчик должен иметь виртуальный размер не менее виртуального размера распаковываемого файла. Т.е. в процессе распаковки распаковываемый файл должен полностью заменить собой ваш загрузчик. - Это идеальный и единственный вариант.

 

*Это идеальный и единственный вариант при отсутствии релоков.

 

djmans
Идея неплоха. Спасибо.
Только у меня не распаковщик, а просто лоадер - грузит внутрь своего процесса другой ехе , настраивает импорт и передает управление

Техническая сторона осталась, даже если принять ImageBase у ехе 400000, то для каждого ехе размер своего загрузчика менять проблемно

 

Rustem
Перезапустить себя есть возможность? Если есть, тогда достаточно после получения информации о другом экзешнике запустить лоадер в остановленном состоянии и выделить\зарезервировать нужный регион, после чего продолжить выполнение дочернего лоадера.

 

В любом случае релокация должна быть. Более того, иногда имеет смысл перенести функционал в длл, если загрузчик юзается из памяти.

 

в принципе, если надо грузить именно внутрь себя, можно попробовать и вариант с манипуляцией бсс секцией. те дефолтный адрес поставить ниже 400000h, а бсс секцию пролоцировать и расширить так, чтоб она покрывала от 400000 и сколько надо с запасом. но тут пробовать надо.

все это трики. имхо, лучше разобраться с захватом памяти на 400000 (под что она выделяется и зачем). не исключено, что причина в слишком высоком расположении загрузчика. возможно, стоит просто расположить его ниже 400000, потом закоммитить участок с 400000, а уже потом вручную подгружать длл-и. автоматическую кучу отключить.
если эту память захватывает ядро под инициализацию, то выделить память неважно где, потом удалить ее. это что прошла иниц. а потом выделять где надо

 

только щас посмотрел сорцы.. ну кто ж такой рос на цпп пишет?

 

qqwe Там нет ничего такого, чтобы понадобился ассемблер

пока идея след.
1. Будет дллка, в которой реализована сама загрузка
2. ЕХЕ заглушка для загрузки длл из п.1 и с sizeofimage как у жертвы и передачи управления
3. ЕХЕ который берет sizeofimage жертвы и делает его таким же в ехе из 2

Таким образом,
+диапазон жертвы 100% наш на любой винде, с длл код становится автоматом перемещаемый
-патчить ехе не очень то красиво, но брать максимальный вирт. размер тоже

 

Rustem

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

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

(а чем вам пропозиция Sol_Ksacap не? можно даже сразу целевой грузить)

 

qqwe от срр там ничего нет. все рантайм библиотеки убраны. точка входа не стандартная. ехе весит 8к
интеллект компилера сведен к минимуму

Sol_Ksacap возможность перезапуска себя есть. Можешете подробнее расказать про метод?

Посмотрел карту памяти, когда загрузчик по адресу 70000000, с адреса 360000 и размер около 60000 занято и инициализировано флаг MAPPED .
хз кто в висте так делает. в хп все тип топ

 

Rustem

попробуйте GetMappedFileName