Я бы еще компилятор от Intel упомянул. Там крайне интересная кодогенерация и крайне интересные возможности по использованию расширенных инструкций процессора. Некоторые настолько редкие используются, что их даже IDA не может скушать.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
wacatac.b!ml
- Автор темы secidiot
- Дата начала
Он discontinued. =)
А тот, что icx (Intel oneAPI DPC++/C++ Compiler) - это форк кланга, очевидно он лучше, чем msvc, так как сам кланг лучше, чем msvc. =)
А бекенд там что? Clang это фронтенд. Как бек там LLVM, но если этот LLVM-байткод перегонять в конкретный таргет архитектурный, то ему требуется бекенд, на винде он использует msvc, если явно не указан mingw или типа того.
Бекенд у него llvm, вообще кланг и llvm это единый проект, и кланг зависит от бекенда llvm, и ему не требуется msvc для генерации кода. Всё что ему нужно от msvc - это его либы, хотя к самому msvc как компилятору это уже не имеет никакого отношения. =)
Я хз, но у меня с дефолт установки clang подтягивает msvc и даже генерит RICH хидеры и жрёт в том числе msvc'шные флаги линкеру.
На одной машине если с установленным MSVC его ставить, то при:
он генерерирует бинарь используя MSVC. И вот смотрю даже Rich хидер присутствует. Только что попробовал.
На машине без MSVC ни разу не пробовал. Но там где был MinGW он использовал MinGW.
clang -v принтит такое в target:
x86_64-pc-windows-msvc
Ты используешь кланг, который идёт в комплекте со студией? Если да, то это скорее всего не оригинальный кланг, а форк мелкософта. Поставь себе нормальный кланг.
А теперь что касается фронтендов и бекендов. Фронтенд это та часть компилятора, которая генерит байткод для бекенда. Задача фронтенда распарсить язык и скомпилировать его в промежуточную интерпретацию. Затем эта интерпретация (LLVM IR в нашем случае) скармливается бекенду, в нашем случае LLVM, который уже генерит машинный код. MSVC не понимает IR, предназначенный LLVM'у, тоже самое касается и GCC, у него свой фронт и бек. Поэтому описанного тобою просто быть не может. Если этот шланг генерит IR для бекенда msvc, значит это кастомный форк, потому что бекенд msvc закрыт и только мелкософт знает, какое у него там промежуточное представление. А вообще скажу честно, это очень странно, не берусь утверждать потому что не помню, но по идее и фронт, и бек компилятся в один экзешник. То есть вообще не может быть такого, что кланг куда-то свой IR передает за пределы своего процесса.
Clang из-за морфинга на основе LLVM который одно время был очень популярен сейчас палиться статически просто на уровне авчека. Попробуй скомпилить им код и поверь чистой статики ты не получишь. Помню одно время файлы скомпиленые clang вообще не палились дефом просто он их не видел как будто а вот сейчас все поменялось.
По детекту то лично у меня получаеться пока обходить облако дефа чисто за счет накручивания инструкций конечно это не от меняет морф таблицы импорта/экспорта. По моему опыту деф орентируться вначале на импорт экспорт и секции а потом уже на код если код перегржен инструкциями то дело в секциях строках импорте или экспорте ну или в строках смотря как они в коде реализованы. Например сейчас облако дефа если видит в экспорте DllReg сразу ставит детект.
Clang на винде по дефолту использует линкер от MSVC - он и генерирует rich-хидер. Можно так же использовать GNU ld или родной lld.
LLD - The LLVM Linker — lld 20.0.0git documentation
lld.llvm.org
Последнее редактирование:
Попробовать под виндой не могу, потому что виндой не пользуюсь. =)
Если проблема существует, то вряд ли она из-за LLVM, потому что в противном случае туда же отлетали бы и раст, и nim, и scala и ещё туча языков. Что может выделять кланг, так это генерация более оптимального кода, нежели у msvc, кланг будучи нормальным компилятором очень неплохо оптимизирует и местами векторизирует код, в то время как msvc чаще всего компилирует "в лоб", "как есть", из-за чего код довольно прямолинейный (за счет чего его легко реверсить) и без сложных инструкций и оптимизаций. А насчет специфических строк... Не припомню, чтобы кланг какую-то отсебятину добавлял. Скажу честно, мне даже интересно стало, если можно, я бы хотел взглянуть на такие самплы (желательно воспроизводимые). =)
А что касается детектов, тут могу достоверно заявить, что у msvc точно не всё гладко. Это из недавних примеров, помню был ещё подобный пример у гугла, а причина тому, что большинство малварщиков юзают именно msvc, а нормальные плюсовики из крупных компаний в основном предпочитают кланг или gcc. =)
Clang от microsoft*, скорее всего. Когда я пользовался виндой и компилил клангом (тогда ставил его из официальных релизов), он юзал родной lld. Может быть с тех пор под виндой что-то поменялось, не знаю. ¯\_(ツ)_/¯
А вообще я за всё время о линкере даже не подумал, наверное всё же спать ночью надо. =)
Могу ошибаться, но это может зависеть от тулчейна, которым был собран clang.
Я говорил про clang который входит в состав visual studio потому-что другова опыта нет когда-то это была панацея сейчас статик детект видимо по rich хидеру. Или по спецефическим секциям которые он добовляет.
С гитхаба этого я и качал его, в msvc нет clang'а, во всяком случае в тех версиях которые юзают я, я дальше 2015 студии не поднимался. Но у меня и цланг древний, судя по всему. Уже 18 версия есть, как погляжу. А у меня 9-я стоит.
Я это всё понимаю. Я поэтому и пишу это, интересуясь, потому что для меня тоже странно. Я глубоко в компиляторы не нырял и не копал, для моих задач это не требуется. Но факт остаётся фактом. Вспомнить бы еще как именно я его устанавливал.
Это дело такое, как и с редкоиспользуемчм кодом. Раз в пару лет тачку сетапишь и забываешь.
P.S. Посмотрел подробнее, сравнив два бинаря. Код из под clang-msvc отличается от msvc в чистую. Он генерирует совершенно иначе его. Но при этом всё равно бинарь как из под студии собран. Даже секции те же все технические. И Rich хидеры. Такое впечатление что он просто линкер msvc дергает, надо посмотреть еще что там в объектниках используется.
UPD: ну да, всё верно. Линкер мсвцшный идёт по дефолту. Можно сменить на mingw'шный
Давай пожалуйста не будем больше пиарить ни gcc ни clang, чтобы все малварщики использовали msvc в чистом виде. Нам от этого ничего не перепадёт. Тут либо каждый сам за себя, либо объединяется в команды и делает всё вместе.
del
Последнее редактирование:
Так и есть, малварщики под винду стараются не использовать ни gcc ни clang - по причине того что майкрософт не будет ставить лишнии детекты на свои продукты, потому что это будет убивать их и так с трудом сформированное сообщество которое пишет на VS - где то тут логика. Но текущий детект в шапке темы - единственная проблема которую довольно таки сложно предсказать, на моем опыте он очень не предсказуемый и чаще всего с ним сталкивался после прохождения исполняемого кода в облаке, после детект данного кода в течении суток - двое появлялся в базах на данный бинарь. Как и писал выше сложилось впечатление, что в облаке запускается бинарь, смотрится что он делает, и если по какой то магии системе кажется что бинарь не несет "смысловой" нагрузки ставится детект, еще сложилось впечатление что детект идет именно на бинарники компилированные на VS. Хотелось бы найти человека который бы более детально данный детект изучал и более точно пояснил причины его появления, я постарался выше описать то что сам смог выяснить.
а кто-то сталкивался с Trojan:Win32/SuspGolang.AG? сейчас такая же проблема. вд начал рандомно вешать этот детект почти на каждый билд
ChatGPT говорит что LLVM/Clang тоже может добавлять метаданные (в том числе и Rich headers). Только это зависит от настроек и платформы. Поэтому это надо отдельно проверять.
del
Последнее редактирование:
Are you using garble?
I think garble won't help to bypass AVs it is certainly intended to obfuscate Go imports, functions name and to remove debug infos to further complicate the RE process.