Вопрос по дебагу (применительно к ida pro)

Тема в разделе "WASM.BEGINNERS", создана пользователем deadly83, 5 авг 2008.

  1. deadly83

    deadly83 New Member

    Публикаций:
    0
    Регистрация:
    25 янв 2007
    Сообщения:
    71
    Доброго времени суток!
    Суть вопроса в следующем:
    Имеем программу, загруженную в отладчик, в программе имеется проблемное место где происходит зацикливание, однако при нажатии на кнопку pause дебагер вываливается в библиотеке ntdll.dll. Каким образом выявить проблемное место? (особенно если в проблемном месте не происходит никаких вызовов с помощью call т.е trace window нам не помощник)
     
  2. JCronuz

    JCronuz New Member

    Публикаций:
    0
    Регистрация:
    26 сен 2007
    Сообщения:
    1.240
    Адрес:
    Russia
    deadly83 или сам файл или кусок кода приводи
     
  3. deadly83

    deadly83 New Member

    Публикаций:
    0
    Регистрация:
    25 янв 2007
    Сообщения:
    71
    jCronuz тю я немного озадачен, но раз ты такое спрашиваешь вот тебе пример зацикливания:
    Код (Text):
    1. mov ecx,2
    2. cc1:
    3. inc ecx
    4. dec ecx
    5. jecxz cc2
    6. jmp cc1
    7. cc2:
     
  4. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    deadly83
    А не на KiFastSystemCallRet вываливается? Если там, то Ваш пример зацикливания не актуален.
     
  5. deadly83

    deadly83 New Member

    Публикаций:
    0
    Регистрация:
    25 янв 2007
    Сообщения:
    71
    l_inc нет не там но ты был близок :) (на самом деле вываливается в ntdll_DbgUiRemoteBreakin) но как мне кажется суть дела это не меняет или я не прав? Если есть информация поделись пожайлуста, во всех случаях приходилось анализировать довольно значительную часть программы чтоб найти нужный кусок. Вопрос в том как указать дебагеру область отладки (или как это правильнее называется я хз) чтоб он не лез в ненужные мне длл.
    Кстати проблема была решена методом систематического тыка опций (конечно я стараюсь избегать применение этого метода ибо долго) вообщем нужно в опциях дебагера ставить такую хрень под названием stop on thread start/exit может быть кому то поможет сэкономить время в дальнейшем.
     
  6. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    deadly83
    Если поток зацикливается на коде, подобном Вашему примеру, то его EIP остается в пределах этого цикла. Следовательно, клацнув в IDA на соответствующий зацикленный поток в окошке Threads, Вы можете увидеть весь текущий контекст зацикленного потока, включая его EIP. Если же поток просто находится в состоянии ожидания, то его EIP указывает на KiFastSystemCallRet, с которого и продолжается исполнение потока в тот момент, когда планировщик потоков решит дать этому потоку процессорное время (в результате какого-то события, которого дожидался поток). Поэтому в случае, если поток вываливается на KiFastSystemCallRet (про DbgUiRemoteBreakin чуть ниже), Ваш пример не актуален. Большинство нормальных потоков при нажатии паузы с вероятностью, близкой к 100%, как раз и вывалятся на KiFastSystemCallRet.
    А теперь по поводу IDA (специально поставил, чтобы посмотреть на неё: сам пользуюсь OllyDbg в качестве отладчика). Когда Вы жмете паузу, то IDA вываливается на служебном потоке, предназначенном специально для отладки (как я указал выше, можно в окошке Threads клацнуть сразу на родной поток процесса и увидеть его контекст, не забивая себе голову разбором этого служебного потока), который создается системой в контексте отлаживаемого процесса. Вот этот поток и стартует с DbgUiRemoteBreakin. Как только вы оттрасируете этот поток до RtlExitUserThread, то IDA переключится на родной поток отлаживаемого процесса. Вот там Вы и увидите, где же зациклился родной поток.