на объектные файлы.
Инструментарий никогда не заменит знаний
Некоторые из средств дизассемблирования и отладки предлагают фантастические возможности. Но они, как и любой другой инструментарий, несовершенны. Особенно это проявляется при анализе злонамеренного кода (вирусов, червей, Троянских коней) или специально разработанных программ. Обычно авторы подобных поделок делают все возможное для затруднения их анализа и снижения эффекта от применения отладчиков, дизассемблеров и других подобных инструментальных средств. Например, вирус RST для Linux в случае обнаружения, что он работает под управлением отладчика, завершает свою работу. Этот же вирус при инфицировании исполняемых и компонуемых файлов ELF (Executable and Linkable Format – формат исполняемых и компонуемых модулей) модифицирует их заголовки таким образом, что некоторые дизассемблеры не могут дизассемблировать двоичный код вируса (обычно это достигается путем размещения кода вируса в необъявленном программном сегменте). Часто злоумышленный код шифруется или сжимается, что защищает его от экспертизы. Черви Code Red распространялись половинками своих программ, маскируясь под строки переполнения, и, таким образом, формат их двоичных данных не подходил ни под один из стандартных заголовков файла.
Поэтому при анализе двоичных данных нужно знать не только о том, какие инструментальные средства и как применять, но и как обойтись без них. Анализируя заголовок файла, возможно, потребуется определить, какие данные в файле модифицированы, как и с какой целью. Вероятно, потребуется проанализировать зашифрованные данные и процедуру их расшифровки, восстановить алгоритм работы программы и выяснить результаты ее работы.
Необходимо знать ассемблер не только в объеме, достаточном для чтения ассемблерных программ, но и для написания программ расшифровки или восстановления данных. Писать на ассемблере намного сложнее, чем читать программы, написанные на этом языке.
Из этого не следует, что инструментальные средства бесполезны. Далеко не так. Нужно только выявить часть программы, оказавшуюся не по зубам инструментальным средствам, и проанализировать ее самостоятельно, а остальную часть программы – при помощи инструментальных средств. Кроме того, иногда для лучшего понимания логики работы программы следует воспользоваться инструментарием.
Тестирование методом «черного ящика»
Термин «черный ящик» относится к любым компонентам или частям системы, чьи внутренние функции скрыты от пользователя системы. При тестировании методом «черного ящика» главное внимание уделяется изучению результатов работы системы в зависимости от ее входных данных без рассмотрения настройки и управления работой ее внутренних компонентов.
Тестирование методом «черного ящика» может быть сравнено с бинарным аудитом (binary auditing). Любой аудит так или иначе имеет дело с бинарными данными, предусматривающими одну возможность из двух. Известны различные толкования «черного ящика» в зависимости от знаний исследователя о его внутреннем строении (его прозрачности). В книге рассматриваются два типа ящиков: «черный ящик» и «ящик из обсидиана». Конечно, это мысленные, а не реальные физические объекты. Тип ящика отражает уровень знаний исследователя
