• XSS.stack #1 – первый литературный журнал от юзеров форума

Компиляция приложения внутри приложения

Disya

Премиум
Premium
Регистрация
19.11.2022
Сообщения
19
Реакции
6
Я хочу сделать генерацию кода и компиляцию кода внутри приложения на c/c++(90% кода на с++). Как это возможно сделать, желательно без триллиона кода? Пишу приложение на базе imgui
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Как это возможно сделать, желательно без триллиона кода?
Не получится без триллиона кода. Если ты хочешь так компилировать Плюсы, то берешь Clang+LLVM+LLD, если Цэ, то можно посмотреть, будет ли libtcc генерировать нормальный для тебя код, эта библиотека существенно меньше.
 
Не получится без триллиона кода. Если ты хочешь так компилировать Плюсы, то берешь Clang+LLVM+LLD, если Цэ, то можно посмотреть, будет ли libtcc генерировать нормальный для тебя код, эта библиотека существенно меньше.
а что если взять libtcc и с ещё помощью реализовать авторан путём инфекта дллок уже имеющихся в авторане софтин

не знал про эту либу спасибо !
 
там же можно и цешный код запускать в памяти, это же сколько путей обхода ав открывается, мм ..
 
Пожалуйста, обратите внимание, что пользователь заблокирован
там же можно и цешный код запускать в памяти, это же сколько путей обхода ав открывается, мм ..
Ну я не вижу существенных преимуществ этого перед загрузкой DLL или COFF из памяти.
 
Ну я не вижу существенных преимуществ этого перед загрузкой DLL или COFF из памяти.
преимущество огромное. тут вопрос философии ав, ставить детекты на файлы tcc ни кто не будет, а компилятор позволяет запускать код в памяти, из этого получаем вечноживущий способ обхода ав. по типу go run фича
 
Ну я не вижу существенных преимуществ этого перед загрузкой DLL или COFF из памяти.
httpx://scanner[.]to/result/Rl5uA4rVkx
концепт чистый вроде как
 
Пожалуйста, обратите внимание, что пользователь заблокирован
преимущество огромное. тут вопрос философии ав, ставить детекты на файлы tcc ни кто не будет, а компилятор позволяет запускать код в памяти
Ну и где это огромное преимущество? Как в одном случае ты из памяти на исполняемые страницы грузишь код, так и в другом. Для антивируса в рантайме абсолютно нет разницы, положил ты на rwe страницы код из JIT-компилятора, или из COFF-объектника, или из DLL.
 
Ну и где это огромное преимущество? Как в одном случае ты из памяти на исполняемые страницы грузишь код, так и в другом. Для антивируса в рантайме абсолютно нет разницы, положил ты на rwe страницы код из JIT-компилятора, или из COFF-объектника, или из DLL.
вопрос статики отходит на много легче чем при обычных обстоятельствах
 
Пожалуйста, обратите внимание, что пользователь заблокирован
вопрос статики отходит на много легче чем при обычных обстоятельствах
Чем легче? Что у тебя будет зашифрованный сорс, который ты будешь из памяти компилить, что у тебя будет зашифрованная длл, которую ты будешь из памяти загружать, вообще нет разницы.
 
Чем легче? Что у тебя будет зашифрованный сорс, который ты будешь из памяти компилить, что у тебя будет зашифрованная длл, которую ты будешь из памяти загружать, вообще нет разницы.
сорс чистить легче, можно даже автоматизировать насрав коментами и пустыми макросами к примеру. а крипт ещё сделай так что бы он детектов сам не добавил ; )
 
сорс чистить легче, можно даже автоматизировать насрав коментами и пустыми макросами к примеру. а крипт ещё сделай так что бы он детектов сам не добавил ; )
Так длл собрана из морфленного сорца, вопрос в том зачем тебе ее компилировать именно на таргете а не скомпилировать у себя и доставить готовое.
Болле того доставляя готовое ты можешь быть уверен что оно не палится и не падает так провел предварительную проверку, а если морфишь что то на месте то уверенности уже нет.
А еще если у аверов будет твой морфер и сборщик они нагенерят много копий и сделают очень устойчивые маски, ты заебешся потом отвязывать детекты.
 
Так длл собрана из морфленного сорца, вопрос в том зачем тебе ее компилировать именно на таргете а не скомпилировать у себя и доставить готовое.
Болле того доставляя готовое ты можешь быть уверен что оно не палится и не падает так провел предварительную проверку, а если морфишь что то на месте то уверенности уже нет.
я про то что детекты с .c файла снять в триллион раз легче чем с компил файла. а tcc.exe палиться не начнёт (скоро)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Болле того доставляя готовое ты можешь быть уверен что оно не палится и не падает так провел предварительную проверку, а если морфишь что то на месте то уверенности уже нет.
Нет, ну чисто гипотетически, единственная вещь, которая приходит в голову - это типа сидеть на таргете и генерировать новые образцы вредоноса, когда старые образцы спалились. Типа ты не осилил llvm или морфинг ассемблера, хочешь морфить цэ-исходники. Основная часть вредоноса в исходниках лежит, на таргете заморфил, скомпилил, положил и запустил. Сидишь и мониторишь, что авер не удалил основную часть, если удалил повторяешь заново. Но тут тоже много 'но', например, если часть, которая морфит и компилит, спалится сама по себе, то уж "наши полномочия всё, окончены", и тд.
 
Нет, ну чисто гипотетически, единственная вещь, которая приходит в голову - это типа сидеть на таргете и генерировать новые образцы вредоноса, когда старые образцы спалились. Типа ты не осилил llvm или морфинг ассемблера, хочешь морфить цэ-исходники. Основная часть вредоноса в исходниках лежит, на таргете заморфил, скомпилил, положил и запустил. Сидишь и мониторишь, что авер не удалил основную часть, если удалил повторяешь заново. Но тут тоже много 'но', например, если часть, которая морфит и компилит, спалится сама по себе, то уж "наши полномочия всё, окончены", и тд.
можно даже не компилить в этом смысл.. можно не держать .ехе файл итоговый а запускать наш .c файл в контексте tcc флагом -run
 
я про то что детекты с .c файла снять в триллион раз легче чем с компил файла. а tcc.exe палиться не начнёт (скоро)
С детектами проблема в нахождении причины, остальное уже как првило проще, хотя иногда придется переписать морф и заменить одну апи двумя другими, и вот проблема в нахождение что именно менять.

Нет, ну чисто гипотетически, единственная вещь, которая приходит в голову - это типа сидеть на таргете и генерировать новые образцы вредоноса, когда старые образцы спалились. Типа ты не осилил llvm или морфинг ассемблера, хочешь морфить цэ-исходники. Основная часть вредоноса в исходниках лежит, на таргете заморфил, скомпилил, положил и запустил. Сидишь и мониторишь, что авер не удалил основную часть, если удалил повторяешь заново. Но тут тоже много 'но', например, если часть, которая морфит и компилит, спалится сама по себе, то уж "наши полномочия всё, окончены", и тд.
Генеришь у себя на таргеты доставляешь билды, не спалился билд в массы, все равно генерить на таргете смысла нет.
 
ребята я не предлагаю на таргете вообще ничего генерировать ....
 
можно даже не компилить в этом смысл.. можно не держать .ехе файл итоговый а запускать наш .c файл в контексте tcc флагом -run
Тогда уже смотри в сторону как скриптовыми языками исполнить шеллкод.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх