After continuing to see new tools emerging, which rely on extracting the NTDLL syscall IDs from "mov eax, X" instruction, I wanted to remind everyone that syscall IDs can easily be calculated by sorting the addresses of Nt*/Zw* functions in NTDLL from lowest to highest. 🍻

Jan 10, 2023 · 4:09 PM UTC

7
61
1
276
Replying to @mrgretzky
Is not this the most used method ? I believe since @ElephantSe4l's freshycalls publication it was the default method people was using.
1
3
I'd think so, but every recently released tool relies on grabbing the ID from "mov eax, X" gadget, instead.
1
2
Replying to @mrgretzky
It's neat property, but some people just don't feel safe relying on it. "Today linker sorts 'em, but tomorrow it won't; and one day PGO may move deprecated stuff far away (e.g. eventpair syscalls)" - it's that kind of thinking. So they opt for more mundane/defensive methods.
1
1
3
This property is not “set” by the linker. It is not a coincidence. Windows use syscall numbers to get real kernel addresses of the services. Then, to build NTDLL stubs, Windows get all the numbers in order to build an ASM file including all stubs.
1
2
Replying to @mrgretzky
Computation of grabbing all functions and sorting vs a simple xor is astronomical. Syscalls can be done pretty rapidly and you’ll have ALOT of cpu time if you don’t store it somewhere sorting all the addresses. You also have to watch out for possible ordinals.
This tweet is unavailable
Sounds like it may be much less complicated 😛
3
Replying to @mrgretzky
CobaltStrike author already uses this technique in KoboldLoader CobaltStrike Beacon v4.x
7