C++ Исходник Lazy Import

[annihilatorq]

Всем привет!
Новый single-header репозиторий с моим вариантом реализации техники лейзи импорта, все подробности расписал в readme. Буду обновлять и фиксить когда потребуется. К сожалению на данный момент таргетил только MSVC, возможно в будущем исправлюсь и перепишу под другие популярные компиляторы)
Поддерживается Release/Debug x64-x86, от 14 до 23 стандарта cpp.

Пожалуйста, авторизуйтесь для просмотра ссылки.

заранее спасибо за толковые советы по улучшению каких-либо аспектов

 

[.TWiSTED]

Всем привет!
Новый single-header репозиторий с моим вариантом реализации техники лейзи импорта, все подробности расписал в readme. Буду обновлять и фиксить когда потребуется. К сожалению на данный момент таргетил только MSVC, возможно в будущем исправлюсь и перепишу под другие популярные компиляторы)
Поддерживается Release/Debug x64-x86, от 14 до 23 стандарта cpp.

Пожалуйста, авторизуйтесь для просмотра ссылки.

заранее спасибо за толковые советы по улучшению каких-либо аспектов

Не особо понятен смысл этого, даже слов подобрать не могу.
"
LI(int, MessageBoxA).call(nullptr, "Hello world.", "Goodbye world...", MB_OK);
"
MessageBox возвращает BOOL , а тут указано как int.
Простые примеры можно делать как угодно.
А вот как на счет HeapAlloc, HeapReAlloc, HeapCreate? Lazy не особо справляется с этими функциями.

 

[Allah_enjoyer]

нахуя юзать лейзи импортер если импорты которые ты используешь один хуй используются и будут дт
это не зависит от того будешь ты их скрывать или нет, они все равно вызываются

 

[Virtualizer]

MessageBox возвращает BOOL , а тут указано как int.

Пожалуйста, авторизуйтесь для просмотра ссылки.

возвращает int, а BOOL в WINAPI это int.

нахуя юзать лейзи импортер если импорты которые ты используешь один хуй используются и будут дт
это не зависит от того будешь ты их скрывать или нет, они все равно вызываются

Хотя бы для того шоб не юзать GetProcAddress и не палить IAT, а по детекту ты прав, смысла 0

 

[mhalaider]

Всем привет!
Новый single-header репозиторий с моим вариантом реализации техники лейзи импорта, все подробности расписал в readme. Буду обновлять и фиксить когда потребуется. К сожалению на данный момент таргетил только MSVC, возможно в будущем исправлюсь и перепишу под другие популярные компиляторы)
Поддерживается Release/Debug x64-x86, от 14 до 23 стандарта cpp.

Пожалуйста, авторизуйтесь для просмотра ссылки.

заранее спасибо за толковые советы по улучшению каких-либо аспектов

Снова прикол подъехал, кайф, но думаю всё так же это будет биться по сигнатурке, чего так или иначе не избежать.

А вот как на счет HeapAlloc, HeapReAlloc, HeapCreate? Lazy не особо справляется с этими функциями.

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

 

[.TWiSTED]

Хотя бы для того шоб не юзать GetProcAddress

Можно кастомный заюзать.

PVOID   GetProcAddress(HMODULE hModule, const char* funcname)
{
    if (!hModule)
        return NULL;

    int a;
    char buf[MAX_PATH];

    int b;
    char name[MAX_PATH];
    memset(name, 0, MAX_PATH);

    strcat(name, funcname);
    for (b = 0; name[b] != L'\0'; b++)
    {
        name[b] = towlower(name[b]);
    }

    PIMAGE_DOS_HEADER      DosHeader = (PIMAGE_DOS_HEADER)RVATOVA(hModule, 0);
    PIMAGE_NT_HEADERS      NtHeader = (PIMAGE_NT_HEADERS)RVATOVA(hModule, DosHeader->e_lfanew);
    PIMAGE_OPTIONAL_HEADER OptionalHeader = &NtHeader->OptionalHeader;

    if (OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].Size) {
        PIMAGE_EXPORT_DIRECTORY ExmportDirectory = (PIMAGE_EXPORT_DIRECTORY)RVATOVA(hModule, OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress);
        DWORD                   NumberOfNames = ExmportDirectory->NumberOfNames;
        PDWORD                  AddressOfFunctions = (PDWORD)RVATOVA(hModule, ExmportDirectory->AddressOfFunctions);
        PDWORD                  AddressOfNames = (PDWORD)RVATOVA(hModule, ExmportDirectory->AddressOfNames);
        PUSHORT                 AddressOfNameOrdinals = (PUSHORT)RVATOVA(hModule, ExmportDirectory->AddressOfNameOrdinals);

        for (DWORD i = 0; i < NumberOfNames; i++)
        {

            strcat(buf, (LPCSTR)RVATOVA(hModule, AddressOfNames[i]));

            for (a = 0; buf[a] != '\0'; a++)
            {
                buf[a] = tolower(buf[a]);
            }

            if (strstr(buf, name))
            {
                return RVATOVA(hModule, AddressOfFunctions[AddressOfNameOrdinals[i]]);
            }
            memset(buf, 0, MAX_PATH);
        }
    }
    return NULL;
}

Приведи рабочий пример с использованием HeapAlloc, HeapReAlloc, HeapCreate , memcpy, memset и т.п.
Иначе оно не отличается от орегинала.

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

то я не туда посмотрел)

 

[Virtualizer]

ты со своими сисколами уже тоже отличился , прекращай постиронить

Дак ты бы для начала сам высрал что-нибудь чем просто засирать треды как СДВГшный дебик

А вот как на счет HeapAlloc, HeapReAlloc, HeapCreate? Lazy не особо справляется с этими функциями.

LI жидко обсирается при юзе в каком-нибудь PresentScene, про хеп/маллок ваще молчу, там жесткий оверхед, разраб так и не пофиксил это

 

[Allah_enjoyer]

Дак ты бы для начала сам высрал что-нибудь чем просто засирать треды как СДВГшный дебик

у меня нет поносной пасты для лика

 

[syscall]

Привет, сможешь прикрепить как это будет выглядеть в иде и в рантайме? Все также плохо как у стандартного лейзи?

 

[invers1on]

Привет, сможешь прикрепить как это будет выглядеть в иде и в рантайме? Все также плохо как у стандартного лейзи?

На гитхабе есть всё

 

[invers1on]

На гитхабе рантайма нету
Есть только скрин приложенный с программы для статического анализа ( IDA: Pro )
Да и кстати, я тя в попу трах трах

А как этот код отличатся в рантайме будет?

 

[syscall]

А как этот код отличатся в рантайме будет?

Посмотреть вложение 264515

Ты бы сначала посмотрел, что с обычным лейзиком в рантайме
Раз ТС переделал этот лейзи импортер, я спросил, что по поводу рантайма? Все ли там плохо, как в обычном или по другому?

 

[metafaze]

история циклична

Shadow syscalls (x64, MASM branch, Shellcode branch)

Достаточно удобный в использовании враппер сискола. мой первый (но не последний) гитхаб репо: https://github.com/annihilatorq/shadow_syscall в будущем будет обновляться. буду рад адекватному фидбэку и советам.

yougame.biz

 

[invers1on]

Ты бы сначала посмотрел, что с обычным лейзиком в рантайме
Раз ТС переделал этот лейзи импортер, я спросил, что по поводу рантайма? Все ли там плохо, как в обычном или по другому?

Перечитай своё общению, иду ты тоже упомянул, скорее всего ты хотел посмотреть асм листинг, но неправильно выразился.А что с "Лейзиком" в рантайме быть должно?Получает модули с пеба, крутит экспорты , или тебе илон маск сигналы шлет и своим межгалактическим , метаморфным движком каждую итерацию цикла мутирует бинарь?

 

[OXXXYMlRON]

единственное что могу добавить - мемберы винапи/нт структур можно было бы и переименовать в снейк_кейс, коли ты используешь снейк кейс в мемберах классов/структур

выглядит заебись

 

[invers1on]

единственное что могу добавить - мемберы винапи/нт структур можно было бы и переименовать в снейк_кейс, коли ты используешь снейк кейс в мемберах классов/структур

выглядит заебись

Заебешься переименовывать, но для соблюдени код стайла было бы не плохо, а ваще не был бы это single-header репозиторий, есть замечательная штука как

Пожалуйста, авторизуйтесь для просмотра ссылки.

 

[annihilatorq]

нахуя юзать лейзи импортер если импорты которые ты используешь один хуй используются и будут дт
это не зависит от того будешь ты их скрывать или нет, они все равно вызываются

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

это не зависит от того будешь ты их скрывать или нет, они все равно вызываются

на уровне - зачем проекту делать защиту от кряка если всё равно всё можно крякнуть))))
или
зачем делать шифрование запросов если через 25 лет супер компьютер всё равно их расшифрует?

Можно кастомный заюзать.

PVOID   GetProcAddress(HMODULE hModule, const char* funcname)
{
    if (!hModule)
        return NULL;

    int a;
    char buf[MAX_PATH];

    int b;
    char name[MAX_PATH];
    memset(name, 0, MAX_PATH);

    strcat(name, funcname);
    for (b = 0; name[b] != L'\0'; b++)
    {
        name[b] = towlower(name[b]);
    }

    PIMAGE_DOS_HEADER      DosHeader = (PIMAGE_DOS_HEADER)RVATOVA(hModule, 0);
    PIMAGE_NT_HEADERS      NtHeader = (PIMAGE_NT_HEADERS)RVATOVA(hModule, DosHeader->e_lfanew);
    PIMAGE_OPTIONAL_HEADER OptionalHeader = &NtHeader->OptionalHeader;

    if (OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].Size) {
        PIMAGE_EXPORT_DIRECTORY ExmportDirectory = (PIMAGE_EXPORT_DIRECTORY)RVATOVA(hModule, OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress);
        DWORD                   NumberOfNames = ExmportDirectory->NumberOfNames;
        PDWORD                  AddressOfFunctions = (PDWORD)RVATOVA(hModule, ExmportDirectory->AddressOfFunctions);
        PDWORD                  AddressOfNames = (PDWORD)RVATOVA(hModule, ExmportDirectory->AddressOfNames);
        PUSHORT                 AddressOfNameOrdinals = (PUSHORT)RVATOVA(hModule, ExmportDirectory->AddressOfNameOrdinals);

        for (DWORD i = 0; i < NumberOfNames; i++)
        {

            strcat(buf, (LPCSTR)RVATOVA(hModule, AddressOfNames[i]));

            for (a = 0; buf[a] != '\0'; a++)
            {
                buf[a] = tolower(buf[a]);
            }

            if (strstr(buf, name))
            {
                return RVATOVA(hModule, AddressOfFunctions[AddressOfNameOrdinals[i]]);
            }
            memset(buf, 0, MAX_PATH);
        }
    }
    return NULL;
}

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

Приведи рабочий пример с использованием HeapAlloc, HeapReAlloc, HeapCreate , memcpy, memset и т.п.
Иначе оно не отличается от орегинала.

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

MessageBox возвращает BOOL , а тут указано как int.
Простые примеры можно делать как угодно.
А вот как на счет HeapAlloc, HeapReAlloc, HeapCreate? Lazy не особо справляется с этими функциями.

literally

 

[annihilatorq]

про хеп/маллок ваще молчу, разраб так и не пофиксил это

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

а пока

HeapAlloc обращается к RtlAllocateHeap, пока не найду решения проблемы с AV, можете делать подобный вызов для использования HeapAlloc()

LI(LPVOID, RtlAllocateHeap).call(LI(HANDLE, GetProcessHeap).call(), 0, static_cast<SIZE_T>(100));

upd: подъехало объяснение, спасибо invers1on

 

[mj12]

Вечно можно смотреть на три вещи, одна из них реверс нативных функций винды, красавчик +rep

 

[Morphling]

Можно кастомный заюзать.

///////////

strstr

ура блять