Вообщем есть досовая прога. В ней есть строка "Demo" в сегменте даных. Поиском в айсе строка находится, но адрес представлен в 32-битном виде и bpm на этот адрес нифига естессно не срабатывает. Подскажите, чем можно отловить момент обращения к строке?
Надо чтобы был не 32-битный режим. Запустил Волкова под ICE - без проблем ищет по сегментам. Не забудь правильно подключиться : dldr.exe C:\vc\VC.COM Карта памяти : mapv86 .
Загружаю программу я как ты и сказал, через dldr. В окне кода все нормально, 16-битный режим. А в окне данных, где выпадает результат s 0 l -1 'Demo' режим 32-битный. Как его переключить в 16-бит? Пойду RTFM по айсу сделаю..
Sh355 Это только видимость. На самом деле там offset 16-битный. Попробовал на qbx.exe Помучился с командой s - хотя указываю длину больше 0FFFF - она ищет в 64 Кбайтах. Т.е. если у тебя хоть какой указан сегмент (не обязательно точно), то задавай bpm прямо по нему - все работает. Короче тебе повезло, что строчка в первые 64 Кб попала, а то и не нашел бы.
Хм. Там показывает 0010:00040542 примерно так. Или может иногда показать 0010:81025642. На 16 бит не очень похоже. И еще, как-то раз айс показал адрес данных как надо - с 16 битным сегментом и смещением. Я на радостях быстро поставил туда bpm. И какое же было мое удивление, когда после следующего запуска программы bpm просто пропал из списка бряков. В связи с чем остались два вопроса: 1. Почему айс показывает то 16, то 32 бит в окне данных? От чего это может зависеть? 2. Куда пропадает bpm, установленый в контексте 16-битной дос программы?
Вообщем, проблема решена d ds:0 и все заработало в 16-битном виде. И bpm заработал отлично тоже, правда почему-то не могу найти код из памяти в файле.
Sh355 А про relocate не забыл. Например, сall в другой сегмент выглядит так : call 0000:адрес ( в файле) call 2378:адрес ( в памяти) Ищи по командам без таких штучек.
Куда-то предыдущий пост пропал Вообщем разобрался, нашел код, дело было не в релоках, а в кривых руках. Дальше началось самое интересное - хардлок, и куча математичеких операций через int 35 (эмуляция сопроцессора), и int 3f непонятно в какой оверлей ведущий.. вообщем полная задница
Это же ДОС ! Они могли простой командой MOV подменить обработчик прерываний. Сначала проверь, кого они вызывают ? ДОС или кусок программы.
Код напичкан такой гадостью: seg003:5AE7 9A B0 01 92 3A call far ptr sub_3AAD0 seg003:5AEC CD 35 46 B8 fld dword ptr [bp-48h] ; (emulator call) seg003:5AF0 CD 35 5E C0 fstp dword ptr [bp-40h] ; (emulator call) seg003:5AF4 CD 3D wait ; (emulator call) seg003:5AF6 9A F5 01 92 3A call far ptr sub_3AB15 после прохождения call по trace over адреса меняются, если зайти туда по F8 то все виснет в самих call находится опкод команды int 3F и после него еще какой-то байт (номер процедуры, что ли). Вот тут я и погряз
Sh355 Похоже действительно плавающая арифметика. Очень муторное дело - я в свое время читал доки и пытался разбираться, но бросил. Но такая старая программа должна уже быть сломана или ты специально тренируешься ? Обычно я такие штуки преодолеваю так : смотрю результат. Результат-то скорее всего слово или меньше. В том куске, что ты привел, вообще все понятно переслали из одной ячейки( fld - fload load) в другую (fst - Fl.store). И т.д. Конечно муторно это...
Не, прога специфичная и не сломана еще никем. Есть желание поглядеть - намылю. меньше двух метров весит. Если тупо поправить джамп после результата, она честно пишет "Full version" и виснет напрочь
