Здравствуйте, 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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>если примитивно подойти к делу, то замыкания будут копировать весь стековый фрейм, в т.ч. лишние переменные, а не только "замкнутые" переменные
Непонятно, зачем им это делать.

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

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

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

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

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

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

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

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

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