Я, к сожалению, лицо лишь интересующееся. Больше, чем написано в посте на секьюрлисте я даже при всем желании написать не смог бы. А копипастить весь пост — неправильно.
Очень интересно! Если там действительно использовался неизвестный язык программирования -это супер! Я как человек интересующийся языками программирования и даже пытающийся разработать собственный, с удовольствием бы ознакомился с новым языком.
А что касается VS 6.0 и прочих — уверен, в Лаборатории Касперского все эти варианты проверили. Более того, судя по описанию, это точно не С++. Я бы скорее поверил в чистый Си, возможно какой-то модифицированный/расширенный компилятор (компиляторов Си ведь гораздо больше чем С++, в силу простоты языка, по той же причине и модифицировать их легче).
На самом деле, на удивление мало информации предоставлено, есть только догадки каким мог быть тот язык/фреймворк на котором написан этот код, но нет информации о том какие языки уже проверены и по какой причине они были отсеяны
Чтобы не надо было искать доп. инфу, приведу несколько цитат и добавлю пару штрихов, чтобы было понятней о чём о идёт речь в данном топике:
Игорь Суменков (эксперт «Лаборатории Касперского») назвал это «Загадка фреймворка Duqu»и применил термин «Событийно-ориентированное программирование».
И в статье на сайте Касперского есть анализ и выводы.
Выводы
Фреймворк Duqu, возможно, написан на неизвестном языке программирования.
В отличие от остальных компонентов Duqu, исходный язык Фреймворка— не C++, при этом использован отличный от Microsoft's Visual C++ 2008 компилятор.
Событийно-ориентированная архитектура позволяет коду выполняться в разных, в том числе асинхронных средах.
С учетом масштаба проекта Duqu можно предположить, что Фреймворк разрабатывала отдельная команда, не связанная с авторами эксплойтов и остальных его компонентов.
Загадочный язык программирования — определенно НЕ C++, Objective C, Java, Python, Ada, Lua и не многие другие языки, которые мы проверили.
Фреймворк Duqu — одна из особенностей, значительно отличающих Duqu от Stuxnet, который полностью написан на MSVC++.
или как пишут на ньюс2:
По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков «включая Brainfuck и Haskell». «Мы пытаемся распознать его с ноября 2011 г. Мы спросили самых крутых специалистов-реверсеров в Microsoft, но не нашли языка, который бы создавал подобный код», — говорит Александр Гостев
Мне кажется логика dll может быть написана на любом языке программирования. А, уже после компиляции, какой-нибудь утилитой типа криптопро пытается перепутать отдельные исполняемые блоки в памяти. В случае с Duqu, крипт добрался внутрь лексем языка (то есть перепутал исполняемые блоки функций стандартных библиотек), после чего стало сложнее идентифицировать язык, на котором dll написана.
Подозреваю, особо фанатичные вирусописатели могли, устав мучаться с невменяемым обросшим горой легаси Си++, просто написали свой язык. Пишут же виртуальные машины. Тем более, в наши дни есть gcc/clang, не надо с нуля компилятор писать. Если так, то сделано неплохо, хотя, конечно, то, что они в конструкторе заполняют таблицу виртуальных функций, вызывает вопрос, а нафига, эффективней же сделать классы и общую таблицу.
Тот факт, что используются безклассовые объекты, конечно, немного запутывает ситуацию, какие есть похожие на безклассовые языки, с деструктором и без сборки мусора? Я что-то с ходу не припомню. Разве что Objective-C. Или бейсик какой-нибудь.
Ну и эксперты тоже немалую работу проделали, чтобы в неизвестном языке найти мониторы событий и прочие штуки.
Написали бы что ли побольше подробностей. Какие конструкции есть в языке, есть ли следы оптимизации ассемблерного кода, и т.д.
Возможно высокоуровневый язык типа C#/Java, оттранслированный собственной тулзой в СИ. Тулза генерит код, который в добавок обфусцирует его. Получаем на выходе ни на что не похожий код. Писать новый язык не нужно, транслятор для C#/Java пишется на ура. Единственно сложное место — это чем заменить GC, по коду должно быть видно как освобождаются объекты (а освобождаются ли? может все статические). Т.е. использовать можно GC и это будет видно, либо подсчет ссылок, и это тоже будет видно, вот если удаление совсем ручное, тогда это дает мало информации.
И нестандартное распределение аргументов по регистрам и стеку?
Хотя информации конечно крайне мало. Очень была бы кстати подробная статья с описанием всех особенностей в сравнении с реализацией аналогичных вещей на С++.
К примеру, я так понимаю что в С++ сначала выделяется память (оператор new — отдельная функция), а затем вызывается конструктор — другая отдельная функция. Это делается в том числе и для того, чтобы конструкторы могли работать как на динамической, так и на стековой и глобальной памяти. В листинге здесь выделение памяти происходит в теле конструктора, то есть объекты могут быть только динамическими, и это сделано на уровне языка, или «конструкторы» — это просто функции, которые вручную выделяют память под структуру и ее заполняют. А это уже похоже на Си. Но опять же нестандартный порядок передачи аргументов вроде не сделать даже на Си…
А, собственно, откуда у граждан из лаборатории такая уверенность, что использовался какой-то специальный язык?
Берём макроассемблер с хорошо прокачанной макро-частью, пишем библиотеку макросов и в бой.
Бонусом — никаких ограничений ни на calling convention, ни на структуру объектов.
Лаборатория Касперского просит помощи сообщества