flat assembler
Message board for the users of flat assembler.
Index
> Windows > Is there a list of syscall? Goto page 1, 2 Next |
Author |
|
revolution 10 Sep 2012, 07:03
znatz wrote: 1. Is there a way to trace into syscall? znatz wrote: 2. Is there a reference of all syscall functions for windows 7? znatz wrote: 3. I have seen sever posts mentioned sysenter, what actually does this instruction do? |
|||
10 Sep 2012, 07:03 |
|
hopcode 10 Sep 2012, 13:50
_________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
10 Sep 2012, 13:50 |
|
znatz 10 Sep 2012, 15:03
hopcode wrote: some references, here, Thank you all! And as to the reference, I had seen it before, but I had no idea what the ID means in the table. Does it mean the calling convention of windows syscall is as follows? mov rax, ID syscall |
|||
10 Sep 2012, 15:03 |
|
revolution 10 Sep 2012, 15:13
znatz: Note that any list of syscall numbers can only ever be considered approximate. MS have never published such a list and therefore might just decide to change them in the next patch-Tuesday. So use at your own risk.
|
|||
10 Sep 2012, 15:13 |
|
hopcode 10 Sep 2012, 15:42
Quote: Does it mean the calling convention of windows syscall is as follows? Code: ntdll.NtReadFile: mov r10,rcx mov eax,3 syscall ret Windows XP Windows 2003 Server Windows Vista Windows 2008 Server Windows 7 Windows 8 for the rest of used registers/flags, OS must conform to the CPU. this makes code not only OS-dependent but CPU-dependent too. also, use carefully by conditional compilation, and after the above warning. Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
10 Sep 2012, 15:42 |
|
znatz 11 Sep 2012, 08:20
Thanks a lot!!
|
|||
11 Sep 2012, 08:20 |
|
Flier-Mate 12 Jun 2023, 13:57
hopcode wrote: some references, here, The syscall numbers change from release to release, not reliable to use syscall. I have seen a reverse-engineering tutorial that actually shows how to generate syscall table in current release of Windows. But it is cool to have that table nonetheless! |
|||
12 Jun 2023, 13:57 |
|
Flier-Mate 12 Jun 2023, 15:01
Are both the same? From my preliminary research, the exit code returned are the same.
Runs on my Windows 10: Code: format PE64 console entry start section ".code" code executable readable start: mov rdx, 7 or rcx, 0xFFFFFFFFFFFFFFFF ;xor rcx, rcx mov r10, rcx mov rax, 0x2C syscall Normal code: Code: format PE64 console entry start include "win64a.inc" section ".code" code executable readable start: mov rcx, 7 call [ExitProcess] section ".idata" import readable library kernel, "kernel32.dll" import kernel, ExitProcess, "ExitProcess" No import table if use syscall, |
|||
12 Jun 2023, 15:01 |
|
revolution 12 Jun 2023, 15:48
Using syscalls has one advantage that I know of. You can bypass the normal APIs to create arbitrary filenames, including nulls. Because internally NT doesn't use c-strings with zero termination, you pass the length instead.
This also creates a headache for anyone trying to open/read/write/delete such files with the normal APIs. It isn't possible to name them using c-strings because the name never matches a null. However that one advantage isn't enough outweigh all the other disadvantages IMO. The code is unreliable, untransferable and sensitive to any changes. Have fun. |
|||
12 Jun 2023, 15:48 |
|
bitRAKE 12 Jun 2023, 19:38
I wonder if MS uses some of the syscalls? Especially in cases where they don't seem to change?
https://hfiref0x.github.io/NT10_syscalls.html hfiref0x wrote: 410 NtTerminateProcess 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 I think they should totally randomize them on each build. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
12 Jun 2023, 19:38 |
|
revolution 13 Jun 2023, 02:03
bitRAKE wrote: I think they should totally randomize them on each build. |
|||
13 Jun 2023, 02:03 |
|
f0dder 13 Jun 2023, 05:56
revolution wrote: Using syscalls has one advantage that I know of. You can bypass the normal APIs to create arbitrary filenames, including nulls. Because internally NT doesn't use c-strings with zero termination, you pass the length instead. As long as you're not writing shellcode, why not just link against the Nt* APIs in ntdll.dll? _________________ - carpe noctem |
|||
13 Jun 2023, 05:56 |
|
Furs 13 Jun 2023, 13:16
revolution wrote: Using syscalls has one advantage that I know of. You can bypass the normal APIs to create arbitrary filenames, including nulls. Because internally NT doesn't use c-strings with zero termination, you pass the length instead. |
|||
13 Jun 2023, 13:16 |
|
revolution 13 Jun 2023, 13:25
Not just nulls, but all 2^16 word values are allowable. So null, forward/backward slashes, etc. are all good as far as NTFS is concerned. And it has no encoding, just raw words. So invalid UTF-16 is fine.
Which, BTW, I forgot to mention, you also need the backend FS to support such ugliness. Using FAT or EXT4 is not going to work. |
|||
13 Jun 2023, 13:25 |
|
ProMiNick 13 Jun 2023, 13:50
Flier-Mate wrote: Are both the same? From my preliminary research, the exit code returned are the same. No import table, no syscall, just return of exit code in eax Code: format PE64 console entry start section ".code" code executable readable start: mov eax, 7 ret _________________ I don`t like to refer by "you" to one person. My soul requires acronim "thou" instead. |
|||
13 Jun 2023, 13:50 |
|
Flier-Mate 13 Jun 2023, 14:27
ProMiNick wrote:
Yes, it works, but is "ret" a reliable way to end a Windows program? The purpose of my code in this thread was to learn syscall, but yeah, it is good to know your code also work. |
|||
13 Jun 2023, 14:27 |
|
f0dder 13 Jun 2023, 15:56
[quote="Flier-Mate"]
ProMiNick wrote: Yes, it works, but is "ret" a reliable way to end a Windows program? No, it's not part of the specification – it works only because of an implementation detail. Unless you're doing 4k intros, import and call ExitProcess. _________________ - carpe noctem |
|||
13 Jun 2023, 15:56 |
|
Tomasz Grysztar 13 Jun 2023, 16:27
f0dder wrote:
Quote: The thread execution begins at the function specified by the lpStartAddress parameter. If this function returns, the DWORD return value is used to terminate the thread in an implicit call to the ExitThread function. In any case, the best you can assume is that RET exits the thread, not the process. It only happens to end the process when there are no other threads - another implicit (and potentially unsafe) assumption. |
|||
13 Jun 2023, 16:27 |
|
revolution 13 Jun 2023, 16:51
Imported libraries can start their own threads. Your app has no control over that.
So if you import a library that creates a new thread you find that your app doesn't exit when using ret because there are other threads still running. I say there is no advantage to using ret except for "hacker points" or something. If you just want your stuff to work without any unexpected weird behaviours use ExitProcess and sleep soundly. The same goes for Linux with "exit". Your app can hang if a .so import makes a new thread. Use "exit_group". Sleep soundly. |
|||
13 Jun 2023, 16:51 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.