Делаю упаковщик x64 DLL.

Проверяю работоспособность через rundll32 dllname,funcname. Успешно загружается внутри с помощью LoadLibraryExW, потом следом rundll32 вызывает GetProcAddress для указанного экспорта (funcname) и в этот момент получаю exception в глубине GetProcAddress. Оказывается, что ее ловит CFG - Control Flow Guard в Windows 10, а именно исключение вызывает функция LdrControlFlowGuardEnforced().

На Windows 7 всё работает, выключаю защиту эксплоитов в Windows 10 - тоже всё работает.

Упакованную DLL загружаю через VirtualAlloc. Каждой секции проставляются нужные атрибуты с помощью VirtualProtect.

Вопрос, что делать???

Проставка флага /NXCOMPAT:NO для упакованного(на диске) и неупакованного файла(в памяти) ничего не дает.

| Сообщение посчитали полезным:

IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG после распаковки восстанавливаете? Целиком?
Как вариант, если не сохраняются CFGшные поля из IMAGE_LOAD_CONFIG_DIRECTORY можно попробовать снять IMAGE_DLLCHARACTERISTICS_GUARD_CF в pe-хидере.
Лучше покажите пример исходного файла и упакованного.

| Сообщение посчитали полезным:

RamMerlabs пишет:
IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG после распаковки восстанавливаете?
Это директории нет у неупакованного файла.

RamMerlabs пишет:
можно попробовать снять IMAGE_DLLCHARACTERISTICS_GUARD_CF
Этого флага тоже нет у упакованного файла.

| Сообщение посчитали полезным:

cracker888

Поэтому и защита срабатывает. Значит нужно отключить.

-----
vx

| Сообщение посчитали полезным:

cracker888 пишет:
выключаю защиту эксплоитов в Windows 10 - тоже всё работает
А вы пробовали готовые упаковщики/протекторы? Может они тоже не будут работать с этой защитой и проблема не в вашем коде?

| Сообщение посчитали полезным:

>>Проверяю работоспособность через rundll32 dllname,funcname
Попробуйте грузить DLL своим лоадером, без rundll.

| Сообщение посчитали полезным:

RamMerlabs

При включённой CFG любая передача управления приведёт к int29, своим или не своим без разницы. mrdata секция не протекчена ядром, можно переписать любые данные, обнулить указатель на карту в частности, это если совсем по тупому делать, не разбираясь как работает защита

-----
vx

| Сообщение посчитали полезным: cracker888

difexacaw пишет:
При включённой CFG любая передача управления приведёт к int29, своим или не своим без разницы. mrdata секция не протекчена ядром, можно переписать любые данные, обнулить указатель на карту в частности, это если совсем по тупому делать, не разбираясь как работает защита
А вот это уже очень близко, и действильно ловлю int 29. А что Вы имеете ввиду под передачей управления? И да, как обнулить указатель на карту, где этот указатель хранится, он для DLL или для EXE? Сейчас хочется может даже по тупому)))

Добавлено спустя 2 минуты
RamMerlabs пишет:
Попробуйте грузить DLL своим лоадером, без rundll.
У меня к сожалению есть такое требование.

user99 пишет:
А вы пробовали готовые упаковщики/протекторы? Может они тоже не будут работать с этой защитой и проблема не в вашем коде?
Надо попробовать.

| Сообщение посчитали полезным:

cracker888

CFG/CFI защита локальна, принцип в том, что локально в процессе нельзя выполнить косвенное ветвление(CFG) или возврат(CFI) на не определённый указатель. Для удаленной записи же процесс полностью открыт и можно что угодно изменить.

> где этот указатель хранится

Открой дизом с символами да посмотри сам, mrdata секция она локально протектится от записи.

А при включённой защите падать будет во всё нэйтиве, там на каждом углу проверки

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
mrdata секция она локально протектится от записи

Есть такая Windows API function used to change protections on .mrdata called LdrProtectMrdata( bProtect )
может она пригодится?

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

plutos

NtProtectVi обёрнутая RWL синхронизацией. Ну да в символах такая есть.

-----
vx

| Сообщение посчитали полезным:

UPX этому коневоду уже предлагали?

| Сообщение посчитали полезным: ClockMan

Топикастор ь малварь пишет а тут все бросились ему помогать.........

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным: ajax

ClockMan пишет:
малварь пишет

Ну тут сыглы, иначе как может срабатывть CFG в длл, у которой ее нет. И вообще ни разу не видел, чтобы CFG срабатывал где-то в GetProcAddress, обычно он работает при передаче управления коду, которого нет в битовой карте CFG модуля.

| Сообщение посчитали полезным:

Apocalypse

LdrGetProcedureAddressForCaller -> LdrpResolveProcedureAddress -> LdrpGetProcedureAddress -> LdrControlFlowGuardEnforced(TRUE) -> RtlpxLookupFunctionTable(FAIL) -> int29.



-----
vx

| Сообщение посчитали полезным: ajax

difexacaw пишет:
LdrControlFlowGuardEnforced(TRUE)
Пытался отредактировать эту функцию и указатели которые узаются в ней, но потом всё падает(

| Сообщение посчитали полезным:

cracker888

Для выяснения причин падений давно изобрели отладчик.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Для выяснения причин падений давно изобрели отладчик.
Я просто не уверен, что копание в ntdll принесет мне какие-то плоды. Вобщем хукнул GetProcAddress, она успешна отработала, а потом DLL-ка упала в какой-то оконной функции и также int 29, кароч надо копать защиту...

| Сообщение посчитали полезным:

cracker888

Оно и должно упасть, при любом обратном вызове(косвенное ветвление) пройдёт проверка указателя в карте.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Оно и должно упасть, при любом обратном вызове(косвенное ветвление) пройдёт проверка указателя в карте.
А как оно падает, если в DLL нет Load Config Directory, я так понял CFG работает при поддержке компилятора, а также заполняется необходимая информация в PE-файле, а именно в Load Config Directory. Почему падает-то? О_О

| Сообщение посчитали полезным: