потому и придумали СС что сплайсинг с длиной более одного байта ненадежен СС кстати весьма и весьма удобно для сплайсинга только что handler несколько другой а так - SEH UEF VEH IDT[3] - все что нужно взрослому мальчику
Если в начале функции будут инструкции типа jmp label_1 ..... ; байт эдак n-цать кода label_1: или call [чего-то там] или lea eax, [edx + some_label] в буфере они будут исполнены неверно. В идеале нужно было бы заправить все смещения, но это ж геммор еще тот. Как такие конструкции обходил?
gilg не только эти, а все опкоды, где офсеты кодируются релативными адресами. придется для всех таких команд править адреса вручную.. другого выхода я не вижу Кстати, хорошо подметили насчет CC. Можно и его юзать. В ринг3 придется поставить хендлер исключений, а в ринг0 можно и IDT подправить
+ ещё бывает так, что ret попадает. А править jmp и ему подобные, ничего сложного - всего несколько команд. gilg или call [чего-то там] или lea eax, [edx + some_label] А эти команды нормально работать будут. Или ты имеешь в виду, что some_label окажется в перемещаемом коде?
эти действительно будут работать нормально. неперемещаемые опкоды только у jmp imm32, call imm32 и еще парочки команд, кажется.
в 64-битной моде как специально сделали чтоб не работало. в принципе. к тому же размер джампа/колла у меня получился >= 11h bytes, и туда _часто_ попадают вышеуказанные проблемные места так что я отказался от такого сплайсинга
Честно говоря не понятен контекст сплайсинга, если в конкретной проге, то всегда код одинаков, и можно сделать конкретно под этот участок. Если в библиотечный код, то всегда можно загрузить вторую копию только с другим именем, и перенаправлять функции на неё. Как правило сплайсингуются именно библы, и проблем с ними нету.
