Судя по всему проект мертв, ибо ни единого бага с сентября 2009 года не было пофикшено. Более того - ssse3/sse4/AES instructions не поддерживаются официально
Несколько подумав полез смотреть другие движки дизассемблера. Требования очень просты - должен собираться под 32/64 бита под windows/linux, в user mode & kernel mode, имена opcodes должны быть легко отключаемы (для экономии места в драйвере например)
Резко стало еще грустнее
- BeaEngine - полная упячка
- diStorm - BSD лицензия канешно сильно лучше чем GPL, но файл include/mnemonics.h повергает в адское уныние
- Mediana - кодировать имена мнемоник в общей с парзером инструкций таблице - полный crap
Проще всего самому добавить/пофиксить все что нужно в том же udis86 чем найти то что требуется на самом деле. Хотя канешно добавление пары семейств команд будет довольно ресурсоемким занятием
PS: добавление инструкции paddd потребовало ровно 4 строчки и установки петона под винду
Список opcodes, не поддерживаемых текущей версией udis86 (из тех что я нашел)
- paddd
- короткая форма fabs (без префикса 0f)
- vmlaunch
- xgetbv
- xsetbv
- xrstor
- xsave
- getsec
- vmread
- vmwrite
- AVX инструкции
XED который в PIN tools используется.
ОтветитьУдалитьЕсли только не смущает, то он жирный сильно - несколько сотен килобайт.
он c сорцами ?
ОтветитьУдалитьлицензия человеческая ?
Ну все правильно - делайте свой форк. Желательно на GitHub'е, может я даже присоединюсь :)
ОтветитьУдалить> может я даже присоединюсь
ОтветитьУдалитьололо, радость то какая нежданная - к нам может быть даже присоединится не осиливший собственного названия для своего бложика придумать !
я прям весь аж дрожу от открывающихся перспектив, бгг
Какой зеленый и толстый мальчик :) Откуда же столько негатива?
ОтветитьУдалитьredp, ты все еще веришь в движки написанные чужими дядями ?
ОтветитьУдалитьможно ведь продолжить списочек вопросов:
ОтветитьУдалитьты все еще используешь компилятор, написанный чужими дядями ?
ты все еще используешь интернет, изобретенный чужими дядями ?
ты все еще используешь булеву алгебру, выдуманную чужим дядей ?
ты все еще живешь в доме, построенном чужими дядями ?
ты все еще потребляешь колбасу, сделанную чужими дядями из туалетной бумаги ?
хе-хе
ты слышал термин "разделение труда" например ?
это все из другой оперы
ОтветитьУдалитьожидай что кто-то разделит то что долго и ресурсоемко
А видишь ли, государыня императрица, пушка - это особь статья, а мортира - это ... тоже особь статья! (с)
ОтветитьУдалитьбгг
А можно подробнее про Mediana? Мешает мнемоника в выходной инструкции, или что?
ОтветитьУдалитьнапример попробуй ее для драйвера собрать
ОтветитьУдалить>например попробуй ее для драйвера собрать
ОтветитьУдалитьВообще, на драйвера планы были -- отчасти для этого был введен Unicode. Я так понимаю, смущает размер таблиц и невозможность отключить в них мнемоники?
код, который отвечает за разбор opcodes, должен быть отделен от куска, который печатает инструкции.
ОтветитьУдалитьСм. например как это в том же udis86 сделано - можно банально не линковать syn-intel.c в драйвер и все будет работать без него
Размер при этом тоже важен
А, ну так у меня отделен. Тут проблема с документацией, хотя я это, вроде, описывал. Достаточно убрать или написать #undef макросов:
ОтветитьУдалить//Include/exclude dumping functions.
#define MEDIANA_CTRL_DUMP
#define MEDIANA_CTRL_DBG_DUMP
из файла mediana_ctrl.h и вывод инструкций не будет включен при компиляции.
насколько я помню строчки с именами мнемоник при этом все равно остаются в коде
ОтветитьУдалитьДа, мнемоника -- это часть таблиц и никуда она не исчезает. Макросы отключают код, который отвечает за вывод инструкции. Была мысль сделать мнемонику вообще отдельно и подключать ее с помощью макроса во время компиляции. Но тогда файл tables.inc будет выглядеть жутко, т.к. каждый элемент, описывающий инструкцию, будет содержать #ifdef ... #endif. Учитывая, что tables.inc и так не подарок, я так делать не стал. Может быть, стоит подумать о такой опции, но перед этим надо посчитать размер таблиц без мнемоник, у меня есть ощущение, что их (таблиц) вклад в размер секции данных -- основной.
ОтветитьУдалитьможно грубо прикинуть - например в файле tables.inc 2289 OPCODE_DESCRIPTORs, из них 987 пустые. Пусть длина одной мнемоники в среднем 6 байт. Получим 2289 * 4 (размер указателя) + 1302 * 6 = почти -17Kb
ОтветитьУдалитьНо и это не все - например размер одной OPCODE_DESCRIPTOR 28байт (под 32бита). Заменив их описание указателем на описание и таким образом имея только один дескриптор для GRP_NULL мы получим 987 * 28 - 2289 * 4 = еще -18Kb
Так, посчитал я, что сколько занимает:
ОтветитьУдалитьsizeof(*opcode_descr): 32
Mnemonics: 7301
Tables: 71456
Empty entries: 29504
Расчеты, в общем-то, почти верны. Можно ввести еще один уровень косвенности, но тут есть проблема. Допустим, у меня есть массив
struct OPCODE_DESCRIPTOR *opcodes_1byte[] =
{
name0,
name_1,
NULL
}
Вот эти вот name0 и name1 надо как-то генерировать. Можно взять что-то в духе мнемоника_операнды типа add_reg_1byte_const, но выглядеть это будет пугающе. Размер уменьшится на 25 килобайт примерно. И появляется вопрос: а стоит ли уродовать исходник из-за двадцати пяти килобайт? И повлияют ли эти 23 килобайт на драйвер? В общем, у меня сомнения...
хозяин - барин (c)
ОтветитьУдалитья бы на вашем месте например задумался над мета-форматом, из которого можно было простым скриптом генерить tables.inc под всякие цели и бесчеловечные эксперименты