Всем доброго здравия! Пишу утилиту для извлечения ASProtect.dll из упакованных файлов. Знаю, что аналогичная уже есть у deroko, но мне ненравиться, что работает она не со всеми версиями, да и как она работатет - тоже не нравится. У себя я реализовал простенький отладочный цикл посредством Debug API - ставяться бряки, читается память, контекст и т.д. Но решил вместо стандартных int3использовать привелигированную инструкцию CLI. И всё бы ничего, да долько стали происходить в отлаживаемом приложении какие-то странные вещи. Я ставил в Ольге бряк на VirtualAlloc и смотрел, какой код будет вызван после того, как эта функция отработает. Смотрел значение контекста на момент срабатывания бряков. Также сделал вывод из своей тулзы тех же значений. И что самое удивительное - они НЕ СОВПАДАЮТ. Более того, после четвёртого срабатывания бряка в ESI я должен иметь адрес некоей важной структуры, и в Ольке это действительно так, но вот в моей тулзе значения остаются прежними для всех первых четырёх срабатываний. Я сохранил лог работы моей тулзы. Аналогичный лог для Ольги можно получить, для чего я выкладываю подопытную программу, на которой тестировал свою тулзень. Как вы можете увидеть, логи не совпадают. В чём возможная причина? Буду признателен за любую помощь, так как уже всё перепробовал и передумал.

d72a_20.04.2010_CRACKLAB.rU.tgz - protected.rar

-----
Stuck to the plan, always think that we would stand up, never ran.

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

потоки есть? их контекст правильно обрабатываешь? отладочные события все через DBG_CONTINUE пропускаешь? а что если вместо CLI попробовать INT4 к примеру?

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

ARCHANGEL пишет:
Пишу утилиту для извлечения ASProtect.dll из упакованных файлов.

А чем не нравится мой скрипт "Создание файла Asprotect_dll.osc"? Ведь он позволяет получить ASProtect.dll со всеми восстановленными подпрограммами, которые содержат эмулированные инструкции. Утилита от deroco как раз не позволяет этого сделать, поэтому выполнить полный анализ ASProtect.dll без восстановленных эмулированных инструкций, попросту невозможно.

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

Av0id
Поток только один - тот, который загрузчиком создаётся. Аспр же дополнительных не порождает, насколько мне известно. Но, тем не менее, всё это предусмотрено - обрабатываются события CREATE_THREAD_DEBUG_EVENT и EXIT_THREAD_DEBUG_EVENT, при которых в массив добавляются либо удаляются оттуда дескриптор и идентификатор потока. Отладочные события пропускаю через DBG_CONTINUE, ведь если бы это было не так, то программа, упакованная аспром, не смогла бы запуститься. А она запускается нормально - отображается главное окно. INT 4 - двухбайтовая, она не годится. Попробовал заменить CLI на HLT - результат тот же.

vnekrilov
Скрипт нравится, но это - скрипт. А так - скорость работы, удобство использования, интерактивность - всё это плюсы отдельного приложения.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

У тебя учтено, что int3-trap, а int13-fault?

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

Archer
Если имеется ввиду, что ExceptionAddress при int3 на единицу больше, чем адрес, по которому расположена инструкция, то да. В случае с привилегированными инструкциями в этом-то и плюс - не нужно декрементировать EIP. И потом - я же говорю - программа, упакованная аспром, запускается под моим "отладчиком", значит учтено. Но почему такие странные вещи творятся с контекстом? Пробовал делать SuspendThread перед чтением контекста - результат тот же. Сейчас выложу скомпилированную утиль, чтоб прояснить некоторые моменты.

323f_22.04.2010_CRACKLAB.rU.tgz - Release.rar

-----
Stuck to the plan, always think that we would stand up, never ran.

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

А если попробовать ставить бряк на VirtualAlloc не с System Breakpoint, а с точки входа?

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

At0m2k
Была такая идея, но с момента срабатывания DebugBreak до точки входа VirtualAlloc ни разу не вызывается, поэтому нет никакой разницы. Тут дело не в этом.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL
А ты проверяешь, твой ли это бряк?

-----
Research For Food

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

daFix
А то! Есть массив для бряков, по которому и ведётся проверка. Если мой, то DBG_CONTINUE, в противном случае - DBG_EXCEPTION_NOT_HANDLED. Так что дело, опять-таки, не в этом.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Блин, ну что такое - крокодил не ловится, кокос не растёт! Заменил постановку бряков на стандартную - int3, а всё равно фигня какая-то происходит и прерывается вообще не там, где ольга. Как такое может быть? Может, проблема в том, что я вначале снимаю бряк, потом вызываю ContinueDebugEvent, а потом снова ставлю бряк? Если да, то как это исправить?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Синхронизация хромает, видимо. Можешь через TF шагать и тыкать бряк на место.

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

Archer
Была такая идея, но показалась мне - не очень. Тем более, что та же Ольга так не делает (я смотрел, да простит меня дядя Олег), и у неё всё норм. А из-за чего может возникать проблема синхронизации?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

От момента, пока ты вызвал ContinueDebugEvent, и до установки бряка потоки могут пролететь мимо места бряка N раз. И кто сказал, что олька так не делает?

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

Вначале хочу сказать: "Спасибо, Archer! За 8 дней ты единственный проявил интерес к моей проблеме". Теперь по делу.

Archer пишет:
От момента, пока ты вызвал ContinueDebugEvent, и до установки бряка потоки могут пролететь мимо места бряка N раз.

Тогда мне не ясно, почему у меня в логе срабатываний не меньше, чем в логи Ольки, а наоборот - в сотни раз больше? Ведь если подумать, то, ну, ладно, предположим, что пока я снова бряк поставлю - поток действительно может проскочить, но у меня тогда будет ущербный лог, а он - избыточный!

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Но можно организовать работу бряка следующим образом

--------------------------Exception handler---------------------------------
1.Брякнулись
2.Восстановили комманду
3.Выполнили свой обработчик
4.sti(не стоит забывать о случаях, когда комманда выполняется не однократно. Например комманда rep, если не ошибаюсь)
5.Ставим бряк обратно
6.run
---------------------------------------------------------------------- ------------

Тогда точно не должно быть пропусков

-----
Research For Food

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

Тогда замени фразу "пролететь N раз" на "простоять и прождать, а ты успеешь снова бряк вляпать". Короче, отсутствие синхронизации плохо. И иногда косяки порождают неявные ошибки, поэтому делай лучше сразу, как положено, а не на авось.

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

Archer
Исправил, всё заработало. Да, проблема действительно была в синхронизации. Тему закрою, спасибо за внимание.

-----
Stuck to the plan, always think that we would stand up, never ran.

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