Бросте пожалуйста в мыло архив "Касперского Дизассемблирование в уме. Errata. от The Svin." Чего-то его не скачать. Спасибо.

animator@e-mail.ru

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

... спасибо. Буду ждать без терпенья.

Я первый,,лови
Ps. не могу приаттачить, кидаю на мыло.

Vstalker
Получил, спасибо. А нет ли у Вас перечня найденных ошибок, который составил The Svin по данному труду Касперского. The Svin как-то выставлял свой перечень в раздел WASM.BOOKS, но ссылка, к сожалению не работает. Буду благодарен.

animator
К сожалению нет.

Погнали!

*****
> Страницы даны по старому изданию TФХК
> стр. 169.
> В заголовке стоит "Структура команд Intel 80x86"
> и в первой же схемке присутсвует SIB.
> Нужно бы уточнение, что SIB стал присутсвовать только с 80386.
> А то глядя на заголовок и схемку у начинающего могут быть непонятки.
> Я уже встретил такое не раз, последний раз на нашей борде.
> Пришлось пояснять что и SIB, и префиксы 66h,67h не существовали до
> 80386.
>
> Далее под этой схемой - следующая схема опкода.
> Она неточная.
> - Отсутсвует бит S (последующие попытки в книге объяснить
> что S якобы замена D несостоятельны, я подробнее могу разъяснить
> почему, то что S и D оказываются оба на месте бит[1] не основание
> считать их вариациями).
> - Бит размерности w не всегда находится в нулевом бите байта кода
> как это нарисовано в схемке.
> Пример mov reg,imm. Там он находится в третьем бите перед (по
> старшинству) тремя битами reg.
> Формат
> 1011 w reg: imm
>
> Далее фраза которая видимо относится к биту D который ты называешь
> "направление".
> "Направление обозначает операнд-приемник".
> Слово "обозначает" странно звучит для моего уха. Бит D определяет
> направление передачи. Косвенно можно сказать, что в конце концов
> это скажет какой из двух операндов определённых в modrm будет
> приемником а какой источником. Но даже в этом случае лучше прозвучит
> "определяет", чем "обозначает".
> Заметь ты вообще до этого места не делаешь разбора что находится в
> modrm - просто только Modrm в схемке без расшифровки сокращённых
> обозначений типа R/M. Однако тут же следует фраза
> "Нулевое значение присваивает результат правому операнду, а единица
> левому". Что ты считаешь правым и левым и где вообще операнды
> определяются ты не разъяснил ещё до этого момента.
> Я вобщем человек привычный к опкоду и формату, и что то несложное могу
> кодировать и просто бинарно без напряжения, но и мне пришлось задуматься
на секунду,
> что тут правый и левый операнд. Если исходить из твоей схемки
> и предположить что правый-левый это относительно их расположения в
> схемке: mod | reg\code| m/r
> То согласно ей reg\code - левый операнд, m/r - правый.
> Но читатель (а имеется ввиду неопытный читатель, опытному это вообще
> не нужно) вынужден догадываться об этом и заниматься дедукцией.
>
> В конце страницы очень странное заявление:
> "Но задумаемся, как это поле будет вести себя если один из операндов
> имеет непосредственное значение?"
> Никак оно себя не будет вести, поскольку его просто не будет.
> Код ID опкода абсолютно другой будет и из него (или уже из ID группы)
> будет очевидно декодеру что никакой трактовки поля D не требуется.
> И потом, что значит "поле ведёт себя"? Поле только содержит
> что-нибудь, а ведёт себя уже дешифратор.
> Также обрати внимание на простой факт - поле S не всегда присутсвует
> даже в тех командах которые в мнемониках с той же инструкцией
> кодируются с битом D при операндах без непосредственного значения.
> Например test. Оно при операндах reg\mem,reg\mem кодируется с битом
> D но в опкоде для test reg\mem,imm бит S не присутсвует в формате, в AND
есть
> а в test - нет. А бит D присутсвует и в том и в другом случае при
> операндах без imm. Это никакая не замена D. И это не поле D пропадает
> и потому стали его использовать под S. Уникальное ID кода и группы
> начинается со старших бит и имеет разную бинарную длину, бит мог
> использоваться для просто новых уникальных кодов инструкций.
> Так что введение бита S никак не обусловлено "понапрасну проподающим
> битом D когда использует непосредственный операнд", оно обусловлено
> своими резонами. Какими - как раз дальше уже у тебя объяснено.
>
> Вобщем непонятно назначение этой фразы. D работает с Modr/m а
> непосредственный операнд разумеется в modrm не присутсвует и над чем
> тут задумываться читаталю нужно было - непонятно.
>
> Поэтому фраза "инженеры Intel учли такую ситуацию и нашли оригинальное
> применение" - это, прости, чепуха.
> Дешифратор после того как находит байт блока код определяет группу
> формата и никаких проблем с ситуацией пропродания D нет.
> У них разное ID.
> Существуют группы вообще и без D и без S и даже без w, место это по всему
> множеству нет "закреплено" за битом D. Небыло никакой ситуации поэтому
> которую нужно было учитывать.
> Была отдельно реализованная возможность использовать sing extention с
> раздельным кодирования для displacement (через поле mod) и для
> immidiate (через введение в определённые группы общего поля бита S)
>
> Пока первая страница.
> Замечания как обычно превосходят по размеру оригинал :)

> Стр. 170. Начинается со странного заявления:
> "Рассмотрим ситуацию когда операнду размером в слово или двойное слово
> присваивается непосредственное значение меньшее по модулю 0х100. Ясно
> что значащим является только младший байт, а нули, стоящие слева, по
> правилам математики можно отбросить".
>
> Тут даже непонятно с чего начать замечание.
> 1. Непонятно зачем писать меньшее по модулю, вместо просто меньшее
> 100h хотя вообще и это было не верно в конкретно данном случае?
> 2. S бит - это Sign Extention. Поэтому заполняются недостающие разряды
> не обязательно нулями, а значением старшего (sign) бита.
> 3. Что тут под меньшим понимается - тоже непонятно, толи в знаковой
> толи в безнаковой трактовке. 00000080h < 00000100h но никак тут
> ты применишь "отбрасывание нулей" по твоей теории с помощью S бита.
> Отбрасывание их (ужимание полного операнда до байта) будет только
> при положительном x <= 7Fh. И отрицательном x >= FF...80h
> т.е. -128>= x <=127.[-128..127] при знаковой трактовке.
> Странно тоже звучат слова "нужно пожертвовать хотя бы одним битом,
> чтобы указать ему на эту ситуацию".
> Отбросить нули можно математематически и в случае 00FFFFFFh.
> Ни о какой математической ситуации процессору не сообщается.
> Ему говорится
> - возьми только байт из памяти как непосредственный операнд,
> а не x байтов полного размера.
> - дополни взятый операнд до полного размера в инструкции заполнением
> старших(недостающих) бит значением старшего бита взятого байта.
>
> Тут нет жертв бита - тут наоборот возможность кодирования ужатием.
> И не флаг это направления. Этои бит S.

> стр. 171.
> Расшифровка префиксов:
> "0xF2 REPNZ
> 0xF3 REP"
> Не сказано про второй, что он также трактуется как REPE (REPZ)
> хотя про первый сказано что он REPNZ.
> Если быть точным - оба этих префикса могут использоваться как просто
> REP в инструкциях типа movsb где нет сравнения. Хотя этот факт
> официально не офишируется.
> Последний бит в этих префиксах используется как бит условия на ZF
> после сравнения в операциях cmps, scas.

****

> стр. 171. Список префиксов.
> Упущены префиксы 2E,3E.
>
> Ещё любопытно как появилась фраза на этой странице:
> "Если используется больше одного префикса из той же самой группы, то
> действие команды неопределено и по своему реализовано в разных типах
> процессоров".
> Во первых что такое "разные типы процессоров"?
> Во вторых - это просто из Интеловских док переписано, или
> действительно ты практически экспериментировал и можешь привести
> пример что на одной модели последовательность префиксов одной группы
> так-то трактуется а на другой иначе?

> стр. 171, 172
> Цитата:
>
> "Разумеется в реальном и 16и разрядном режиме указатель команд всегда
> обрезается до 16 бит".
>
> Коментарий:
> 1.Странное сочетание "реальном и 16и разрядном режиме" реальный и 16и
> разрядный не годятся как перечисление сущностей - реальный тоже 16и
> разрядный. Если имелся ввиду полный список нужно было упомянуть, RM,VM
> и PM 16бит. Вообще достаточно было сказать просто 16и разрядный код.
> 2. Насчёт "обрезаний" - не так это, эффективный адресс может
> формироваться и как 32х разрядный (с 67h) но при привышении
> эффективной части он не "обрежется" а произойдёт особый случай 12 или
> 13 без кода. Это же произойдёт и с 66 с3 если двойное слово в стеке
> превысит 16и битный лимит.

***
> Hi,Крис!
> Оказался я на страничках 172 и 173 уже :)
> На странице 172 применяется термин CL0,
> IMHO лучше поменять на привычный CPL0, даже я споткнулся на секудну -
> типа "что за CL0?"
> Там же опять рассуждения про обрезание адреса - нужно бы ещё подробнее
> изучить этот вопрос. В официальной доступной - это третий том часть 17.26
> среди хорошей нашей Григорьев, лучше вообще дополнительную инжинерную
> доку от Интела, у нас такие с контроллерами приходили на базе 486DX.
> Толстые таки буки, схем побольше и информация поконкретней.
> Нет там обрезания. Если кто и что может обрезать - разве что
> обработчик 13го после определения в чём причина, это уже не сам камень.
> На странице 173 первая фраза:
> "Декодер за один раз считывает только 16 байт, и если команда "не
> уместится" то он попросту не сможет считать продолжение и сгенерирует
> общее исключение".
> Комментарий:
> Дело в том что он сгенерирует исключение и если инструкция превысит
> уже 15 байт - это есть в документации и легко проверить запустив
> какой-нить смешной опкод - например 14 раз F3 затем например 40h.
> Потом, если первое не вызвало ничего (вобще-то из опыта не должно,
> но мало ли что на каких-то моделях) увеличить колличество F3 перед 40h
> до 15и увеличив тем самым инструкцию до 16и - получим общее исключение
> защиты. 15 байт просто максимально возможный размер инструкции по
> правилам. И исключение будет если размер > 15и (а не 16и как у тебя в
> примере).

> Цитата:
> "Префиксы ПЕРЕКРЫТИЯ сегмента могут встречаться перед любой
> командой"
> Коментарий:
> Наверное, правильно сказать ПЕРЕОПРЕДЕЛЕНИЯ сегмента.
> Тем более перед этим тебя вполне устаивал этот термин, но почему-то
> в этом месте ты поменял его на "перекрытие".

***

> стр. 173.
> Цитата:
> "Практически для каждой команды, если регистром-приемником фигурирует
> AX(AL) существует специальный однобайтный опкод, который в трёх
> младших битах содержит регистр-источник".
>
> Комментарий:
> Сильная фраза :) Непонятно где клемо ставить.
> Во первых
> - Если имелись ввиду однобайтные инструкции размером 5:3 (5 бит - код
> ID и 3 поле reg) то таких всего 5: inc,dec,push,pop,(xhchg(E)AX,reg)
> 1. Инструкций всего 5 (т.е. не для каждой команды)
> 2. Из них двуоперандная только ОДНА. И та может работать только с
> ПОЛНЫМ размером (DWORD в 32х битном режиме, WORD в 16и).
> Т.е. с помощью её ты не закодируешь байт (т.е. AL) в формате 5:3 нет
> бита размерности w. Соответсвенно если ты даже попытаешь сделать
> xhcg al,al у тебя уйдёт на это 2а байта, т.к. прийдётся кодировать с
> вариантом с modrm (100001 1 0: 11 000 000;hex 86 C0)
> Во вторых маленькая неточность по сравнению с первой -
> если уж ты пытался высказать такое про AX(AL) то почему тогда не EAX
> тоже :)
> В третьих сказано в трёх младших битах регистр - источник.
> Понятно, что там где всего один аргумент говорить о регистре источнике
> но что можно говорить о единственной команде которая не противоречит
> твоему высказыванию - xchg eax,reg где один из операндов (eax)
> задаётся неявно? Я не могу утверждать ЧТО задаётся тут неявно -
> источник или приемник. Оба регистра выступают здесь в обоих качествах.
> А байта modrm нет чтобы рассудить хотя бы через бит D.

> Конец стр. 173 начало 174.
> "Для многих команд (Jx) четыре младших бита обозначают условие
> операции".
> Замечание1.
> Лучше было сказать Jcc (условные переходы) - это общепринятый термин,
> тогда слово "многие" можно было опустить.
> Замечание2.
> Вообще-то официальное название этого поля TTTN.
> Оно присутсвует не только в Jcc но и в CMOVcc, SETcc.
> И везде кодируется одинаково.
> В третьих если говорить про 4е младшие бита, то следовало бы сказать
> чего - а именно старшего байта блока code.
> Т.к. например возможен 00001111:10001tttn вариант.
> Где на блок кода уходит два байта.

***

> Hi, Крис!
> стр. 174.
> "Трёхбитовое поле reg, содержащие регистр источник, очевидно не
> используется, когда за ним идёт непосредственный операнд".
> Это не единственный случай, и даже не самый частый.
> Наиболее частый случай - однооперандная инструкция, тогда modrm если
> операнд задаётся явно, поле codr тоже используется для codid.
> Потом нет там никакого префикса 0F. Там просто двух - уровневые
> реляционные отношения - ID группы и ID команды внутри группы.
> У ID группы старшие биты часто (но не всегда) = 1111
> но само ID длинее.
> Под префиксом в машинном коде интел понимаются определённые вещи,
> которые обладают чёткими свойствами - размер в байт, и любое место в
> череде префиксов. Т.е. не полубайт и не стоящий обязательно в конце
> череды префиксов. Действительно коды группы обладают сходством между
> собой и отличием от "чистых" ID, но не стоит называть их поэтому
> префиксами - они не обладают свойствами префиксов.
> Тогда почему бы префиксом на этом основании не назвать 7 бит 1111011
> а не четыре 1111? Потому, что в hex цифру не влазят?
> Это как раз ID группы. Последний бит в зависимости от инструкции
> W или не используется (как в call,push\pop и т.д.), бит S отсутствует.
> Поэтому "ужимание" непосредственного операнда до байта для test
невозможно,
> например. В то время как для and reg\mem, imm - возможно.
> В первом случае используется формат с битом w но без s, во втором и с
> w и с s.
>
> Потом - существуют группы использующие поле codr для code ID но у них
> нет 0xF - например sub reg\mem,imm; and reg\mem,imm и т.п.
> У этой группы ID 100000 s w

> стр. 174.
> "Заметим, что это же поле используют многи инструкции, оперирующие
> одним операндом (jmp, call). Это всё очень сильно затрудняет написание
> собственного дизассемблера\ассемблера, но зато даёт простор для
> самодифицирующего кода".
>
> Я, честно говоря, не понял в чём тут затруднения для дизассемблера,
> и почему это даёт простор :)
> Правда Женя Сусликов споткнулся как раз на группе 1111011x - автоматом
> обрабатывал младший бит как w не проверяя является ли ID в codr
> POP\PUSH\CALL\JMP из-за этого у него получался смешной декодинг типа
> pop al или call ch :)
> До сих пор не исправил кажется. Я напоминал ему недавно снова.
> Но так я понял Hiew у него сейчас не главная тема, обещал исправить
> вместе с другими указанными ошибками в дизассемблировании но не обещал
> что скоро.
> А мы с Яном Hiew любим. Особенно Ян.

***

> стр. 175. Цитата:
> "Опять же можно восхитится лаконичностью решения инженерова Intel,
> которые ухитрились закодировать столько регистров всего в трёх битах"
>
> Комментарий.
> Ну мы же знаем что это не так :)
> Ни один гений не определит 24е сущности через 3и бита.
> Сколько (а на схемке 24е) регистров удалось закодировать только
> благодоря введению ещё бита w для определения между группами partial и
> full. И префикса 66 для определения между полным и альтернативным
> полным. Т.е. имеем до 9и дополнительных бит. Причём введение префикса
> 66 разумеется решение от безвыходности в которую Intel сам себя
> загнал, предложив совместимость сверху вниз. Нельзя было менять формат, а
без
> него место для дополнительного switch'а оставалось только в префиксе.
> Иначе можно было придумать формат с битом для этой цели.
> Другое дело что сам по себе бинарный подход к ID полями произвольной
> длины позволил не использовать w или 66 когда в этом небыло
> необходимости. В фиксированном формате этого бы не получилось.

> Это решил тебе написать Ян (семилетний Хрюк)
> стр. 175. Цитата.
> "BX - это индексный регистр. И стоит первым среди индексных"
>
> На самом деле BX и BP - это базовые регистры.
> А стоит он первым не среди индексных, а среди тех которые могут быть
> использованы как указатели на память в 16и битном режиме.
> Только SP указатель неявный, т.е. его нельзя закодировать через байт
> modr/m. Но он всё равно используется при инструкциях PUSH,POP и ещё
> RET и другие (ПОПА например:)-61h ПУША-60h .
> А про алфавит - процессор не знает ничего, для него это регистры блока
> общего назначения с кодами 000 ... 111.

***

> стр. 176. Цитата:
> "..так как требуемый регистр может находится в области памяти, занятой
> другой переменной (это происходит, когда ячейка памяти определяется по
> индексу регистра; при этом считываются три бита и суммируются с базой,
> но никак не проверяются пределы)"
>
> Перечитал раз десять - ничего не понял...
> Нужны разъяснения.
> Что значит "требуемый регистр может находится в области памяти"?
> Как регистр в какой то ещё области памяти может находится помимо
> своего блока в процессоре?
> Что такое "ячейка памяти определяется по индексу регистра"?
> Что тут индекс регистра? Код регистра? (000 для eax?) или это значение
> которое находится в индексном регистре?
> Что за три бита считываются с какой базой суммируются?
> код регистра с базою определённой в дескрипторе селектора сегмента?
> Вообщем я ничего не понял.
> Боюсь, что же самое произошло со многими читателями.

> стр. 176. цитата:
> "если эмулировать ещё два сегментных регистра в обработчике int 0x6, то
очень
> трудна будет как отладка так и дизассемблирование"
> Опять ни слова не понял.
> Знаю:
> - что такое особый случай 6
> - что такое прерывание
> - что такое обработчик прерывания
> - что такое сегментный регистр.
> Но совершенно не понял:
> - что такое "эмулировать 2а сегментных регистра"
> - и как программа это может сделать в обработчике - попытаться
> перенаправить 6ой вектор (или шлюз) что ли на свою процедуру
> обработчик и там что-то эмулировать?
>
> Вообще страница 176 начинается (и предологает - посвящена) кодам
> сегментных регистров. Никаких примеров кода включающего эти коды я не
> обнаружил.

***

> стр. 177 (ура наконец-то на новой странице!)
> "На самом деле регистр CR1 просто не существует! И любая попытка
> обращения к нему вызывает исключение int 0x6....
> ... Всех этих команд не существует, и они приводят к вызову
> прерывания 0х6... и тем не менее очевидно, что при обращении к регистрам
DR4-5
> исключения"
>
> Я правильно понял, что всё доказательство построенно на вызове
> прерывания #UD?
> Тогда начнём с конца:
>
> "Debugging Extensions (bit 3 of CR4). References to debug registers DR4
and DR5
> cause an undefined opcode (#UD) exception to be generated when set;
> when clear..."
> Т.е. и при обращении к DR4-5 мы можем получить #UD при определённых
> обстоятельствах. Что тем не менее не убеждает нас в отсутвсвии DR4-5.
> Единственное что можно сказать про то что вызвала особый случай #UD
> что инструкция такая выполнена быть не может.
> И это никак отсутсвия или наличия чего-то не подтверждает.
> Инструкции (выполнимой) такой действительно в настоящих моделях нет.
> Есть ли там физически регистр CR1 - неизвестно. Согласно документации
> - есть. С микроскопом даже не определишь правда ли это.