На чем написан антивирус касперского

Антивирус Касперского

Информация

Разработано	Лаборатория Касперского
Первая версия	1997 г.
Последняя версия	2018 (19.0.0.1088 (г)) ( 30 ноября 2018 г. )
Написано в	C ++ и Nemerle ( в )
Операционная система	Microsoft Windows и кроссплатформенность
Среда	Windows , Linux , Macintosh
Форматы чтения	Базы сигнатур Антивируса Касперского ( г )
Языки	Многоязычный
Тип	Антивирус и антишпионское ПО
Лицензия	Проприетарное программное обеспечение
Веб-сайт	kaspersky.com

Антивирус Касперского (KAV) (ранее AntiViral Toolkit Pro или AVP) — это антивирус, созданный российской компанией « Лаборатория Касперского» . Последний также делает доступной на своем сайте онлайн-систему поиска вирусов. Исходный код Антивируса Касперского незаконно распространялся в Интернете в 2008 году, программное обеспечение его версии 8 написано на C ++ и Delphi .

Резюме

Презентация

Kaspersky — это антивирус с классическими функциями защиты, такими как:

• Место хранения
• Анализ электронной почты
• Эвристический анализ
• Сканирование сжатых файлов
• Защита от шпионского ПО , вирусов , других червей и троянов .
• Проактивная защита , в частности предотвращение установки руткитов .
• Возможность запускать приложения в виртуальном режиме.

Kaspersky предлагает лицензии от 1 до 3 лет.

Награды

По данным AV-Comparative, Антивирус Касперского входит в число лучших антивирусных сканеров с точки зрения обнаружения, несмотря на то, что антивирус не прошел два теста, проведенных в 2007 и 2008 годах журналом Virus Bulletin . Кроме того, PC World наградил этот антивирус в версии 6 наградой «Выбор редакции» в 2007 году. Наконец, Ars Technica считает Kaspersky Antivirus одним из лучших программ безопасности для платформ Windows .

Kaspersky был протестирован PassMark в 2008 году.

Пределы

В этом выпуске отсутствуют некоторые параметры, такие как: персональный брандмауэр , AntiSpam, AntiBanner и родительский контроль. Эти инструменты доступны в Kaspersky Internet Security.

Kaspersky, как и большинство его конкурентов, несовместим с другими антивирусами и антишпионскими программами.

Macintosh

В 2009 году выпуск Kaspersky Antivirus был доступен для Mac OS X платформы . Тесты пришли к выводу, что антивирус потребляет всего 1% ЦП . Эта редакция содержит сигнатуры для блокировки вирусов, предназначенных для платформ Windows и Linux .

Источник

Прага-1998: история прорывной технологии.

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

В чём секрет успеха компании?

Этот вопрос мне задают периодически, регулярно и в разных вариациях. Простого ответа на него, конечно же, нет и быть не может. Формула «как сделать максимально много и чтобы получилось хорошо» — она не бывает простой. Ну, наверное, за исключением мега-выигрыша в лотерею или внезапно свалившегося миллионного наследства. Но это не мой случай. У нас успех сложился из многих факторов, в основном – технологических. И сейчас я расскажу про одну из самых основных/базовых технологий, которая помогает нам уже много лет создавать прорывные продукты самых разных категорий, которые при этом гарантируют высочайший уровень защиты от всевозможных кибер-вредоносных угроз.

Краткое изложение последующих рассказов =>

Эта технология называется «Прага».

Почему так? – очень просто.

Она была придумана в городе Прага, где мы однажды весной 1998-го года собрались небольшой компанией попить пива и поесть чешских вкусностей подумать о перспективной архитектуре наших будущих продуктов. «Пражские посиделки» оказались чрезвычайно успешными — в результате была синтезирована новая компонентная технология, которая до сих пор продолжает эволюционировать и является «скелетом» практически всех наших продуктов. Более того, на эту «Единую Компонентную Архитектуру» (кратко «ЕКА») поглядывают и другие компании, которые столкнулись с проблемой «разноязыких» проектов и разработок, а такое случается частенько – особенно когда на сложном проекте работают независимые (или частично независимые) команды, а иногда даже компании. Или же они сливаются вместе в результате поглощений.

Если кратко, то «Единая Компонентная Архитектура», связывающая воедино самые разнообразные продукты на всевозможных платформах (операционках) выросла из относительно небольшого технологического проекта «Прага». О чём я сейчас и расскажу подробнее.

Итак, в этом году исполняется двадцать лет нашим «пражским посиделкам». Я понял это, разбирая архивы и наткнувшись на документ, озаглавленный Prague Technology Documentation и датированный двадцать вторым июня 1998 года. Как раз тогда мы задумались, как бороться с «инновационным» вирьём и решить некоторые чисто технические проблемы антивирусного движка. Однако найденный ответ оказался сильно шире, мощнее и полезней. Поэтому «Прага» во многом определила технологическое ядро наших продуктов на добрые десять лет вперёд.

С чего всё началось?

Компания была где-то посередине между этапами «гаража» — в нашем случае – второго этажа детского сада (да-да, мы в начале 1990-х снимали комнату в одном из детских садов(!) в московском районе Строгино) и стеклянного офиса. Мы успешно лицензировали наш движок ряду иностранных партнёров, на рынок уже вышла крайне удачная версия Antiviral Toolkit Pro 3.0, но технологическое будущее не было безоблачно. Две основные вещи, которые явно требовались и сулили большие трудности в воплощении – это обработка подозрительных объектов вне зависимости от места их хранения (типичный пример – «матрёшка» из вложенных объектов, то есть исполняемый файл малвары внутри архива, запакованного в другой архив), а также создание антивирусного движка, который максимально быстро обновлялся и требовал минимальных (в идеале – нулевых) изменений для портирования между платформами.

Если кто забыл, вирмейкеры образца конца девяностых были крайне изобретательны, поэтому для некоторых принципиально новых вирусов требовалось не просто обновление баз, а обновление именно самого движка. Интернет у пользователей при этом был либо никакой, либо очень медленный, так что доставить обновление весом в пару мегабайт было нешуточной проблемой. Учитывая, что Windows 98 только-только начала триумфальное шествие по планете, но отнюдь не вытеснила DOS целиком, все новшества в детекте должны были мгновенно работать и там, и там.

В общем, было над чем подумать, поэтому тёплая компания из Алексея Де-Мондерика, Андрея Крюкова, Андрея Никишина, Вадима Богданова, Ларисы Груздевой и меня десантировалась на неделю в Прагу-7 для мозгоштурма. Мы сняли конференц-зальчик в отеле и каждый день где-то с 9 до 5 рисовали и обсуждали, а затем перемещались в ресторан и бильярдную, чтобы продегустировать чешское пиво и «положить пузо на сукно».

Поработали продуктивно, и уехали оттуда с готовой концепцией. Де-Мондерик положил мысли на бумагу, с которой и начался этот блогпост. Вот она:

Крюков и Никишин продолжили обсуждать «Прагу», но по-настоящему активно её создание пошло уже в 1999 году, когда к этой команде присоединился Андрей Духвалов.

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

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

Первую версию, готовую к использованию в продукте, Духвалов создал для AVP 4.0. Там на «Праге» ещё не было переписано всё и вся, но уже проявились сильные стороны архитектуры:

• полностью решена проблема обработки сложных вложенных объектов. Антивирус на «пражском» движке был первым на рынке, кто легко лечил зараженные файлы внутри архивов, например, или детектировал вирусы на границе томов многотомного архива. Причем модулю детекта и лечения без разницы, где там зараженный объект был изначально – в каком архиве, на какой файловой системе, и так далее;
• логика антивирусного движка легко обновляется с базами, причём для принятия новой логики не требуется перезапуск;
• модули крошечные и легко адаптируемые к разным платформам. Благодаря этому шестую версию KAV, например, легко перенесли на Mac;
• всё работает очень быстро и требует минимум памяти; «Прага» потребляла на порядок меньше ресурсов чем все существующие объектные фреймворки того времени.

Благодаря использованию «Праги» мы оказались на переднем краю IT-индустрии, поскольку модульный подход к разработке тогда был не столь развит, а у нас он получил очень эффективное воплощение. Мы потом даже получили на «Прагу» четыре американских патента – 7386885, 7730535, 7418710, 8234656.

Более того, «Прага» интегрировалась с кодом, написанным на иных принципах. Именно поэтому изначально её встроили в версию 4.0, но только для решения узкого круга задач. Там она показала себя настолько хорошо, что когда с разработкой версии 5.0 «по науке» вышли существенные проблемы, у Духвалова возникла мысль «а давай-ка сделаем новую версию целиком на «Праге». Из этой мысли и выросла революционная Шестёрка, история создания которой уже очень подробно описана.

Для того, чтобы вырастить из «антивирусного плагина» фреймворк для создания целого продукта, некоторые подходы пришлось обобщить и переосмыслить. Основной движущей силой здесь были Андрей Духвалов и Павел Межуев, без которых «Прага» не была бы пригодна для таких сложных задач.

Конечно, в мире разработки нет ничего идеального, и у «Праги» были два больших недостатка.

Во-первых, сложности в отладке. Во-вторых, сложность вхождения. Как ни крути, это – объектная система собственной разработки, накладывающая достаточно строгие требования на идеологию написания кода, да ещё писать модули поначалу нужно было на чистом Си. В общем, даже в 2002 году на собеседованиях программисты впадали в уныние от такой перспективы 🙂 Быстро обучать людей было трудно, а разработчиков требовалось все больше. Ведь компания росла, продукты становились сложнее, нужно было запускать их на экзотических аппаратных платформах.

Поэтому, как и везде в IT-индустрии, в приоритет вышли технологичность и скорость разработки, и постепенно пришлось переходить на более известные и стандартные объектные фреймворки. Тем не менее, небольшие фрагменты на «Праге» успешно трудятся в наших продуктах до сих пор.

На самом деле, конечно, эти недостатки были чисто процессно-ресурсного характера. Их можно и нужно было устранить, поскольку преимущества внедрения «Праги» сильно перевешивали и сполна оправдывали затраченные ресурсы. «Прага» решала одну из сложнейших (и затратнейших) задач, которая стала особенно актуальной в последнее десятилетие — переносимость технологии (включая бинарную переносимость) на различные платформы. Вместо того, чтобы создавать продукт заново и с нуля на каждую операционку и процессор мы использовали готовый отлаженный движок. Эта долгосрочная R&D инвестиция (включая конференц-зал и пиво 🙂 не только сполна окупилась, но до сих обеспечивает наше технологическое лидерство — «Единая Компонентная Архитектура» (как эволюционный преемник «Праги») используется в полный рост и мы пока не видим задач, которые она не могла бы решить. Это ещё раз доказывает, что хорошая архитектура может выдержать испытание десятилетиями. (Ну, за архитектуру! 🙂

Как любит говорить Граф (в миру – Алексей Де-Мондерик), очень важную роль «Прага» сыграла и совсем не в технологической плоскости. Вокруг неё естественным образом сформировалась группа вовлечённых людей, энтузиастов с горящими глазами, из которых впоследствии и выросла команда знаменитой «Шестёрки». Ну, за команду!

И за вот такой немного неожиданный юбилей нашей главной и очень прорывной технологии!

Источник

Защита Касперского. Кто и как делает самые известные секьюрити-продукты

Содержание статьи

Сегодня мы попытаемся заглянуть «под капот» популярнейшего в наших (и не только наших) краях антивирусного продукта — Kaspersky Internet Security для всех устройств. Мы попробуем разобраться, как организована разработка, какие решения и компоненты используются, а также расскажем, как попасть в команду «Лаборатории Касперского». А поделятся с нами всеми этими секретами сразу три руководителя отделов разработки — под Windows, Mac и Android соответственно.

К нашим экспертам вопросов было много, поэтому мы разбили их на тематические блоки.

Блок 1. Принцип работы антивируса

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

Комментирует Андрей Рубин:

В антивирусе для macOS (а с этого года Apple решили поменять название своей операционной системы именно на такое, чтобы оно перекликалось с iOS, watchOS и прочими tvOS) используются ровно те же компоненты и технологии защиты компьютера от зловредов, что и у «старшего брата» — антивируса для Windows. Это сканирование, постоянная защита, проверка сетевого трафика и так далее. Конечно, несмотря на то что сами компоненты защиты ровно те же самые, что у Windows, и собираются из ровно тех же исходников, у антивируса для Mac есть свои специфичные поставщики данных и событий, которые внедрены в систему и, собственно, обеспечивают компоненты защиты работой: драйверы, или, как их тут называют, «кексты» (сокращение от KErnel EXTension) для файлового и сетевого перехвата, расширения браузеров для перехвата URL’ов и содержимого страниц.

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

Рис. 1. Московский офис «Лаборатории Касперского»

Есть ли необходимость в антивирусе для macOS? Насколько часто macOS инфицируется? Ведь Mac ближе к UNIX, следовательно, если нет root-прав, то особо ничего и не сделаешь.

Да, вредоносного ПО для macOS, прямо скажем, не так много, как для Windows или Android. Хотя последние несколько лет количество вредоносного ПО для платформы macOS неуклонно росло. Так, только за 2015 год, по данным «Лаборатории Касперского», было зафиксировано почти шесть миллионов уникальных атак на Mac-девайсы. Всего же за время изучения вредоносного ПО для Mac компания обнаружила более 24 тысяч образцов разных зловредов для этой платформы, причем интенсивный рост наблюдается недавно — всего с 2014 года (рис. 2).

Рис. 2. Количество вредоносных файлов для OS X

Но тут дело скорее в рыночной доле, или, другими словами, в количестве пользователей, которое у macOS сильно меньше, чем у Windows или Android. В этом смысле macOS напоминает того неуловимого Джо из анекдота, который никому особо не нужен. А что касается защиты — macOS не так уж принципиально отличается от остальных систем, будь то Windows, Android или UNIX (который еще более неуловимый Джо, чем macOS). Исключение составляет iOS, где операционка запрещает установку и запуск программ из сторонних источников. Если же этого не запрещать, то система в принципе не может быть на 100% безопасна: защита операционки будет работать ровно до тех пор, пока проблема не возникнет в прокладке между стулом и клавиатурой, то есть пользователе. А пользователя можно обмануть, «социально заинжинирить» и так далее. Тем более что пользователи Mac настолько уверены в своей неуязвимости (ибо так завещал Стив Джобс), что зачастую не соблюдают элементарных правил компьютерной гигиены, которые у пользователей Windows уже сидят в генетической памяти поколений.

Но дело даже не в пользователях. Всегда есть и будут «зеродэи» (уязвимости нулевого дня) — такие уязвимости в программном коде операционной системы или широко распространенных программ, про которые знают «плохие парни» и еще не знают «хорошие парни». А через эти уязвимости компьютер можно заразить и без участия пользователя. И Apple тут находится, по моему мнению, позади Microsoft, которая ест эти уязвимости пачками все последние двадцать лет и на самом деле уже научилась и безопасно разрабатывать, и быстро реагировать на обнаруженные уязвимости. Apple, при всем уважении, находится если не в начале, то по крайней мере в середине этого большого пути, хотя их крестовый поход против джавы и флеша, как самых дырявых компонентов на операционке, заслуживает похвалы. Но живой пример: мы обнаружили remote DoS (под названием Darwin Nuke) в одной из последних операционок, и фикс вышел только через несколько месяцев после обнаружения. А все эти месяцы любого пользователя Mac и iPhone можно было нюкнуть одним пакетом (конечно, если только у него не стоял Kaspersky Internet Security для Mac).

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

Нужен ли антивирус на Android-устройстве, если root-права не были получены?

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

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

Что касается необходимости в антивирусе на Android: на данный момент «Лаборатории Касперского» известно более двадцати миллионов уникальных вредоносных пакетов под Android, на фоне таких масштабов необходимость в антивирусе у большинства пользователей не вызывает никаких сомнений.

Представим, что есть типичный пользователь Android-устройства. Телефон без root-прав, приложения устанавливаются только с Play Market. Какие угрозы меня поджидают и как мне может помочь ваш продукт?

Во-первых, Google Play не является гарантированно чистым источником, вредоносные программы есть и там. Во-вторых, зловреды могут попадать на устройство и в обход Google Play без ведома владельца устройства с использованием специальных уязвимостей в Android OS, например при серфинге в интернете или при подключении телефона к компьютеру.

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

Kaspersky Internet Security для Android относится к классу комплексных решений для защиты пользователя и позволяет обеспечить всестороннюю безопасность пользователя и его данных.

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

Какие типы вирусов преобладают для macOS?

Комментирует Андрей Рубин:

Конечно же, трояны. Как я уже сказал, пользователи Mac крайне доверчивы, особенно если картинки красивые и тексты написаны без ошибок и сулят всякое.

Но есть еще один вид угроз, который важен в контексте защиты Мака. Дело в том, что поскольку компьютеры Mac — это все-таки премиальный сегмент, то часто пользователи Мака — люди не простые, или даже наоборот: большинство таких людей, скорее всего, пользователи Мака. Это бизнесмены, топ-менеджеры, знаменитости. То есть самые вероятные цели для так называемых таргетированных атак. Например, несколько лет назад целью такой атаки был далай-лама, который как раз и пользуется Маком.

Хочется прояснить некоторые детали относительно антивирусных баз.

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

Конечно, существует целая антивирусная лаборатория, сотрудники которой день и ночь «долбят», как дятлы, вредоносный код и постоянно обновляют антивирусную базу. А другой отдел тестирует эту базу со всеми когда-либо вышедшими продуктами «Лаборатории», чтобы убедиться, что все решения у всех пользователей будут работать с этими базами как часы. И конечно же, вручную и то и другое сделать уже невозможно, поэтому вкалывают роботы, а не человек. И если тестирование автоматизируется понятным образом (чего там, берешь и автоматизируешь), то вот автоматизация анализа — это, конечно, экстремально сложно, и тут надо быть на острие прогресса и в вопросах машинного обучения, и в вопросах облачных технологий.

Блок 2. Процесс разработки

Переходим к не менее интересному блоку, в котором будут раскрыты тайны разработки KIS: что и на каком языке пишется, какая IDE и какие средства отладки используются, какие применяются сторонние библиотеки.

Рис. 3. Процесс разработки: вид сверху

Какие компоненты и на чем пишутся? Используется ли один язык программирования для всех компонентов антивируса?

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

С другой стороны, так как мы пишем под macOS, то мы вынуждены использовать Objective-C, потому что весь пользовательский интерфейс под macOS (и iOS) пишется исключительно на API, который доступен только на этом языке. На наше счастье, Objective-C интероперабелен с C++ (они могут вызывать друг друга как в одну, так и в другую сторону). В результате все нутро продукта пишется на C++, а пользовательский интерфейс — на Objective-C.

К сожалению, новомодное изобретение Apple под названием Swift, при всей его красивости по сравнению с Objective-C (который, конечно, объективно страшен), не обладает таким важным качеством, как интероперабельность с C++, поэтому применение Swift ограничено. Если вспомнить шаблон проектирования под названием Model — View — Controller, то Свифту уготована участь быть языком контроллеров, а модель продолжат писать на Objective-C, чтобы по-прежнему можно было вызывать плюсовые «кишки» продукта.

Практически все мобильные платформы позволяют писать код на С++. Использование нативных компонентов позволяет создавать кросс-платформенный переиспользуемый код, он более быстр и эффективен по сравнению с интерпретируемым Java-кодом, поэтому большая часть базовых технологий у нас написана на C++. На Java пишется часть бизнес-логики, UI и взаимодействие с операционной системой.

Что касается среды разработки — мы стараемся без лишней необходимости не ограничивать разработчиков в выборе средств, а среда разработки — это дело привычки и вкуса. Тем не менее большинство разработчиков пишут код в Android Studio, некоторые — в Eclipse, iOS-разработчики используют Xcode.

Компонентов защиты, да и не только защиты, в продукте много. Основной язык разработки — С++, но им дело не ограничивается. Используются и другие языки: C#, Pascal, JavaScript, Nemerle.

Какая используется среда разработки (IDE)?

Мы используем Xcode, и нет смысла для разработки для Мака брать что-то другое.

Инструментов используем много, но основная среда для разработки Windows-продуктов — Microsoft Visual Studio.

Используются ли сторонние библиотеки/решения? Если да, то какие?

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

Современную разработку ПО сложно представить без использования сторонних библиотек, и мы тут не исключение. В ряде проектов используется Dagger 2, из других Java-библиотек могу выделить android-support-library v7, Guava, Apache Commons, из С++ — Boost, STL, OpenSSL, cURL, Breakpad. Полный список внешнего кода можно посмотреть в интерфейсе любого нашего продукта в разделе «Сторонний код». При использовании сторонних библиотек особое внимание мы уделяем их качеству: тестируем безопасность, следим за появляющимися уязвимостями, при необходимости оперативно переходим на новые версии библиотек.

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

Как разрабатывается интерфейс пользователя? Продукт довольно удобный и понятный, поэтому созревает вполне логичный вопрос: наверное, есть специальный отдел, который прорабатывает интерфейс пользователя до мелочей?

Да, есть специальный отдел дизайнеров, а в нем существуют две роли: проектировщик интерфейса, задача которого именно в продумывании структуры и наполнения интерфейса пользователя, и графический дизайнер, который «делает красиво» — подгоняет пиксели так, чтобы Джони Айв если бы вдруг увидел, то одобрил бы. Но успех пользовательского интерфейса, по моему мнению, даже не в дизайнерах, а в синергии между дизайнерами и продукт-менеджером. Ведь продукт-менеджер — это тот человек, задача которого — сделать пользователя продукта счастливым, и он спит и видит, как он еще может это сделать. И он просматривает и отбраковывает десятки вариантов до тех пор, пока не дойдет до именно того единственного, который принесет максимальное количество счастья.

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

Как устроена коллективная работа над продуктом? Какая система используется для контроля версий, как организовано взаимодействие между разработчиками?

На нашу удачу, у нас пока еще не такая большая команда, как у нашего «старшего брата» (Kaspersky Internet Security для Windows), мы все сидим рядом и можем видеть и слышать друг друга, что хорошо влияет на работу и позволяет не создавать лишних формальностей, которые, конечно, необходимы в более крупных командах. Но вот что приходится формализовывать, так это взаимоотношения с другими командами, делающими те «запчасти», из которых мы в результате строим наш продукт. И тут нужно все расписывать очень подробно, кто за что отвечает, так как у наших команд разные цели и мы у них не единственные, да и, конечно, не главные заказчики. Ну и конечно, мы используем один общий репозиторий для хранения исходников. Большой компании это просто намного удобнее, чем куча маленьких и распределенных.

С какими сложностями столкнулись разработчики при создании Android-версии? Пришлось ли использовать какие-то хаки, например недокументированный API?

Несмотря на миллионы известных вредоносных приложений, Google считает платформу достаточно защищенной и не интегрирует в ОС Android специальные API, предназначенные для реализации антивирусных продуктов. Вендоры вынуждены искать обходные пути, зачастую использовать API двойного назначения. Я бы не стал называть такой подход хаком, тем не менее он требует значительной изобретательности и смекалки, нам постоянно приходится искать все новые и новые пути реализации системных перехватчиков, что нам позволяет повышать качество защиты. Что касается документированности — исходный код платформы Android открыт, а нет лучшей документации, чем код. Безусловно, это нам помогает.

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

За более чем двенадцать лет существования направления мобильной разработки в «Лаборатории Касперского» мы попробовали множество различных практик и остановились на самых подходящих и наиболее зрелых, с нашей точки зрения. У нас есть корпоративный стандарт по написанию кода, который базируется на лучших мировых практиках, например Java Coding Convention под Android адаптирует лучшее из Oracle Java Code Conventions и Google Java Style Guide, учитывая при этом особенности продуктов нашей компании.

Автоматическая проверка стиля написания кода, наряду с другими практиками, интегрирована в систему Continues Integration, построенную на базе Jenkins. Сборочный конвейер остановит сборку, если обнаружит нарушение стиля или других правил статического анализатора кода, ровно так же, как тестовый конвейер выдаст ошибку, если какие-либо автоматические тесты не пройдут.

В Android-мире целый зоопарк устройств с совершенно разными версиями ОС. Есть ли отличия по функциональным возможностям или UI в зависимости от версии ОС?

Android — одна из самых динамично развивающихся платформ, на текущий момент актуальна 24-я версия API (Android 7.0). Понятно, что никто из разработчиков уже не поддерживает устаревшие версии ОС, отсутствующие у пользователей, тем не менее, согласно статистике, версии API с 14 (Android 4.0) достаточно популярны, и их необходимо поддерживать. Каждая версия API приносит с собой новые возможности, часть API становится deprecated и перестает работать. Производители устройств, в свою очередь, пытаются выделяться на фоне других, зачастую путем интеграции в платформу новых модулей, переопределения исходных или даже исключения целых подсистем.

Все это приводит к катастрофической фрагментации платформы Android. И если такие приложения, как, например, игры, абстрагируются от нижнего слоя платформы и, как правило, не используют специфических API, для секьюрити-решений ситуация обратна: они сильно зависимы от версии ОС и характеристик устройств — и функционально, и в плане реализации. Нам приходится учитывать специфику отдельных устройств и постоянно дорабатывать продукты, улучшая их работу на отдельных девайсах.

Блок 3. Оптимизация, тестирование и отладка кода

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

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

Как происходит процесс отладки? Используются ли встроенные инструменты среды разработки или какие-то сторонние?

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

Мы используем стандартные инструменты разработки, предоставляемые разработчиками операционных систем, Apple и Google, в случае с Google работаем с Java-кодом, как правило, в Android Studio. Как правило — потому что мы стараемся без лишней необходимости не ограничивать наших разработчиков конкретными инструментами. Например, если сотрудник привык писать код в Eclipse, мы не будем силой переводить его на Android Studio. Eclipse, кстати, гораздо более подходит для работы с нативным кодом, чем Android Studio. Отладка обычно ведется в средах разработки, для нативного кода полезны утилиты lldb и gdb, для поиска утечек памяти используется Memory Analyzer.

Как организован процесс тестирования? Какие инструменты используются для тестирования продукта в Маке?

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

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

Какие инструменты используются для тестирования Android-версии?

Тестирование построено по всем канонам: для каждого продукта существует стратегия тестирования, есть тест-планы, тестируемые конфигурации, создаются функциональные, регрессионный и приемочный тест-планы. Особое внимание мы уделяем автоматизации тестирования, значительная часть кода покрыта модульными тестами, автоматизируются функциональные, нагрузочные и UI-тесты, применяются практики исследовательского тестирования. Для релизов со значительными изменениями проводятся внешние бета- и пилотные тестирования. Цена ошибки для продуктов в сфере информационной безопасности значительно выше, чем, скажем, для игры, поэтому мы уделяем большое внимание мониторингу качества уже выпущенных продуктов, выявляем ошибки, краши и ANR’ы. Мы устанавливаем себе довольно амбициозные цели по времени исправления недочетов и в подавляющем большинстве случаев выдерживаем их.

Блок 4. Организационные вопросы

Как распределены роли в команде?

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

Как можно попасть в команду разработчиков? Какие требования к кандидату?

Надо хотеть программировать на Маке и под Мак, это главное. Надо хорошо знать C++ и/или Objective-C — у нас есть специализация с уклоном в сторону либо C++, либо Objective-C, но и другой язык в какой-то степени надо знать тоже.

Рис. 4. Рабочие места девелоперов

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

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

Попасть просто — прийти к нам на собеседование. Требования разные. Зависит от позиций. Например, по разработчикам С++: хорошие знания С++, хорошее знание Windows (знаний на основе книги Рихтера нам достаточно :)).

Роли в команде тоже, в общем-то, стандартные: аналитики, дизайнеры, архитекторы, девелоперы, девлиды, тестеры, тестлиды. Думаю, что по названию этих ролей понятна их функция.

Есть ли социальный пакет, какой график работы?

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

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

Как обстоят дела с премиями и отпусками?

С отпусками и премиями хорошо. Без них — плохо. Если серьезно, то летом, конечно, многие в отпуске. А премии — это не сейчас, а по результатам года.

Что нужно, чтобы стать тестером «Лаборатории Касперского»? Возможна ли удаленная работа?

Удаленной работы у нас в компании нет. Тестеров мы берем либо в ручное тестирование (тут требования примерно как у среднего сисадмина), либо в автотестирование (а тут будет, по сути, программирование на питоне).

Самый провокационный вопрос: установлен ли на вашем личном компьютере антивирус, и если да, то какой?

Конечно. Kaspersky Internet Security для Mac последней версии, а также Kaspersky Password Manager, Kaspersky Safe Kids — другие наши неантивирусные продукты для Мака.

Рис. 5. Крыша мира

Заключение

Надеемся, что эта статья пролила свет на процесс создания популярнейшего защитного решения Kaspersky Internet Security и дала понять, чем живут его разработчики.

Источник