Уже много слов было сказано про червя Flame (Win32/Flamer), но почему то никто не публикует результаты более детального изучения кода этой вредоносной программы. А код у Flame между тем очень интересен и таит в себе еще не мало открытий для вдумчивых и усидчивых исследователей. Ведь не спроста он оставался незамеченным на атакованных системах долгое время, причем на этих системах стаяло антивирусное ПО некоторых известных вендоров, но сейчас все же не об этом ;)
Итак, в чем же связь между Flame, Duqu и Stuxnet? Так как нами были проанализированы все три вредоносные программы, то мы решили не просто описать свои внутренние ощущения, а подтвердить это родство техническими фактами.
Начнем с того, что код Win32/Flamer анализировать не очень приятно, даже при отсутствии жесткой обфускации. Объектно-ориентированный код схож с тем, что уже встречалось ранее в Stuxnet и Duqu, но однозначного сходства не так уж и много. В основном схожесть кроется в стиле кодирования и архитектуре этих вредоносных программ. Если в случае Stuxnet и Duqu ООП архитектура была построена на одном фреймворке и концепциях, то у Flame есть отличия. У всех трех вредоносных программ реализована сложная логика работы, а использование ООП концепций, реализованных на C++, заставляют разбираться в работе не только самой вредоносной программы, но и компилятора тоже. В качестве наглядного примера посмотрите на реконструкцию вызова метода Rc4_GetBufferSize() в модуле mssecmgr.ocx:
В процессе статического анализа бывает сложно установить однозначное соответствие со значением в VTABLE и указателем VPTR. Для того, чтобы упростить себе жизнь в процессе статического анализа мы прибегаем к ухищрению и эмулируем конструкции С++ при помощи определения структур. Этот метод хорошо описан в статье "Reversing C++ programs with IDA pro and Hex-rays".
Итак, в чем же связь между Flame, Duqu и Stuxnet? Так как нами были проанализированы все три вредоносные программы, то мы решили не просто описать свои внутренние ощущения, а подтвердить это родство техническими фактами.
Начнем с того, что код Win32/Flamer анализировать не очень приятно, даже при отсутствии жесткой обфускации. Объектно-ориентированный код схож с тем, что уже встречалось ранее в Stuxnet и Duqu, но однозначного сходства не так уж и много. В основном схожесть кроется в стиле кодирования и архитектуре этих вредоносных программ. Если в случае Stuxnet и Duqu ООП архитектура была построена на одном фреймворке и концепциях, то у Flame есть отличия. У всех трех вредоносных программ реализована сложная логика работы, а использование ООП концепций, реализованных на C++, заставляют разбираться в работе не только самой вредоносной программы, но и компилятора тоже. В качестве наглядного примера посмотрите на реконструкцию вызова метода Rc4_GetBufferSize() в модуле mssecmgr.ocx:
Первая часть нашего анализа "Flame, Duqu and Stuxnet: in-depth code analysis of mssecmgr.ocx" повествует о взаимосвязи Stuxnet/Duqu и Flame. А так же в подробностях описан способ внедрения модулей Flame в процессе установки.
Во второй части "Flamer Analysis: Framework Reconstruction" уделено больше внимания реконструкции ООП фреймворка и востановлениию структуры внутренней БД.
Комментариев нет:
Отправить комментарий