Он по хорошему должен инлайниться.
Это функция из shlwapi.dll, добавь линкеру эту библиотеку и она появится, к CRT она не относится.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Статья Гайд: Отключаем CRT и Оптимизируем программу
- Автор темы c0d3r_0f_shr0d13ng3r
- Дата начала
тут другое. идёшь на мсдн https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathfileexistsw
внизу пишет Library Shlwapi.lib
подключаешь эту либу к проекту - profit!
Вот я тупанул, я думал что #pragma comment(lib, "Shlwapi.lib") добавила все в проект, а оказывается нет.
Max secure орет точно из-за отсутсвия нативных ресурсов и подписи
Остальные скорее всего тоже из-за этого
спасибо, помог. Без цлр будет трудно, но всё же. 
nice idea to remove iat hooks from userland but i think will face problem when encrypt it and load it with process hollowing .
thanks dude for this tut i will try it
thanks dude for this tut i will try it
- Автор темы
- Добавить закладку
- #47
Неа, проблем быть не должно.
Maybe there a problem in my Loader becouse i was trying to load some Stealer and the stealer has no IAT he almost fail but any other exe can load normaly
Дополнение: https://******/threads/503823/ заместо * bhf . im
Статья хорошая. Ты включил оптимизацию, не пойму зачем ты заглушку менял, она и так легкая
Я тут попробовал c параметром компоновщика filealign поиграться(парамент компоновщика /filealign:размер). По умолчанию секции на диске выровнены на границу 512 байт. Я пробовал установить /filealign:16, из 2.5 кб получил 1.1кб, однако бинарь крашит. Хз в чем проблема я в масме пробовал так делать там все вполне работало даже с выравневанием по 16 байтной границе. Короче все значения < 512 ставишь - краш.Мб кто то знает решение?
Так решения нет для нативного загрузчика венды. Я не помню подробностей, почему так, но загрузчик системы будет крашить пешники, у которых выравнивание меньше 512 байт. Там какие-то проблемы с отображением файла в память были вроде, которые к эксепшену приводят. В принципе, если ты сделаешь свой загрузчик, который с этим будет работать, то проблем не должно быть. В памяти выравнивание секций в любом случае предполагает 4096 байт.
Я не совсем правильно выразился, дело в том что как бы краша нет, но CreateProcess дает ошибку, мол неверный формат Win32 файла. Там что то со структурами PE. Один жучок я обнаружил - это поле e_lfanew в дос хидере указывало неправильный RVA на NT хидер , это то что я обнаружил, другое вроде все норм, но после попроавки все равно не работает, хз не внимательный я наверное
KasperWAF
Гость
/del, завис и перепутал термины
Последнее редактирование модератором:
Зачем его мне вычислять? Я говорю то что у меня e_lfanew содержал неправильный RVA до НТ хидера. Зачем мне что то прибавлять, если бы я пропатчил e_lfanew на базу + RVA получился бы VA, а это поле должно содержать именно RVA. И вообще когда ты писал то что в e_lfanew содержится смещение, а не RVA, то вообщем то какая разница?
KasperWAF
Гость
Сорри, перепутал термины. Но суть моего сообщения остается прежней, когда ты ставишь нестандартное выравнивание - у тебя едут секции и без понимания всех тонкостей/особенностей работы виндового загрузчика смысла играться с этим нету, ток нервы испортишь. В чем вообще проблема написать свой загрузчик и собирать/пересобирать PE как угодно, адаптировав загрузчик под нужный формат?
Дык с секциями все норм.... Для загрузчика нормально, то что секции так выровнены. По крайней мере по 16 байтной границе(знаю потому что проверял на масме выравнивания ставить по 16 байт и все норм было). И кстати в чем проблема по вашему мнению если секции съехали? В таблице секций RAW адреса вполне корректны
Поэкспериментировал немного на эту тему. Выход 401 байт, вполне себе рабочий exe, система кушает. Можно и меньше если руками поколдавать, Rich срезать и dos стаб может можно еще уменьшить.
Компилятор из Microsoft Windows SDK v7.1
64.stub
1.c
Компилятор из Microsoft Windows SDK v7.1
64.stub
Код:
4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00
B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 B8 00 00 001.c
C:
void entry() {
return;
}
Код:
cl.exe /nologo /c /O1 1.c
link.exe /nologo /SUBSYSTEM:WINDOWS /FIXED /ALIGN:1 /STUB:64.stub /ENTRY:entry 1.obj
Зачем вообще сейчас все эти извраты с отключением всего что только можно, что бы ужать программу ? Да даже лет 5-7 назад это уже было неактуально (и даже раньше не имело профита), те же крипторы пишутся сейчас так, что бы походить на нормальный софт, то есть как минимум должны быть +\- дефолтные настройки компиляции, весь этот CRT код наоборот добавит "+" к легиту софта на стороне ав. Никогда не понимал зачем ужимать так exe\dll, одно дело когда ты пишешь сплойты и нужен мелкий шелл, потому как буфер может быть ограничен, либо другие сложности, тогда еще надо думать о оптимизации по размеру. Я вам так скажу, тема эта со сжатием и получением бинаря в 1,5 кб на Сишке поднималась уже миллионы раз на форумах аж с каменного века и имела лишь смысл как померяться письками, только тут у кого меньше - лучше, но профита это никакого никогда не давало.
Шеллкод на С/С++ ты с CRT/STL не сделаешь. Если у тебя модульная малварь, а не всратый стиллак на 7мб, то можно не морочиться со всякими там TLS'ами, которую ты не используешь, но вынужден будешь настраивать при использлвании CRT при загрузке модулей в виртуальную память. CRT фиксированный код, его сложно интегрировать с какими-то обфускаторами и полиморфами. С одной стороны его и не нужно морфить, так как он стандартный и попадает один и тот же условно во все бинари, которые код используют, но это далеко не означает, что какой-то сраный авер не поставит на него комплексную сигнатуру. История с языком Nim вообще в этом плане достаточно показательна.