Какие проблемы могут возникнуть при замене call DWOR ptr ds:[косвенный адрес] на call адрес ? У меня после этой, как казалось, равнозначной замены, получаются два разных кода в памяти во время исполнения. Из-за чего это может происходить ? Я думал что из-за релоков, но у меня ImageBase равен адресу загрузки, т.е. релоков быть не может.

И второй вопрос, почему hex код команды call адрес (адрес один и тот же) может быть разным в разных местах программы ? проверено с п-ю Hiew 6.86 ввожу в режиме редактирования call адрес и получаю разный hex код

428793665__

И второй вопрос, ...

Потому что CALL содержит смещение относительно следующей за CALL команды, таким образом CALL на то же место из разных мест кода будет содержать разное смещение:

CALL FOO  ; смещение вписанное здесь = плюс 500 байт

...  ; 500 байт кода

FOO PROC

...  ; 1500 байт кода

CALL FOO  ; смещение вписанное здесь = минус 1500 байт

Получается, если мне нужно пропатчить 100 команд, HexView не поможет автоматизировать эту процедуру ? т.е. придется в нем ручками 100 раз поиск/редактирование/применить ?

AsmGuru62
Что-то я не пойму, разве в инструкции CALL указывается не смещение относительно начала сегмента? Причем тут смещение относительно инструкции?

AsmGuru62
Сейчас сам посмотрел. Действительно, вы правы. Но, у Зубкова я, кажется, про это не читал... Или плохо читал?
Команда:
CALL операнд
Назначение:
Вызов процедуры
Процессор:
8086

Сохраняет текущий адрес в стеке и передает управление по адресу, указанному в операнде. Операндом может быть непосредственное значение адреса (метка в ассемблерных программах), регистр или переменная, содержащие адрес перехода. Если в качестве адреса перехода указано только смещение, считается, что адрес расположен в том же сегменте, что и команда CALL. При этом, так же как и в случае с JMP, выполняется ближний вызов процедуры. Процессор помещает значение регистра EIP (IP при 16-битной адресации), соответствующее следующей за CALL команде, в стек и загружает в EIP новое значение, осуществляя тем самым передачу управления. Если операнд CALL — регистр или переменная, то его значение рассматривается как абсолютное смещение, если операнд — метка в программе, то ассемблер указывает ее относительное смещение. Чтобы осуществить дальний CALL в реальном режиме, режиме V86 или в защищенном режиме при переходе в сегмент с теми же привилегиями, процессор помещает в стек значения регистров CS и EIP (IP при 16-битной адресации) и выполняет дальний переход аналогично команде JMP.

По-моему это общеизвестно.

В коде операции внутрисегментного CALL\JMP в непосредственном
операнде записывается смещение относительно этой команды.

В ассемблерной мнемонике этих инструкций
записывается целевой адрес.

При ассемблировании\дизассемблировании эти представления
переводятся друг в друга. Так сложилось...

captain cobalt
Да, я этого не знал. Я считал, что смещение относительно команды указывается только при адресации типа: short, а при адресации типа: near, указывается смещение относительно начала сегмента.

т.е. все таки HexView не помощник в автоматизации, итог то каков ?