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

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

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

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

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

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

Здравствуйте, 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 в конце. то есть переданный как параметер, видел такое только с С++. в С все более менее шаблонно.

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

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

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

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

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

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

+1.

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

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

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

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

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

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