9
arm64 syscall numbers are defined at: https://github.com/torvalds/linux/blob/v4.17/include/uapi/asm-generic/unistd.h
This is a bit confusing since it is quite different from x86 and x86_64 and arm which define syscall numbers under arch/, but that file has a comment saying:
New architectures should use this file and implement the less feature-full calls ...
9
Update: See this answer for up-to-date information on where ARM64 syscall definitions are found. Note that the information below may just be for backwards-compatibility.
See arch/arm64/include/asm/unistd32.h:
...
#define __NR_restart_syscall 0
__SYSCALL(__NR_restart_syscall, sys_restart_syscall)
#define __NR_exit 1
__SYSCALL(__NR_exit, sys_exit)
#...
9
The Intel and AMD instruction sets are similar but not identical.
There are many examples of that: FMA3/FMA4, AMD-V and VT-x (and their extensions), etc.
The fast system call interface is yet another difference.
Intel supports SYSENTER in all modes1 - Legacy Mode (or, on the few 32-bit only Intel CPUs, simply Protected Mode), Long Mode and Compatibility ...
7
This doesn't happen during the system call. It happens in user-mode.
WOW64 processes have two user-mode stacks - a 32-bit stack, which is the one you normally use, and a 64-bit stack. The WOW64 ntdll does not make system calls. Where the native 32-bit ntdll would sysenter (via an indirect call to SharedUserData!SystemCallStub) the WOW64 ntdll has an ...
6
7FFE0308h is a pointer inside the KUSER_SHARED_DATA struct.
The pre-set address for access from kernel mode is defined symbolically in WDM.H as KI_USER_SHARED_DATA. It helps when debugging to remember that this is 0xFFDF0000 or 0xFFFFF780`00000000, respectively, in 32-bit and 64-bit Windows. Also defined is a convenient symbol, SharedUserData, which casts ...
6
System calls vs. function calls
I mean, I know they are system calls, also printf along with scanf, strcmp are C functions.
Many C library functions are wrappers around system calls. printf and scanf are are examples of this. However, it should not be assumed that all C library functions execute system calls, as none of the string.h library functions, ...
5
The short answer is that syscall has less overhead than int 0x80.
For more details on why this is the case, see the accepted answer to Intel x86 vs x64 system call, where a nearly identical question was asked:
I'm told that syscall is lighter and faster than generating a software interrupt. Why it is faster on x64 than x86, and can I make a system call ...
5
Following cites, answering your first question come from Windows Internals Sixth Edition Part 1, page 225:
Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution
of 32-bit x86 applications on 64-bit Windows. It is implemented as a set of user-mode DLLs, with
some support from the kernel for creating 32-bit versions ...
5
To answer your question, let us first set a solid ground in terms of entities and definitions.
ELF stands for "Executable and Linkable format".
That is, it defines the structure and shape of two types of files:
Executables (Shared Objects *.so and stand-alone executables)
Linkables (Object files *.o)
Let us focus on executables.
Dependencies resolution ...
3
This StackOverflow answer is a great resource.
In summary, for 32 bits: Syscall number is eax. ebx, ecx, edx, esi, edi, ebp are used for arguments. You invoke the syscall with int 0x80. All registers are preserved after the syscall.
For 64 bit, that answer cites this specification, which might be a good "authentic resource" as you asked for.
This is a ...
3
int 2Eh is used on 32bit OS to enter the kernel mode. On 64-bit, the same is obtained by using syscall. The check done on memory address 0x7ffe0300 is one of the ways to detect the bitness.
2
Generally a reverse engineer translates assembly code to a higher level language, for that reason it is quite a necessity to be familiar with that language (or at least a similar language), usually understanding the intrinsics of those languages and how common language constructs are translated to the lower level is very helpful.
Understanding system level ...
2
PIN_AddSyscallEntryFunction and PIN_AddSyscallExitFunction should do the trick. Link to the Documentation.
Snippet using theses APIs : (credits to Jurriaan Bremer)
#include <stdio.h>
#include "pin.H"
void syscall_entry(THREADID thread_id, CONTEXT *ctx,
SYSCALL_STANDARD std, void *v)
{
printf("system-call: %d, arguments:",
...
2
Pintools on Windows can also aid you in instrumenting system calls. Also, if its discovered that the cpu supports sysenter/syscall, those are used in place of int 2e. However, this has no bearing on whether or not instrumentation can take place.
To answer your second question, yes, NtReadFile, NtWriteFile and NtDeviceIoControlFile are the *nix equivalent of ...
2
Generally speaking, yes, there are a lot of ways to generate entropy without system calls (this can be weak entropy, but anyway).
Here is a small (but obviously not even close to pretend to be full) list:
rdrand, rdseed instructions from intel random generator(btw, supported by AMD since 2015).
rdtsc instruction - which gives you a tick count since power ...
2
not sure what you mean
dot will always sound like dot wont it ?
so logically it will always have the same frequency and same duration ?
like wise dash will always sound like dash ?
if it varied like monkeydash , goatdash , pigdash each time it sounded then it wont be morse code ....
so logically dash will have the same frequency and duration
so ...
1
I would add information to the first answer.
The switch of the mode from Wow64 to 64bit, aka "Heaven's Gate", is in wow64cpu.dll. offset j_Wow64Transition is a part of wow64cpu.dll.
These slides helps you to understand the procedure of executing 64bit syscall from Wow64 process with assembly codes as a example.
1
I wouldn't call it authentic, but this surely is a source I've been using for quite some time now.
Double click on the line of the syscall to see what the parameters are (and their types).
You may see things like struct sockaddr __user, for these you need to dig a bit into the source files.
1
If you're using Wine, you just need to enable the trace. Do the following:
$ WINEDEBUG="trace+msvcrt" wine your_binary.exe
Taking a look to the Wine's source code I verified that both Sleep and Beep are being traced.
Beep:
void CDECL MSVCRT__beep( unsigned int freq, unsigned int duration)
{
TRACE(":Freq %d, Duration %d\n",freq,duration);
Beep(...
1
LMGTFY:
An interrupt is a signal from a device, such as the keyboard, to the CPU, telling it to immediately stop whatever it is currently doing and do something else. For example, the keyboard controller sends an interrupt when a key is pressed. To know how to call on the kernel when a specific interrupt arise, the CPU has a table called the IDT, which is ...
1
Generally system programming is not required, but recommended...
It is also important to understand the application flow, the CPU architecture (stack, heap, exceptions), file format (PE, ELF).
I suggest two good resource:
Crackmes.de
Reverse engineering for beginners - https://beginners.re/RE4B-EN.pdf
tuts4you - https://tuts4you.com/download.php?list.17
1
you can get system call stack with strace too. you just need to compile strace with libunwind. After that you just need to use -k to get system call stack for each system call.
1
JavaJournal, which was built on top of the pyspresso framework, was designed specifically for tracing method calls in Java.
1
C:\>md win32k
C:\>cd win32k
C:\win32k>copy c:\WINDOWS\system32\win32k.sys .
1 file(s) copied.
C:\win32k>"c:\Program Files\IDA Free\idag.exe" -B -A win32k.sys
wait till *.idb and *.asm is produced in the directory
C:\win32k>echo :redo >wait.bat
C:\win32k>echo if not exist *.idb (sleep 30 ^& goto :redo) >> wait.bat
C:\...
1
Place a read breakpoint on the memory you patched to find out what instructions are accessing it, that should lead you to some sort of checksum function or comparison to the file on disk. Then you can patch this check as well.
Only top voted, non community-wiki answers of a minimum length are eligible
