Хакеры выбирают CISC
АрхивЛюбая цивилизация должна бороться с бессознательной силой, которая может противостоять любому сознательному намерению коллектива, предать или блокировать его.
Френк Херберт. "Мессия Дюны"
Френк Херберт. "Мессия Дюны"
Вряд ли нужно объяснять, кто такие хакеры. Компьютерные взломщики, которые никогда не вводят серийный номер и не отсылают регистрационную карточку, а влезая в недра программы, так видоизменяют ее, чтобы она и вовсе никаких вопросов не задавала или воспринимала любой код, как правильный.
Бороться с этим можно только техническими приемами и совершенствованием механизма защиты. Хакеру, чтобы их обойти, необходимо сначала изучить программный код. А поскольку исходных текстов в его распоряжении нет, приходится анализировать программу непосредственно в исполняемом виде, иначе говоря, ассемблере. Для этого нужно не только знать архитектуру и набор команд конкретного микропроцессора, но и обладать незаурядной усидчивостью и скрупулезностью. Ведь одна строка исходного текста программы на языке высокого уровня может компилироваться в десятки и даже сотни машинных инструкций!
А сколько строк в средней программе? Десятки тысяч! И среди них где-то есть и такие, что принадлежат защитному механизму. Попробуй-ка их найти! И ведь находят! Всегда есть люди, имеющие не только голову на плечах, но и уйму свободного времени в придачу.
Обратим внимание читателя, что за редкими исключениями сложность не в нейтрализации защитного механизма, а в поисках его среди мегабайтов постороннего кода. Однако это еще не означает, что в программе, в десятки раз большей, найти ту же защиту во столько же раз труднее.
Хакер всегда стремится ограничить диапазон поиска. Выделять характерные конструкции, присущие защите, и искать их в программе. Например, строка языка высокого уровня
...
If (IsValidIUser(UserPassword,LegalPassword)
...
будет скомпилирована в следующий код:
...
PUSH offset LegalPassword
PUSH offset UserPassword
CALL isValidUser
OR AX,AX
JX xxxxxx
...
Характерной последовательностью станет CALL / OR AX,AX / JX, а в передаваемых функции параметрах практически всегда будут присутствовать пароли: введенный пользователем и оригинальный. Первый злоумышленнику наверняка известен (должен же он был помнить, что набрал на клавиатуре пару минут назад), поэтому не составит труда найти его в памяти машины. С большой вероятностью поблизости от него окажется и оригинальный пароль.
Плохая степень защищенности программ и простота освоения ассемблера 80x86 серии микропроцессоров привели к тому, что на этой платформе пасется очень много хакеров и программы ломаются быстрее, чем доходят до покупателя.
Простота анализа объясняется тем, что язык ассемблера 80x86 имеет высокий уровень, каждая строка выражает законченную мысль, и представление программы довольно компактно.
Совсем иная ситуация с RISC-микропроцессорами. Например, на Apple программ ломают не в пример меньше. Ну не любят хакеры RISC. И ведь есть за что! Машинный язык RISC гораздо ниже уровнем, откомпилированный код содержит иногда вдесятеро больше инструкций, а значит, во столько же раз возрастает необходимое для анализа время. Иными словами, увеличивается число связей между отдельными фрагментами кода и сложность анализа с увеличением размеров кода растет экспоненциально.
При этом характерные конструкции выделить не удается. Следовательно, автоматический поиск, при всей его привлекательности, придется пока отложить на полку. А ручной труд - долог и утомителен. Сколько бы у человека ни имелось в распоряжении свободного времени, есть шансы на то, что "сексу" с отладчиком (или дизассемблером, одним словом, с защитой) он предпочтет покупку легальной версии программы.
Конечно, это не означает, что хакеров на RISC-платформах нет. Просто их гораздо меньше, поскольку анализ машинного кода подобных архитектур требует не только времени, но и определенных математических знаний и опыта работы. А профессионалы, как правило, достаточно заняты, хорошо оплачиваемы и наверняка предпочтут утомительному анализу дешевых программ более интересное и прибыльное занятие.
Параллелизм еще больше усложняет анализ. Традиционно CISC-команды располагаются друг за другом в порядке их исполнения, который определен алгоритмом. В статье "Свет в конце тоннеля" показано, что в параллельных архитектурах такая зависимость часто утеряна. Команды располагаются не в порядке, предусмотренном алгоритмом, а так, чтобы максимально увеличить скорость их выполнения.
В коде, генерируемом новыми оптимизирующими компиляторами, разобраться порой очень непросто. Хотя Pentium может выполнять одновременно только две инструкции! Параллелизм RISC-архитектур значительно выше, а вместе с ним - и сложность понимания того, что происходит в программе.
Особенно выделяются кросс-платформные компиляторы, использующие часть регистров под быстрый кэш данных. В этом случае регистры постоянно перезагружаются малоосмысленными значениями, интенсивно обмениваются содержимым друг с другом, и требуются поистине титанические усилия, чтобы в произвольной точке кода определить, какие данные в каком регистре находятся, откуда и кем получены.
Неудивительно, что на RISC-платформах хакеров так мало: несмотря на слабость защит программного обеспечения и, по сравнению с PC, большую его стоимость, взлом становится нерентабельным.
Сообщение, что Merced будет построен на параллельной RISC-архитектуре, встревожило многих хакеров. Ведь это означает, что если не будет положен конец их существованию (среди хакеров немало действительно талантливых и неординарных личностей), то, во всяком случае, ему будет нанесен серьезный ущерб.
Впрочем, передышка не обещает затянуться: взломщики перейдут в другую стадию своего существования. У хакеров уже существует богатый инструментарий для абстракции от второстепенных деталей. Появление Windows 95 и, вследствие этого, резкое усложнение анализа программного обеспечения (вспомните, какими простыми были программы под MS-DOS всего несколько лет назад) породило всплеск инструментария "высокоуровневого" взлома, многим из которого сегодня пользуются юзеры, никак не причисляющие себя к хакерам.
Переход на RISC-платформы только поначалу вызовет уменьшение числа хакеров. Но в скором будущем с совершенствованием хакерского инструментария круг людей, способных на взлом, начнет расширяться.
Мощности компьютеров возрастут настолько, что все чаще и чаще можно будет прибегать к грубой силе - атаке простым перебором. Даже сегодня производительность процессоров достаточна, чтобы автоматически вскрыть немало защит, пусть за большое, но конечное время.
Когда RISC-платформы станут достаточно распространенными, будут ломать программы и на них. Но эти люди уже не будут хакерами. До конца исчезнет дух общения с машиной, железом, низким уровнем и вообще тем, что в действительности представляет собой компьютер. Мы наблюдаем закат того хакерства, которое зародилось в шестидесятых-семидесятых годах. Компьютер настолько прочно входит в нашу жизнь, что становится бытовым прибором наподобие телевизора или холодильника. Вы можете представить себе поклонника телевизора стандарта PAL/SECAM?
Архитектура для вируса
Пока вирусы можно писать, их будут писать! Разумеется, для этого должна быть определенная продержка со стороны самого компьютера, иначе у злоумышленника ничего не получится. Можно ли вообразить вирус для игровой приставки "Дэнди"? Разумеется, нет. Ибо поражать ему абсолютно нечего: записать что-нибудь в картриджи программно нельзя даже при большом желании.
Выходит, непременным условием существования вирусов является записывающее устройство. Но если оное изъять, то пользователь тоже не сможет сохранять результаты своего труда.
Другим непременным условием является возможность интерпретировать программный код и как данные, и как инструкции. То есть на этапе поражения файла вирус интерпретирует его тело как данные, а затем, при исполнении, - как инструкции. Но это особенность знаменитой фон-неймановской архитектуры, на которой построен персональный компьютер. Возможны архитектуры, где код и данные разделены и не могут быть смешаны. Быть может, в будущем, когда обратная совместимость с кодом для Intel перестанет быть значимой, на нее и перейдут.
Но пока с вирусами приходится бороться другими путями, причем, как правило, со следствием, а не с причиной - вирусописателями.
А что, если сделать так, чтобы писать вирусы было неинтересно? Многие ли тогда продолжат свои занятия? Для какой архитектуры написано больше всего вирусов? - Для Intel 80x86. Для остальных компьютеров вирусы пока не представляют серьезной угрозы. Счастливы их пользователи, даже слово такое, антивирус, не все слышали.
А все потому, что обычно вирусы - продукт творения студентов и школьников, которые изучили ассемблер 80х86 и хотят опробовать свои силы, но не находят им применения достойнее. Догадывались ли они, что простые знания ассемблера окажутся невостребованными и неконкурентоспособными на сегодняшнем рынке программного обеспечения? Наверняка! Не могли не знать! Зачем же тогда изучали ассемблер?
Ответ прост. CISC-ассемблер - это действительно очень интересный и простой язык, доступный для освоения любому неспециалисту. Он позволяет красиво выражать многие идеи и приемы программирования. В нем широкое поле для нестандартных подходов и выражения собственного индивидуализма. Словом, он интересен. Это факт. Что бы ни говорили противники, но раз люди изучают его и программируют, значит, в нем есть то, что зажигает сердца. Ведь почему-то массово никто не рвется программировать на низком уровне PowerPC, скажем. Ну не лежит к ним сердце вирусописателей, и все тут!
Действительно, как отмечалось в трех предыдущих статьях, RISC-архитектура не столь интересна на низком уровне. Она создавалась не для людей, а для компиляторов, и человеку невероятно скучно и трудоемко писать для нее вирусы.
Конечно, вирусы есть. Они пишутся на языках высокого уровня, на макросредствах того же "Ворда" и многих других приложений. Но не в таких количествах, как на PC! И возникают гораздо реже, а не с завидным постоянством по несколько штук в день.
Merced, выполненный по RISC-технологии, рождает надежду, что с его появлением ряды вирусописателей потихоньку будут редеть до той степени, когда с существованием вирусов можно будет смириться, как с неизбежным злом или силами природы, такими как землетрясение, цунами или ураган.
Но не скрыт ли в таком прекрасном с виду будущем невидимый, но от того не менее опасный риф? Ведь по сути, как действуют антивирусы? Разработчик получает копию вируса в свое распоряжение, после чего снимает вирус в "фас" и "профиль" и добавляет эту информацию в базу, после чего периодически отправляет пользователям обновление.
Нет, в оперативности работы нет никакой проблемы. Фирмы реагируют на вирусы моментально. А с появлением Интернета упростилась и обратная связь с пользователем. В идеале сайт разработчиков может обновляться по несколько раз в день.
Сложность в том, что до того момента, пока вирус не будет обнаружен хотя бы одним пользователем и отослан на экспертизу, он может сладко спать в десятках компьютеров. А пробуждение его может оказаться очень болезненным. Ведь если до этого момента его никто не обнаружил и не удалил, может оказаться разрушенной информация на сотнях тысяч жестких дисков!
А как пользователь может обнаружить никак не проявляющий себя вирус? Для этого разработчики и включили в свои продукты такую "вкусность", как "эвристические анализаторы". Иными словами, возможность обнаружить новые, дотоле неизвестные науке вирусы. И, как бы ни был критикуем этот механизм, он все же не так плох и очень часто срабатывает и выручает. Ведь в CISC-архитектурах трудно что-либо скрыть. Любой код (или почти любой) можно найти по характерным для него инструкциям и последовательностям команд. Иными словами, эвристический анализатор наследует идеи, которые впервые применили хакеры в своих автоматических вскрывателях защит.
По сути, нет большой разницы, что искать - тело вируса или защиты. Главное - задать точный критерий, остальное программа сделает самостоятельно. Но это значит, что RISC-архитектуры не позволят сегодняшним антивирусам ловить "насекомых".
Более того, чтобы включить вирус в базу, его надо проанализировать. И здесь вирусописатели получают шанс вырваться вперед. Действительно, их выбор ничем не ограничен. Не нравится ассемблер - можно выбрать любой язык высокого уровня. А вот исследователи вирусов исходных текстов сего творения будут лишены, и им придется заниматься трудоемким дизассемблированием двоичного кода, чтобы потом включить его в поддержку.
Некоторые фирмы в погоне за числом поддерживаемых вирусов просто определяют их уникальные последовательности (сигнатуры), не вникая, как работают конкретные особи. Иногда это сходит им с рук: вирусы действительно успешно обнаруживаются и даже корректно лечатся. Но некоторые "насекомые" способны видоизменять свое тело по прошествии определенного времени. И тогда новый клон окажется невидимым для антивируса.
Поэтому, скрепя сердце, разработчики вынуждены коротать дни и ночи за дизассемблером. Переход на RISC-архитектуру только добавит работы. При этом может возникнуть одна проблема. В RISC набор команд существенно меньше. Следовательно, придется использовать более длинные сигнатуры.
Но на этом пути тоже ждут трудности:
- соседние команды из-за параллелизма архитектуры относятся к различным участкам алгоритма. Следовательно, мысль о непрерывной сигнатуре придется отбросить, несмотря на всю ее привлекательность и простоту технической реализации;
- увеличится число ложных срабатываний, ибо в RISC-ассемблерах инструкции не образуют сколь-нибудь характерных и уникальных последовательностей.
Поэтому трудно сказать, какая архитектура лучше. У каждой есть свои достоинства и недостатки. Выигрывая в одном, мы неизбежно теряем что-то другое. Ведь и появление новых вирусов в большей мере зависит не от архитектуры, а от людей, точнее, их агрессии и враждебности друг к другу.
И, быть может, в чем-то хорошо, что IBM PC позволяет выливать зло написанием вирусов, а не надеванием на руку кастета и поджиданием одинокого прохожего в темном переулке. Ведь уничтоженные данные можно восстановить, испорченную материнскую плату заменить новой. Не такая уж большая плата за ненависть, не так ли?