DisAsm-11

[Hunta]

Пока большая часть моих программ - RequestWare, то есть, если что-то из написанного мной кому-то интересно, а у меня на недо-сайте не выложено - пишем в теме или в личку - обсуждаемо.

В очередной раз понадобилось дизассемблировать некий файл и оказалось, что дизассемблера под этот формат нет или я пока про него не знаю. Особенно учитывая, что это (фактически) .LDA, но вот хранится он в ФС типа DOS/Batch-11-овской и копия блоков файла получить без проблем, но вот на выходе - не совсем .LDA получается. Точнее, .LDA, но с добавками.

В общем, это было, видимо, последней каплей, и я таки сел клепать свой дизасм.

Тут дальше была инфа про минус первую версию, но поскольку с той поры прошло много написанного кода, я слегка подредактировал первоначальную версию

Картинки (из за непонятной проблемы может прилетать ошибка - вроде помогает refresh. разбираюсь, но пока непонятно, что происходит)

"Учитывая, что разбор инструкций идёт по таблице, добить полный набор инструкций - дело ещё одного вечера, а вот потом начнётся самое интересное " - и я даже не знал тогда - насколько оно интересней

Подопытные кролики. Упоминание их здесь не означает, что работы по восстановлению доведена до конца, но можно посмотреть на результат работы DisAsm-11, когда программа загружалась

DESS
Игрушка Stalk

[Advertiser]

[Vslav]

.LDA, но вот хранится он в ФС типа DOS/Batch-11-овской и копия блоков файла получить без проблем, но вот на выходе - не совсем .LDA получается.

.bic - это формат абсолютного загрузчика DEC, его обычный srec-cat умеет конвертировать в hex/bin или во что захочешь.
Я так .bic тестов для LSI-11 конвертил: "srec_cat file.bic -dec_binary -o file.bin -binary"
Вот тут я еще короткое описание формата выложил

[Hunta]

.bic - это формат двоичного загрузчика

Я это знаю (поэтому и написал - .LDA), но возиться с аддоном для TotalComand-ер и его прикручиванием к FAR-у - не стал (особенно учитывая, что FAR у меня 64-ёх битный, а аддон вроде 32-ух), учитывая, что в листинге XXDP виден и начальный блок и длина - в RT11 просто скопировал эти блоки в файл на HX, приаттаченный к папке Windows. И вот в таком файле есть нюанс - он не совсем .LDA, но с отличием разобрался влёт. Ну и на саму загрузку такого файла и его первоначальный парсинг структуры ушло... мм... минут 20(?) написания кода. Сделал бы быстрее, но посадил одну мааааленькую ошибку и с ней проколупался

В общем, сейчас доделываю первоначальное декодирование (полное описание таблицы декодирование и шоб оно шло сразу, при загрузке данных из .LDA), посмотрю, что получится, а потом буду писать анализатор - где код, где данные.. Для начала

- - - Добавлено - - -

Вот тут я еще короткое описание формата выложил

Да оно как бы есть и в доках на RT Там единственное только не совсем чётко описан байт контрольных сумм И из за ошибки в проге (как я думал) и из этого описания долго не мог понять - чего у меня КС получается нулевой Только потом дошло, что я на автомате написал правильный вариант подсчёта КС и при правильной КС ноль и должен получаться

[Vslav]

В общем, сейчас доделываю первоначальное декодирование

Преобразованием формата должны заниматься утилиты-преобразователи. Когда попадается новый формат - я всегда на srec-cat смотрю сначала, до сих пор он практически все потребности закрывал. А писать дизассемблер для известного процессора.... Маловероятно что IDA получится превзойти.

[Hunta]

Преобразованием формата должны заниматься утилиты-преобразователи.

В моей проге это не преобразование формата - это считывание исходных данных. И если в случае с .LDA метаинфы почти нет, то в случае сложных .SAV и .TSK будет некоторое количество метаинформации, которая так же должна быть доступна и обрабатываться дизассемблером.

А писать дизассемблер для известного процессора.... Маловероятно что IDA получится превзойти.

Учитывая, что я люблю использовать структурные макросы - я это дело делаю с прицелом на них - и вот тут что то я сомневаюсь, что IDA мне выдаст такой исходник. Плюс. .SAV и .TSK файлы бывают с поддержкой оверлеев, I+D - как у IDA с этим?

Когда попадается новый формат - я всегда на srec-cat смотрю сначала, до сих пор он практически все потребности закрывал

Как насчёт .SAV с оверлеями и I+D?

- - - Добавлено - - -

В любом случае. Эту прогу я пишу под СВОИ потребности и смогу дорабатывать при их изменении. А поскольку меня интересует только один процессор (ну по крайне мере пока) - большая часть возможностей IDA мне как бы.. ни с какого бока. Плюс его платность и написание модулей расширения - на каком языке? На С или С++ - оба языка (особенно второй) не люблю.

[Vslav]

В моей проге это не преобразование формата - это считывание исходных данных.

И? Конвертировали LDA в HEX и загрузили в IDA.

И если в случае с .LDA метаинфы почти нет, то в случае сложных.

Все "метаданные" что там есть вполне описываются обычным Intel-Hex, ничего не теряется.

SAV и .TSK будет некоторое количество метаинформации, которая так же должна быть доступна и обрабатываться дизассемблером.

А что, DISS не справится с .SAV ? Для RSX тоже есть дизассемблер. И изначально про SAV и TSK речи не было.

Учитывая, что я люблю использовать структурные макросы - я это дело делаю с прицелом на них - и вот тут что то я сомневаюсь, что IDA мне выдаст такой исходник.

А ты не сомневайся, посмотри IDA SDK, там вполне вменяемый Питон, перевод в макросы сделать можно.

Плюс. .SAV и .TSK файлы бывают с поддержкой оверлеев, I+D - как у IDA с этим?

Для DOS x86 Borland и Microsoft поддерживаются "из каропки". Для других архитектур надо сделать парсер на Питоне.
Но это тебя совсем уж далеко занесло. И чего только люди не придумают лишь бы изобретение велосипеда оправдать . Ну, дело твое.

большая часть возможностей IDA мне как бы.. ни с какого бока.

Дело не в возможностях. IDA это фреймворк, именно для построения интерактивных дизассемблеров, допиливается быстро.
Если процессор известен и предполагается большие время-затраты (ты сам тут про оверлеи начал рассказывать), то надо работать в нормальном инструменте.
Мне надо было микрокод LSI-11 разобрать, я знал что оно будет конечно (собственно там только три микросхемы и существуют ), а для IDA надо было делать целую новую архитектуру, поэтому я забил и сделал свое за неделю вечерами на Питоне (заодно попрактиковался на питоне, и половина кода потом ушла в Ассемблер), но пилить дизасм для PDP-11 - это только развлекать себя переизобретением велика

[Hunta]

DISS

Может - DESS?

И изначально про SAV и TSK речи не было.

А ты думал, я решил написать только для дизасм .LDA? Может ещё подумал - одного конкретного файла? Естественно прицел идёт на ВСЕ файлы (obj, sav, tsk, оверлейные, I+D) от XXDP, DOS/Batch-11, RT и RSX.

это только развлекать себя переизобретением велик

Аха. Люблю это дело. Ибо существующие - не устраивают и/или не нравятся.

- - - Добавлено - - -

А, да, ещё забыл про multiuser таски от RSX. А так же драйвера.

- - - Добавлено - - -

Если процессор известен и предполагается большие время-затраты (ты сам тут про оверлеи начал рассказывать), то надо работать в нормальном инструменте.

Вот я и не считаю для данной задачи его нормальным инструментом

[Hunta]

Последствия игр с программой
Встаешь на ячейку, видишь в среднем окне - а куда, возможно, её содержимое указывает...
О, да это код - щелчок по кнопке S - и в среднем окне уже видишь код
Если это команда с двумя аргументами, соответственно среднее окно для источника, правое - приёмника Если, конечно, потенциально это указатели
Пока ещё альфа-заготовка - то есть много для чего показа в правых окнах не будет, но...

[Hunta]

Встали на команду, справа видна ячейка, на которую команда ссылается - видим строку ASCII
Перешли в правое окно, щёлкнули по клавише A - строка сформирована
Перешли в левое окно, щелкнули по кнопке P - имеем ссылку в команде

Можно анализировать дальше

[Hunta]

Вечерами ломал голову над внутренними переделками программы с прицелом на поддержку файлов программ с перекрытиями. Вроде как идеи обкатал в голове и вчера вечером закончил переделку - до реальной поддержки пока ещё далеко, но первый шаг сделан. После переделки было на удивление мало сбоев в работе - была пара месте, где не была сделана необходимая правка и с пяток правок, связанных с генерацией меток.

А потом, развлекаясь в дизассемблирование DESS-а, налетел на некорректную визуализацию ячеек с данными.

Вообще, (правильная) визуализация данных - с учётом того, что разные типы данных занимают разное количество слов, а то и байт, плюс к этому добавляется необходимость (правильной) генерации меток, в том числе байтовых - по ощущениям - одного порядка сложности с дизассемблированием команд. Но в командах сложное место фактически одно - понять - операнд - это число или адрес, да и то - есть некоторые подсказки.

Немножко пошаманил, теперь визуализация идёт более корректно.

Исходная картинка

По адресу 11631 видим наличие строки, но младший байт - это терминатор предыдущей строки, а наша начинается на старшем байте. В предыдущей версии программы, если бы на этой ячейке выдал команду ASCIZ, то получил бы по адресу 11630 то же самое (.WORD 006400), потом много пустых строк (ибо символы ушли бы в .ASCIZ, которая начинается с 11631, но там - неправильная визуализация) и .WORD 0 по адресу 11662.

Теперь визуализация более корректная

Похожая проблема с визуализацией ячеек, старший байт которых помечен как БАЙТ данных, а младший ни как не помечен

Снова более корректная визуализация
А вот визуализация ячейки, оба байта которой помечены как БАЙТЫ

Всё это привело к мысли, что надо бы подсвечивать пометки на словах и байтах, но для этого надо отказываться от простого текста в выводе окон результатов дизассемблирования, с чем пока не хочется связываться, гораздо проще сделать что то типа статусной строки, в которой будет выводится эта информация.