Отголосок прошлого :)

    На cracklab-е обсуждается тема взлома конверта, разработкой которого я занимался раньше :) Интересно, сколько времени потребуется на решение задачки (восстановление извлеченных инструкций). Судя по всему, версия конверта достаточно древняя.
    Кстати, технику выдергивания одной инструкции (а это и делает опция /RIP_CODE) используют достаточно большое количество протекторов. Очень часто таким образом запутывают граф потока управления. Armadillo, к примеру, ставит int 3 вместо извлеченной инструкции. В некоторых конвертах ставится call, что накладывает ограничения на размер инструкции (>= 5 байт).
    При кажущейся простоте подхода восстановить исходные инструкции может быть и не так просто. Все зависит от того, насколько защищен интерпретатор извлеченной инструкции. Можно, в принципе, попробовать восстановить посредством анализа входов и выходов, но здесь возникает проблема идентификации этих входов и выходов. Например, как определить, что была извлечена инструкция mov eax, [imm]? Поставить бряк на память? А если есть фальшивые чтения памяти? А если флаги доступа к страничке эпизодически меняются тем же VirtualProtect-ом? Плюс ко всему, необходимо полное покрытие исследуемеого файла дизассемблером, что в случае перехваченных инструкций еще более затруднительно. Т.е. задачка то в общем случае вовсе нетривиальная :)
    Другой вопрос в том, какой защитный механизм срабатывает при интерпретации такой перехваченной инструкции. Может так случиться, что восстанавливать исходные нет никакой необходимости. Проще подкорректировать интерпретатор так, чтобы он всегда работал как надо :)
    В случае с конвертами, идущими в качестве бесплатного (или платного) приложения к донглам, упор делается на поддержку всех выпускаемых ключей. А значит и младших (медленных и устаревших), и сетевых моделей. Это значит, что вызывать электронный ключ каждый раз при вызове интерпретатора перехваченной инструкции даже при использовании профайлера нельзя (именно поэтому мы пока не видим хороших автоматических решений для ключей с загружаемым кодом). Особенно четко это проявляется в случае сетевых ключей. Поэтому используется либо периодический опрос (когда клиент сам задает период опроса донгла), либо кеширование информации, полученной с помощью донгла.
    В случае периодического опроса вся вина при потере производительности ложится на клиента, который осуществляет защиту. Период опроса он, как правило, задает самостоятельно.  
    В случае кеширования информации необходим хитрый механизм, который, в зависимости от платформы, на которой запущено защищенное приложение, будет определять время, в течение которого информация будет храниться в кеше. Или надо придумать некоторый параметр, который это время регулировал бы, свалив всю вину на клиента :) Информация в этом случае достаточно стандартная (расшифрованные с помощью донгла код, байт-код или данные,  ключ для расшифрования чего-либо, какое-нибудь инициализирующее значение для чего-либо, полученное с помощью донгла).
    Самое интересное в том, что для задачи привязки софта к ключу (или лицензирования вообще) глубокой разницы между полноценной обфускацией кода программы и выдергиванием по несколько (или даже по одной) инструкций с последующим встраиванием интерпретатора нет. В случае лицензирования ведь нет необходимости защищать пользовательский код от анализа, а надо, чтобы он не работал при невалидной или отсутствующей лицензии. А вот механизм лицензирования должен быть действительно качественным, что сложно обнаружить в унифицированных решениях в силу объективных причин.

Новый Год!

Год предыдущий принес много перемен (желаемых, в основном). Во многом удалось добиться своего, и, в целом, я доволен достигнутыми результатами, хотя хотелось большего, как всегда :). Встреча Нового Года прошла в теплой семейной атмосфере.  По правде говоря, у меня давно не было такого светлого праздника. Предыдущий год позволил накопить определенный потенциал в виде идей, знаний и частичных  реализаций. Кое-что из задуманного уже дает свои результаты, которые заинтересовали тех, кто в теме. В этом году основная задача - закончить начатое без революций и катаклизмов, уложившись в запланированные сроки. Дает свои плоды и образовательная программа, позволяющая выявлять людей, с которыми можно в дальнейшем работать. Короче говоря, жизнь идет, и в нужном ключе, что не может не радовать :)

Переезд в Калугу

Все, мы покинули Москву :)  Уже работаю из дома - из своей, а не снимаемой в default city квартиры. Свершилось! Впрочем, Москва в 3-х часах езды, поэтому туда тоже можно будет ездить иногда. Радует то, что ряд стереотипов начинает рушиться. Например, больше становится компаний, готовых работать с людьми удаленно, не требуя от них переезда в место своей дислокации. Современные технологии связи обеспечивают такие возможности. Выгода для всех участников процесса налицо. Те, кто не понимает этого (а точнее, не принимает в силу сложившихся стереотипов, придумывая разнообразные, зачастую нелепые, объяснения, почему так не делать), ограничивают сами себя. Такие необоснованные ограничения зачастую являются плохо прикрытым результатом управленческого непрофессионализма. Забавно было слушать некоторых товарищей, отговаривавших меня от таких действий, называя переезд дауншифтингом :) Как-как, а так я бы это не стал называть :) Дауншифтинг был, когда я с позиции руководителя работ в одном Калужском НИИ уехал в Москву работать простым системным программистом,  не выигрывая на тот момент ни по позиции, ни по деньгам. Уехал за профессиональным ростом, который, полагаю, состоялся. Теперь настало время развиваться дальше.

PS. К Москве отношусь положительно. Можно даже сказать, люблю этот город. Обязательно будем периодически туда ездить. Может, даже появится время наконец-то погулять по городу без суеты и насладиться им в полной мере.

Атаки на системы клиент-банк

Прочитал интересную новость. Эта информация выявляет в очередной раз очень интересную проблему безопасности систем клиент-банк, о которой так много рассуждают разного рода специалисты. Рассуждают, в основном, в своем кругу, поэтому широкому кругу пользователей систем клиент-банк результаты этих бесед неизвестны. Совершенно очевидно, что с помощью классической криптографии защититься от этих атак невозможно. Ни GUI клиент (если это толстый клиент), ни криптопровайдер, ни драйвер устройства (речь идет о токене) никак не защищены от исследования. Да, используются протоколы классической криптографии, но они никак не рассчитаны на то, что приложение, их использующее, будет выполняться на недоверенной платформе. Использование токенов с  ЭЦП на борту также не дает гарантий безопасности, т.к. на подпись такому токену, как правило, отправляется хеш-сумма подписываемого документа. Таким образом, остаются способы подсунуть на подпись хеш-сумму другого документа. Чтобы создать программу, производящую такие зловредные действия для конкретной клиентской части, достаточно произвести ее тщательный анализ с помощью IDA.  Т.к. клиентская часть ничем не защищена и одинакова для многих тысяч пользователей, исследования принесут море удовольствия и не займут много времени, а атака может стать достаточно массовой. Хорошо документированные сервисы MS Crypto API еще более упрощают задачу :)
Один из технических выходов из ситуации - рандомизация каждой конкретной клиентской части. Т.е. ее структура должна стать совсем другой! Это означает  отказ от стандартизации, которая считается догмой. В частности,  имеет смысл подумать от использовании обфускации и White-Box криптографии, применяя эти механизмы, пусть и в автоматическом режиме, но уникально для каждой клиентской части. Однако, не смотря на техническую возможность, если не обезопасить полностью, то сильно снизить риски, существуют еще и административные вопросы, связанные, например, с сертификацией. Пока все участники процесса не осознают давно уже назревшую необходимость перемен, вряд ли мы увидим какой-то великий прогрессивный сдвиг в направлении улучшения защиты. Способы решения проблем будут, скорее всего, локальными и уже сейчас представлены - одноразовые пароли, SMS-уведомления и т.д. У них есть свои недостатки, связанные с недостаточной гибкостью. Например, SMS - это сервис, не гарантирующий доставку сообщений. С большой вероятностью антивирусные компании будут создавать свои механизмы противодействия атакам на клиентскую часть, что уже радует.

PS. Техническое описание атаки: http://habrahabr.ru/company/eset/blog/107520/
Красиво :)

О студентах...

Преподаю в Калужском филиале Бауманки. Все говорят о деградации студентов. Типа, с каждым курсом все глупее и глупее. Говорят все, включая самих студентов :) Я пришел к выводу, что на самом деле люди не глупее, у них всего-навсего ценности несколько другие. И, плюс к этому, колоссальная неуверенность в себе, усугубляемая тем, что многие из них еще не знают чего конкретно хотят и, как следствие, не знают куда расти. Да и такого жесткого мотиватора, который был у моего поколения в 90-е, у нынешних студентов нет. Т.е. вопрос далеко не в умственных способностях, с которыми у большинства все нормально, а в банальной мотивации. И давить надо именно на мотивацию, а в плане науки, при наличии желания, они сами все, что им надо, вытянут из преподавателя плюс к стандартным материалам. Кое-что уже получается. Думаю, с переездом в Калугу из Москвы будет получаться еще больше...

Проблема декомпозиции многомерных полиномов

Хороший приятель дал интересную ссылку  на статью, посвященную сабжу. Очень интересная работа - однозначно позволяет расширить кругозор и, возможно, улучшить качество моего LRC-метода, т.к. прицел в ней идет на схожие конструкции. Ну или придумать атаку на него :) В последнее время как раз немножко увлекся компьютерной алгеброй и символьными вычислениями и обнаружил, что русскоязычных книг на эту тему не очень много. Доходчивое описание базиса Гребнера, например, встречается достаточно редко. 

Одно из самых доходчивых: 

Кокс Д., Литтл Дж., О'Ши Д. Идеалы, многообразия и алгоритмы. Введение в вычислительные аспекты алгебраической геометрии и коммутативной алгебры.

Есть еще достаточно неплохая книга:

Прасолов В.В. Многочлены.

Уход...

Вчера был мой последний день работы в компании "Актив". Для меня это был целый этап в жизни.  Этап, когда я, попав в реально сильный и передовой коллектив в качестве слабенького системного программиста, вырос до эксперта, к мнению которого в Компании прислушивались. Это был хороший, сильный коллектив. Это были люди, которые меня многому научили. Я счастлив, что мне удалось в качестве и разработчика, и руководителя поучаствовать в целом ряде флагманских проектов. Почему ухожу? Наверное, пришло время. Я стал чувствовать себя не в своей тарелке - хочется большего, хочется движухи и более амбициозных проектов, хочется поменьше разговоров и побольше реальных дел,  хочется, чтобы никто не висел грузом на моих ногах, не давая мне развиваться, а также очень хотелось довести мой самый любимый Проект, посвященный обфускации, до конца, не смотря на то, что все люди, которые в него верили и продолжают, покинули компанию по похожим причинам. Что интересно, если бы Проект не был актуальным, то не создавалось бы сейчас в параллели некоторое количество аналогов, за развитием которых я внимательно слежу. Хотелось не разговоров о развитии, а реального развития - выхода на международные рынки. Хотелось роста. Хотелось выполнения данных мне обещаний. Ну что ж... Консервативный путь развития тоже имеет право на существование, но это не мой путь...