Title says it all.

Would it be possible to add this function into the mix? RtlCreateProcessReflection()

supports WINDOWS 11 PRO 22H2??

Hi,

Problem

I'm using the jumper_randomized method for generating the syscalls. The generated stubs are in the following form:

NtAllocateVirtualMemory PROC
	mov [rsp +8], rcx          ; Save registers.
	mov [rsp+16], rdx
	mov [rsp+24], r8
	mov [rsp+32], r9
	sub rsp, 28h
	mov ecx, 0C1D1ED76h        ; Load function hash into ECX.
	call SW3_GetRandomSyscallAddress        ; Get a syscall offset from a different api.
	mov r15, rax                           ; Save the address of the syscall
	mov ecx, 0C1D1ED76h        ; Re-Load function hash into ECX (optional).
	call SW3_GetSyscallNumber              ; Resolve function hash into syscall number.
	add rsp, 28h
	mov rcx, [rsp+8]                      ; Restore registers.
	mov rdx, [rsp+16]
	mov r8, [rsp+24]
	mov r9, [rsp+32]
	mov r10, rcx
	jmp r15                                ; Jump to -> Invoke system call.
NtAllocateVirtualMemory ENDP

Now I had some code in the following form:

//Doing some other stuff beforehand

NtProtectVirtualMemory(hCurrentProc, &pEventWrite, (PSIZE_T)&size,oldprotect, &oldprotect);
void* address = NULL;
NtAllocateVirtualMemory(GetCurrentProcess(), &address, 0, &newSize, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);

Which workes fine when compiled in Debug mode, but crashed when compiled as a Release build. In Realease mode, address was not set to 0, but to a value pointing to some instruction in ntdll.dll. After viewing the code in disassembly, the instruction to zero out the value of address was optimized by the compiler to this code: mov qword ptr [address],r15, which of course loads the value from our previous syscall into the variable, which in turn leads to problems with the next NtAllocateVirtualMemory call.

The problem only occurs when some additional code is executed before doing the syscalls. But I don't really want to post the full code here in the issue :D . When the additional code is removed, to program works without problems. I hope that the workarounds are enough for people who are running into the same problem.

Workaround

There are two possible workarounds I could find while debugging:

• add/remove code to your application until the compiler optimizes in some other way
• change the optimization in the project settings (Project -> Settings -> C++ -> Optimization)

@klezVirus Do you think there is any other way to circumvent this? I guess I ran in a super specific edge case here because of the code optimization. Registers r12-r15 however should be saved and restored before a ret.
R12..R15 are call-preserved registers you can use for whatever you want, as long as your save/restore them before returning. (https://stackoverflow.com/questions/53290932/what-are-r10-r15-registers-used-for-in-the-windows-x64-calling-convention)

However, I don't really see a good solution in how this could be done in the stubs.

Cheers

I starred your repo because your idea is nice, however because you are using ReadProcessMemory which is a user mode function (in fact any API called...), you already lost.

Besides this you should use a SEED like PRNG or something.

Good idea again, but you should rework it a bit.

RtlCreateUserThread from prototypes.json is not a syscall and should be removed. (Also the prototype itself is incorrect for x64 usage but that hardly matters.)

All calls to Nt-api via wow64 on Windows 11 x64 22H2 return status 0xC000000B, on win 10 x64 everything works correctly.

NtOpenProcess PROC
push ebp
mov ebp, esp
push 0D59FFE03h ; Load function hash into ECX.
call SW3_GetRandomSyscallAddress ; Get a syscall offset from a different api.
mov edi, eax ; Save the address of the syscall
push 0D59FFE03h ; Re-Load function hash into ECX (optional).
call SW3_GetSyscallNumber
lea esp, [esp+4]
mov ecx, 04h
push_argument:
dec ecx
push [ebp + 8 + ecx * 4]
jnz push_argument
mov ecx, eax
mov eax, ecx
push ret_address_epilog
call do_sysenter_interrupt
lea esp, [esp+4]
ret_address_epilog:
mov esp, ebp
pop ebp
ret
do_sysenter_interrupt:
mov edx, esp
jmp edi
ret
NtOpenProcess ENDP

Hi @klezVirus,

Not quite sure what I am doing wrong here but I cannot seem to assemble under Linux mingw. I am doing x86 with mingw target from syswhispers. Seems like the assembler cannot workout some symbol defs. See below.

$ python3 syswhispers.py -a x86 -c mingw -f NtCreateThreadEx,NtAllocateVirtualMemory,NtProtectVirtualMemory,NtWriteVirtualMemory,NtOpenProcess,NtClose,NtFreeVirtualMemory -m jumper_randomized -o syscalls_common

$ i686-w64-mingw32-gcc -masm=intel -c syscalls_common.c
/tmp/ccfeQDkK.s: Assembler messages:
/tmp/ccfeQDkK.s:770: Error: symbol push_argument' is already defined /tmp/ccfeQDkK.s:780: Error: symbol ret_address_epilog' is already defined
/tmp/ccfeQDkK.s:784: Error: symbol do_sysenter_interrupt' is already defined /tmp/ccfeQDkK.s:811: Error: symbol push_argument' is already defined
/tmp/ccfeQDkK.s:821: Error: symbol ret_address_epilog' is already defined /tmp/ccfeQDkK.s:825: Error: symbol do_sysenter_interrupt' is already defined
/tmp/ccfeQDkK.s:852: Error: symbol push_argument' is already defined /tmp/ccfeQDkK.s:862: Error: symbol ret_address_epilog' is already defined
/tmp/ccfeQDkK.s:866: Error: symbol do_sysenter_interrupt' is already defined /tmp/ccfeQDkK.s:893: Error: symbol push_argument' is already defined
/tmp/ccfeQDkK.s:903: Error: symbol ret_address_epilog' is already defined /tmp/ccfeQDkK.s:907: Error: symbol do_sysenter_interrupt' is already defined
/tmp/ccfeQDkK.s:934: Error: symbol push_argument' is already defined /tmp/ccfeQDkK.s:944: Error: symbol ret_address_epilog' is already defined
/tmp/ccfeQDkK.s:948: Error: symbol do_sysenter_interrupt' is already defined /tmp/ccfeQDkK.s:975: Error: symbol push_argument' is already defined
/tmp/ccfeQDkK.s:985: Error: symbol ret_address_epilog' is already defined /tmp/ccfeQDkK.s:989: Error: symbol do_sysenter_interrupt' is already defined

Hi,

Please consider the following improvements:

1. If one does not use anything else but these definitions, NTSTATUS will be missing, you can just add:

#ifndef SW3_HEADER_H_
#define SW3_HEADER_H_

#include <windows.h>

#ifndef _NTDEF_
typedef _Return_type_success_(return >= 0) LONG NTSTATUS;
typedef NTSTATUS* PNTSTATUS;
#endif

2. If one needs to use another definition set like phnt, the definitions will clash at compile time. My suggestion is to rename the structures/definitions with a prefix like:

typedef struct _SW3_SYSTEM_HANDLE
{
	ULONG ProcessId;
	BYTE ObjectTypeNumber;
	BYTE Flags;
	USHORT Handle;
	PVOID Object;
	ACCESS_MASK GrantedAccess;
} SW3_SYSTEM_HANDLE, *PSW3SYSTEM_HANDLE;

Same for functions (there is no reason we cannot name them as we wish):

EXTERN_C NTSTATUS Sw3NtCreateProcess(
	OUT PHANDLE ProcessHandle,
	IN ACCESS_MASK DesiredAccess,
	IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
	IN HANDLE ParentProcess,
	IN BOOLEAN InheritObjectTable,
	IN HANDLE SectionHandle OPTIONAL,
	IN HANDLE DebugPort OPTIONAL,
	IN HANDLE ExceptionPort OPTIONAL);

This would prevent the "already defined" compiling issue. Perhaps add a flag like --custom-prefix which would prefix the functions/structured/definitions as the user specifies.

3. Instead of the current initial see, you might want to consider using xoshiro prng.

Thanks!

I complierd my virus with gcc

violation of access rights during execution at address 0x00000000

SysWhispers is dead, long live SysWhispers!

or something to make this usable from rust easily?

My understanding is that Jumper and Jumper_randomized would jump into NTDLL space, and use the syscall instructions by jumping into those assembly instructions, however when I trace the program with Frida, I can see that none of calls are jumped or at least Frida script is catching them being called outside of the NTDLL space.

I also enabled the debug and prints for Found Syscalls and I see them getting kicked In. I tried debugging with the debugger and I saw jumps to NTDLL but I am not sure why the calls are still made from outside of the NTDLL address space.

Using the following functions and command to generate the syswhisper files in generic code injector
python3 syswhispers.py -a x64 -c msvc -m jumper_randomized -f NtAllocateVirtualMemory,NtWriteVirtualMemory,NtOpenProcess,NtCreateThreadEx,NtProtectVirtualMemory

I used the following Frida script to trace the syscalls origination:

var modules = Process.enumerateModules()
//send("[+] list of Modules " + modules.toString())
var ntdll = modules[1]
//send("[+] list of Modules " + ntdll.toString())


var ntdllBase = ntdll.base
send("[*] Ntdll base: " + ntdllBase)
var ntdllOffset = ntdllBase.add(ntdll.size)
send("[*] Ntdll end: " + ntdllOffset)

const mainThread = Process.enumerateThreads()[0];
Process.enumerateThreads().map(t => {
Stalker.follow(t.id, {
  events: {
    call: false, // CALL instructions: yes please
    // Other events:
    ret: false, // RET instructions
    exec: false, // all instructions: not recommended as it's
                 //                   a lot of data
    block: false, // block executed: coarse execution trace
    compile: false // block compiled: useful for coverage
  },
  onReceive(events) {    
  },
  transform(iterator){
      let instruction = iterator.next()
      do{
        
        //I think this reduces overhead
        if(instruction.mnemonic == "mov"){
            //Should provide a good filter for syscalls, might need further filtering
            if(instruction.toString() == "mov r10, rcx"){
                iterator.keep() //keep the instruction
                instruction = iterator.next() //next instruction should have the syscall number
								//This helps to clear up some false positives
                if(instruction.toString().split(',')[0] == "mov eax"){
                    var addrInt = instruction.address.toInt32()
                    //If the syscall is coming from somewhere outside the bounds of NTDLL
                    //then it may be malicious
                    if(addrInt < ntdllBase.toInt32() || addrInt > ntdllOffset.toInt32()){
                        send("[+] Found a potentially malicious syscall: " + instruction.toString())
                    }
                }
            }
        }
        
      iterator.keep()
      } while ((instruction = iterator.next()) !== null)
  }
  
 
})
})

Compiling and running to sysensor in x86 environment will cause abnormal crashes