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

Alternatives methods of avoiding heuristic analysis / Avoiding lazy API calls by utilizing NTDLL.dll

vxug

CD-диск
Пользователь
Регистрация
10.10.2019
Сообщения
12
Реакции
19
If you're unfamiliar with PE file IAT / EAT, google it. I dont want to cover
it in this paper.

If you're unfamiliar with DLL implicit / explicit loading, google that too.

Anyway, by default PE files will implicitly load:
-ntdll.dll = user mode kernel stuff
-kernel32.dll = disk stuff, memory stuff, whatever
-user32.dll = UI stuff
-msvcrt.dll * = standard IO, printf, stdio.h, whatever

it should be noted other dlls will be present depending on how the PE file is
compiled, it isnt unusual to see an array of different DLLs present such
as psapi.dll, shlwapi.dll, etc. regardless, the core dlls will always be the ones
listed above

ntdll is going to contain user-mode / kernel-mode apis, before function calls
enter kernel mode, they usually end here.

* whatever version msvcrt is designed to be utilized. it varies.


Full paper is attached.
 

Вложения

  • paper1.txt
    9.9 КБ · Просмотры: 76
I'm sorry for writing in English. I'm sure it is annoying.

You are correct. You can call both ZwCreateFile or NtCreateFile from user-mode. However, when your thread invokes SYS-ENTER depending on the routine it may wrap to either Zw or Nt. Drivers often utilize Zw because ZwCreateFile is used for verified kernel-mode sources. NtCreateFile is invoked in kernel-mode when it believes parameters may not be safe.

Quoting MSDN - "A kernel-mode driver calls the Zw version of a native system services routine to inform the routine that the parameters come from a trusted, kernel-mode source. In this case, the routine assumes that it can safely use the parameters without first validating them. However, if the parameters might be from either a user-mode source or a kernel-mode source, the driver instead calls the Nt version of the routine, which determines, based on the history of the calling thread, whether the parameters originated in user mode or kernel mode. "

Quoting MSDN - "When a user-mode application calls the Nt or Zw version of a native system services routine, the routine always treats the parameters that it receives as values that come from a user-mode source that is not trusted. The routine thoroughly validates the parameter values before it uses the parameters. In particular, the routine probes any caller-supplied buffers to verify that the buffers are located in valid user-mode memory and are aligned properly."

-------------------------------------------


Я извиняюсь за то, что пишу на английском. Я уверен, что это раздражает.

Ты прав. Вы можете вызвать как ZwCreateFile, так и NtCreateFile из пользовательского режима. Тем не менее, когда ваш поток вызывает SYS-ENTER в зависимости от подпрограммы, он может переноситься в Zw или Nt. Драйверы часто используют Zw, потому что ZwCreateFile используется для проверенных источников в режиме ядра. NtCreateFile вызывается в режиме ядра, когда считает, что параметры могут быть небезопасными.

Цитата MSDN - «Драйвер режима ядра вызывает версию Zw собственной подпрограммы системных служб, чтобы сообщить подпрограмме, что параметры поступают из надежного источника режима ядра. В этом случае подпрограмма предполагает, что она может безопасно использовать параметры без предварительной их проверки. Однако, если параметры могут быть из источника пользовательского режима или источника режима ядра, драйвер вместо этого вызывает версию подпрограммы Nt, которая на основе истории вызывающего потока определяет, параметры возникли в пользовательском режиме или режиме ядра. "

Цитата MSDN - «Когда приложение пользовательского режима вызывает версию собственной системной службы Nt или Zw, эта процедура всегда обрабатывает полученные параметры как значения, полученные из источника пользовательского режима, которому не доверяют. проверяет значения параметров, прежде чем использовать параметры. В частности, подпрограмма проверяет любые предоставленные вызывающей стороной буферы, чтобы убедиться, что эти буферы находятся в действительной памяти пользовательского режима и выровнены должным образом. "
 
And we are interested how we can get correct syscall codes for each service, for each win version.
syscall is more cool to use than ntdll call.
Fuck Whisper, you already talked that using hardcoded syscall table is the only right way to do it.... Did you forget my man??? BTW you can also find appropriate syscall in runtime just by making a little disassembly of interesting function.
 
Whisper, because this is translated I cannot tell the connotation of your writing. However, reliably getting SYSCALL numbers and/or functional pointers is done by parsing the export address table at run-time. If you're being serious, I can happily supply you with C or ASM versions of this to demonstrate how it is achieved programmatically. If you're being sarcastic, then :P


------------------------------------------------------------------------------------------------------------------------------------------------------


Шепотом, потому что это переведено, я не могу сказать смысл вашего письма. Однако надежное получение SYSCALL numbers и / или функциональных указателей выполняется путем анализа таблицы адресов экспорта во время выполнения. Если вы серьезно, я могу с радостью предоставить вам версии C или ASM, чтобы продемонстрировать, как это достигается программно. Если вы саркастичны, то :P

<3
 
oh... visor you can frighten off this nice American coder.

It's upsetting that VX is dead worldwide except in the Ukraine and Russia. I appreciate the love. :P

Огорчает, что VX мертв во всем мире, за исключением Украины и России. Я ценю любовь.
 
However, reliably getting SYSCALL numbers and/or functional pointers is done by parsing the export address table at run-time.
Bad way bro =(, it can be hooked, patched, corrupted an so on...you should use different way.
And Heavens gate it name for gate from 32bit mode to 64 (for call ntdll64 bit services) and way back.
 
It's upsetting that VX is dead worldwide except in the Ukraine and Russia. I appreciate the love. :P

Огорчает, что VX мертв во всем мире, за исключением Украины и России. Я ценю любовь.
VX deadly here too...sorry am so sad for that.
 
vxug my boiii. VX is not dead. Ancient paradigm from 2000s is dead. But today we see redteams, blueteams. VX is not dead. But paradigm has changed. Man i love you. Dont worry about scene death. We all there and we not gonna disappeare. Amin.
It's dead =( just few mans who can something...visor so optimistic. We should call Indy he is last VX knight =)
 
All pentesting community is modern vx. Instead of ezines we have a blackhat con or offensive con or ... thousands of con's. Do not tell me that its all dead. Paradigm has changed. BUT. BUTT. SUKA AAHAHA. BUTT... BUT. OKAY? Today more peoples involved in this движуху. (пишу как славик коменты к сорцам LOL). Короче. More people involved and more shitty content is generated. So there very small amount of interesting topics. And very small amount of people working on low level stuff. Thats all difference between 2000s and 2020s. In my humble opinion.
 
Visor, you are correct. There are tons of shit content released. It's disappointing. I have been searching for several months now and it appears Russians / Russia releases excellent content. It's no surprise z0mbie was Russian.

-------------------------------------------------------------

Visor, вы правы. Есть тонны контента дерьма выпущен. Это разочаровывает. Я искал несколько месяцев, и кажется, что Россия / Россия выпускают отличный контент. Не удивительно, что z0mbie был русским.
 


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