flat assembler
Message board for the users of flat assembler.

Index > Windows > Is there a list of syscall?

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 13 Jun 2023, 17:05
Tomasz Grysztar wrote:
So the only detail that is open for interpretation is whether the first thread of the process is treated specially.

Yup – and IMHO it's not a good idea to extrapolate usermode public API documentation to unspecified OS internals. There's a lot of reasons (a very big one being the OS implemented mainly in C) that it will probably keep on working forever, but it's dangerous to make assumptions. Especially when you don't gain much from it.

Also, as you state yourself:
Tomasz Grysztar wrote:
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.

And these can be created for a myriad of reasons, including but not limited to printer drivers and endpoint security software.

Tomasz Grysztar wrote:
But that's mostly an issue with how documentation is written - it may not give a strong argument for exiting the main thread with RET, but in my opinion it is an argument for improving the documentation.

Amen.

I do believe some leeway should be given, not requiring every bit of OS internal to be documented, otherwise things would be set in stone and very hard to improve (I'm not sure I agree with e.g. the Linux approach of keeping the ABI 99.9% stable), and it's also fair to target documentation and assumptions of a mass-market OS at the C level. But the entrypoint guarantees and assumptions ought to be more clearly specified.

(There's also a bit of pedantry of whether we can even call the AddressOfEntryPoint the canon entrypoint, DLLs and TLS callbacks and whatnot Wink )

_________________
Image - carpe noctem
Post 13 Jun 2023, 17:05
View user's profile Send private message Visit poster's website Reply with quote
MatQuasar



Joined: 25 Oct 2023
Posts: 105
MatQuasar 27 Feb 2024, 10:31
ProMiNick wrote:

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     


Now let's try adding "pop eax" at the beginning of the code...:

Code:
format PE console

section ".code" code executable readable

entry $

    pop  eax
    mov  eax, 7
    ret
    


It still returns but returns to nowhere, with random exit code.
Evil or Very Mad
Post 27 Feb 2024, 10:31
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20142
Location: In your JS exploiting you and your system
revolution 27 Feb 2024, 13:00
MatQuasar wrote:
Now let's try adding "pop eax" at the beginning of the code...:

Code:
format PE console

section ".code" code executable readable

entry $

    pop  eax
    mov  eax, 7
    ret
    


It still returns but returns to nowhere, with random exit code.
Evil or Very Mad
If by "returns" you mean it crashes with no place for the exception handler to be invoked (and thus it simply gets killed), then yes, it "returns".

You can get the same effect by replacing "pop eax" with "xor esp,esp".
Post 27 Feb 2024, 13:00
View user's profile Send private message Visit poster's website Reply with quote
MatQuasar



Joined: 25 Oct 2023
Posts: 105
MatQuasar 27 Feb 2024, 14:47
revolution wrote:
If by "returns" you mean it crashes with no place for the exception handler to be invoked (and thus it simply gets killed), then yes, it "returns".


Thanks for explaining the internal working. Smile

revolution wrote:
You can get the same effect by replacing "pop eax" with "xor esp,esp".


This is new idea, never tried it before.
Post 27 Feb 2024, 14:47
View user's profile Send private message Reply with quote
MatQuasar



Joined: 25 Oct 2023
Posts: 105
MatQuasar 26 May 2024, 15:35
Flier-Mate wrote:
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, Laughing


Or, like this:

Code:
format PE console
entry start

include "win32a.inc"

section ".code" code executable readable

start:

  push 7
  push 0xFFFFFFFF
  call [NtTerminateProcess]

section ".idata" import readable

  library ntdll, "ntdll.dll"

  import ntdll, NtTerminateProcess, "NtTerminateProcess"       
Post 26 May 2024, 15:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20142
Location: In your JS exploiting you and your system
revolution 26 May 2024, 16:18
You can explore the int 0x2e on Win32. That is the mechanism the OS uses to transfer control to the kernel. So you could eliminate the import table for Win32 also.
Post 26 May 2024, 16:18
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 2452
Furs 26 May 2024, 18:02
A more robust way would be to scan the memory for ntdll, since it's always loaded, find its export table and use LdrLoadDll or whatever. At least that one is "stable" unlike syscalls.
Post 26 May 2024, 18:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20142
Location: In your JS exploiting you and your system
revolution 27 May 2024, 06:04
Yeah, I should have mentioned that the syscalls (int 0x2e on Win32) are not documented. And MS might have changed the numbering and arguments as they "upgraded" to each new OS version.

So use at your own rick. Razz

But it might still make for a fun project to have a Win32 program without any import table, and without the cumbersome memory scan. There are already posts on here that do the memory scan thing, so it wouldn't be new, but I don't know of any pure syscall (int 0x2e) version being posted.
Post 27 May 2024, 06:04
View user's profile Send private message Visit poster's website Reply with quote
MatQuasar



Joined: 25 Oct 2023
Posts: 105
MatQuasar 27 May 2024, 08:18
revolution wrote:
...but I don't know of any pure syscall (int 0x2e) version being posted.


When I trace NtTerminateProcess in 64-bit, can see the use of "int 0x2e", but not in 32-bit version.

But trying to call "int 0x2E" opened my post-mortem debugger, "illegal instruction".


Description: Int 0x2E gave illegal instruction
Filesize: 17.06 KB
Viewed: 65 Time(s)

aa.PNG


Description: Step into "NtTerminateProcess" in 64-bit PE
Filesize: 31.04 KB
Viewed: 65 Time(s)

a.PNG


Post 27 May 2024, 08:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20142
Location: In your JS exploiting you and your system
revolution 27 May 2024, 08:40
IIRC you'll need Win2000 for int 0x2e.

On XP and above it uses sysenter

On 64-bit code it is syscall.

On WoW64 32-bit code might want to try "call fs:[0xc0]"

As mentioned above, the kernel entry methods are not officially documented so MS feels fine changing them at any time. You can find online random people posting their analysis with various lists etc. but none of those is guaranteed to actually work on any given system.
Post 27 May 2024, 08:40
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.