хрень какая-то творится с этим мощным проектом - те dynamorio.dll, которые они раздают тут под видом версии 2.2.0.2 не соответствуют сорцам из их svn
Например в svn явно есть поддержка AVX (см. например core\x86\decode_table.c), а в dll имен этих мнемоник нет
Никто не пробовал сам его собирать ?
Update: проект мне понравился например тем что таблица импорта содержит исключительно ntdll. Что делает его пригодным например в написании собственного shimа и теоретически даже возможен порт в нулевое кольцо
четверг, 30 июня 2011 г.
спам пришел
давеча
С интересом жду предложений пройти детектор лжи и колоноскопию например, бгг
Учебный Центр Luxoft приглашает Вас зарегистрироваться на Facebookинтересно сколько им пробашлял цукенберг ?
С интересом жду предложений пройти детектор лжи и колоноскопию например, бгг
среда, 29 июня 2011 г.
udis86 with ssse3 & sse4
а вот например как всем известно последняя версия udis86 не поддерживает ssse3 & sse4 совершенно официально
Первая моя наивная попытка добавить их самостоятельно провалилась с позором. Например пишем в x86optable.xml скажем для
компилируем и смотрим itab.c
И например видим что дескрипторы для инструкции попали в таблицы ud_itab_entry itab__0f & itab__pfx_sse66__0f
Впрочем такой вариант тоже не работает:
Похоже что текущая реализация opgen.py не поддерживает opcodes длиннее 3х байт. Добавить же нужно следующие инструкции
Первая моя наивная попытка добавить их самостоятельно провалилась с позором. Например пишем в 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х байт. Добавить же нужно следующие инструкции
вторник, 28 июня 2011 г.
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
умеет 32 & 64 бита и полный фарш - mmx/sse/sse2/sse3/ssse3/sse4/avx - под linux/mingw/vs2008/vs2010
вроде даже работает, несмотря на FPU (partially)
Update: опыты показали также что ему неизвестны инструкции invept, invvpid, movbe и AMD-V Virtualization ISA Extension
суббота, 25 июня 2011 г.
сломал голову
как известно под лучшей в мире операционной системой код может быть
Тут все просто и очевидно - первый template задает размерность, второй - сhar или wchar_t. Метод get_format_string зовется из somefunction для получения правильных форматных строк для printf например. Заметьте при этом что сам get_format_string не имеет аргументов типа W и вообще служит исключительно для специализации:
Это компилируется.
Проблема возникает при попытке определить частично специализированный метод get_format_string. Например такое не работает:
при компиляции возникает ошибка C2768
И как же будет правильно специализировать такой метод шаблонного класса ?
Update: гугл говорит нам что "частичная специализация шаблонной функции шаблонного класса в чистом виде невозможна" и предлагает использовать костыли в виде traits и прочую boostоподобную упячку. Реальность однако подсказывает что вот такой код, вставленный внутри определения класса, вполне даже работает:
vs2008 есличо
У меня есть подозрения что главная гордость с++ - шаблоны - на самом деле реализованы в нем крайне черезжопу анус мертвого страуса
- 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 есличо
У меня есть подозрения что главная гордость с++ - шаблоны - на самом деле реализованы в нем крайне через
среда, 22 июня 2011 г.
patched udis86
пока отдельные альтернативно-одаренные граждане ждут "форка на github чтобы может быть присоединиться" (бгг) я выложил все что накорябал в udis86 на проклятый sourceforge например
Изменений не особо дофига:
добавлены opcodes для
Для добавления ssse3/sse4 нужно править схему декодера, который в настоящее время не поддерживает 4х байтные opcodes, что довольно долго и ресурсоемко (особенно верификация добавленного)
И да - на сайте udis86 творится полный бардак. Например вот этот xml местами не соответствует docs/x86optable.xml
Изменений не особо дофига:
добавлены opcodes для
- getsec
- paddd
- popcnt
- vmlaunch
- vmread
- vmwrite
- xgetbv
- xsetbv
- xrstor
- xsave
Для добавления ssse3/sse4 нужно править схему декодера, который в настоящее время не поддерживает 4х байтные opcodes, что довольно долго и ресурсоемко (особенно верификация добавленного)
И да - на сайте udis86 творится полный бардак. Например вот этот xml местами не соответствует docs/x86optable.xml
вторник, 21 июня 2011 г.
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 я так и не вкурил, но иначе оно не работает
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 я так и не вкурил, но иначе оно не работает
понедельник, 20 июня 2011 г.
god hate us all
а вот например давеча я используя udis86 нарвался на некий файлик, содержащий инструкцию paddd (которая содержится в MMX и якобы должна поддерживаться. Однако же...). Далее последовало внимательное и поучительное разглядывание bug tracker
Судя по всему проект мертв, ибо ни единого бага с сентября 2009 года не было пофикшено. Более того - ssse3/sse4/AES instructions не поддерживаются официально
Несколько подумав полез смотреть другие движки дизассемблера. Требования очень просты - должен собираться под 32/64 бита под windows/linux, в user mode & kernel mode, имена opcodes должны быть легко отключаемы (для экономии места в драйвере например)
Резко стало еще грустнее
Проще всего самому добавить/пофиксить все что нужно в том же udis86 чем найти то что требуется на самом деле. Хотя канешно добавление пары семейств команд будет довольно ресурсоемким занятием
PS: добавление инструкции paddd потребовало ровно 4 строчки и установки петона под винду
Список opcodes, не поддерживаемых текущей версией udis86 (из тех что я нашел)
Судя по всему проект мертв, ибо ни единого бага с сентября 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 (из тех что я нашел)
ололо
Кудрин советует хранить деньги в рублях
что-то мне подсказывает что завтра к банкоматам и в обменниках будут неиллюзорные очереди например
что-то мне подсказывает что завтра к банкоматам и в обменниках будут неиллюзорные очереди например
пятница, 17 июня 2011 г.
античный race-condition bug
а вот например перечитываю перелистываю (склероз патамушта) старую книжку Windows NT File System Internals и в главе 9 в псевдокоде SFsdCommonRead вижу subj
Если конкретно - гражданин захватывает ERESOURCE FCB->MainResource на чтение и проверяет, не был ли еще инициализирован cache manager для данного файла (страница 430 есличо). Проблема в том, что на Ъ-многоядерной машине может одновременно исполняться два и более buffered read IRP для этого файла и соотв-но как себя поведет cache manager в таком случае - неизвестно. Скорее всего плохо ему станет
Если конкретно - гражданин захватывает ERESOURCE FCB->MainResource на чтение и проверяет, не был ли еще инициализирован cache manager для данного файла (страница 430 есличо). Проблема в том, что на Ъ-многоядерной машине может одновременно исполняться два и более buffered read IRP для этого файла и соотв-но как себя поведет cache manager в таком случае - неизвестно. Скорее всего плохо ему станет
четверг, 16 июня 2011 г.
icfp contest 2011
EKOPath 4
думаю все уже читали и тут и даже тут
будучизлобным параноиком крайне недоверчивым я даже скачал
Во первых оно не собирается. Т.е. совсем
Во вторых насколько я вижу по сорцам - это несколько обточенный напильником gcc 4.2.1, причем 44 измененных файла имеют цопирайты QLogic Corporation и только 8 файлов - PathScale, LLC.
В третьих я не понимаю как они умудрялись продавать эту патченную версию gcc, не имея проблем со стороны fsf
Загадошно и непонятно зачем оно нужно в принципе
будучи
Во первых оно не собирается. Т.е. совсем
Во вторых насколько я вижу по сорцам - это несколько обточенный напильником gcc 4.2.1, причем 44 измененных файла имеют цопирайты QLogic Corporation и только 8 файлов - PathScale, LLC.
В третьих я не понимаю как они умудрялись продавать эту патченную версию gcc, не имея проблем со стороны fsf
Загадошно и непонятно зачем оно нужно в принципе
суббота, 11 июня 2011 г.
β version
начало см. тут
Cкочать - 32 & 64bit
archive password: silentBeta
Changelog:
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
четверг, 9 июня 2011 г.
пятница, 3 июня 2011 г.
Skype protocol reverse engineered
думаю все уже видели например
Отличная работа, чо
В комментах беснуются всякие анально уязвленные, как обычно
Update: сорцы (большей частью датированные октябрем 2009) доставляют неимоверно - выход hex-rays в основном, доведенный напильником до состояния компилябельности:
Отличная работа, чо
В комментах беснуются всякие анально уязвленные, как обычно
Update: сорцы (большей частью датированные октябрем 2009) доставляют неимоверно - выход hex-rays в основном, доведенный напильником до состояния компилябельности:
//pop edi
//pop esi
//pop ebp
//xor al, al
if (eax == 1){
eax = 1;
}else{
eax = 0;
};
Подписаться на:
Сообщения (Atom)