И еще один ответ - Аркадий:

Нельзя. Вот выдержка из текстика, который я недавно подготовил (зря
что-ли выклянчивал тут разные доки?):

______________O\_/_________________________________\_/O______________
- instruction format:

prefixes
opcode (1 or 2 bytes)
modrm byte (0 or 1 byte)
SIB byte (0 or 1 byte)
displacement (0, 1, 2, or 4 bytes)
immediate value (0, 1, 2, or 4 bytes)

Prefixes may include:

- instruction prefixes REP/REPE/REPZ (F3h), REPNE/REPNZ (F2h),
LOCK (F0h);
- address-size prefix (67h);
- operand-size prefix (66h);
- segment override prefixes CS: (2Eh), DS: (3Eh), ES: (26h), SS: (36h),
FS: (65h), GS: (65h).

The 80386 (and newer) CPUs set a limit of 15 bytes on instruction length.
Exception 13 (GPF) occurs if this limit is violated.
_____________________________________________________________________
O/~\ /~\O

Это означает, что сначала надо просканировать все префиксы, потом определить
длину опкода (1-2 байта), потом определить наличие modrm (определяется
опкодом) и SIB (определяется modrm-ом) байт. Наконец, нужно учесть длину
смещения (0-4 байт) и непосредственного значения (0-4 байт), наличие и длина
которых определяются префиксами (address/operand-size) и modrm/SIB байтами.

И опять Аркадий:
>> и т.д. НО для этого мне нужно знать размер команд вот я и спрашиваю зависит
>> ли размер команды от 2 байта или же размер команды можно вычеслить по 1
>> байту если нет то обясните по какому принципу hiew вычесляет длинну команд
F> Длина = длина опкода по таблице
F> ;строго говоря, для префиксов надо вызывать это рекурсивно,

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

F> ;но для простоты будем считать префиксы однобайтовыми опкодами

Нельзя. Например, ты не можешь отделить от инструкции префикс смены
разрядности адреса/операнда.

как вычеслить какой modrm соответствует определеннуму опкоду потом как вычеслить sib для данного modrm и наконец от чего можно отталкиватся при вычеслении смещения
я пологаю что есть таблица ?? покоторой это можно выщитать или есть способы вычесления .......... если есть поделитесь =)

dr.golova спасибо я как раз это и понял осталось только понять принцип вычесления всего этого ..........

> dr.golova спасибо я как раз это и понял осталось только понять принцип вычесления всего этого ..........

А принципа тут нет - надо просто тупо вколотить таблицу для всех опкодов =) Но про префиксы было верно замечено - их надо обрабатывать вначале (я выкинул этот кусок кода), потому что скажем префикс 0х66 будет влиять на размер def_data и соответсно на размер инструкции.

На, держи еще маленько. Ответил sars:

>;но для простоты будем считать префиксы однобайтовыми опкодами

Нужно глядеть как эти префиксы влияют на остальное.


>если это группа Jxx/JMP/CALL (без mod_reg_r/m), то длина = длина +
>адрес/смещение, конец

Ну и анализ флагов, которые мы установим, если предшествовали префиксы.


>если опкод имеет mod_reg_r/m, то
> длина = длина +1

Тут по таблице интеловской глядеть нужно, там куча нюансов.


> если есть смещение, то длина + длина смещения

Чтобы узнать это, нужно этот байт разобрать и на префиксы глядеть.

> если есть SIB, то
> длина = длина + 1
> ... и т.п.

Аналогично и с сибом, там свои правила

Вобщем челу однозначно нужно разбираться с интеловскими таблицами, я по второму тому от Интела разбирался. На удивление все просто оказывается.

Ну, а теперь на бис - The Svin:

Высказанные предположения никакого отношения к определению размера
команды не имеют.
Нет никакого принципа такого "по первому байту" по "второму байту".
Вообще перепендикулярные домыслы какие-то, все "в молоко".
Длина определяется динамически и в зависимости от группы зависеть
может от массы вещей.
Даже внутри блоков размер может быть разный.
Как определяется - я подробно описывал в тюторах и учебных программах.
При этом я описал только основные принципы, все группы я не описывал.
Таблицы Интела - говно и если sars ты по ним научился чему-то, то ты
гений.
Коротко я рассказать не могу, если бы мог то и писал бы коротко.
А уже написал до черта, и до конца ещё не дописал.
Что Белоусов расказывал про "сканирование байтов по таблице" я не
понял нифига, дуднук я видимо. Если бы он алгоритм написал - я бы
может что и понял про сканирование. По словам немогу.
Вольдемар, опкод может состоять из блоков:
префиксы (байты - могут быть, могуть не быть, может быть несколько) ,
код (разной длины, причем часть битов может быть
в том же байте в котором определяется адрес, а может и не быть -
зависит от группы), полей регистров, блока modr/m (который кодируется
по сложной схеме, может расширятся на sib и displacement, по разному
кодируется в 32х битной и 16и битной адресации, дисплейсмент может
быть байт, слово, двойное слово), непосредственный операнд (размер
которого зависит от режима адресации и бита w, который находится
вообще не в непосредственном операнде а в блоке кода).

Короче опкод - это сложный динамический формат, и определение длины
его происходит непосредственно в момент декодирования по сложному
алгоритму.
Даже не весь его формат - а только один блок к примеру modr/m и его
расширение - это уже сложный динамический формат и только его
декодирование - это алгоритм сложнее чем Бойер Мур.
Его длина (только этого блока) будет зависеть и от текущего режима и
от наличия впереди префикса 67h, и от состояния бит, которые укажут
есть ли дисплейсмент, содержится ли sib, находятся ли в базе "особые
значения", какое поле mod.
Короче, чтобы не утомлять - полный декодер modrm с тестовой программой
есть где-то на форуме - посылал я раньше.
Там можно посмотреть алгоритм определения размера этого блока.
Более менее полную логику "на стенде" можно посмотреть в обучалке
последней.
Но в обучалках недошли руки до tttn, FPU (хотя тут очень просто),
MMX,SSE и т.д.

Если есть вера и понты о том, что "всё понятно у Intel" - то sars прав
- второй том содержит форматы, которые понятны только тем кто и так
принципы знает, и вопросов "как узнать размер" не задаёт, а смотрит
туда за справками о формате группы.

Если говорить о дизассемблировании то более менее "соответсвующих"
дасмов видел только 2а - SICE (лучший по точности) и Hiew
(подтягивается за ним). Остальные (включая OllyDbg) - жутко тормозные
и глюкавые. 1ое место по тормознутости IDA, что вызывает вообще
сомнения в том что автор вразумительно понимает строение опкода.
Такое ощущение что он декодирует "прямым отражением" блоков.

Сожалею, если "наступил на горло песне" на фоне оптимистических
рассказов "как всё там просто".
Рад был бы помочь, но всё что мог объяснить - итак уже выложено на сайте.

Ух, разошлись. Теперь Аркадий:

AY> Что Белоусов расказывал про "сканирование байтов по таблице" я не
AY> понял нифига, дуднук я видимо. Если бы он алгоритм написал - я бы
AY> может что и понял про сканирование. По словам немогу.

Что-то я именно таких своих слов не припомню. Но если требуется
накидать скелетик алгоритма (со "сканированием"), то вот:

1. заводим табличку опкодов. Где-то так (напоминаю, это только скелет):

char * opcode_name [] = {
        "add", /* 0 */
        "adc", /* 1 */
        ...
        "push", /* 10 */
        ...

OPCODE_FLAGS { OP_SIZE8 = 1, OP_RM = 2, ...
            /* OP_SIZE1632 = 0, OP_MR = 0, ... */
OPCODE_KIND { OP_SECOND, OP_MODRM, OP_IMM8, OP_IMM1632, OP_SREG, ...

struct OPCODE {
        byte arg_mask; /* маска для битов аргумента */
        OPCODE_FLAGS flags; /* биты описания */
        OPCODE_KIND kind; /* тип инструкции */
        count name_idx; /* индекс в массиве имён */
                                /* или индекс второго байта */
                                /* если kind==OP_SECOND */
};

OPCODE optable [256] = {
/* 00 */ { 0, OP_SIZE8, OP_MODRM, 0, }, /* add rm8,r8 */
/* 01 */ { 0, 0, OP_MODRM, 0, }, /* add rm16/32,r16/32 */
/* 02 */ { 0, OP_RM+OP_SIZE8,
                               OP_MODRM, 0, }, /* add r8,rm8 */
...
/* 06 */ { 0x18, 0, OP_SREG, 10, }, /* push es */
...
/* 0E */ { 0x18, 0, OP_SREG, 10, }, /* push cs */
/* 0F */ { 0, 0, OP_SECOND, ..., },

Соответственно, нужна ещё табличка для вторичных байтов - 0F и D8-DF.

Да, забыл дальнейшее. Впрочем, полагаю, тут всё тривиально: берёшь
опкод, проверяешь по таблице. Если в .kind указано, что это префикс, меняешь
набор флагов (в соответствии с .flags из таблицы). Если в .kind указано
OP_SECOND, пеоеходишь к вторичной таблице и всё повторяешь. Наконец, в
противном случае вызываешь соответствующий декодер (в зависимости от .kind),
с аргументами - битами аргумента из опкода (opcode&.arg_mask), текущим
набором флагов и полем .flags.

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

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

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

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

Складываться общий размер может из таких частей:
1. Префиксы (их может быть несколько притом в реальности может быть больше чем нужно для правильной работы инструкции).
2. Блок кода.
3. Блок modr/m + возможное его рассширение на sib и\или displacement.
4. Непосредственный операнд.

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

Попытка выразить например блок кода в байтах - с точки зрения математики такая же за уши притянутая вещь как четвёртый постулат Евклида. Поскольку байты которые содержат БИТЫ уникального ID кода, при этом могут содержать и другие биты - операндов, флаги размера и сжатия непосредственного операнда, направление передачи и т.п.
Подчеркну - термин "тип формата" - это просто тут же мной придуманый термин, чтобы не говорить много слов.
Дам понятие через примеры.
Например опкоды
01000 xxx
01001 xxx
01010 xxx
01011 xxx
10010 xxx
Относятся к одному типу формата 5:3 где 5 бит на ID кода и 3и на код регистра.
8 кодов относятся например к формату:
100000sw: md cod m/r :[sib]:[disp]:imm.
Здесь полное ID - это 6 старших бит первого байта и
3и средних (3ий,4ый,5ый) следующего байта - ещё называющего байт modrm.

Итак первое слагаемое - префиксы.
Они прибавляются и прибавляются к общей сумме байт опкода
пока декодер не натнётся на биты которые уже он не может трактовать как префикс и пытается их трактовать как ID. Префиксы могут быть при этом и ненужные
и поэтому сказать что в такой-то инструкции будет столько то префиксов можно только говоря об оптимальной закодированной инструкции, но кто гарантировать это может?
Если говорить о каком то пределе (например 4х как Intel)
то что будет с дизассемблером который наткнулся на случай когда их больше? Предел определяется только одной вещью - префиксов не может быть бесконечное колличество поскольку вообще общая длина инструкции не может быть больше 15 байт. И если процессор уже выбрал 15 байт как байты относящиеся к данной инструкции но при этом ещё не "дошёл" до конца - он просто генерирует особый случай.
В частности можно точно сказать что префиксов никогда больше 14и и если их уже 15 - то перед нами гарантировано неверный код. Вообще же префиксов, понятно может быть не больше 15-x где х размер инструкции с выкинутыми префиксами. Обычно (за исключением случая идущих подряд 15и префиксов) такая ситуация становится ясна когда пошло
декодирование после префиксов.
2. 2е слагаемое - байт содержащий код операции или его начальные биты, они содержат биты ID из которых понятен тип формата, а имеено где (если есть) ещё биты и какие ещё части входят и первые ориентиры где в каких битах что искать. Именно тут и определяется будет ли следующим байтом байт modr/m есть ли непосредственный операнд или ещё какие-то части (нужно помнить что у Intel полно исключений, когда некоторые типы форматов не укладываются в типичные схемы - например, вообще-то почти всегда когда используется операнд в памяти адрес которого явно или косвенно (через описание слагаемых - базовых и индексных регистров, маштабирование и т.п.) указывается в команде (т.е. есть битовые поля в опкоде из которых это можно узнать) то используется байт modr/m. НО! Есть и исключения
например для al,ax,eax существует и дополнительный ничем не похожий на все другие типы формата опкод для типа
mov eax,[address] где байт modr/m не используется).
Итак для того что для нас представляет интерес на этом этапе мы можем понять - сколько ещё байт содержат биты кода и какие ещё части входят.
Но чтобы перейти к следующим слагаемым размера скажем
что части эти могут иметь разный размер.
3. Байт modr/m - если понимать его с его возможным расширением, то может иметь очень разный размер.
Отчего он будет зависеть - полностью разжёвано в статьях
в разделе Образовательные программы.
Скажем только что влияет на его размер несколько вещей и часть этих вещей находятся в самой этой части а часть в других.
Вначале определяется по каким правилам его декодировать
по 16и битным или 32х битным в смысле разрядности адреса.
И это влияет и на размер и на содержание.
Определяется это исходя из текущей адресации в селекторе CS и наличии в команде в префиксах 67H.
Дальше исходя из того в какой разрядности он декодируется будет определяться имеется ли дисплейсмент, какого размера дисплейсмент, для 32х битного имеется ли sib ещё. И т.д.
Эти вещи уже определяются битами которые берутся в самой этой части - в modr/m и sib.
Если говорить только о размере то можно представить множество всех возможных размеров этой части (modr/m,sib,disp) для 32х битной адресации как:
1 + x + y
где x (sib) может быть 0 или 1
а y (disp) может быть 0 или 1 или 4е.
для 16и битной как
1+y
где y (disp) может быть 0 или 1 или 2.

4. Последнее слогаемое - непосредственный операнд.
Сколько на него (если он присутсвует) байт уйдёт зависит от
a) типа формата. (в некоторых типах предусмотрено, только фиксированный размер, в некоторых размер зависит от размера операнда, в некоторых от размера операнда и состояния бита s)
b) размера операнда (который в свою очередь может зависеть от текущего режима адресации, наличия префикса 66h, состояния бита w)
c) состояния бита s.
Причём обратим внимание что биты w,s,и префикс 66h находятся вообще в других частях общего кода инструкции.

Это лишь самое общее описание того, что влияет на размер и из чего он состоит.
Меня честно говоря гложет сомнения в бесполезности того, что я пытаюсь кратко изложить это. Получается не проще а более общё, и в результате более непонятно.

С другой стороны это не так и сложно. У меня 8и летний сын кодирует прямо в машинном коде и ему достаточно бросить взгляд на бинарный дамп что не только сказать размер но и сами инструкции, при этом он никаками долбаным таблицами Интела не пользуется, я например вжизь бы их выучить не смог. А они как раз и пытаются привести через пусть огромный понос hex таблиц но зато к какой-то брадисообразной упрощённой схеме референса. Знающий человек разумеется успевает декодировать инструкцию в уме развалив её на битовые поля быстрее в несколько раз чем другой ищет нужное значение по этой таблице, а без таблицы вообще вподает в прострацию.

Раздел общеобразовательные программы содержит ряд статей и обучалок на тему. Если интересно.
Спасибо Володе за высокую оценку :)
Но проще чем там у меня объяснить не получается.
На самом деле я видел массу статей где это всё объясняется очень коротко, но сам ввиду своей ограниченности по ним учится мог с большим трудом.
Ян вообще терял к ним интерес к ним через минуту.
Во и придумывался пусть долгий но более понятный путь разъяснения, чтобы такие же глупыши как я с ним могли в этом деле разобраться.
Не претендую что эти обучалки нужны реальным пацанам,
но нам с Яном важен был результат и мы его получили - кодируем вручную без особых проблем, может кому эта методика и ещё сгодится.
Статьи там довольно сырые IMHO, будут потихоньку дорабатываться. Art Of Dissassembly - на самом деле конспект этих статей, с пачкой привнесённых авторами от себя ошибок.

Спасибо Володе за высокую оценку :)

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

всем огромное спасибо !!! информация очень полезная я еще почитаю в разделе общеобразовательные программы и тогда думаю доконца разберусь !!!
The Svin пишет:

Если интересно.

КОНЕЧНО интересно все что касается данной темы мне очень интересно

P.S. огромное спасибо всем за отклик !!! особенно The Svin и volodya

Мне-то за что? Ты Свина, Голову, ФатМуна и Аркадия с Сарсом благодари - они тебе помогали, а не я.

The Svin
А ты не думал написать одну нормальную статью на эту тему?
Всякие там ArtOfDisassemble - туфта для начинающих, да и 99% остального материала тоже.
Все как один начинают переписывать мануалы интела, расписывая биты регистров, modrm и т.п., а на большее тяму не хватает.

Мля, а вот как сгруппировать все эти команды - никто не объясняет, т.е. классифицировать их по конечному (небольшому) кол-ву признаков.
Ты вот тоже в тексте говорил о "группах". Че это такое?

Я сегодня ночью разбирал сорцы Borg'а, так вот там для дизассемблирования (и вычисления длин инструкций) используется таблица

asmtable tables86[]=
{ {asm86,TABLE_MAIN,0,0,0,0xff,0,0xff,0},
  {asm86sub0f,TABLE_EXT,0x0f,0,0,0xff,0,0xff,1},
  {asm86sub80,TABLE_EXT,0x80,0,8,0x07,0,0xff,0},
  ...
  {asm86subdfb,TABLE_EXT,0xdf,0,8,0x1f,0xc0,0xff,0},
  {asm86subdfc,TABLE_EXT,0xdf,0,1,0xff,0xc0,0xff,1},
  {NULL,0,0,0,0,0,0,0,0}
};

Почему они ее построили именно так, а не иначе - я так и не понял.

Ну, в ArtOfDisassemble, они уже не из Intel а у меня переписывают, творчески перерабатывая :)
Переработка заключается в том, что выкидывается какое-то колличество материала, часть которого, например, отсутсвует у Intel, так они выкинули разъяснения про бит S равный 1 совместно с W = 0. А один из распространённых вопросов "непоняток" у тех уже начал чуть-чуть понимать в предмете. И тучка других мелочей выкидывается без которых картина не полная, не ясная и изучающий предмет человек, если он психологией своей похож на меня, начинает испытывать дискомфорт.

Но поводу одной статьи.
Если мог бы написать сейчас - написал бы.
Пишу я как получается, стараясь ориентироваться на себя.
Тут уж ничего неподелать. Конечно же в конце концов должно быть сделано обобщение. Пока используется принцип не от теории к практике а от частного к общему и от практики к теории. Изучаются разные стороны предмета. После того как они будут все описаны и детально разжёваны, будет сделано обобщение на более высоком уровне.
На то у меня есть свои резоны.
Коротко изложить их если - "от теории к практике" работает хорошо приём тогда когда сама теория понятна, а теория понятна когда она ассоциируется с чем то уже из опыта.
Так вот принимая во внимание что аудитория программисты, и принимая во внимание с какими типами данных и принципами работы с ними типичный программист имеет дело для них сам формат опкода, рассматривая его в "истинном виде" , непривычен. Некратные байтам бинарные поля, линейная разбросанности данных для передачи информации, вычисление размера исходя из анализа этих полей при том что нет такого поля где этот размер лежит в числовой форме и т.д. и т.п.
Поэтому делаются такие обучалки что-бы люди могли пообвыкнуть к такой логике и принципам хранения информации какая заложена в опкоде, а не пытались выразить его в своих категориях. В этом конкретном топике - только этим, к примеру и занимаются, пытаются рассмотреть опкод и развалить его на привычные типы.
На мой крестьянский взгляд - это неправильно. Дизассемблеры будут большими и медленными если использовать подобный подход.
Вот я пытаюсь сначала предложить не пытаться решить к кому относится карась - к птицам или насекомым, а попытаться просто рассмотреть карася таким какой он есть.
После внимательного рассмотрения этого карася со всех сторон обобщения прийдут сами собой.
Получается медленно пока, усугибилось тем, что полетел диск с 2х летней работой над книгой, в нём в частности были написанные движки по кодированию\декодированию, так что для новых обучалок их надо заново писать.
И материалы для статей, в частности статей по строению опкоду. Делается так - я сначала накапливаю какие-то разные мысли по предмету, приёмы объяснения, упражнения и
примеры и т.п. Потом из них выбираю что получше и включаю в статью. Сейчас некоторый психологический дискомфорт от того что это всё пропало и нужно заново писать.
И от того может и нет "финальной" статьи по теме с "финальными" обучалками.

Чтобы понять самостоятельно о группах, можно почитать конечные статьи во втором томе Intel, а также посмотреть на обучалки чтобы само понятие "группы" почувствовать.
Каждая обучалка у меня использует только одну "группу".
Группа определяет какие части включаются в опкоды группы и
так же и местоположение. Я в самом посте выше показывал примеры таких групп.
Определяется группа по ID опкода.
Строгого определения ID нет, определяется алгоритмически от старших бит по маскам, и отсечения при таком способе непренадлежности к какой то группе.
Ещё под группой понимают (уже несколько другой смысл) такие две вещи:
1. Расширение алфовита - это когда уже ID становятся мало - т.е. зарезервированных опкодов не хватает на новые инструкции назначают какое-то из оставшихся значений признаком группы или set. Когда процессор видит такой ID - он понимает что это не инструкция а указание что ID находится в следующем байте но трактовать его нужно уже по другой таблице (можем условно назвать её "таблицей новых опкодов")
2. Второе понимание группы это когда "уточняющие" биты находятся в поле "codr" байта modrm.
Например видит процессор последовательность 100000хх - и понимает что это формат такой то а для уточнения какая именно инструкция в этом формате - нужно посмотреть в следующий байт в три средних бита.
Т.е. если это
100000хх хх 000 ххх - то это add.
а если
100000хх xx 001 xxx - то это or

The Svin
из чего строится опкод я понял и от чего зависит его длинна тоже а вот как всетаки смотря на опкод в двоичном представлении узнать все это об нем я не понял ....

Неужто ты уже успел всё прочитать и протестировать себя на всех обучалках из секции Образовательные программы?