Хочу сделать базонезависимый код. Есть код, который будет размещаться в пустом месте секции чужой программы. Этот код перебирает все адреса идущие вниз по секции от места внедрения кода (адрес инкрементируется), и попутно ищется определенная комбинация байт. Задача стоит такая, чтоб не выскочить за пределы текущей секции. То-есть ограничить перебор адресов последним адресом секции. Есть-ли какие "хитрые команды", которыми можно определить этот "последний адрес"?
Типа как эта, я ее применил, чтоб определить "текущий адрес".


| Сообщение посчитали полезным:

LdrFindEntryForAddress/RtlPcToFileHeader() -> IMAGE_SECTION_HEADER.SizeOfRawData

Гнилой конечно метод. Выделяйте память, если это инфект, то добавляйте новую секцию и(или) юзайте лодер.

| Сообщение посчитали полезным: Crawler

virtual size секции. считывается из PE заголовка файла:
--> Link <--

Dr0p
не напрягай мосх. чую, это просто мемпатчер. размер нужен для поиска паттерна

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным: Vovan666, Kuzya69

Как вариант еще можно через VirtualQuery получить размер

| Сообщение посчитали полезным:

ajax

Догадываюсь что он будет делать. PEB.Ldr -> сканим список, находим секцию. Низя, если конечно не стартап код, перед доступом к базе данных лдр необходимо залочить её(LdrLockLoaderLock()), иначе другой поток может чота загружать отгружать, что в конце концов отвалится всё.)

| Сообщение посчитали полезным:

Это будет обычный лоадер. Который загружает этот код в программу-жертву. Этот код найдет нужные байты и пропатчит их. Скажем так, стремлюсь к унивесальности, чтоб не писать одно и тоже под разные версии программ-жертв.

| Сообщение посчитали полезным:

Вообще да, самое боянистое - прицепить Windows.h, дернуть нужные структуры и посмотреть размер SizeOfRawData) А дальше - просто прибавляем к полученному текущему адресу.

-----
Харе курить веники и нюхать клей, к вам едет из Америки бог Шива, и он еврей.

| Сообщение посчитали полезным:

и всё-же -- не RawSize, а VirtSize (как и сказали ajax и Veliant ), если патч памяти. В файле код может быть упакован.

Crawler,
узнали размер SizeOfRawData... А дальше - просто прибавляем к полученному текущему адресу.
-- и что получим в результате?..

| Сообщение посчитали полезным:

Именно raw, это размер дисковой секции, без учёта хардверного выравнивания(для не bss верно, но она не executable).

| Сообщение посчитали полезным: Crawler, Abraham

Ну в принципе получилось все. Правда пришлось подумать при изучении РЕ-заголовка.
Всем спасибо!
Просто вызов стандартных апи может у меня обломиться. Например при использовании другого компа, а тем-более другой винды. Да и код получился приятный, короткий.

| Сообщение посчитали полезным:

Kuzya69,
...вызов стандартных апи может у меня обломиться. Например при использовании другого компа, а тем-более другой винды.
-- ) Так адреса функций нужно получать через GetProcAddress(), тогда не обломится.

| Сообщение посчитали полезным: Kuzya69

Dr0p,Crawler,
вяло поясню, что имелось в виду. Размер дисковой секции вполне может быть 0, если упакованный код содержится в другой дисковой секции.
Так что же тогда в ней искать, если RawSize==0 ?...

--ADD--
Dr0p,
Возможно, недостаточно чётко сформулировал.
Например, UPX превращает в файле секцию кода в "пустышку" с RawSize=0 и VirtSize = реальный_размер_распакованного_кода, а сам запакованный код в файле лежит в другой секции (специально добавленной UPX'ом). В памяти код распаковывается в свою изначальную секцию и запускается на выполнение, при этом в PE-хидере в памяти для этой секции кода продолжает оставаться RawSize=0.
Ну, да ладно. Не стОит продлевать оффтоп... Просто уточнил сказанное. (Это если рассматривать общий случай).

| Сообщение посчитали полезным:

dosprog

Ну если данных на диске нет, то и искать нечего.

| Сообщение посчитали полезным: