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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уход...

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

Обфускаторы, виртуализаторы, конечные автоматы и защита софта

Частенько приходится слышать что-то вроде этого: "Обфускация - ерунда, а вот виртуализация кода - практически неломаемая штука". Встречается еще и что-то вроде такого: "Это не обфускация. Наш метод базируется на сложной задаче декомпозиции большого конечного автомата". И т.д., и т.п. Если взглянуть в вики, то можно прочитать вот что: Обфускация (от лат. obfuscate — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции. Т.е. и виртуализация, и создание в программе некоторого конечного автомата (что и есть виртуализация), что-то выполняющего, также являются одними из разновидностей этой самой обфускации. Виртуализация кода подразумевает под собой перевод исходного, как правило машинного, кода в код некоторого виртуального процессора с последующим встраиванием интерпретатора этого кода в тело защищаемой программы. Такой подход усложняет анализ защищенного кода, но не делает невозможным взлом программы и исследование логики ее работы. Аналогичное можно сказать и про декомпозицию конечного автомата, т.е. в данном случае про создание соответствия между исходным автоматом (x86 кодом, например) и полученным в результате обфускации автоматом. В теории все звучит достаточно неплохо, однако на практике, имея доступ к утилите, осуществляющей защиту, в подавляющем большинстве случаев, наделав простых сэмплов, можно набить шаблоны и снять защиту.
В последнее время стали популярны стековые ВМ в самом простом исполнении. Каждой ассемблерной инструкции ставится в соответствие некий обработчик, который делает то же самое, что и исходная инструкция вплоть до сохранения регистра флагов. Плюс имеется некий цикл выборки команд и передачи управления обработчикам. Помнится, был такой язык Forth. Так вот, стековые ВМ очень похожи по архитектуре. У Ахо, Сети, Ульмана такая архитектура называется абстрактной стековой ВМ. Не уверен точно, но, возможно, идея использования виртуального процессора пошла со времен, когда люди столкнулись с виртуальной машиной Visual Basic-а. Соблазны использовать такого рода обфускацию следующие:
1. "Эксперты" нараспев говорят, что это круто.
2. Маркетологи нараспев говорят, что п.1.
3. Размер запутуанного кода вырастает не так сильно.
4. Реализация не требует особых математических знаний и навыков, что позволяет справиться с задачей рядовому системному программисту.
5. Сроки реализации прогнозируемы по времени.
6. Результат тоже прогнозируем.
7. Легко накручивать сверху фичи - контроль целостности, несколько циклов выборки, отсутствие циклов выборки, предварительный анализ флагов и создание обработчиков, которые могут их как угодно менять и т.д.
8. Ломать это бывает лениво.
9. Пипл схавает, ибо ничего лучшего за эти деньги на рынке нет.
Мое глубокое убеждение в том, что без качественной обфускации тела самой ВМ ее можно декомпилировать, а следовательно, и взломать. Поэтому обычно тело ВМ чем-нибудь морфят и вообще всячески защищают. От качества морфера зависит очень многое. Большинство морферов работают на уровне одной инструкции, не анализируя графа потока управления в целом (см. п. 9). Зачастую здесь на помощь приходит антиотладка (эвенты, многопоточность и т.д.). Т.е. достаточно старые приемы, никак не обоснованные математически и дающие сомнительную стойкость в сочетании с жуткими тормозами и глюками. Причем, чем больше антиотладки, тем больше этих самых глюков. Замедление 4-5 порядков - это норма для таких ВМ. Часто можно встретить выполнение логических инструкций на базе стрелки Пирса, например, что хорошо конвертируется обратно посредством вбивания шаблона в декомпилятор.
А можно ли создать идеальный обфускатор? Нет, т.к. существует класс подпрограмм, которые, чем ни накрой, не защитишь. Вырожденный случай - программа, распечатывающая сама себя. А можно ли создать хороший обфускатор - такой, чтобы крайне сложно было написать автоматический деобфускатор? Да. Но для этого нужно, как минимум, уметь делать следующее:
1. Отслеживать граф потока данных защищаемой подпрограммы.
2. Распознавать переменные на стеке.
3. Обфусцировать не на уровне одной инструкции, а на уровне всей подпрограммы, а лучше - на уровне программы.
4. Использовать минимальный набор инструкций.
А для того чтобы создать сам механизм обфускации на уровне всей подпрограммы, необходимо неплохо разбираться в математике и криптографии. В частности, методы White-Box криптографии после некоторой модификации вполне подходят и для решения задачи обфускации. Совершенно очевидно, что создание такого обфускатора - более ресурсоемкое занятие. Причем, в целях ограничения размера, код можно и на стековой ВМ интерпретировать - еще уровень защищенности добавится. Т.е. значимость системных программистов в данной работе не отвергает никто. Однозначно можно утверждать, что это работа не для одного человека, а для целой команды. Работу эту делать долго и может встретиться масса подводных камней. Плюс еще есть немаловажный политический момент. К сожалению, очень много специалистов по защите софта таковыми себя только мнят. Любой человек мало-мальски знающий ассемблер, немножко знающий WinAPI и PE-формат, а также умеющий пользоваться IDA и OllyDbg - уже такой специалист. Если он еще и C++ знает, то вообще очень крут :) Вот так, на таком уровне понимания, и пишется подавляющее большинство программных защит. Не удивительно, что и стойкость их невысока, и взламываются они достаточно стандартно. Один такой "эксперт" мне сказал как-то: "Специалисту по защите софта не надо знать математику, ему надо знать что с чем в нужный момент поксорить". О чем можно было говорить дальше? На пути создания хорошего обфускатора стоит еще и вопрос окупаемости, т.к. обфускация в подавляющем большинстве случаев используется для защиты относительно недорогого софта, а протекторы с кучей фич, пусть и в большинстве своем несложно отламываемых, стоят недорого, принося авторам мизерные доходы. Мнение "экспертов" вкупе с непониманием, как извлечь выгоду из столь дорогого в производстве продукта, крайне отрицательно сказываются желании инвесторов полноценно финансировать создание обфускаторов. Таким образом, действительно интересные идейно, но крайне глючные в реализации, продукты создаются энтузиастами и забрасываются на этапе альфа-версий в лучшем случае - либо создаются на инвестиции различного рода секретных ведомств, что сильно ограничивает к ним доступ со стороны простых смертных, да и, в силу ограниченности применения, продукты тоже глючные. В связи с таким положением дел я бы рекомендовал для действительно стойкой защиты софта использовать ключи с загружаемым кодом. Либо, если есть ощущение собственной крутости, не надеяться на протекторы, а писать защиту для своих программ самостоятельно, используя сторонние продукты не более как на вспомогательный инструмент, т.к. производители таких продуктов полагаются, в основном, на п. 9.

Интересное мнение про обфускацию

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