Вызов напрямую winapi

Доброго времени, форум!)

Делаю эксперименты с попытками вызовоф winapi функций через sycall, получается вот что: на вин10 все вызовы проходят успешно, на вин11 проходят успешно не все Например NtSetInformationFile правильно работает, а NtCreateSection не работает, ошибка - нет доступа с0000005. Код один и тот де, х64. Кто нибудь подскажет?

 

Номер сервиса совпадает?

 

Да, конечно. Различий вообще ни в чем нет, только вин10 и вин11

 

Ты не понял, номера сервисов от версии к версии Венды могут меняться, дизассемблируй NtCreateSection в ntdll.dll на 11ой Венде и сравни номер сервиса, который ты вызываешь с номером сервиса, который вызывает функция.

--- Сообщение объединено, 13 июл 2022 ---

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

 

Да, я знаю. Но в данном случае не менялись. Например NtReadVirtualMemory номер 63, как в 10 так и в 11. Я думаю, может какая защита появилась?

 

piligmindo, код надо, или семпл, иначе это угадывание.

--- Сообщение объединено, 13 июл 2022 ---

не пробовал, надо глянуть; но там парсить в памяти/с диска элементарно, и не надо хардкодить. Ищем все апи Zw (Nt), смотри первый байт, если это 0xB8 (mov ), то значит сискол, копируем номер после оного. Работает и на 32 бит и на 64 .

 

Это обычный код, который можно найти на гипхабе или в интернете, думаю, что нет смысла его выкладывать..

 

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

 

у меня лично NtCreateFile работает на 11, а гуглить где-то конкретно секции как то лень; нет так нет, сидите со своими приватами.

 

Ды дело не в приватах, я просто на гитхабе нашел и пытаюсь копилировать. Если есть возможность проверить - проверь NtCreateSection пожалуйста, потому что NtCreateFile у меня тоже работает

 

так дай ссылку

 

https://github.com/XShar/Calling_Syscalls_Directly

 

Хз, у меня все отработало и на 10 и на 11.

--- Сообщение объединено, 13 июл 2022 ---

мб неправильно понял задачу, но номера никак не связаны с алфавитом - две функции на А вначале, но и другие тоже. Вин10.

 

Хм, интересно... Буду разбираться.

 

piligmindo, тут игра в экстрасенсов, но раз приват семплы / сорцы не показываешь, то как иначе?
могу сказать только то, что на последней обновленной вин11 вызов

Код (C++):

1. pNtCreateSection(&hSection, SECTION_MAP_READ | SECTION_MAP_WRITE | SECTION_MAP_EXECUTE, NULL, (PLARGE_INTEGER)&sz, PAGE_EXECUTE_READWRITE, SEC_COMMIT, NULL);

с правами юзера через сискол возращает 0L (suxxess) и секция создается. А там дальше уже смотрите.

 

piligmindo, на 7ке пашет нормульно, правда в цикле поиска номера сискола есть бажинка (функция GetSysCallNumber)

 

я вызывал NtCreateFile на win10 всё работает,интересно а с помощью NtCreateFile удалить файл возможно ?

 

Думаю такой финт работает только для своих файлов.
Если кто-то уже открыл файл без флага FILE_SHARE_DELETE, то FILE_FLAG_DELETE_ON_CLOSE принудительно сбросится, или CreateFile() вообще вернёт ошибку. Там в нёдрах по этой теме происходят интересные вещи, и в доках по NTFS упоминается следующее.

Когда файл открывается в первый раз, NTFS создаёт для него внутреннюю свою структуру FCB (File Control Block), в которой указываются флаги доступа к файлу на диске. Однако и ядро ОС создаёт себе структуру FILE_OBJECT, чтобы вести учёт уже открытых дескрипторов и прочее - в ней тоже имеются поля с флагами.

Суть в том, что адрес структуры FCB заносится в поле FsContext создаваемого FILE_OBJECT, и поскольку NTFS находится на более низком уровне при доступе к диску, то FCB имеет приоритет перед "файловым объектом" системы.

Спойлер: FILE_OBJECT

Код (Text):

1. 0: kd> dt _file_object 0xfffffa8010ef7b00
2. nt!_FILE_OBJECT
3.    +0x000 Type                 : 0n5
4.    +0x002 Size                 : 0n216
5.    +0x008 DeviceObject         : 0xfffffa80`0f910cd0 _DEVICE_OBJECT
6.    +0x010 Vpb                  : 0xfffffa80`0f90cb20 _VPB
7.    +0x018 FsContext            : 0xfffff8a0`02ec2bc0 Void
8.    +0x020 FsContext2           : 0xfffff8a0`027c6a70 Void
9.    +0x028 SectionObjectPointer : (null)
10.    +0x030 PrivateCacheMap      : (null)
11.    +0x038 FinalStatus          : 0n0
12.    +0x040 RelatedFileObject    : (null)
13.    +0x048 LockOperation        : 0
14.    +0x049 DeletePending        : 0  <------------------- Ожидание..
15.  
16.    +0x04a ReadAccess           : 1
17.    +0x04b WriteAccess          : 0
18.    +0x04c DeleteAccess         : 0
19.    +0x04d SharedRead           : 1
20.    +0x04e SharedWrite          : 1
21.    +0x04f SharedDelete         : 0
22.  
23.    +0x050 Flags                : 0x40002
24.    +0x058 FileName             : "\Program Files (x86)\AkelPad"
25.    +0x068 CurrentByteOffset    : 0x0
26.    +0x070 Waiters              : 0
27.    +0x074 Busy                 : 0
28.    +0x078 LastLock             : (null)
29.    +0x080 Lock                 : _KEVENT
30.    +0x098 Event                : _KEVENT
31.    +0x0b0 CompletionContext    : (null)
32.    +0x0b8 IrpListLock          : 0
33.    +0x0c0 IrpList              : _LIST_ENTRY
34.    +0x0d0 FileObjectExtension  : (null)
35.  

Если-же открытый файл открывается снова, ОС создаёт для него новый FILE_OBJECT, однако в его поле FsContext прописывает указатель на тот-же FCB. Именно в этом общем FCB и хранится инфа о блокировках (какие доступы и от каких процессов были запрошены), что приводит к конфликту при попытке процесса(В) открыть файл с флагом DELETE.

 

Я неправильно написал тогда, сортировать надо по смещению, относительно базового адреса, если вдруг для кого-то это еще будет актуально.