HIEW - интерфейс плагинов

Скажу честно, даже в банальной маркетинговой политике я полный ноль, а вот что умеет делать hiew мне рассказывать не надо



Я вижу другое - автор hiew хочет малой кровью сделать API.



И чтобы общение по данной теме было более плодотворным нужно определится:

либо seh рассказывает свою концепцию(видение) hiew plugin API, а мы вносим предложения, удовлетворяющие требованиям концепции, по набору функций;

либо автор hiew будет придерживаться классической(научнообоснованной) концепции создания API переложенной применительно к плагинам.



Во втором случае придется многие(если не большиство) функций hiew адаптировать под API.



Из плюсов "классики": расширяемый набор экспортируемых функций, полная обратная совместимость последующих версий API.



Ну или получим в итоге API а-ля FAR plugin API в нынешнем его представлении(надо сказать плачевном представлении).



Если же первый вариант, то ждем-с концепцию API от автора hiew и только потом можно будет формировать список функций.

 

The Svin

Спорно всё это, очень спорно.. Я, конечно, не зарегистрированный пользователь (а если точнее, то вообще не пользователь Hiew, не мои интересы).



Но помнится мне, что полное название программы «Hacker view» (или ошибся?). Что мешает оправдать название и сделать просмотр памяти?



Потом, держаться за ДОС только лишь из идеалов не нужно. Но если интерфейс в тектовом режиме грамотно и удобно спроектирован (в случае Hiew так и есть) — то и не стоит переходить на GUI, ибо не факт, что будет лучше.



IMHO, конечно…

 

volodya

О! Нет! Не читайте ни в коем случае - попса!



После того как я прочел вот этот материал:

http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.h tml



Доверие к статьям на том сайте у меня пропало - не люблю когда мне нагло врут :\

 

О! Нет! Не читайте ни в коем случае - попса!



Напиши что-то свое. Почитаем, обсудим

 

Знаешь хакерам по всему миру никаких особых оправданий названия не требовалось, они просто пользовали и пользуют Hiew.



Теперь про просмотр памяти. Ты в курсе организации памяти в защищённом режиме и в частности в Windows?

Какую память hiew должен просматривать? Физическую?

Виртуальную линейную? Если линейную то какого процесса? Своего?

Всех? И вешать всю систему на момент просмотра, так как в любой момент может быть сделана страничная операция?

Второй SoftIce что ли делать?

 

Дело не во мне, а авторе статьи, на которую ты дал линк.



Неужели ты готов рассматривать материал от дилетанта?

Там больше воды, чем каких-либо дельных предложений



P.S. Поправочка: чтобы моё высказываение не было голословным даю ссылочку:

http://www.ambysoft.com/userInterfaceDesign.pdf

Тут коротко и ясно - правда, на английском языке.

Хотя Hiew UI меня устраивает, так как привык уже к нему

 

The Svin

От просмотра физической мало толку, хотя мож кому-то и надо. Виртуальную? Да. Какого процесса? Любого выбранного. Я бы сказал, "как в WinHex", но боюсь, закидают шапками..

 

Никто шапками не будет закидывать, я первый не дам.

Просто обмениваемся взглядами, вежливо и открыто

 

Tupo



Выходим в отедльный топ. Там и поговорим.

 

причем как ленивый пользователь ))

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



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

да уж, вносить предложения это мы умеем ))

несколько сотен написанных плагинов - это называется плачевным состоянием ?

 

это проблемы пользователей которые не хотят читать хелпов а хотят читать туториалы.

я как-то даже сел писать большое описание, но оно сразу же превратилось в банальное описание кнопок, т.е. в hiew.hlp только более развернутое. Таланта красиво лить воду у меня нет, объяснять строение PE нет желания...

 

Я честно говоря уже запутался что хочет автор %)



Ну ладно, пусть HiEW остается таким какой он есть.

Будем значит память смотреть через WinHEX, а в дизассемблированном виде в SoftIce или в ImpRec.

Тогда я вообще не знаю для чего можно использовать движок дизассемблера HiEW, ни тебе отладчик в виде плагина прикрутить как в Ида, ни тебе скрипты писать нельзя.

 

sen

Ленивый? Позвольте не согласится.

Я использую те функции, которые предоставляет мне hiew.

Получается hiew - это программа для ленивых пользователей

Если ты отвечашь - нет, на некоторые предложения, значит у тебя всё-таки есть какие-то задумки/критерии.



Хочется узнать о них, чтобы знать в каком направлении мыслить.

Похоже у нас разное понимание plugin API.



Скриптовый язык - это plugin API + интерпретатор языка между прочим

Я как и Asterix уже и не знаю что тебе присоветовать



Ок! Даю описание "спартанского" hiew plugin API



Формат плагина:

DLL с одной экспортируемой функцией - pluginGO

В качестве входного параметра функция принимает указатель на структуру HiewFileInfo.



Cтруктура HiewFileInfo имеет два поля dwBuffAddr и dwFileSize - адрес начала буфера, в который hiew загрузил файл, и длина загруженного файла, соответственно.



Функция pluginGO возвращает 0 в случае успешного завершения и -1 в случае ошибки.



Поддержка:

Требуется только Загрузчик плагинов.



Алгоритм работы Загрузчика плагинов:

1. Открывает папку с плагинами, чтобы пользователь мог выбрать файл плагина.

2. Загружает DLL и передаёт управление функции pluginGO, предоставив ей заполненную структуру HiewFileInfo.

3. По результату завершения функции pluginGO

3а. Если плагин завершил работу с ошибкой, то буфер с файлом обновляется копией с диска

3б. Если плагин завершил работу с ошибкой, то содержимое буфера с файлом сравнивается с содержимым копии на диске. Если различно - выставляется флаг "модифицирован" и обновляется основное окно hiew.



Всё



Главная проблема: под такое API найдется мало желающих писать плагины.

Потому что слишком жирно использовать hiew ради 5 функций: выбрать файл, открыть хэндл, считать файл, записать файл, закрыть хэндл.

А лично ты пробовал? :\



Я писал FAR-лагины и под старое(до версии 1.65) и под новое API.

Главная проблема старого API - не было гибкости. Функции UI принимали мало параметров, часть из них попросту имели дефолтовое значение.

Главная проблема нового API - абсолютно хаотичный набор функций. Невозможно сразу сказать - что можно написать, а что нет. :\

(Бету 6 не смотрел, возможно имеются изменения к лучшему)



Большое количество плагинов под Far - это заслуга популярности самого Far'а

 

и в чем ты запутался ? в различиях между файлом и процессом ?

а что, я обещал что можно будет сразу использовать движок дизассемблера ? О нем пока и речи нет.

 

внешний модуль как расширение возможностей hiew и использованием внешним модулем всех возможностей hiew - разница есть ?

...

чисто файловые функции меня мало волнуют - какая разница, писать hiewreadfile() либо readfile() ? я вижу только одну - во втором случае надо будет самому открыть и закрыть файл.

первое: какие данные отдать плагину, с файлом плагин может разобраться сам



и второе, о чем ты не упоминал ни разу и о чем я уже спрашивал - экранный интерфейс.

Чтобы плагин спросил у человека некие данные я могу предоставить только функцию GetString(), без всяких разбиений на поля, потому что такого разбиения сейчас просто нет. А на вывод могу отдать только Menu() и Window( char **textlines ) с уже готовым текстом. Например этого хватит для подсчета crc выделенного блока, но не хватит для интерактивного плагина который хочет сохранить блок как массив байтов/слов/... и при этом еще и спросить у пользователя в каком виде сохранять, по сколько штук в строке и т.п.

 

проверьте ящики почтовые )), cah'и от 7.10 только что ушли



7.10 20/02/05 - sav-file теперь пакуется

- в калькуляторе: @x - взять значение из файла под курсором

- поддержка clipboard (Shift-Insert)

- отбор текстовых строк в бинарных файлах

- FIX: в таблице импортов 'левое' имя функции по ординалу (2K/XP)

- FIX: показывается DLLNAME.ORDINAL вместо DLLNAME.DLL.ORDINAL

 

sen

Разница есть, но связи нету!



API подразумевает использование функций и данных основной программы.

Концепция классического API(переложенного применительно к плагинам) звучит так:

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

2. Любое действие выполняемое плагином должно быть подконтрольно основной программе(подразумевается что плагин использует только данные от основной программы и экспортируемые ею функции).



На практике это выглядет так.

По первому пункту:

1. Если hiew распознаёт формат загружаемого файла, значит должна быть функция, которая передаёт плагину информацию о формате файла.

2. Более частный случай: Если hiew распознает заголовок PE-файла, то должны быть, к примеру, функции "получить список имен секций PE-файла", "получить информацию о секции".



По второму пункту:

На примере доступа к загруженному файлу: Нельзя давать доступ плагину к загруженному файлу напрямую. Должны быть операции чтение и запись блока, то есть область видимости.



При таких операциях hiew предоставляет плагину буфер, который содержит информацию из загруженного файла.

Такой подход и увеличит стабильность системы hiew+плагин и облегчит контроль за действиями плагина: при операции "запись в файл" достаточно будет сравнить содержимое буфера и содержимое соответствующего участка загруженного файла, чтобы выявить произвел ли плагин изменения. Плюс реализация механизма отката будет проще.

Иначе перед запуском плагина придется делать копию файла на диске.

Отдавать все генерируемые данные, в результате работы hiew.(информация о формате файла, более детальная информация по формату файла, дизассемблер команды, запись/чтение блока из загруженного файла)



А те данные, которые hiew не генерирует, плагин сгенерирует сам - это и есть расширение возможностей hiew.

Я не говорил об этом, так как применительно к hiew - это не главное.

FAR - это файловый менеджер, поэтому основной упор его API на управление FAR'ом и его модулями.

В случае с hiew - это не требуется(ИМХО).



Думаю нужен минимальный набор:

Для запуска плагинов - Вызов списка плагинов

Доступ к информации о плагине можно реализовать в виде кнопки "info" в том же списке плагинов.



Сам оконный интерфейс:

1. Вызов диалога OK

Входных параметров у функции два - указатель на текст диалога, указатель на тайтл диалога.



2. Вызов диалога Yes/No

Входных параметров у функции два - указатель на текст диалога, указатель на тайтл диалога.



(Retry/Abort/Cancel всегда можно реализовать в виде нескольких диалогов Yes/No)



3. Кастом диалог, который содержит поля ввода данных + сопроводительный текст к ним.(Внешний вид как у диалога при операции PutBlock)



Входной параметр один - указатель на структуру, к примеру, назовем её DIALOGINFO



Структура представляет список контролов + 2 поля заголовка

Формат:

DIALOGINFO struct

StructSize DWORD ? ; размер структуры

lpTitle DWORD ? ; заголовок диалога

ControlInfo CONTROLINFO <> ; структура контрола

ControlInfo CONTROLINFO <>

ControlInfo CONTROLINFO <>

ControlInfo CONTROLINFO <>

; ...

DIALOGINFO ends



Структура CONTROLINFO имеет формат:

CONTROLINFO struct

ControlType DWORD ? ; тип контрола

lpTitle DWORD ? ; сопроводительный текст

lpResult DWORD ? ; указатель на буфер для результата

CONTROLINFO ends



ControlType - числовое значение, например,

1 - поле ввода hex-числа BYTE

2 - поле ввода hex-числа WORD

3 - поле ввода hex-числа DWORD

4 - поле ввода беззнакового dec-числа

5 - поле ввода знакового dec-числа

6 - поле ввода строки

7 - поле выбора опции

Список приблизительный, а в дальнейшем его можно будет расширить.



lpTitle - сопроводительный текст. Для контрола "выбор опции", это список строк: 1ая строка - сопроводительный текст, последующие строки - опции, конец списка - пустая строка.



lpResult - указатель на буфер с результатом

в случае "выбор опции" - это номер опции,

в случае ввода строки - в буфере будет строка,

в случае ввода числа - в буфере будет число.

В случае не заполнения пользователем поля значение поля lpResult обнуляется.



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



На том же этапе можно выполнять проверку на конфликт или не делать таковой, а просто присваивать новое значение пункта меню при каждом запросе.



Таково мое предложение по интерфейсной части плагина.

 

хм... PlugIn'ы и API для hex-редактора -- орригинально

Какой же API hiew будет предлагать плугинам ? Чтение байта ? Запись байта ?

Какие-либо навороченные плугины будут по сути независимыми программами, которых с hiew будет связывать только то, что они из него вызываются. Лучше уж просто сделать кучу полезных функций, напр. добавить к просмотру PE-заголовка возможность редактирования (hex) полей, etc.

Ну а если же подумать получше... Хорошо если в этом API будет интерфейс с disasm-unit'ом hiew'a, чтоб можно было написать хотя бы фильтр для 'мусорных' команд или декодер для полиморфа... как некстати IDA на ум пришла

 

...skipped...



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

скажи что конкретное ты хочешь написать ?

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

плагин как генератор данных... эт интересно.

а данные он потом будет запихивать их обратно в хиев чтобы тот отрабатывал дальше.



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



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

 

знаешь есть такое понятие mainstream, так плагины сейчас это оно самое заодно со скинами.

полностью разделяю и не понимаю зачем пользоваться файловым i/o через hiew если плагин может с файлом работать сам как угодно.

не будет использование через hiew более безопасным. Плагин может испортить файл любыми функциями, сие зависит от писателя плагина.

это давно уже сделано

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