RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> >> Я сейчас глянул на содержимое тех половинок. В общем, хорошо, что остался только один файл. Потому что половинки содержали взаимно-противоречивую информацию.
> > 
> > Хм.. Как они могут быть противоречивыми?
> 
> Да вот так. Разный набор имён (что неудивительно), но при этом ещё и разный порядок имён, и разные адреса тех имён, которые присутствуют в обоих файлах.
> 
> > Может быть, они были для разных версий ядра? Например, одно для halfstrict ядра, другое для allstrict? -- Хотя, разные ядра, по идее, должны находиться в разных архивах... 
> 
> Вот именно. В архивах с отладочными - файлы другие (такие же конфликтующие).
>   
> > Желательно, конечно, полностью автоматически, или полуавтоматически с небольшим обьемом ручной работы. Например, кое-что поручить скриптам, если это возможно...
> 
> Всё, что в данном случае можно сделать автоматически, IDA делает и без скриптов. То, что она не делает - требует применения головы.
> 
> > Хм, типов и полей -- действительно нет. Но сами имена структур, функций, меток -- есть. Это хоть какая-то помощь.
> 
> Чем оно помогает? То, что по данному адресу находится переменная или функция, IDA и так поймёт (заодно и функцию от переменной отличит, и размер переменной, скорее всего, определит.) А конкретные имена для твоей затеи никакого значения не имеют.
> 
> > Но то что нету смещений полей, это конечно, очень плохо. Если есть конструкция типа
> > 
> > mov [var +_offset], _something
> > 
> > то var можно найти в .map- или .sym-файле (хотя в .sym'е и не все переменные, а только экспортированные...), а смысл _offset будет непонятен.
> 
> Не только. В большинстве случаев это будет просто "mov [_offsetX], _something". Суммирование произведёт компилятор, и ты даже не узнаешь, что оно имело какое-то отношение к var.
> 
> > Но если в программе поля структур не меняются при модификации, то смысл _offset и не нужен, достаточно просто числа, происхождение которого неизвестно (и неважно). А смещения полей в структурах и не требуется менять.
> 
> Да, я уже писал об этом. Но если _something в твоём примере на самом деле - offset _some_func, то из sym-файла ты тоже об этом не узнаешь, а это уже существенно.
> 
> > Допустим, есть конструкция типа
> > 
> > mov eax, offset lalala
> > 
> > -- Тогда на выходе дизассемблера на месте offset lalala стоит какое-то число. Откуда оно взялось? Если вставлять NOP'ы между инструкциями, то смещения меток типа lalala могут меняться. А мы не знаем, что число в инструкции mov -- это смещение метки lalala, и что это смещение надо поправтить. Вот это может быть действительно проблемой... :(
> 
> Вот. Об этом уже несколько раз говорилось.
> И ещё одна проблема замечена. Почему-то в IDA автоанализ пропускает куски кода - не дизассемблирует их, а оставляет в виде DB ??. Только для того, чтобы убедиться, что в файле таких мест не осталось, нужно его весь просмотреть. Если предположить, что размер .asm получился 10 МБ, а на экран помещается 1 КБ текста, то это больше 10 тысяч экранов.
> 
> >> Кстати, обрати внимание, что многие адреса имеют по несколько имён. IDA такого не позволяет.
> > 
> > Ну, алиасы меток можно и убрать из map-файла, например, с помощью AWK-скрипта. Если есть .sym, то можно ли из .sym получить снова .map? (обратная операция делается при помощи утилиты mapsym).
> 
> Развернуть в текст можно, например, утилитой tdump из комплекта борландовского TASM (tdump file.sym file.txt).
> А дальше можно просто испортировать этот файл в IDA вместо .sym (скрипт такого импорта написать ничуть не тяжелее, чем вправлять мозги скрипту для импорта .sym).

_, __, _, __, /_\ \|_) /_\ \|_) \| \| \| \| \| \| \ ~ ~ ~ ~ ~ ~ ~