dynamorio

хрень какая-то творится с этим мощным проектом - те dynamorio.dll, которые они раздают тут под видом версии 2.2.0.2 не соответствуют сорцам из их svn
Например в svn явно есть поддержка AVX (см. например core\x86\decode_table.c), а в dll имен этих мнемоник нет
Никто не пробовал сам его собирать ?
Update: проект мне понравился например тем что таблица импорта содержит исключительно ntdll. Что делает его пригодным например в написании собственного shimа и теоретически даже возможен порт в нулевое кольцо

спам пришел

давеча

Учебный Центр Luxoft приглашает Вас зарегистрироваться на Facebook

интересно сколько им пробашлял цукенберг ?
С интересом жду предложений пройти детектор лжи и колоноскопию например, бгг

udis86 with ssse3 & sse4

а вот например как всем известно последняя версия udis86 не поддерживает ssse3 & sse4 совершенно официально
Первая моя наивная попытка добавить их самостоятельно провалилась с позором. Например пишем в x86optable.xml скажем для psignb что-нть такое:

<instruction mnemonic="psignb">
  <opcode> aso rexr rexx rexb ; sse66 0f 38 08 ; V W </opcode>
  <opcode> aso rexr rexx rexb ; 0f 38 08 ; P Q </opcode>
</instruction>

компилируем и смотрим itab.c
И например видим что дескрипторы для инструкции попали в таблицы ud_itab_entry itab__0f & itab__pfx_sse66__0f

Впрочем такой вариант тоже не работает:

<instruction mnemonic="psignb">
  <opcode> aso rexr rexx rexb ; sse66 0f sse38 08 ; V W </opcode>
  <opcode> aso rexr rexx rexb ; 0f sse38 08 ; P Q </opcode>
</instruction>


Похоже что текущая реализация opgen.py не поддерживает opcodes длиннее 3х байт. Добавить же нужно следующие инструкции

xbyak

заюзал сегодня кодогенератор с совершенно непроизносимым именем от епонцев
умеет 32 & 64 бита и полный фарш - mmx/sse/sse2/sse3/ssse3/sse4/avx - под linux/mingw/vs2008/vs2010
вроде даже работает, несмотря на FPU (partially)

Update: опыты показали также что ему неизвестны инструкции invept, invvpid, movbe и AMD-V Virtualization ISA Extension

γ version

например
archive password: almostWorks
β тут
Добавлены три опции:

• -mods - печатать список модулей per process
• -dump_patched - скинуть на диск секции отпатченных модулей ядра
• -kdmask - показать маски KD

Были пофикшены

• баг в парзере PE файлов - огромное спасибо sen
• новая версия udis86
• для угнанных exported symbols иногда показывает кто их перехватил
• имена RPC интерфейсов зачитываются из реестра
• и еще всякое про что вам знать необязательно

сломал голову

как известно под лучшей в мире операционной системой код может быть

• 32 или 64 битным
• ASCII или Unicode

два этих требования совершенно ортогональны. Соотв-но вот например у меня есть такой класс:

template <typename T>
class someclass
{
 public:
   template <typename W> void somefunction(const W* filename);
 private:
   template <typename W> const char *get_format_string(int index) const;
};

Тут все просто и очевидно - первый template задает размерность, второй - сhar или wchar_t. Метод get_format_string зовется из somefunction для получения правильных форматных строк для printf например. Заметьте при этом что сам get_format_string не имеет аргументов типа W и вообще служит исключительно для специализации:

template <typename T>
template <typename W>
void someclass<T>::somefunction(const W *filename)
{
  ...
  // вызываем get_format_string
  printf(get_format_string<W>(FORMAT_INDEX1), args);
}

Это компилируется.
Проблема возникает при попытке определить частично специализированный метод get_format_string. Например такое не работает:

template <typename T>
template <>
const char *someclass<T>::get_format_string<char>() const

при компиляции возникает ошибка C2768
И как же будет правильно специализировать такой метод шаблонного класса ?

Update: гугл говорит нам что "частичная специализация шаблонной функции шаблонного класса в чистом виде невозможна" и предлагает использовать костыли в виде traits и прочую boostоподобную упячку. Реальность однако подсказывает что вот такой код, вставленный внутри определения класса, вполне даже работает:

template <typename W>
 const char *get_format_string(int index) const;
template <>
 const char *get_format_string<wchar_t>(int index) const
{
// тело специализированного метода например
}

vs2008 есличо
У меня есть подозрения что главная гордость с++ - шаблоны - на самом деле реализованы в нем крайне через жопу анус мертвого страуса

patched udis86

пока отдельные альтернативно-одаренные граждане ждут "форка на github чтобы может быть присоединиться" (бгг) я выложил все что накорябал в udis86 на проклятый sourceforge например
Изменений не особо дофига:
добавлены opcodes для

• getsec
• paddd
• popcnt
• vmlaunch
• vmread
• vmwrite
• xgetbv
• xsetbv
• xrstor
• xsave

Исправлен баг 2899373

Для добавления ssse3/sse4 нужно править схему декодера, который в настоящее время не поддерживает 4х байтные opcodes, что довольно долго и ресурсоемко (особенно верификация добавленного)

И да - на сайте udis86 творится полный бардак. Например вот этот xml местами не соответствует docs/x86optable.xml

LFENCE vs XRSTOR

а вот например правя сегодня во все дыры udis86 наткнулся на чудесное:
lfence - 0F AE /5
xrstor - 0F AE /5
кажется от нас что-то скрывают (c)

Update: в доке от Intel сказано ровно то же самое. Опыты однако показали что правильно должно быть примерно так:
lfence - 0F AE /5 /mod=11 с любым /rm. Итого этой инструкции 8 различных opcodes
xrstor - 0F AE /5 /mod=!11
почему mod не должен быть равен 11 я так и не вкурил, но иначе оно не работает

god hate us all

а вот например давеча я используя udis86 нарвался на некий файлик, содержащий инструкцию paddd (которая содержится в MMX и якобы должна поддерживаться. Однако же...). Далее последовало внимательное и поучительное разглядывание bug tracker
Судя по всему проект мертв, ибо ни единого бага с сентября 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 (из тех что я нашел)

ололо

Кудрин советует хранить деньги в рублях
что-то мне подсказывает что завтра к банкоматам и в обменниках будут неиллюзорные очереди например

античный race-condition bug

а вот например перечитываю перелистываю (склероз патамушта) старую книжку Windows NT File System Internals и в главе 9 в псевдокоде SFsdCommonRead вижу subj
Если конкретно - гражданин захватывает ERESOURCE FCB->MainResource на чтение и проверяет, не был ли еще инициализирован cache manager для данного файла (страница 430 есличо). Проблема в том, что на Ъ-многоядерной машине может одновременно исполняться два и более buffered read IRP для этого файла и соотв-но как себя поведет cache manager в таком случае - неизвестно. Скорее всего плохо ему станет

icfp contest 2011

если кто например считает себя дофига умным (я уверен - тут каждый первый такой, бгг) - уже завтра например
Помнится в прошлый раз меня не хватило даже на то чтобы понять смысл задания
Во всяком случае это прикольнее чем искать watermarks в ida.wll, бгг

EKOPath 4

думаю все уже читали и тут и даже тут
будучи злобным параноиком крайне недоверчивым я даже скачал
Во первых оно не собирается. Т.е. совсем
Во вторых насколько я вижу по сорцам - это несколько обточенный напильником gcc 4.2.1, причем 44 измененных файла имеют цопирайты QLogic Corporation и только 8 файлов - PathScale, LLC.
В третьих я не понимаю как они умудрялись продавать эту патченную версию gcc, не имея проблем со стороны fsf
Загадошно и непонятно зачем оно нужно в принципе

β version

начало см. тут
Cкочать - 32 & 64bit
archive password: silentBeta

Changelog:

• .exe стал еще толще
• работает (не все проверяльщики при этом одинаково доступны) под w2k
• работает на windows 7 sp1
• по просьбам трудящихся вывод был разделен пустыми строчками в произвольных местах и убраны кое-какие некритичные сообщения об ошибках
• можно задавать только нужные проверяльщики из командной строки
• IDT дампится для всех камней
• для процессов проверяются всякие хуки в ntdll. Меня терзают впрочем смутные сомнения что иногда неверно определяется наличие shim

Опции командной строки:

• -all - проверить все юзермодные процессы
• -pid PID - проверить конкретный процесс
• -hal - проверить dispatch tables в hal.dll
• -idt - проверить IDT
• -ndis - проверить TDI & NDIS. Под w2k работает так себе и допиливать мне лень
• -rpc - показать зарегистрированные в системе RPC интерфейсы
• -wmi - показать зарегистрированные в системе WMI entries

что ни делают

выходит только гулаг:

Skype protocol reverse engineered

думаю все уже видели например
Отличная работа, чо
В комментах беснуются всякие анально уязвленные, как обычно
Update: сорцы (большей частью датированные октябрем 2009) доставляют неимоверно - выход hex-rays в основном, доведенный напильником до состояния компилябельности:

//pop     edi
//pop     esi
//pop     ebp
//xor     al, al
           if (eax == 1){
                   eax = 1;
           }else{
                   eax = 0;
           };