Господа объясните, когда я в SIce ставлю GetProcAddres + 3, я обманываю пакер, т.к. он проверяет БП на вход в функцию?
У меня здесь не достаток информации :(
Да и SIc'a нет, что бы поэксперементировать...

nice

Да, обманываешь, но зачем тебе оно раз у тебя даже SoftIce сейчас нет :-)

Asterix
Будет ;), я принцип понять хочу!
А почему + 3, а не +7 ? это надо в библиотеке Windows (напр Kernel32.dll)смотреть, к конкретной функции?

А в TRW2000 возможен такой трюк?
И я как понимаю, тут надо BPM а не BPX использовать?

Почему не +7, ха..., так можно и за границы кода API вылезти :-)
TRW2000 вообщето глюковатая штука, хотя на 98-й я иногда его использую,
но если бряк ему не понравится то всё сразу вылетает, вместе с
системой ;-)

Asterix
А я в виртуалке работаю :)
Шлеп и система востановлена, одним копированием файла

55 PUSH EBP ; ВХОД В ФУНКЦИЮ
8BEC MOV EBP,ESP
81EC2C050000 SUB ESP,000000052C

И Я СДЕЛАЮ ФУНКЦИЯ+5, ТО ПОЛУЧИТСЯ
2C05 SUB AL,005; пОЛУЧАЕТСЯ НАРУШЕНИЕ РАБОТЫ ФУНКЦИИ?

пОЛУЧАЕТСЯ НАРУШЕНИЕ РАБОТЫ ФУНКЦИИ?

Возможно..

Ребята, вы меня поражаете. Давайте расставим точки над i. Хочу сразу сказать, что эти вопросы не возникли бы в принципе, если бы был прочитан Intel Manual.
Как можно отлаживать программу? 3 способа на сегодняшний день:
1) С поднятым флагом трассировки (TF = 1)
2) Влепляя в определенное место :) программы зарезервированный для этих целей опкод ССh, потом процессор генерирует исключение и это исключение перехватывается отладчиком, устанавливающим обработчик в IDT.
3) Через отладочные регистры DR0-DR7.
В твоем, nice, случае, используется CCh. Только не думай, что в этом есть что-то магическое! Айс знает, что символьному имени GetProcAddress поставлен в соответствие VA, скажем, 123456789h. ВСЕ! Туда ставится CC, подменяя собой предыдущий опкод, который айс запоминает и потом ставит на место. Все. Если ты ставишь бряк на GetProcAddress+3, то бряк получается по адресу 12345678С - всего делов! Никакого нарушения работы функции не получится, т.к. опкод СС будет заменен айсом на валидный (который он запомнил). И боятся вылезти за код API не нужно, не такой уж он и маленький :) Что до детекции CC в самом начале функции - это да, такой трюк есть. Делается настолько элементарно, что я даже код приводить тут не буду! Можно и еще веселее сделать - проверять какой-то диапазон, скажем, байт 15-20 на СС. От такого bpx GetProcAddress+3 не спасет. Надо переходить на bpm GetProcAddress x - тут уже работают DR-регистры. Но только и тут не все так радужно :) Но и против этого есть свой болт :) Словом, весело.

volodya
А мне кажется, что здесь есть подводный камень - если CCh попадает на место внутри валидной инструкции и делает эту самую инструкцию инвалидной. По идее работы CPU - CCh можно ставить только на ПЕРВЫЙ БАЙТ инструкции. Если-бы CCh можно было ставить где угодно, как тогда работал бы такой код?

mov al, 0CCh

Естественно, CCh должен стоять на границе инструкции.

AsmGuru62
Four-F

Да, ессно, но что мешает ГЛАЗЫНЬКАМИ поглядеть КУДА ставить CC? Понятное дело - первый байт.

volodya
Огромное СПАСИБО! Объяснил неучу.
А по поводу документации Intel, не знаю я англ.
Это вы с Asterix'ом на exetools/forum постите во всю, а у меня изучение в процессе :(
В школе плохо учился, с нуля пришлось начинать...

nice

Не.., я английского не знаю, Володе проще..

volodya

Вот чтоб не глядеть для каждой API и ставят тупо
bpx GetProcAddress+3 подразумевая начало API функции

55    PUSH EBP
8BEC  MOV EBP,ESP

Asterix

Это частный случай. Что ты будешь делать, если пролог отличается? Например, ebp опущен. Многие оптимизирующие компиляторы его убирают!