Здравствуйте, rttrtt, Вы писали:

R>Важный фрагмент кода известного трояна Duqu написан на неизвестном до сих пор языке программирования, рассказал CNews главный антивирусный эксперт «Лаборатории Касперского» Александр Гостев.

Nemerle уже проверяли? (дежурная шутка)

R>По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков программирования, «включая Brainfuck и Haskell». «Мы пытаемся распознать его с ноября 2011 г. Мы спросили самых серьезных специалистов-реверсеров в Microsoft, но не нашли языка, который бы создавал подобный код», — говорит Александр Гостев.

Интересно, как именно они их проверяли?

Нашел кое-что от ЛК: Загадка фреймворка Duqu

Здравствуйте, rttrtt, Вы писали:

R>Небольшой пиар для касперского:
R>Важный фрагмент кода известного трояна Duqu написан на неизвестном до сих пор языке программирования,
"написан неизвестно на каком языке" -- так будет правильно.

Здравствуйте, rttrtt, Вы писали:

R>Троян Duqu написан на неизвестном языке программирования

Стопудова, его в гугле писали. Новые никому не нужные и малоизвестные языки — это их фишка.

http://www.cnews.ru/news/top/index.shtml?2012/03/07/480558

Небольшой пиар для касперского:

Важный фрагмент кода известного трояна Duqu написан на неизвестном до сих пор языке программирования, рассказал CNews главный антивирусный эксперт «Лаборатории Касперского» Александр Гостев.

Фрагмент кода, написанный на неизвестном языке программирования, получил в «Лаборатории Касперского» название «Фреймворк Duqu». Он предназначен для обмена информацией между модулем, внедряемым в операционную систему заражаемого ПК и командными серверами Duqu.

По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков программирования, «включая Brainfuck и Haskell». «Мы пытаемся распознать его с ноября 2011 г. Мы спросили самых серьезных специалистов-реверсеров в Microsoft, но не нашли языка, который бы создавал подобный код», — говорит Александр Гостев.

Напомним, что о трояне Duqu стало известно 1 сентября 2011 г. По предположению экспертов, этот троян был создан для точечных атак и кражи информации из компьютеров промышленных объектов, а также правительственных и коммерческих структур Ирана.

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, rttrtt, Вы писали:

R>>Важный фрагмент кода известного трояна Duqu написан на неизвестном до сих пор языке программирования, рассказал CNews главный антивирусный эксперт «Лаборатории Касперского» Александр Гостев.

R3>Ассемблер — это не язык?

Можно считать, что нет, это не язык, это метаязык. Ассемблер без макросов — это автокод (был такой удобный термин в советское время). С набором макросов ассемблер превращается в произвольный язык, хоть и с сильными ограничениями. Вот загляните сюда — пример, что можно сделать из ассемблера.
Если кто-то породит набор таких макросов, он сможет неплохо писать под конкретную задачу и не будет похоже ни на один язык программирования среднего или высокого уровня...

SD>>Один из самых простых способов определить язык — последовательно скармливать различным дизассемблерам.
D>ужос! понабрали..

Что не нравится-то? Прежде, чем лезть грязными руками в бинарники, проще их скормить IDA.

D>по каким таким структурам данных и по каким сегментам?

По разным, по тем, которые в стандартных либах или SDK/PSDK/DDK.

D>про те которые в PE формате или про что?

По этим тоже можно много чего определить, но в основном только среди детских поделок, где ничего не стрипнуто.

Здравствуйте, IT, Вы писали:

IT>Инопланетяне? Асари или даже может быть кварианцы.

Сразу видно, третий масс эффект релизнулся...

Это был C с каким-то ОО-фреймворком: http://www.securelist.com/en/blog/677/The_mystery_of_Duqu_Framework_solved

Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, rttrtt, Вы писали:

R>>По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков программирования, «включая Brainfuck и Haskell».

L>Я не программист,

В каком смысле?

L>Может быть, Duqu написан на Форте, который также можно рассматривать как метаязык?

Маловероятно. У скомпилированного фортовского кода очень чёткий вид. Грубо говоря, это небольшой кусок машинного кода с непосредственным выполнением действий, дальше большой блок кусков, в которых преобладают над всем вызовы подпрограмм (напрямую машинными командами или просто списками адресов), небольшое количество втиснутых прямо в код констант и чёткая цепочка определённых программистов "слов" с их именами и ссылками между ними. Конкретная адаптированная реализация может терять или модифицировать какие-то части этого набора (например, список словаря ведётся отдельно и затем дискардится), но не все и не до конца. Или у касперского предельно тупые эксперты (не верю), или это не Форт.

Здравствуйте, dudkin, Вы писали:

D>Здравствуйте, мыщъх, Вы писали:


D>в c насколько я помню конвенция и для внутренних соблюдается, эта фича с++. хотя могу и путать.
при глобальной оптимизации компилятор гонит функции на граф и если не инлайнит, то может распределить регистры оптимально между всеми вызовами данной функции, нарушив все конвекции. точно знаю, что это умеет делать intel c++.

в ms vc чуть-чуть более упрощенная схема -- там несколько конвекций fastcall. кстати, поэтому obj файлы, скомпилированные с разными ключами оптимизации могут не стыковаться. компилятор считает, что ему дали _все_ файлы проекта и он их глобально заоптимизировал. а потом вы берете один такой файл и юзаете его в другом проекте. и все. приехали. легко проверяется экспериментально. я вот только не помню на каком числе аргументов это начинает работать. вроде бы если меньше трех, то юзается обычный fastcall, т.к. он всех устраивает

кстати, основные чудеса у ms vc с возвратом аргументов по значению. можно начать со структур. там такой кошмар творится... порой структуры уничтожаются, растаскиваясь на составляющие и киляются незающанные. допустим, возвращаем структуру (по значению) где пара int и большой массив. int'ы используются, а массив -- нет. оптимизирующий компилятор ms vc (не помню начиная с какой версии) выкидает массив, и кладет int'ы в eax/edx.

D> да бред эти эксперты, написал какому нибудь такому же олуху, а тот мож и рад бы прочитать его английский не разобрать.
в том-то и дело, что без фио это звучит в стиле "британские ученые". т.е. может и правда, но фиг проверишь.

D> микрософт хорошо и быстро отвечает когда найдешь у них баг, или когда им самим чего то нужно. а так смысл то? да и кому писать на деревню билу
реверсеры у них в разных подразделениях. от антивируса до группы совместимости приложений, которые их реверсят, пытаясь понять какого хрена оно не работает на новой винде и чей это баг. кстати, и те, и другие пишут об этом в своих блогах. но ни те, ни другие не занимаются отождествлением компиляторов. а вот группа разработчиков компиляторов, вероятно, могла проанализировать код и сказать что это за движок и сколько там ручной работы. код они не реверсят, но работают с асм-листингами, что практически одно и тоже в данном контексте. и у них знаний о компиляторов как бы побольше будет, т.к. они же изучают конкурентов.


D>да тут просто парень блестнуть хотел. слабо верится что он и в правду сидел перебирал компиляторы,
D>с той же скоростью с которой отвечал добрым самаритянам
так ведь вопросы были дебильные. типа "а вы ДИ пробовали". дык даже в факе по ди написано что за код он генерит. я тоже могу ответить, что это не ди. и не форт. а вот на счет фрон-эндов си с плюсами вопросов никто и не задавал, хотя таких компиляторов довольно много и они генерят код на си. который потом оптимизируется и компилируется. проверять их -- это действительно нужно кучу времени убить.

разработка _языка_ под такой заказ невероятна. язык просто так не создашь. ладно, не будем цепляться к словам. транслятор. но и транслятор тоже нет смысла писать для x86 -- есть готовые. а вот кодогенераторы пишут многие программисты потому что так проще. ну вот я последние из чего писал -- парсер .class файлов на java. программа берет описание структур .class файла из спекки, генерирует "рыбу" (типа скелет), который я уже наполняю мясом. и там идет "эмуляция" объектов, причем шаблонная, т.к. код генерируется автоматом. но дальше он правится руками и потому возникают чудеса вроде описанных в статье.

метапрограммирование вообще очень популярно сейчас. пишем сценарий и программу на питоне, которая читает сценарий и, хе-хе, генерирует код на си. таких программ -- куча в сети. выходит, что фактически мы пишем на питоне, а получается программа на си

N>Интересно, как именно они их проверяли?

Большинство языков программирования имеют специфические порядки следования инструкций. Например, работа со стеком (уже по этому признаку определяются многие языки), calling conventions.

Один из самых простых способов определить язык — последовательно скармливать различным дизассемблерам. Простые случаи вроде C/C++ отлавливаются без проблем. Не очень понимаю, как в этом смысле определить Brainfuck (я в целом не специалист в этом вопросе ).

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

Вообще, IMHO, поверх сгенерированного бинарного кода мог пройти бинарный обфускатор. Тогда характерные особенности кодогенераторов вряд ли удастся найти.

PS: ах да, еще по набору вызываемых инструкций процессора зачастую можно даже опции компилятора узнать, не то что язык.

Здравствуйте, Lazytech, Вы писали:

L>Нашел кое-что от ЛК: Загадка фреймворка Duqu

Собственно из этого поста и высосана вся остальная шумиха. Умение быстро находить первоисточник в наше время первейший скилл.
А то развели блин балабольства на целую страницу.

Здравствуйте, rttrtt, Вы писали:

R>По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков программирования, «включая Brainfuck и Haskell». «Мы пытаемся распознать его с ноября 2011 г. Мы спросили самых серьезных специалистов-реверсеров в Microsoft, но не нашли языка, который бы создавал подобный код», — говорит Александр Гостев.

Инопланетяне? Асари или даже может быть кварианцы.

Здравствуйте, Lazytech, Вы писали:

L>Нашел кое-что от ЛК: Загадка фреймворка Duqu

ну и где они там нашли неизвестный компилятор?
то что с с-runtime связи нет это значит что была включена опция "Ignore default libs" и /GS- многие так делают чтобы уменьшить размер ехешника
передача параметров через eax — скорее всего fastcall
параметер "this" про который они там тихо офигивают что он в любом регистре — тоже всё просто! если передается не через _thiscall а как обычный параметер ( int MyClass.DoSmth(param) vs. int _fastcall DoSmth(MyClassPtr, param) ) то оптимизирующий компилятор С++ действительно засунет в любой регистр

Здравствуйте, dudkin, Вы писали:

D>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Это был C с каким-то ОО-фреймворком

D>свистуны эти лаборанты касперского "мы спросили самых серьезных специалистов-реверсеров в Microsoft"!
D>и код хоть и был сгенерен Си-шный, но компилировали Visual С++ это он во время оптимизации умеет по разным регистрам параметры раскидывать ( Си компилер следует calling conventions )

calling conventions только для внешних функций. для остальных -- в соглашениях нет необходимости, особенно с появлением глобальной оптимизации. вот когда все функции транслировались независимо друг от друга, то тут без соглашений было никак. а с глобальной оптимизацией -- как хочу, так и передаю параметры. главное, чтобы гарантированно эти функции не вызывал никто другой, что и отслеживает компилятор.

кстати, а кто там "самый серьезный в ms"? без упоминания имен -- как-то несерьезно. это же не гос. тайна. могли бы сослаться на конкретных людей, желательно процитировав их ответ, ибо "хз, с ходу не ответишь, а серьезно разбираться ни времени, ни мазы нет" радикально отличается "мы потратили 100500 человеко-часов и over 9000 баксов, но так и не нашли компилятор".

в ms действительно очень много очень сильных спецов по этой теме. я вот тут начал их постепенно опрашивать. ищу к кому же из них обращались из ЛК. интересно просто... пока не нашел никого (конечно, это ни о чем не говорит, т.к. далеко не всех их я знаю). но тут непонятно -- обращались от имени ЛК или персонально от своего имени и спец из ms мог даже не знать, что разговаривает с сотрудником из ЛК. последнее наиболее вероятно, ибо официальные запросы региструются и таких запросов в ms непоступало. неофициальное общение между сотрудниками различных компаний скажем так не запрещено, но и не разрешено. и при таком общении свою компанию как бы и не скрывают, но как бы и не афишируют и обычно используют персональные емелы.

кстати, спецы из ms не специализируются на отождествлении компиляторов. это делают другие фирмы. и делают это профессионально и, конечно, за бабки. зачем они это делают? а очень просто. когда начинаются судебные разборки между А и Б нужно как минимум доказать, что схожесть бинарников не обусловлена особенностью кодогенерации или библиотек. простой пример. напишите простой цикл for, do и while. умный оптимизатор во всех трех случаях сгенерит полностью идентичный код ибо различия нивелируются еще на подступах к оптимищации.

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

Здравствуйте, rttrtt, Вы писали:

R>Важный фрагмент кода известного трояна Duqu написан на неизвестном до сих пор языке программирования, рассказал CNews главный антивирусный эксперт «Лаборатории Касперского» Александр Гостев.

Ассемблер — это не язык?

Здравствуйте, SkyDance, Вы писали:

SD>Один из самых простых способов определить язык — последовательно скармливать различным дизассемблерам.

ужос! понабрали..

SD>Ассемблер, кстати, если писать традиционными путям (даже почти без макросов), тоже можно определить (по структурам данных, сегментов и т.п.).

по каким таким структурам данных и по каким сегментам?
про те которые в PE формате или про что?

Здравствуйте, rttrtt, Вы писали:

R>По словам эксперта, при изучении Duqu аналитиками «Лаборатории Касперского» было проверено около трех десятков языков программирования, «включая Brainfuck и Haskell».

Я не программист, поэтому попрошу отнестись к моей безумной догадке снисходительно.
Может быть, Duqu написан на Форте, который также можно рассматривать как метаязык?

Оказывается, я не первый, кто высказал это предположение.

Лаборатория Касперского просит помощи сообщества

Шитый код же почти. Форт это самопальный.

Здравствуйте, netch80, Вы писали:

L>>Я не программист,

N>В каком смысле?

В буквальном. Про Форт знаю потому, что он используется в моем любимом скриптере nnCron.

N>Маловероятно. [skip] Или у касперского предельно тупые эксперты (не верю), или это не Форт.

Понятно.

basic?

Здравствуйте, wildwind, Вы писали:

W>Умение быстро находить первоисточник в наше время первейший скилл.

Если честно, на первоисточник я набрел чисто случайно: "Форт" "Duqu"
Кстати, результаты гуглопоиска уже изменились: буквально пару часов назад ссылка на ту статью была на 2-м месте.

Твикнул поисковый запрос: "Форта" "Duqu"

Здравствуйте, Lazytech, Вы писали:

L>Здравствуйте, wildwind, Вы писали:

W>>Умение быстро находить первоисточник в наше время первейший скилл.

L>Если честно, на первоисточник я набрел чисто случайно: "Форт" "Duqu"
L>Кстати, результаты гуглопоиска уже изменились: буквально пару часов назад ссылка на ту статью была на 2-м месте.

Лучше вместо "Форт" напиши "Forth"

http://www.securelist.com/ru/blog/41063/Zagadka_freymvorka_Duqu

> Расположение полей в памяти объекта зависит от конкретного класса. Например, не у всех классов таблица функций находится в начале. При этом у некоторых классов бинарно совместимы таблицы функций, но прямых указаний на наличие у них общего класса-предка, как в других объектно-ориентированных языках, не обнаруживается.

о! у причастного к этому работают мозги

> В большинстве объектно-ориентированных языков методы получают параметр «this», при этом порядок передачи этого параметра обычно фиксирован — в определенном регистре или параметре в стеке. Однако для классов Фреймворка Duqu этот порядок не фиксирован — параметр может передаваться в любом регистре или в стеке.

это конечно хорошо, но уже делались предположения насчет Internal Linkage (в терминах llvm) и последующих оптимизаций

Здравствуйте, m e, Вы писали:

ME>http://www.securelist.com/ru/blog/41063/Zagadka_freymvorka_Duqu

>> Расположение полей в памяти объекта зависит от конкретного класса. Например, не у всех классов таблица функций находится в начале. При этом у некоторых классов бинарно совместимы таблицы функций, но прямых указаний на наличие у них общего класса-предка, как в других объектно-ориентированных языках, не обнаруживается.

>> В большинстве объектно-ориентированных языков методы получают параметр «this», при этом порядок передачи этого параметра обычно фиксирован — в определенном регистре или параметре в стеке. Однако для классов Фреймворка Duqu этот порядок не фиксирован — параметр может передаваться в любом регистре или в стеке.

ME>это конечно хорошо, но уже делались предположения насчет Internal Linkage (в терминах llvm) и последующих оптимизаций
Обфускацию забыли как вариант)

Реально это может быть си с кодогенерацией, где кодогенерация реализует некую простую модель сервисов. Тогда и таблица функций будет "где придётся", и прототипное ООП будет чем-то напоминать, и функции для простоты кодогенерации станут массово виртуальными, и обмен сообщениями как основа взаимодействия объектов достаточно органично вписывается. Не такой уж большой по размеру фреймворк вырисовывается, чтобы думать про что-то ещё.

Старые книжки, середины-конца 90-х, часто рекомендовали подобный подход, даже в the pragmatic programmer есть глава на тему.

Здравствуйте, netch80, Вы писали:

N>Лучше вместо "Форт" напиши "Forth"

Русское название я использовал в поисковом запросе потому, что речь идет о Лаборатории Касперского, а не о Symantec или McAfee.

(Убрал часть ответа под кат, дабы не захламлять ветку. )

	Скрытый текст
	Мне известно английское название этого языка, а также то, что оно происходит от словосочетания "fourth-generation computer language", то бишь «язык программирования четвертого поколения», с вынужденным усечением до "forth" (англ. вперед; далее) из-за ограничения длины идентификатора пятью символами: I developed Forth over the period of some years as an interface between me and the computers I programmed. The traditional languages were not providing the power, ease, or flexibility that I wanted. I disregarded much conventional wisdom in order to include exactly the capabilities needed by a productive programmer. The most important of these is the ability to add whatever capabilities later become necessary. © Starting FORTH by Leo Brodie Я даже прочел книги Starting Forth и Thinking Forth вышеупомянутого автора. Правда, фортером — как и программистом вообще — от этого не стал.

	Скрытый текст
	Пардон, процитировал не то, что надо: The first time I combined the ideas I had been developing into a single entity, I was working on an IBM 1130, a "third-generation" computer. The result seemed so powerful that I considered it a "fourth-generation computer language." I would have called it FOURTH, except that the 1130 permitted only five-character identifiers. So FOURTH became FORTH, a nicer play on words anyway.

b-3>Реально это может быть си с кодогенерацией, где кодогенерация реализует некую простую модель сервисов.

вообще и правда, это может быть такой реализацией ооп-на-си

b-3>Тогда и таблица функций будет "где придётся",

самое главное — вот это не понял — почему?

b-3>и прототипное ООП будет чем-то напоминать,

ммм... похоже именно что напоминать; там же надо уметь в рантайме добавлять новый метод?

b-3>и функции для простоты кодогенерации станут массово виртуальными,

да

b-3>и обмен сообщениями как основа взаимодействия объектов достаточно органично вписывается.

поподробнее

b-3>Не такой уж большой по размеру фреймворк вырисовывается, чтобы думать про что-то ещё.

согласен еще и потому, что можно брать исходник на с++, индентить его, и затем не слишком сложным перл-скриптом генерить исходник на си, где таблици виртульных функций будут прямо внутри объектов; это выглядит вполне нормально, да еще можно и тестировать свой код дважды — как скомпиленый g++, так и скомпиленый в виде ооп-на-си

Здравствуйте, SkyDance, сдается мне Вы писюль пинали в своем ЛК:

SD>Что не нравится-то? Прежде, чем лезть грязными руками в бинарники, проще их скормить IDA.

в иде всего два языка если на то пошло С++ (с вариациями) и Дельфи

SD>По разным, по тем, которые в стандартных либах или SDK/PSDK/DDK.

это интересно! то есть ты хочешь сказать для каждого языка эти структуры разные?

SD>По этим тоже можно много чего определить, но в основном только среди детских поделок, где ничего не стрипнуто.

и что же там можно определить среди детских поделок?

Здравствуйте, rttrtt, Вы писали:

врядли это новый ЯП, скорее самопальный ООП на императивном ЯП, возможно на C

я сам когда-то экспериментировал с ОО организацией с помощью структур — макросы сильно помогают

Здравствуйте, Lazytech, Вы писали:

L>Нашел кое-что от ЛК: Загадка фреймворка Duqu


Некоторые вещи, например, наличие таблицы ф-ий в самом объекте, или сугубо событийное т.е функциональное программирование, похоже на то, как ООП эмулируется замыканиями, где объект представляет из себя фактически открытый тупл из замыканий (методов) и полезных полей. И тогда this может приходить в каком угодно по счету аргументе — зависит от сигнатуры метода, которому удовлетворяет это замыкание и то, из каких других функциональных объектов оно было образовано.

Очереди/контексты выполнения и прочие похожие вещи — продолжения.

V>Некоторые вещи, например, наличие таблицы ф-ий в самом объекте, или сугубо событийное т.е функциональное программирование, похоже на то, как ООП эмулируется замыканиями, где объект представляет из себя фактически открытый тупл из замыканий (методов) и полезных полей. И тогда this может приходить в каком угодно по счету аргументе — зависит от сигнатуры метода, которому удовлетворяет это замыкание и то, из каких других функциональных объектов оно было образовано.

а пример можно? интересно именно как "this может приходить в каком угодно по счету аргументе"

(что же касается дуку, то там, если я правильно понял, нет сборки мусора и даже нет замыканий — объекты строятся явным образом; впрочем, возможно что там замыкание создается с помощью копирования объектов и ссылок, и про это просто умолчали)

Здравствуйте, m e, Вы писали:

V>>Некоторые вещи, например, наличие таблицы ф-ий в самом объекте, или сугубо событийное т.е функциональное программирование, похоже на то, как ООП эмулируется замыканиями, где объект представляет из себя фактически открытый тупл из замыканий (методов) и полезных полей. И тогда this может приходить в каком угодно по счету аргументе — зависит от сигнатуры метода, которому удовлетворяет это замыкание и то, из каких других функциональных объектов оно было образовано.

ME>а пример можно? интересно именно как "this может приходить в каком угодно по счету аргументе"

Вариантов несколько. 1. this требуется для извлечения полей/методов. Например, адрес первого поля совпадает с this. 2. this может входить в одно из существующих замыканий, причем, самая дешевая физическая реализация замыканий — это пара: {адрес ф-ии, адрес аргументов}. В этом случае this может являться тем самым вторым элементом пары, т.е. подаваться как минимум вторым элементом на стек. Либо же третьим и выше, если аргумент-замыкание шел не первым в списке аргументов.

Для сравнения, реализация замыкания в ООП-стиле (через абстрактный метод с нужной сигнатурой) — это +2 к уровню косвенности при извлечении адреса целевой ф-ии. В кучерявых вложенных замыканиях это будет в 2 и более раза проседание производительности.

ME>(что же касается дуку, то там, если я правильно понял, нет сборки мусора и даже нет замыканий — объекты строятся явным образом; впрочем, возможно что там замыкание создается с помощью копирования объектов и ссылок, и про это просто умолчали)

А нафига GC при однократном строительстве графов объектов? Тем паче, что вирус должен создавать минимум издержек, чтобы быть менее заметным. Бери для сравнения так же критичные к эффективности приложения — мультимедия. В них граф объектов строится лишь при инициализации, а затем данные просто передаются по графу без дополнительных выделений памяти из кучи по мере событий поступления входных данных (по сети или с диска).

Здравствуйте, dudkin, Вы писали:

L>>Нашел кое-что от ЛК: Загадка фреймворка Duqu

D>ну и где они там нашли неизвестный компилятор?

Так про неизвестный компилятор я ничего не говорил. Я всего лишь выдвинул дилетантское предположение о том, что для создания Duqu могли использовать язык Форт, разновидностей коего предостаточно.

Здравствуйте, m e, Вы писали:

ME>а пример можно? интересно именно как "this может приходить в каком угодно по счету аргументе"
А в чём проблема?
У нас же нет "настоящего" ООП. Пишем функцию типа

int Append(Item & item, List * this)

Кладём указатель на неё в слот append, и вызываем:

pList1->append(item, pList1);

Вуаля — this передан не первым.
Фиксированный порядок this возникает только там, где его подстановка неявно выполняется компилятором.
Кроме того, расположение method table внутри объекта тоже не фиксировано — то есть либо это всё же голый C, где разметка слотов выполнена вручную, либо какой-то реальный язык высокого уровня с оптимизирующей (?) трансляцией в аналог вот такого С.

ME>(что же касается дуку, то там, если я правильно понял, нет сборки мусора и даже нет замыканий — объекты строятся явным образом; впрочем, возможно что там замыкание создается с помощью копирования объектов и ссылок, и про это просто умолчали)
Я не вижу, как можно определить отсутствие либо наличие замыканий в исходном языке по скомпилированному коду.

Здравствуйте, IT, Вы писали:

IT>Инопланетяне? Асари или даже может быть кварианцы.
Классический вариант — с клингона — я бы тоже сразу отбрасывать не стал.

S>pList1->append(item, pList1);

S>Вуаля — this передан не первым.

гы! я почему-то думал встретить там нечто сложное, и даже не догадывался до столь простого

S>Я не вижу, как можно определить отсутствие либо наличие замыканий в исходном языке по скомпилированному коду.

вопрос интересный

если примитивно подойти к делу, то замыкания будут копировать весь стековый фрейм, в т.ч. лишние переменные, а не только "замкнутые" переменные

Здравствуйте, m e, Вы писали:

ME>если примитивно подойти к делу, то замыкания будут копировать весь стековый фрейм, в т.ч. лишние переменные, а не только "замкнутые" переменные
Непонятно, зачем им это делать.

KV>Это был C с каким-то ОО-фреймворком:

А мне непонятно, почему вдруг это так важно — на чём написан?
По-моему, гораздо важнее чем пакован/криптован (если, конечно, это так).

Здравствуйте, x64, Вы писали:

KV>>Это был C с каким-то ОО-фреймворком:

x64>А мне непонятно, почему вдруг это так важно — на чём написан?

Потому что это хороший параметр для оценки того, что ещё можно ожидать от его авторов. С какой-то вероятностью и идентификация источника.
Даже если нельзя определить личность автора, можно о нём что-то понять.

x64>По-моему, гораздо важнее чем пакован/криптован (если, конечно, это так).

А это уже вопрос метода функционирования.

Здравствуйте, x64, Вы писали:

KV>>Это был C с каким-то ОО-фреймворком:
x64>А мне непонятно, почему вдруг это так важно — на чём написан?
спортивный интерес? на стадии реверсинга определить компилятор и библиотеки важно, т.к. это ускоряет анализ. ида не всесильна и не все библиотеки распознает даже из числа стандартных. а если они нестандартные и необычные, то очень полезно откомпилировать этим компилятором набор типичных конструкций, а в случае библиотек -- посмотреть исходный код. это реально ускоряет анализ. а вот после анализа... гм... ну я не знаю... на фига знать на чем оно написано?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Это был C с каким-то ОО-фреймворком

свистуны эти лаборанты касперского "мы спросили самых серьезных специалистов-реверсеров в Microsoft"!
и код хоть и был сгенерен Си-шный, но компилировали Visual С++ это он во время оптимизации умеет по разным регистрам параметры раскидывать ( Си компилер следует calling conventions )

Здравствуйте, Sinclair, Вы писали:

S>Кладём указатель на неё в слот append, и вызываем:
S>pList1->append(item, pList1);

Кстати, такой порядок — норма для всех штатных API Erlang'а — модифицируемый "объект" (структура данных) последним аргументом.

Не происходит ли эта манера из каких-то теоретических работ?

ME>>(что же касается дуку, то там, если я правильно понял, нет сборки мусора и даже нет замыканий — объекты строятся явным образом; впрочем, возможно что там замыкание создается с помощью копирования объектов и ссылок, и про это просто умолчали)
S>Я не вижу, как можно определить отсутствие либо наличие замыканий в исходном языке по скомпилированному коду.

В C-подобном языке замыкания, пригодные для вызова совсем постороннего кода, могут быть построены только генерацией кода на ходу. Это достаточно характерное действие. Для ABI стиля x86-32 в этом случае есть порождение в выделенном исполняемом сегменте команд типа push constant; jmp function2. Для ABI x86-64 (неважно, Windows или по стандарту AMD, как в Unix) это генерация в таком же сегменте циклического сдвига группы регистров, записи константы в один из них и всё того же jmp.

В C++-подобном языке, и во фреймворках для C типа GLib, замыкание опознаётся через структуру, состоящую из указателя на функцию и одного или нескольких параметров данных. Оптимизация может это нарушить, в простом видимом компилятору случае, и тогда действительно может быть нетривиально; но если структура осталась целой (чем более сложный код, тем вероятнее это), то именно такое сочетание, его одномоментное формирование без последующей модификации и его реализация (параметры добавляются в вызов функции по указателю, пришедшему с ними) заставляет подозревать замыкание.

Здравствуйте, мыщъх, Вы писали:

М>спортивный интерес? на стадии реверсинга определить компилятор и библиотеки важно, т.к. это ускоряет анализ. ида не всесильна и не все библиотеки распознает даже из числа стандартных. а если они нестандартные и необычные, то очень полезно откомпилировать этим компилятором набор типичных конструкций, а в случае библиотек -- посмотреть исходный код. это реально ускоряет анализ. а вот после анализа... гм... ну я не знаю... на фига знать на чем оно написано?

да тут похоже "эксперт суменков" только от груди касперского отняли, решил удивить мир

Здравствуйте, dudkin, Вы писали:

D>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Это был C с каким-то ОО-фреймворком

D>свистуны эти лаборанты касперского "мы спросили самых серьезных специалистов-реверсеров в Microsoft"!

Я думаю, это просто в MS нормальных спецов не осталось. Или они не заинтересованы что-то делать.

D>и код хоть и был сгенерен Си-шный, но компилировали Visual С++ это он во время оптимизации умеет по разным регистрам параметры раскидывать ( Си компилер следует calling conventions )

Вообще-то там не было приведено ни одного показательного примера размещения аргументов в регистрах. В примере с class2_count и class2_dtor используется первое слово на стеке, это вообще самый стандартный вариант. У конструктора параметров нет. Может, где-то оно и может быть "в любом регистре или на стеке", но или у Вас тайные от нас знания о внутренностях Duqu, или у нас всех тут нет реальных данных и я не вижу причин верить в эти утверждения про "любой регистр".

Здравствуйте, мыщъх, Вы писали:


М>calling conventions только для внешних функций. для остальных -- в соглашениях нет необходимости, особенно с появлением глобальной оптимизации. вот когда все функции транслировались независимо друг от друга, то тут без соглашений было никак. а с глобальной оптимизацией -- как хочу, так и передаю параметры. главное, чтобы гарантированно эти функции не вызывал никто другой, что и отслеживает компилятор.

в c насколько я помню конвенция и для внутренних соблюдается, эта фича с++. хотя могу и путать.

М>кстати, а кто там "самый серьезный в ms"? без упоминания имен -- как-то несерьезно. это же не гос. тайна. могли бы сослаться на конкретных людей, желательно процитировав их ответ, ибо "хз, с ходу не ответишь, а серьезно разбираться ни времени, ни мазы нет" радикально отличается "мы потратили 100500 человеко-часов и over 9000 баксов, но так и не нашли компилятор".

да бред эти эксперты, написал какому нибудь такому же олуху, а тот мож и рад бы прочитать его английский не разобрать.


М>кстати, спецы из ms не специализируются на отождествлении компиляторов. это делают другие фирмы. и делают это профессионально и, конечно, за бабки. зачем они это делают? а очень просто. когда начинаются судебные разборки между А и Б нужно как минимум доказать, что схожесть бинарников не обусловлена особенностью кодогенерации или библиотек. простой пример. напишите простой цикл for, do и while. умный оптимизатор во всех трех случаях сгенерит полностью идентичный код ибо различия нивелируются еще на подступах к оптимищации.

микрософт хорошо и быстро отвечает когда найдешь у них баг, или когда им самим чего то нужно. а так смысл то? да и кому писать на деревню билу

М>почему бы не направить запрос в фирму, которая непосредственно занимается такими вопросами? вероятно, потому что фирма потребует денег, а денег никто давать не собирается, ибо это чисто спортивный интерес.

да тут просто парень блестнуть хотел. слабо верится что он и в правду сидел перебирал компиляторы, с той же скоростью с которой отвечал добрым самаритянам

Здравствуйте, netch80, Вы писали:



N>Вообще-то там не было приведено ни одного показательного примера размещения аргументов в регистрах. В примере с class2_count и class2_dtor используется первое слово на стеке, это вообще самый стандартный вариант. У конструктора параметров нет. Может, где-то оно и может быть "в любом регистре или на стеке", но или у Вас тайные от нас знания о внутренностях Duqu, или у нас всех тут нет реальных данных и я не вижу причин верить в эти утверждения про "любой регистр".


упс, чуть не спалилсо
не. я просто сам несколько раз видел как неожиданно посреди функции вдруг начинают использовать esi там или edx. без соответствующего push, без инициализации, и без pop в конце. то есть переданный как параметер, видел такое только с С++. в С все более менее шаблонно.

Здравствуйте, мыщъх, Вы писали:

М>calling conventions только для внешних функций. для остальных -- в соглашениях нет необходимости, особенно с появлением глобальной оптимизации. вот когда все функции транслировались независимо друг от друга, то тут без соглашений было никак. а с глобальной оптимизацией -- как хочу, так и передаю параметры. главное, чтобы гарантированно эти функции не вызывал никто другой, что и отслеживает компилятор.

А вот против этого, кстати, работает манглинг. Если есть foo() с двумя аргументами, и не static, то можно сгенерировать foo для стандартной конвенции и __3foo${12ff073af8740820} для своей, специальной для данного случая (под хэшом — представление параметров).

М>почему бы не направить запрос в фирму, которая непосредственно занимается такими вопросами? вероятно, потому что фирма потребует денег, а денег никто давать не собирается, ибо это чисто спортивный интерес.

+1.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, мыщъх, Вы писали:

М>>calling conventions только для внешних функций. для остальных -- в соглашениях нет необходимости, особенно с появлением глобальной оптимизации. вот когда все функции транслировались независимо друг от друга, то тут без соглашений было никак. а с глобальной оптимизацией -- как хочу, так и передаю параметры. главное, чтобы гарантированно эти функции не вызывал никто другой, что и отслеживает компилятор.

N>А вот против этого, кстати, работает манглинг. Если есть foo() с двумя аргументами, и не static, то можно сгенерировать foo для стандартной конвенции и __3foo${12ff073af8740820} для своей, специальной для данного случая (под хэшом — представление параметров).

да, в простых случаях работает. в более сложных (при возврате структур по значению) компилятор начинает извращаться. пару раз видел, что компилятор заменил значение ссылкой. обычно же структура копируется во временную переменную, но тут компилятор выкинул очень странных финт. локальная структура дочерней функции была выделена в скрытом аргументе этой функции, с которой эта функция и работала. а по ее завершению -- компилятор вернул указатель и не освобождал аргументы вплоть до завершения матери. в результате удалось сэкономить на компировании структуры во временную переменную, что и память и время. хотя вообще-то умные программисты так и поступают даже без помощи компилятора. лучше выделить память самим и передать ее как аргумент, чем возвращать по значению структуру. хотя последнее -- удобнее.

http://habrahabr.ru/post/140288/
Антивирусники пиарятся, развели понимаешь детективную историю на пустом месте. Это надо же было потратить столько времени чтобы догадаться что троян написан на самом распространенном языке и собран самым распространенным компилятором.