Библиотека Интернет Индустрии I2R.ru

Зло нельзя определить по запаху
Френк Херберт "Мессия Дюны"

                Первый пик массовой вирусной эпидемии пришелся на некогда популярный компьютер <Эппл>. Наиболее излюбленным объектом атаки в то время оказался загрузочный сектор гибких магнитных дисков.

Очень скоро появилось множество простых утилит, которые проверяли целостность содержимого загрузочного сектора при его запуске, а так же резидентов, которые просто блокировали запись в оный до подтверждения пользователя.

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

Наиболее очевидным выходом из сложившейся ситуации стало использование операционных систем с разграничением доступа, периодическая проверка CRC исполняемых файлов, а так же создание резидентных программ блокирующим запись.

Но исполняемые файлы в отличие от загрузочного сектора, могут активно модифицироваться не только вирусом. Практически ни один ревизор не может работать на компьютере программистов. То есть людей постоянно изменяющих множество исполняемых файлов  Впрочем, программисты по судьбе своей мученики и их мольбам долго никто не внимал.

Сегодня наибольшее распространение получили макро-вирусы. Это укоренившиеся, хотя неправильное название. На самом деле стоило бы их назвать скрит-вирусами, поскольку они написаны  и функционируют на встроенном языке некоторого программного продукта (скрипте).

CorelDraw, PhotoShop, Quake II, Unreal вот далеко не полный перечень пакетов, поддерживающих развитые интерпретируемые (реже компилируемые) языки. Все они обеспечивают возможность функционирования и размножения вирусных и вредоносных программ (закладок и троянцев)

Вот тут-то антивирусная индустрия  получила хороший щелчок. Она оказалась совсем не готова к такому развитию событий. Все средства предупреждения заболевания оказались бессильны. Ведь документ, создаваемый приложением, от записи и модификации не запретишь. То есть запретить-то, конечно, можно, и  технически реализовать элементарно, но только любой пользователь отключит такую защиту - документ на то и документ, что бы с ним  работать, а не смотреть <только на чтение>.

По той же причине все эти вирусы отлично функционируют и на NT и даже на UNIX и Макинтош, поскольку операционной системой для них оказывается само приложение, обрабатывающие скрипты.

Любопытно, что вирусы для Quake и Unreal не детектируются абсолютно ничем. Ни AVP, ни DrWeb о них ничего не знают. Впрочем, это простительно для разработчиков. Сегодня практически каждый уважающий себя программный пакет поддерживает скриты или макрокоманды. Даже при желании уследить за всеми происходящими событиями невозможно. Совсем недавно, буквально в июле этого года появились первые вирусы и троянские дополнения к профессиональному дизассемблеру IDA PRO. В этом не было бы ничего удивительного, если бы средства языка обеспечивали бы поиск файлов для возможного инфицирования. Таковых функций IDA PRO не поддерживала, а значит, и существование вирусов (в традиционном понимании этого слова) было в ней невозможным.

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

На самом деле все вирусы подобного типа очень легко обнаруживаются простым визуальным просмотром скрипта. Достаточно дать себе немного труда проанализировать алгоритм работы последнего, ну и конечно, иметь представление на что обращать внимание в первую очередь.

Прежде всего все вирусы подобного типа можно разделить на две большие категории. Первые манипулируют только документами приложения и остаются исключительно в рамках виртуальной машины интерпретатора скрипта. Вторя же категория может выполнять команды процессора и операционной системы, а значит, не только инфицировать или уничтожать исполняемые файлы, но даже <покрошить> Ваш жесткий диск!

Последние опаснее, а, значит,  интереснее. Вот с их рассмотрения мы и начнем. Самый простой способ вырваться из застенок виртуальной машины это воспользоваться файловым вводом \ выводом.  Допустим, можно записать любую пришедшую нам на ум команду MS-DOS в файл C:\Windows\winstart.bat (ну или autoexec.bat) будучи уверенным, что рано или поздно он будет исполнен.

На языке IDA-Си это может выглядеть так.

auto a;

a=fopen("C:\\WINDOWS\\winstart.bat","wb");

writestr(a,"@ECHO Hello, Hard Disk \n");

fclose(a);

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

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

Вслед за этими появились вирусы, которые использовали низкоуровневые файловые операции для модификации исполняемых файлов. Действительно, что стоит загрузить жертву в память, инфицировать любым возможным алгоритмом и записать вновь на диск?

Таким образом вирус вырвется за пределы виртуальной машины и начтет гулять по диску. Конечно, это окажется нежизнеспособно на Windows NT, при условии правильного подхода к разграничению доступа к ресурсам, но для многих пользователей станет неожиданным сюрпризом, ведь большинство из них полагает, что макро-вирусы существуют только в Ворде и диск отформатировать вряд ли смогут. А отсюда и беспечность.

Беспечность необъяснимая и неоправданная. Ведь большинство интерпретаторов поддерживают команду "Exec" для запуска внешних приложений из скрипта. Злоумышленники могут вызвать 'format.com' поэтому не помешает его запрятать подальше или даже вообще исключить с дисков всех пользователей, через чьи руки проходят сомнительные скрипты и документы.

Необходимо отметить, что реализация exec часто сводится к вызову win32 API функции CreateProcess, другими словами расширение файла не играет никакой роли. MyDocument.doc вполне может быть запущен, не смотря на <неисполняемое> расширение. Следовательно, вирус может создавать внешне легальный файл документа, чем и маскировать свое присутствие. 

Впрочем, все эти <махинации> могут быть обнаружены простым сканированием скрипта на предмет ключевых слов <exec, fopen> и других. Поэтому следующим этапом эволюции было создание шифируюшихся вирусов. На первый взгляд это нереально. Как может расшифровываться интерпретируемый скрипт если он совершенно не имеет представления о физической памяти, в которую он загружен.

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

auto a,b,c,d;

a="ida.";

b=0xCA;

c=b/2;

b=b>>1;

d=b + (b>>5) | (1<<4);

a=a+c+d+b;

Message("%s \n",a);

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

Однако, ключевые команды типа "exec" оставались в открытом виде и обнаруживались тривиальным сканированием файла. Поэтому  вирусописатели предприняли попытку скрыть их от посторонних глаз. IDA PRO, как и большинство других интерпретаторов имела возможность загрузки скриптов с диска. Это дало возможность создать временный файл, в который записать расшифрованное тело вируса, и затем передать ему управление.

Что бы Вы думали делает приведенная ниже программа?

static main()

 {

 auto a,b,temp,s0;

 b=0;

 s0="0x040x030x160x030x1E0x140x570x1A0x160x1E0x19

     0x5F0x5E0x570x0C0x3A0x120x040x040x160x100x12

     0x5F0x550x3F0x120x1B0x1B0x180x5B0x570x3e0x33

     0x360x560x570x2B0x190x550x5E0x4C0x0A0x7A0x7D

     0x00\n";

 a=fopen("temp.idc","wb");

 while(1)

 {

    temp=substr(s0,b,b+4);

    b=b+4;

    temp=xtol(temp);

    if (temp==0) break;

    temp=temp ^ 0x77;

    fputc(temp,a);

 }

 fclose(b);

 Compile("temp.idc");

 }

Да, действительно, она иллюстрирует классический пример шифрованных вирусов. Для упрощения данный пример использует <вирусоопасный> вызов "fopen", но нетрудно оформить его как сохранение документа или генерацию отчета.

Вызов <Compile> к сожалению не может считаться  характерным для вирусов, поскольку он очень часто употребляется мирными программами для подзагрузки своих модулей. Ведь редко кто пишет сколь ни будь серьезные скрипты в одном файле. Поэтому в целом  такие вирусы выглядят на внешний вид безвинно.

Сейчас в Сети много таких дополнений к IDA, даже появились классические <Универсальный Кракер> и <Кракер Интернета PRO>. Впрочем, последний это все же действительно предоставляет бесплатный доступ в Интернет, а не форматирует жесткий диск. Он дозванивается до провайдера по указанному номеру, активно мигая лампочками модема, после чего сообщает, что якобы утащен зашифрованный файл паролей и в подтверждение этого выплевывает нечитабельный текст на экран. Далее сообщается, что расшифровать это может автор скрипта, всего за 1$, а до 1 сентября в рамках рекламной компании и вовсе бесплатно - достаточно только отослать ему это по следующему адресу. И пользователь сам того не подозревая, отправляет не зашифрованный файл паролей провайдера, а свой логин и пароль, <поксоренный> и дополненный мусором, что бы не бросаться в глаза.

Попадаются даже творения выполненные по <стелс> технологии. Вирус перехватывает событие "OnOpen" и "OnLoad" и вручную загружает файл таким образом, что бы он выглядел в незараженном виде. Поэтому просматривать скрпты на предмет поиска вирусов можно только средствами, гарантирующими достоверность отображения и невозможность внедрения постороннего кода.

Обычно это <блокнот> или другой простейший редактор. Это справедливо для IDA PRO, но часто оказывается невозможным для тех приложений, которые скрипты хранят в собственном формате вместе с документом. В таком случае  просмотр внешними средствами оказывается невозможным.

Вслед за <стелс> были написаны и полиморфные вирусы. Для IDA PRO на сегодняшний момент известно два из них и оба функционируют по одному и тому же принципу. Это обычный шифрованный вирус с множеством расшифровщиков. Причем сам алгоритм генерируется <налету>. Они в настоящий момент не определяются ни одним антивирусом. Впрочем, к чести их авторов к скриптам приложен подробный файл описания, что эта программа делает  и перед каждым заражением запрашивается подтверждение пользователя. Но что стоит, удалив всего одну строку, получить <полноценный> современный вирус, которым потом можно заразить множество ничего не подозревающих пользователей, недоумевающих почему разработчики антивирусного обеспечения будучи информированными об этой проблеме продолжают ее спокойно игнорировать, вероятно, полагая, что IDA PRO не настолько распространенный продукт, что бы тратить человеко-часы на анализ и включение в базу этих <насекомых>?

Между тем 8 из 10  известных мне источников IDA PRO заражены теми или иными вирусами. Кстати, никак не проявляющими себя, но написанными достаточно некорректно, что бы приводить к нестабильной работе, сбоям и зависаниям дизассемблера. Не так редки вирусы и под <Visual Studio>, попадающие на компакт-диски, но это уже другая история.

Их проявления и возможности ничем не ограничены, ведь как было показано выше, практически из любой виртуальной машины можно вырваться и передать управление процессора на свой код.

Однако, прием создать файл, а затем его запустить все же несерьезен и на системах с правильно организованной системой разграничения доступа просто не работоспособен. Существуют ли другие пути? Да, существуют. Многие интерпретаторы имеют <лазейки> - недокументированные функции, позволяющие делать то, что мягко выражаясь ни в коем случае не положено.

Например, IDA PRO имеет функции _peek и _poke, читающие и записывающие физическую память компьютера. Следовательно, можно передать управление на свой код! Однако, для этого его сперва нужно скопировать в память, и не на первое попавшиеся место, а обязательно в свободный регион, иначе система рискует повиснуть вместе с вирусом, что будет сигнализировать о ненормальности ситуации (стоит ли говорить, что большинство опытных пользователей присутствие вирусов на своем компьютере замечает именно по конфликтам).

В MS-DOS свободному региону соответствует нулевое значение хозяина блока в заголовке MCB. Но что бы проскандировать всю цепочку необходимо узнать адрес первого блока. Но кто его скажет вирусу? Однако, существуют способы узнать это самостоятельно и ниже будет показан один из них.

Но как теперь передать управление процессору на наш код? Это головоломная на первый взгляд задача  имеет множество решений и одно из них заключается в модификации обработчика клавиатурного прерывания (мы ведь можем писать в память!) таким образом, что бы он указывал на наш код. Рано или поздно пользователь нажмет на  клавишу и вирус получит управление.

static MyGetByte(a)

 {

 return (_peek(a) & 0xFF);

 }

 static MyGetWord(a)

 {

 return  MyGetByte(a)+(MyGetByte(a+1)*0x100);

 }

 static GetNextMCB(a)

 {

 a=a+ (MyGetWord(a+3) <<4) +0x10;

 return a;

 }

 static GoToMCB(a)

 {

 if (_peek(a)!='M') return 0;

  while(1)

  {

   a=GetNextMCB(a);

   if (_peek(a)=='Z') return 1;

   if (_peek(a)!='M') return 0;

  }

 }

 static FindFirstMCB()

 {

  auto a;

  a=0x0;

  while(1)

  if (GoToMCB(++a)) break;

  return a;

 }

 static FindFreeMCB()

 {

  auto a;

  a=FindFirstMCB();

  while(MyGetWord(a+1))

  {

  a=GetNextMCB(a);

  if (MyGetByte(a)=='Z') return 0;

  }

  return a;

 }

 static SaveInt0x16(a)

 {

 auto temp;

 for (temp=0;temp<4;temp++)

 _poke(a+temp,MyGetByte(0x16*4+temp));

 }

 static SetNewInt0x16(a)

 {

  _poke(0x16*4,a);

  a=a>>4;

  a=a & 0xFFF0;

  _poke(0x16*4+1,0);

  _poke(0x16*4+2,a);

  a=a>>8;

  _poke(0x16*4+3,a);

 }

 static CopyEject(a)

 {

  _poke(a,0xCF);

 }

 static SetOldInt0x16(a)

 {

  auto temp;

  for (temp=0;temp<4;temp++)

  _poke(0x16*4+temp,MyGetByte(a+temp));

 }

 static main()

 {

 auto a;

 a=FindFreeMCB();

 if (!a) return;

 Message("Найден свободный блок по адресу %x \n",a);

 if (!AskYN("NO","Сейчас     будет    инфицирован    Ваш  компутер  \n Вы в самом деле хотите это сделать? Подтвердите!"))return;

 if (!AskYN("NO","Подтвердите необходимость инфицирования еще раз!")) return;

 SaveInt0x16(a);

 CopyEject(a+4);

 SetNewInt0x16(a+4);

 AskYN("X","Поздравляем Вас с успешной активацией вируса!");

 SetOldInt0x16(a);

 }

Схематичный пример показан выше. Тело вируса в нем отсутствует, и весь смысл сводится лишь к тому, что бы передать управление процессора на команду возврата из программы 'ret'. Работать это будет исключительно в среде чистой MS-DOS (консольный режим win32 за таковой не считается) и поэтому представляет не более чем познавательный интерес.

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

В IDA функции  _peek и _poke недокументированны, но тем не менее присутствуют и являются ключевой частью ядра для собственных нужд дизассемблера. Можно ли гарантировать, что подобных <лазеек> нет в других пакетах?

Разумеется нет! История не однократно убеждала в том, что незакрытые люки и отладочные функции явление привычное. К тому же большинство из них обнаруживаются элементарным образом. Например, если посмотреть какие функции экспортирует IDA.WLL, то среди них обнаружится не только _peek и _poke, но и даже _call! Таким образом обеспечивая всю необходимую злоумышленнику низкоуровневую работу.

Перейдем теперь ко второй группе - существующей только в рамках одного приложения. За кажущейся внешней безопасностью такие вирусы могут нанести даже более существенный урон, ибо порча исполняемых файлов всегда может быть ликвидирована переустановкой программного обеспечения с дистрибьютивных дисков, то искажение документов пользователя часто оказывается необратимым.

Рассмотрим типичную ситуацию - пишет человек книгу, которую периодически резервирует на внешний носитель (дискету, скажем). При этом, разумеется,  новая копия затирает предыдущую. Если в  этот момент целостность сохраняемого документа была нарушена то восстановление окажется невозможным (ведь оригинал затерт). Что стоит вирусу в огромном документе стереть несколько фрагментов или исказить их? Маловероятно, что пользователь на это сразу обратит внимание. А когда обратит, то скорее всего будет уже поздно и потребуется тщательно перечитать весь текст, проводя утомительную работу по его восстановлению. То же можно отнести и к электронным таблицам, например. Или текстам программ (на платформах Visual Studio, IDA и т.д.)

Проблема в невозможности отличить действия пользователя от действий вируса. Макрос оболочки FAR, удаляющий все файлы без подтверждения  будет работать и защищенных операционных системах, наследуя права пользователя, и в отличие от <обычных> вирусов он не вызовет подозрений при установке. Да и антивирусы его не заметят. Ну никто не собирается поддерживать все программные пакеты, включая такие незначительные как FAR.

Итак, макрокоманды. Записанные последовательности нажатий или сочетаний клавиш, которые могут впоследствии выполняться автоматически. Это настолько удобно, что сегодня поддерживается практически всеми пакетами. Отказываться от этой возможности бессмысленно, но необходимо по крайней мере обеспечить такой уровень безопасности, что бы вирус не мог создавать и назначать горячие клавиши макросам самостоятельно.

К сожалению в жизни макросы настолько тесно связаны с интегрируемым языком, что последний называют макроязыком, чаще чем скриптами. Вирусу ничего не стоит, скажем, на клавишу Insert <подцепить> последовательность в стиле <Выделить все>, <удалить>, <записать>. После чего пользователю остается только рвать на себе волосы.

В IDA нет подобных функций и никакого программного управления макросами там нет. Все они должны быть непосредственно заданы в файле idatui.cfg или введены с клавиатуры. Однако, это ограничение для вирусов <прозрачно>. Они открывают нужный файл, записывают в него вредоносный макрос и:

Другие пакеты имеют схожие проблемы с безопасностью. Некоторые из них, как например FAR, хранят макросы в реестре. Вирус может либо импортировать новую запись в реестр, либо воспользоваться функциями API для его модификации. И то  и то современные приложения обычно предоставляют скриптам в свое распоряжение.

Кроме того, существует такое понятие, как эмуляция ввода. Для этого достаточно послать окну соответствующую серию сообщений. Причем никто не запрещает выходить за пределы родительского окна и посылать сообщения любому на свой выбор. Для этого достаточно воспользоваться функцией Win32 API FindWindow.

Чаще всего предметом атак становиться эксплодер или проводник Windows. Вирус может использовать его для размножения и внедрения в другие объекты, а так же для всевозможных <шуток> типа трясущихся или <убегающих от курсора> окон.

Заявление, что такое возможно из языка IDA вызвало большой скепсис среди разработчиков антивирусов. Действительно, ее язык не поддерживает функции win32 API и никак не представляет такой возможности. На само же деле это возможно. Возможно благодаря функции _CALL, которая передает управление по указанному физическому адресу. Впрочем, задача вычисления адресов требуемых функций, и передача параметров (call никаких параметров не принимает и не возвращает) достаточно нетривиальна и интересна сама по себе. Не вникая в подробности технической реализации, оптимальное решение заключается в поиске свободного фрагмента памяти (а под win32 это уже весьма нетривиальная задача и для ее решения необходимо быть осведомленным во многих тонкостях организации памяти) и копировании в него простейшего менеджера, обеспечивающего обмен параметрами и вычисления необходимого адреса процедуры. Разумеется, что ничего не остается, кроме как воспользоваться GetProcAddress. Весь фокус в том <волшебном> способе получения адреса этой функции. Зная его ничего не стоит вызывать из IDA все богатство функций win32 API. В этом случае возможности вируса будут ограничиваться лишь злобностью или фантазией злоумышленника.

Все описанные выше вирусы можно назвать неризедентыми, поскольку они активны только в момент запуска макроса или скрипта. Однако, существуют и такие, что остаются в течении всего сеанса работы.

Что бы получать управление вирусу приходится перехватывать одно из многочисленных событий, таких, например, открытие файла или документа, начало и завершения сеанса работы. По аналогии с древними <досовскими> вирусами это можно назвать перехватом прерываний. Хотя в данном случае рассматриваются уже не прерывания, но с точки зрения вируса нет существенной разницы, да и обработка их осуществляется аналогично.

Отметим, что только резидентные вирусы способны стелсироваться. Для этого они должны грузиться по возможности раньше остальных программ. В IDA файл IDA.IDC автоматически выполняется каждый раз при запуске. Очень часто он становиться объектом атаки вирусов. К счастью он состоит не многим более десятка строк и любые посторонние включения нетрудно заметить. Впрочем, это не характерно для других приложений. Часто число строк в стартовых файлах (то есть файлах инициализации) очень велико и их нельзя отключить без  ущерба для работы системы. Чем больше файл, тем легче затеряться в нем вирусу. Особенно, если приложение не озабоченно проверкой целостности своего хозяйства.

Стоить отдать должное тем разработчикам, которые из соображений политики безопасности хотя бы предоставляют возможность отключения обработки макросов, скриптов и событий. Word на самом деле не относиться к их числу. Генерация событий не отключается.  Блокируется лишь выполнение макросов. При этом существует достаточно много способов перехватить управление на себя (ведь события все продолжают генерироваться и обрабатываться!) То что пока нет известных вирусов, реализующих такие идеи, еще не повод беспечно считать, что их не будет в и дальнейшем.

Впрочем, разработчикам антивирусов вероятно это известно, более того даже имеют готовые модули для интеграции в свой продукт, но не делают этого. Почему? Не хотят вирусописателям дарить лишние идеи. Ждут пока те до этого додумаются сами. Это по официальным данным.

А по неофициальным - просто дают понять значимость новых версий и необходимость технической поддержки. Какая разница догадаются вирусописатели до новой идеи сегодня или через день. А вот пользователь страдает. Его любимый антивирус не защищает от новых насекомых, а ведь мог бы:.

В этот отношении IDA аналогична. Файл 'OnLoad.idc' выполняется при любой загрузке анализируемых файлов в дизассемблер. Следовательно, вирус может это перехватить и представить файл как незараженный.

Такие вирусы действительно существуют. Они поражают PE файлы windows и отличаются от <обычных> только тем, что так модифицируют 'OnLoad.idc', что с IDA неправильно дизассемблирует зараженные файлы, следовательно и результаты анализа окажутся неверны. Конечно, трудно поверить, что разработчики и исследователи вирусов могу  допустить такое на своем компьютере. Но где гарантия что беспечность не сыграет своей злой роли, так что на это просто не обратят внимание? Тем более, что IDA широко используется для анализа вирусов и противодействие ей это достаточно эффективный способ затруднить анализ.

Отсюда же возможно внедрение вируса во все дизассемблируемые файлы. Дело в том, что IDA лишь однократно загружает файл в свою базу, а потом к нему уже никогда не обращается. Неплохая мысль после окончания загрузки его инфицировать. Если до этого момента файл был здоров, что и подтвердит дизассемблирование, то никто не поинтересуется дальнейшей судьбой этого файла.

Такое случилось в одной организации, когда уважаемая фирма подрядилось провести в оной тщательный поиск вирусов и закладок. Юный хакер в это время сумел добраться по локальной сети организации и модифицировать файл 'OnLoad.idc' (а поиск <насекомых> проводился, разумеется, с помощью IDA). В результате ни одна закладка обнаружена не была, да еще  и оказались добавлены новые.

Нельзя назвать мастером того, кто досконально не знает своего инструмента. Его сильных и слабых сторон. К сожалению, сегодня программные пакеты настолько сложны и велики, что просто не реально полностью изучить их до появления новой кардинально переработанной версии.

Следовательно, даже специалисты не застрахованы от атак злоумышленников. И это случается на порядок чаще, чем того можно было предполагать. Ведь не все <специалисты> профессионалы. Это такие же люди с присущими им слабостями и беспечностью.

Только беспечностью объясняться вера в непогрешимость IDA. На самом же деле она, как и любой другой программный пакет может быть заражена вирусами без ведома пользователя. И если разработчики антивирусного обеспечения не изменят своего отношения к ситуации в ближайшем времени, то вирусописатели могут склониться в сторону вирусов-скриптов для узкоспециализированных продуктов.

В этом случае нарушиться оперативность пополнения антивирусных баз и эпидемия рискует охватить большое число пользователей и принести огромный убыток множеству фирм. Ведь наработки профессионала стоят значительно дороже, чем множество игрушек на компьютере <общего назначения>.

К тому же если программы сегодня практически уже не копируют друг у друга,  а приобретают лицензионный  диск (без шуток - мы говорим о высокооплачиваемых профессионалах!) или идут непосредственно на сайт разработчика, то документы все интенсивно копируют друг и друга!

И этому воспрепятствовать никак нельзя! Сейчас стандартом для распространения документов стал формат Word, электронных таблиц - Exel: неудивительно, что распространение макровирусов приняло характер эпидемии.

Выходом является передача данных в <чистом> виде без макросов и любых автоматически исполняемых модулей. Например, Word поддерживает RTF формат, в котором распространение вирусов невозможно.

Однако, необходимо убедиться, что это именно RTF, поскольку активный вирус может перехватить управление и сохранить файл как документ ворд с макросами, но с расширением 'rft'. Word проигнорирует несоответствие расширения с внутренним содержанием и вирус продолжит свое существование.

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

Браузеры так же поддерживают скриты Бацика и Java, не считая остальных команд появившихся в результате интеграции с операционной системой. Для них могут использоваться многие приведенные выше приемы прорыва за пределы виртуальной машины.  И ведь Интернет и HTML вирусы уже существуют не первый день и наблюдают активное пополнение в своем полку.

Антивирусные средства не могут быть эффективными против них. Можно охватить одно-два-три распространенных приложения, но сколько при этом останутся за кадром, где вирусы смогут бесконтрольно плодится и делать все что им вздумается?

Решение проблемы заключается не в совершенствовании антивирусов, а в усилении безопасности со стороны разработчиков программных пакетов. Прежде всего необходимо раздельно сохранять макросы и содержимое документов. Причем макросы должны записываться в обычный текстовой файл, изучить которой можно средствами гарантирующими неискаженное отображение содержимого. Виртуальность интерпретаторов необходимо усилить и в первую очередь вирутализировать файловый ввод \ вывод или вообще отказаться от него перейдя к концепции синхронных и асинхронных потоков. Очень заманчиво воспользоваться появившимся в Windows 95 пространством имен. Суть его заключается в том, что приложения оперируют не с физическими файлами, а с объектами OLE. Грубо говоря можно сделать так, что при перезаписи файла потребуется разрешение от самого файла!

Но даже такие меры не позволят полностью искоренить вирусы, а только затормозить их развитие и немного обезопасить пользователя. Как бы ни совершенствовались системы защиты, всегда найдутся способы их обойти. Даже в тех случаях, когда это будет невозможно. Существуют же <психологические> вирусы. Да, на полном серьезен без шуток. Такие вирусы есть. Правда летальных исходов не было, но кто гарантирует, что для некоторых людей со слабым сердцем вирус окажется безвреден?

Разумеется, речь идет о так называемых <письмах> счастья и прочей подобной чепухе, посящей разослать себя по многочисленным адресами. И ведь рассылают. И не только рассылают! Еще форматируют жесткие диски и хватаются за сердце при сообщении <все ваши файлы заражены>.

Злоумышленники часто пишут от чужого имени и предлагают выполнить команды в стиле <deltree> для удаления вируса с диска. Защититься от них практически невозможно. В IDA некоторые <насекомые> распространяются через человека, то есть сообщают какие операции стоит ему выполнить, что бы скрип заработал. Разумеется, что в ряде случаев эти требования выполняются даже высокопрофессиональными специалистами!

Что же тогда говорить о простых пользователях? В одной электронной библиотеке долгое время лежат файл в формате Word, при загрузке которого появлялось сообщение, что для его чтения нужно использовать другую версию программы или сделать такие то действия. Как нетрудно догадаться, если пользователь не был сильно продвинут в компьютерах, то скоро вирус оказывался на его жестком диске, вопреки всем системам безопасности. Вирус же сам просил пользователя совершить завуалированную последовательность действий, приводящую к их отключению.

А потому, разработчики антивирусов в равной мере должны защищаться как от вирусов, так и от самих пользователей. Впрочем, от последних даже сильнее. Необходимо по крайней мере использовать не отключаемую защиту и ни в коем случае не доверять пользователю полного контроля над системой.

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

                Вся беда заключается в том, что сложность программного обеспечения с каждым днем все растет, а вместе с ней  и время необходимое для полного изучения. Если с интерфейсом кое-как методом проб и ошибок все же разбираются, то возможности интегрированных языков часто остаются <за кадром>.

                Известный редактор Мульти-Едит написан полностью на собственном языке  и  его возможности поистине безграничны. При этом редко кто хотя бы в общих чертах представляет себе, что это такое и какая опасность может грозить.

                А плагины? Идея возможности наращивания функциональных возможностей приложения за счет подключения внешних модулей завоевала сердца всех разработчиков. Последние версии IDA так же поддерживают ее.

                Парадоксально, что мало кто задумывается, что раз плагины содержат <голый> исполняемый код, то вирусы могут великолепно избирать их объектами для атаки. Или любой плагин может содержат закладку или троянский компонент.

                Но вот только на вирусы их не поверяют. А впрочем, какие антивирусы это поддерживают? Десятки ни с чем не совместимых форматов не вызывают энтузиазма у разработчиков. А напрасно.

                Широко известны случаи распространения вирусов через дополнения к самим антивирусам! Злоумышленнику не надо даже модифицировать файл, вызывая протест со стороны мониторов и дисковых ревизоров. Достаточно только скопировать его в нужный каталог или попросить об этом пользователя.

                Что будет дальше? Это зависит только от фантазии и агрессивности злоумышленника. Технически противостоять ситуации антивирусная индустрия не в силах. Так закончится ли когда-нибудь это смутное время вирусных атак и эпидемий? Ведь победило же человечество чуму, холеру: сейчас борется со СПИДом.

                Чем же сложнее победить человеческие творения? Дело в том, что СПИД он один, а человечества очень много миллиардов. Как бы он ни мутировал и не изворачивался - победить его вопрос времени.

                А компьютерные вирусы пишутся не один, а многими тысячами людей и еще больше хотя их писать, но в меру своих умственных способностей не могут. Вот так и рождаются все многочисленные троянские программы, банально форматирующие диск.

                Специалистов по антивирусам гораздо меньше и они просто не в силах контролировать ситуацию, разрываясь между желанием раскрутить юзера на бабки, обеспечить себя работой на будущее ну и спасти человечество от эпидемии. Покупали бы люди их продукцию если бы постоянно ни слышали леденящие душу истории об очередной распространяющейся со скоростью лесного пожара, заразе?

                Пока эта ситуация не измениться вирусы продолжат свое существование. Ведь мы страдаем не от программного кода, а от агрессии человеческой. Победить вирусов, это значит победить злобу на Земле. Но наступит ли такой момент, что ближний ближнему своему не возжелает зла? Ведь компьютер (вирус то есть)  это просто инструмент. Точно такой как нож, кастет, пистолет.

                Бессмысленно сражаться с вирусами. Бесполезно сажать и наказывать их авторов. Агрессия только умножает агрессию. Необходимо смотреть глубже и устранять те корни, от которых и идет желание причинить другому вред. Вирусы, как выход агрессии не самых худший вариант. Компьютерный террор оставляет после себя обратимые разрушения. Ведь все уничтоженные данные всего можно восстановить (ну пусть с большими или меньшими трудозатратами), а вот когда жертвами становятся живые люди, то оживить их даже усилиями всего человечества невозможно.

                Но это уже не имеет отношения к компьютерам. А что антивирусы? Они должны оберегать пользователя от ошибки или неверного шага. Только тогда называться они уже будут <антиюзеры>. А что? Ведь пользователь свой главный враг. Никакой вирус не оживет, пока его не запустит человеческая рука не осведомленного в тонкостях программирования пользователя.