Russian
Интернет находится в нормальном состоянии, крупных эпидемий и других серьезных инцидентов службой мониторинга «Лаборатории Касперского» не зафиксировано. Уровень опасности: 1

Фреймворк Duqu: задача решена

Игорь Суменков
Эксперт «Лаборатории Касперского»
опубликовано 19 мар 2012, 18:00  MSK
Сюжеты: Duqu
0.1
 

В поисках решения

В предыдущем блогпосте про Фреймворк Duqu я писал про одну из нерешенных нами задач — определение языка, на котором написан необычный код, отвечающий за общение Duqu с C&C серверами. Нам, техническим специалистам, задача показалась очень интересной, и мы решили предложить IT-сообществу поучаствовать в ее решении.

Мы получили намного больше ответов, чем ожидали — более 200 комментариев и 60+ писем с указанием различных языков и фреймворков, которые могли быть использованы при создании кода Фреймворка Duqu. Мы хотим поблагодарить всех, кто участвовал в решении и помогал идентифицировать загадочный код.

Самыми популярными вариантами, которые вы предложили, были:

  • LISP (различные диалекты)
  • Forth
  • Erlang
  • Google Go
  • Delphi
  • OO C
  • Старые компиляторы C++ и других языков

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

igorsk
Simple Object Orientation (for C)

It seems someone over at reddit (http://www.reddit.com/r/ReverseEngineering/) hit the jackpot: the code snippets look _very_ similar to what this would produce: http://daifukkat.su/wiki/index.php/SOO
There are a few other OO frameworks for C, but they don't match as well: http://ooc-coding.sourceforge.net/ http://sooc.sourceforge.net/

Jonwil
Re: Other C/C++ compiler?

I have seen how GCC works internally and its ABI (for a number of different versions) and I can confirm that the Duqu code is definitely not generated by GCC. I don’t know how other C++ compilers work but the things I see in the ASM (like where the pointers to the functions go, the way the "this" pointer is passed etc) do not suggest C++ to me but something else entirely. (such as the aforementioned "object-oriented" frameworks for C that exist)

igorsk
Re: Other C/C++ compiler?

I’m 99% sure the machine code was generated by MSVC. It’s something you get a feel with experience, but I can point out two things that are quite characteristic of MSVC: 1) it uses esi as the first candidate for temporary storage; 2) "pop ecx" instead of "add esp, 4".

Мы также получили два письма, в которых Pascal Bertrand и другой автор, пожелавший остаться анонимным, предположили, что код Фреймворка Duqu был создан с помощью одного из объектно-ориентированных диалектов языка С, называемых обычно "OO C".

Все эти комментарии оказались очень важными, они позволили точно определить компилятор, который был использован авторами Duqu, — компилятор из поставки Microsoft Visual Studio. После нескольких экспериментов с различными версиями MSVC и опциями компиляции мне удалось воспроизвести код функции конструктора, о котором я писал в предыдущем посте, и получить из этого кода бинарный код, совпадающий с найденным в Duqu.


Результат дизассемблирования кода Duqu: функция конструктора класса связного списка


Восстановленный вручную код этой функции на языке С

При компиляции указанного выше кода на С с помощью компилятора из поставки MSVC 2008 с опциями /O1 (оптимизация по размеру) и /Ob1 (разворачивать только __inline функции) получается машинный код, совпадающий с оригинальным кодом этой функции в Duqu. Следует заметить, что другие опции компиляции, а также изменение порядка операции и if/else блоков изменяет конечный код; компилятор MSVC 2005 также генерирует другой код. Из этого следует, что, скорее всего, Фреймворк Duqu был скомпилирован MSVC 2008 с опциями /O1 /Ob1 из исходного текста на языке С.

Благодаря полученным данным мы можем выделить два наиболее вероятных решения исходной задачи:

  1. Код был написан с использованием объектно-ориентированной надстройки С, основанной на макросах или стороннем препроцессоре. Это решение было предложено и в ваших комментариях, т.к. это стандартный способ реализации объектно-ориентированного подхода в С.
  2. Код был написан на чистом С с использованием объектно-ориентированных методов. Мы не можем полностью отрицать этот вариант, т.к. технически почти невозможно отличить препроцессор от программиста, практикующего разработку в режиме копирования/вставки.

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

В настоящее время существует несколько «ОО С» фреймворков с открытым исходным кодом, причем некоторые из них генерируют код, близкий к коду Duqu. Наиболее похожий код создается с помощью SOO (Simple Object Orientation for C), однако вряд ли именно он был использован — проект появился в то время, когда Duqu уже атаковал первые компьютеры-жертвы.

Независимо от того, какой из вариантов решения является правильным, можно сделать определенные выводы. В Payload DLL содержится 95 Кб событийно-ориентированного кода, написанного на ОО С, — языке без автоматического управления памятью, с небезопасными указателями. Подобный стиль программирования присущ серьезным «гражданским» программным проектам, но не встречается в современном вредоносном ПО. Более того, событийно-ориентированная модель была разработана как часть Duqu или его ОО расширения С.

Трудно однозначно определить причины использования ОО С вместо С++. Мы попробовали найти причины этого, опираясь на описания других ОО С проектов и пообщавшись с профессионалами, использующими подобные методы разработки. Наиболее вероятными причинами представляются:

  1. Недоверие к компиляторам С++. Это типично для разработчиков с многолетним опытом, которые начинали с ассемблера, а затем постепенно перешли на С. Когда появился С++, многие отказались от его использования из-за неявного управления памятью и запутанных конструкций, вызывавших неявное выполнение кода (конструкторы, операторы и т.п.).
  2. Широкая переносимость. Многие годы не было общего для всех компиляторов стандарта С++, возникали проблемы совместимости с компиляторами различных производителей. Если нужно было обеспечить компилируемость различными средствами разработки под несколько платформ, нужно было использовать С.

Обе причины явно указывают, что код Фреймворка был написан разработчиками «старой школы» с многолетним опытом работы.

Выводы

  • Фреймворк Duqu был написан на C и скомпилирован с помощью MSVC 2008 с опциями "/O1" и "/Ob1".
  • При разработке, скорее всего, использовалось собственное объектно-ориентированное расширение языка С, обычно называемое «ОО С».
  • Событийно-ориентированная архитектура была разработана как часть Фреймворка или в рамках расширения ОО С.
  • Код общения с C&C мог быть позаимствован из другого программного проекта и затем адаптирован к задачам проекта Duqu.

Мы полагаем, что разработка велась профессионалами, использующими наработки программистов «старой школы». Подход, который использовали авторы Duqu, обычно встречается в серьезных программных проектах, и почти никогда — во вредоносных программах. Это ещё раз указывает на то, что Duqu, как и Stuxnet, — уникальная разработка, выделяющаяся на фоне всех вредоносных программ.


10 комментариев

новые сверху
список
 

Murmoshka

25 мар 2012, 11:09
0
 

Привет конторе из бункера в Тропарево!!!
На улице Островитянова в СВР России работают великие люди, которые смеются над вашими дилетантскими попытками устанавливать компетентных лиц. Этим, конечно, надо заниматься, но не так грубо и открыто, как делаете это вы.
Приходите к нам на чай.

Murmoshka

25 мар 2012, 11:05
0
 

Re: Re: Re: Re:

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

sluge

22 мар 2012, 11:14
3
 

ну тут по поводу старой школы можно поспорить...
Вот взять например известного хакера криса касперски. Язык не поворачивается назвать его разработчиком старой школы, вернее сказать что он вообще не разработчик, но он пишет именно на с, в первую очередь потому что С++ компилятор пихает в программу много всякого барахла, в результате чего код распухает, а как изветно, размер для вируса-очень критической параметр. Или взять например вирусняк zeus-тоже написан на с, но писали его явно люди новой школы, к тому же которые уж точно знали с++, а писали его на с опять же-чтобы уменьшить его размер и уменишить зависимости от стандартных библиотек.
Вы тут поминаете переносимость-о какой переносимости идет речь, если проект делался на MSVC? Как известно, MSVC с одной стороны обеспечивает очень хорошую поддержку для проектов старых версий, но с другой, этот проект почти невозможно перенести на любой другой компилятор.

sluge

22 мар 2012, 09:56
-1
 

Re:

ну вот вы пришли ко врачу, он вам выписал анализы, вы его спрашиваете зачем?

Александр Гостев

21 мар 2012, 00:18
-3
 

Re: Re: Re:

Я не видел такого утверждения в ваших прошлых комментариях. Поэтому ваши теперешние заявления и вопросы тут мало кого интересуют.

antanta

20 мар 2012, 23:30
-2
 

"Культурные люди стали на точку зрения следствия: работала шайка гипнотизеров и чревовещателей, великолепно владеющая своим искусством"

w8m

20 мар 2012, 21:03
1
 

Re: Re:

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

Александр Гостев

20 мар 2012, 19:21
-2
 

Re:

ведущие специалисты Хабра зато смогли ? :)

w8m

20 мар 2012, 07:59
-1
 

Просто приведу комментарии с хабра:

- "Может я тупой, по почему так важно, на каком языке написан вирус?"
-- "Потому что это лишний раз позволяет пропиариться антивирусной компании."

- "Ммм, недопонял что-то: ведущие специалисты не смогли сразу установить, что код написан на одном из самых распространенных языков и скомпилирован при помощи одного из самых распространенных компиляторов?"

nlo

19 мар 2012, 19:18
2
 

да не уж то!!!

Забыли упомянуть о опции "Favor Small Code (/Os)" без которой не получится конструкций:

stosd
stosd
stosd
stosd
stosw
stosb

И про вариант, что opensource код фреймворка который использовали, банально не компилировался как C++, а не "Недоверие к компиляторам С++" и остальное.

Для добавления комментариев необходимо


Bookmark and Share
Закладки

Также в аналитике

В блоге