То что делает Тавис помогает сделать экосистему безопаснее, а эти ребята обычный криминал, который создает очень много проблем нормальным людям. Очень грустно если вы не видите разницу.
Тоже посмотрел его статьи, есть вполне серьезные работы за последние 2 года, а есть где он числиться 4ым-5ым автором, я бы не стал на них сильно внимание обращать. В целом нормальный чел, хотя тема на мой взгляд не самая интересная. С февраля 2019 он переезжает в Корею кстати.
С точки зрения защиты кода Вы 100% правы. Защита должна быть построена таким образом, чтобы её нельзя было бы пропатчить 1 байтом, сам не раз сталкивался с таким. Поэтому предлагаемое в статье решение может (и должно) использоваться только как один из компонентов многослойной защиты. Themida отличный пример (хоть и не managed-code).
Ну и не нужно забывать, что такие методы могут применяться и в малвари, полезно знать какие есть способы обнаружения песочницы.
Обсуждали в этой статье на Хабре.
Вкратце. Разработать полностью «прозрачную» виртуализацию с приемлемым уровнем производительности просто невозможно (пруф), а существующие ВМ оставляют нам множество артефактов, которые можно детектить.
Вот интересная статья на тему фаззинга инструкций ВМ (ссылка). Можно все не читать, просто обратите внимание на таблицу 2 на странице 10, они показывают количество инструкций, которые работают в этих виртуальных машинах по-другому, чем на нативной. И это они взяли относительно небольшое количество команд. Самое главное, что разработчики ВМ и не стремятся сделать ВМ «прозрачной» (зачем им тратить на это время и ресурсы?), им достаточно добиться совместимости.
Да, но тогда придется моделировать и процессор, а это уже не виртуальная машина, а полноценный эмулятор, например qemu поддерживает такой режим. Там как Вы правильно заметили очень серьезные потери в производительности, чем вирусописатели активно и пользуются. Например фазе заражения системы предшествует длительный цикл «пустых» операций, которая в эмуляторе может занимать несколько часов и даже дней, а на реальной машине исполняется за пару минут.
Вообще, есть сейчас несколько интересных работ, где ребята используют реальную, физическую машину для анализа вредоносного кода. Привожу пару ссылок кому интересно: ссылка 1 ссылка 2
Ну ок, давайте проведем мысленный эксперимент (бог с ней с квантовой физикой, давайте что нибудь попроще). Предположим что мы живем в некоторой виртуальной среде. У нас была некоторая спецификация к этой среде и команда которая её реализовала.
Предположим согласно этой спецификации у обычных домашних котов в этой среде не может быть шерсть более двух цветов (общеизвестный факт, что в подавляющем большинстве случаев трехцветными бывают только кошки из-за генетических особенностей). Предположим также, что в команде разработчиков было криволапое существо, которое допустило ошибку при реализации цвета кота, так что при определенных обстоятельствах коты получаются трехцветными.
Теперь вопрос: каким образом мы можем утверждать, что видя трехцветного кота это баг, а не фича нашего мира, не видя спецификации к нашей виртуальной системе?
Чтобы найти баг, нужно хотя бы иметь представление о том, как это должно работать в «реальной» системе. А так баг это или фича остаётся только догадываться.
К сожалению создание такой виртуальной машины, которая не будет детектится является фундаментально неразрешимой задачей, вот здесь есть небольшая, но отличная статья на эту тему (кому интересно): ссылка
Проблема еще в том, что VMWare, да и другим производителям виртуальных машин в целом это и не нужно, например есть целый набор инструкций x86, которые в виртуальной машине работают немного не так, как на реальной машине. Это уже пофиксить гораздо сложнее, а вот задетектить легко, требуется 5-7 машинных инструкций.
Хм, не понял контекст, извините.
Ну и не нужно забывать, что такие методы могут применяться и в малвари, полезно знать какие есть способы обнаружения песочницы.
Добавлю от себя, что можно эту информацию также выдернуть из реестра Windows. Кстати малварь в основном так и делает.
Вкратце. Разработать полностью «прозрачную» виртуализацию с приемлемым уровнем производительности просто невозможно (пруф), а существующие ВМ оставляют нам множество артефактов, которые можно детектить.
Вот интересная статья на тему фаззинга инструкций ВМ (ссылка). Можно все не читать, просто обратите внимание на таблицу 2 на странице 10, они показывают количество инструкций, которые работают в этих виртуальных машинах по-другому, чем на нативной. И это они взяли относительно небольшое количество команд. Самое главное, что разработчики ВМ и не стремятся сделать ВМ «прозрачной» (зачем им тратить на это время и ресурсы?), им достаточно добиться совместимости.
Вообще, есть сейчас несколько интересных работ, где ребята используют реальную, физическую машину для анализа вредоносного кода. Привожу пару ссылок кому интересно:
ссылка 1
ссылка 2
Предположим согласно этой спецификации у обычных домашних котов в этой среде не может быть шерсть более двух цветов (общеизвестный факт, что в подавляющем большинстве случаев трехцветными бывают только кошки из-за генетических особенностей). Предположим также, что в команде разработчиков было криволапое существо, которое допустило ошибку при реализации цвета кота, так что при определенных обстоятельствах коты получаются трехцветными.
Теперь вопрос: каким образом мы можем утверждать, что видя трехцветного кота это баг, а не фича нашего мира, не видя спецификации к нашей виртуальной системе?
На мой взгляд никак.
ссылка
Проблема еще в том, что VMWare, да и другим производителям виртуальных машин в целом это и не нужно, например есть целый набор инструкций x86, которые в виртуальной машине работают немного не так, как на реальной машине. Это уже пофиксить гораздо сложнее, а вот задетектить легко, требуется 5-7 машинных инструкций.