Would someone be able to clarify whether when you type a command at the Windbg command prompt are the 64 bit addresses displayed in the very first column virtual or are they actually physical addresses ?
lkd> uf nt!KiInitSpinLocks
nt!KiInitSpinLocks:
fffff802`127eb05c 48895c2408 mov qword ptr [rsp+8],rbx
fffff802`127eb061 48896c2410 mov qword ptr [rsp+10h],rbp
fffff802`127eb066 4889742418 mov qword ptr [rsp+18h],rsi
fffff802`127eb06b 57 push rdi
fffff802`127eb06c 4883ec20 sub rsp,20h
fffff802`127eb070 33ed xor ebp,ebp
fffff802`127eb072 488bd9 mov rbx,rcx
fffff802`127eb075 c781a058000001000000 mov dword ptr [rcx+58A0h],1
fffff802`127eb07f 448d4520 lea r8d,[rbp+20h]
fffff802`127eb083 488d8100590000 lea rax,[rcx+5900h]
fffff802`127eb08a 89a998580000 mov dword ptr [rcx+5898h],ebp
fffff802`127eb090 4889a9882c0000 mov qword ptr [rcx+2C88h],rbp
fffff802`127eb097 8bf2 mov esi,edx
fffff802`127eb099 418bc8 mov ecx,r8d
Assuming you're on a physical machine (not a VM) and assuming that the physical memory is handled in a contiguous way (it needn't be in VMs), 0xfffff802127eb05c is at 18446735286 GB in your RAM.
But yeah, the documentation leaves it open. Just if you know that there is up to disassemble physical memory, you'll find the statement
The up command disassembles only physical memory, while the u command disassembles only virtual memory.
Related
I have an executable which simply inputs a string using "gets" and places it in a buffer. Using gdb the disassembly of the executable comes out to be -
push %rbp
mov %rsp,%rbp
sub $0x40,%rsp
mov $0x400684,%edi
call 0x400470 <puts#plt>
lea -0x40(%rbp),%rax
mov %rax,%rdi
mov $0x0,%eax
call 0x4004a0 <gets#plt>
lea -0x40(%rbp),%rax
mov %rax,%rsi
mov $0x400699,%edi
mov $0x0,%eax
call 0x400480 <printf#plt>
mov $0x0,%eax
leave
ret
I am trying to pass a shellcode which prints "hello world" on the console overflowing the buffer (64 Bytes) of the program. Address Space Layout Randomization (ASLR), Stack Smashing Protection (SSP) and preventing the execution of code from the stack all are disabled. The inputs like "\xdf" etc which I see in tutorials all over the internet are not overwriting the return address as intended. The program is considering "", "x", "d", "f" to be separate characters. The shellcode I am using is -
\x90\x90\x90\x48\x65\x6c\x6c\x6f\x2c\x20\x57\x6f\x72\x6c\x64\x21\x0d\x0a\xdf\xff\xff\xff\x7f
The last 5 bytes are what I want the return address to point to i.e (0x7fffffffdf). How to achieve the desired result? Thanks!
When compiling below code:
global main
extern printf, scanf
section .data
msg: db "Enter a number: ",10,0
format:db "%d",0
section .bss
number resb 4
section .text
main:
mov rdi, msg
mov al, 0
call printf
mov rsi, number
mov rdi, format
mov al, 0
call scanf
mov rdi,format
mov rsi,[number]
inc rsi
mov rax,0
call printf
ret
using:
nasm -f elf64 example.asm -o example.o
gcc -no-pie -m64 example.o -o example
and then run
./example
it runs, print: enter a number:
but then crashes and prints:
Segmentation fault (core dumped)
So printf works fine but scanf not.
What am I doing wrong with scanf so?
Use sub rsp, 8 / add rsp, 8 at the start/end of your function to re-align the stack to 16 bytes before your function does a call.
Or better push/pop a dummy register, e.g. push rdx / pop rcx, or a call-preserved register like RBP you actually wanted to save anyway. You need the total change to RSP to be an odd multiple of 8 counting all pushes and sub rsp, from function entry to any call.
i.e. 8 + 16*n bytes for whole number n.
On function entry, RSP is 8 bytes away from 16-byte alignment because the call pushed an 8-byte return address. See Printing floating point numbers from x86-64 seems to require %rbp to be saved,
main and stack alignment, and Calling printf in x86_64 using GNU assembler. This is an ABI requirement which you used to be able to get away with violating when there weren't any FP args for printf. But not any more.
See also Why does the x86-64 / AMD64 System V ABI mandate a 16 byte stack alignment?
To put it another way, RSP % 16 == 8 on function entry, and you need to ensure RSP % 16 == 0 before you call a function. How you do this doesn't matter. (Not all functions will actually crash if you don't, but the ABI does require/guarantee it.)
gcc's code-gen for glibc scanf now depends on 16-byte stack alignment
even when AL == 0.
It seems to have auto-vectorized copying 16 bytes somewhere in __GI__IO_vfscanf, which regular scanf calls after spilling its register args to the stack1. (The many similar ways to call scanf share one big implementation as a back end to the various libc entry points like scanf, fscanf, etc.)
I downloaded Ubuntu 18.04's libc6 binary package: https://packages.ubuntu.com/bionic/amd64/libc6/download and extracted the files (with 7z x blah.deb and tar xf data.tar, because 7z knows how to extract a lot of file formats).
I can repro your bug with LD_LIBRARY_PATH=/tmp/bionic-libc/lib/x86_64-linux-gnu ./bad-printf, and also it turns out with the system glibc 2.27-3 on my Arch Linux desktop.
With GDB, I ran it on your program and did set env LD_LIBRARY_PATH /tmp/bionic-libc/lib/x86_64-linux-gnu then run. With layout reg, the disassembly window looks like this at the point where it received SIGSEGV:
│0x7ffff786b49a <_IO_vfscanf+602> cmp r12b,0x25 │
│0x7ffff786b49e <_IO_vfscanf+606> jne 0x7ffff786b3ff <_IO_vfscanf+447> │
│0x7ffff786b4a4 <_IO_vfscanf+612> mov rax,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ab <_IO_vfscanf+619> add rax,QWORD PTR [rbp-0x458] │
│0x7ffff786b4b2 <_IO_vfscanf+626> movq xmm0,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ba <_IO_vfscanf+634> mov DWORD PTR [rbp-0x678],0x0 │
│0x7ffff786b4c4 <_IO_vfscanf+644> mov QWORD PTR [rbp-0x608],rax │
│0x7ffff786b4cb <_IO_vfscanf+651> movzx eax,BYTE PTR [rbx+0x1] │
│0x7ffff786b4cf <_IO_vfscanf+655> movhps xmm0,QWORD PTR [rbp-0x608] │
>│0x7ffff786b4d6 <_IO_vfscanf+662> movaps XMMWORD PTR [rbp-0x470],xmm0 │
So it copied two 8-byte objects to the stack with movq + movhps to load and movaps to store. But with the stack misaligned, movaps [rbp-0x470],xmm0 faults.
I didn't grab a debug build to find out exactly which part of the C source turned into this, but the function is written in C and compiled by GCC with optimization enabled. GCC has always been allowed to do this, but only recently did it get smart enough to take better advantage of SSE2 this way.
Footnote 1: printf / scanf with AL != 0 has always required 16-byte alignment because gcc's code-gen for variadic functions uses test al,al / je to spill the full 16-byte XMM regs xmm0..7 with aligned stores in that case. __m128i can be an argument to a variadic function, not just double, and gcc doesn't check whether the function ever actually reads any 16-byte FP args.
When compiling below code:
global main
extern printf, scanf
section .data
msg: db "Enter a number: ",10,0
format:db "%d",0
section .bss
number resb 4
section .text
main:
mov rdi, msg
mov al, 0
call printf
mov rsi, number
mov rdi, format
mov al, 0
call scanf
mov rdi,format
mov rsi,[number]
inc rsi
mov rax,0
call printf
ret
using:
nasm -f elf64 example.asm -o example.o
gcc -no-pie -m64 example.o -o example
and then run
./example
it runs, print: enter a number:
but then crashes and prints:
Segmentation fault (core dumped)
So printf works fine but scanf not.
What am I doing wrong with scanf so?
Use sub rsp, 8 / add rsp, 8 at the start/end of your function to re-align the stack to 16 bytes before your function does a call.
Or better push/pop a dummy register, e.g. push rdx / pop rcx, or a call-preserved register like RBP you actually wanted to save anyway. You need the total change to RSP to be an odd multiple of 8 counting all pushes and sub rsp, from function entry to any call.
i.e. 8 + 16*n bytes for whole number n.
On function entry, RSP is 8 bytes away from 16-byte alignment because the call pushed an 8-byte return address. See Printing floating point numbers from x86-64 seems to require %rbp to be saved,
main and stack alignment, and Calling printf in x86_64 using GNU assembler. This is an ABI requirement which you used to be able to get away with violating when there weren't any FP args for printf. But not any more.
See also Why does the x86-64 / AMD64 System V ABI mandate a 16 byte stack alignment?
To put it another way, RSP % 16 == 8 on function entry, and you need to ensure RSP % 16 == 0 before you call a function. How you do this doesn't matter. (Not all functions will actually crash if you don't, but the ABI does require/guarantee it.)
gcc's code-gen for glibc scanf now depends on 16-byte stack alignment
even when AL == 0.
It seems to have auto-vectorized copying 16 bytes somewhere in __GI__IO_vfscanf, which regular scanf calls after spilling its register args to the stack1. (The many similar ways to call scanf share one big implementation as a back end to the various libc entry points like scanf, fscanf, etc.)
I downloaded Ubuntu 18.04's libc6 binary package: https://packages.ubuntu.com/bionic/amd64/libc6/download and extracted the files (with 7z x blah.deb and tar xf data.tar, because 7z knows how to extract a lot of file formats).
I can repro your bug with LD_LIBRARY_PATH=/tmp/bionic-libc/lib/x86_64-linux-gnu ./bad-printf, and also it turns out with the system glibc 2.27-3 on my Arch Linux desktop.
With GDB, I ran it on your program and did set env LD_LIBRARY_PATH /tmp/bionic-libc/lib/x86_64-linux-gnu then run. With layout reg, the disassembly window looks like this at the point where it received SIGSEGV:
│0x7ffff786b49a <_IO_vfscanf+602> cmp r12b,0x25 │
│0x7ffff786b49e <_IO_vfscanf+606> jne 0x7ffff786b3ff <_IO_vfscanf+447> │
│0x7ffff786b4a4 <_IO_vfscanf+612> mov rax,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ab <_IO_vfscanf+619> add rax,QWORD PTR [rbp-0x458] │
│0x7ffff786b4b2 <_IO_vfscanf+626> movq xmm0,QWORD PTR [rbp-0x460] │
│0x7ffff786b4ba <_IO_vfscanf+634> mov DWORD PTR [rbp-0x678],0x0 │
│0x7ffff786b4c4 <_IO_vfscanf+644> mov QWORD PTR [rbp-0x608],rax │
│0x7ffff786b4cb <_IO_vfscanf+651> movzx eax,BYTE PTR [rbx+0x1] │
│0x7ffff786b4cf <_IO_vfscanf+655> movhps xmm0,QWORD PTR [rbp-0x608] │
>│0x7ffff786b4d6 <_IO_vfscanf+662> movaps XMMWORD PTR [rbp-0x470],xmm0 │
So it copied two 8-byte objects to the stack with movq + movhps to load and movaps to store. But with the stack misaligned, movaps [rbp-0x470],xmm0 faults.
I didn't grab a debug build to find out exactly which part of the C source turned into this, but the function is written in C and compiled by GCC with optimization enabled. GCC has always been allowed to do this, but only recently did it get smart enough to take better advantage of SSE2 this way.
Footnote 1: printf / scanf with AL != 0 has always required 16-byte alignment because gcc's code-gen for variadic functions uses test al,al / je to spill the full 16-byte XMM regs xmm0..7 with aligned stores in that case. __m128i can be an argument to a variadic function, not just double, and gcc doesn't check whether the function ever actually reads any 16-byte FP args.
I want to get user's input from the console and use the IP address for a socket connection instead of hardcoding the IP address.
From my learning on https://azeria-labs.com/tcp-bind-shell-in-assembly-arm-32-bit/, I modified the socket structure (still using a hardcoded address) as such:
struct:
.ascii "\x02\xff"
.ascii "\x11\x5c"
ipv4: .byte 0
ipv4_2: .byte 0
ipv4_3: .byte 0
ipv4_4: .byte 0
I then copy the actual address to the 4 bytes for IP address
adr r1,ipv4
mov r2,#127
strb r2, [r1]
adr r1,ipv4_2
mov r2,#0
strb r2, [r1]
adr r1,ipv4_3
mov r2,#0
strb r2, [r1]
adr r1,ipv4_4
mov r2,#1
strb r2, [r1]
The connection will complete successfully. However, if I want to get an IP address input from user, such as 255.255.255.255, each single digit actually takes up one byte individually, so 255 is treated as 0x2 0x5 0x5, instead of 0xff which is the intended interpretation (one byte). The code to read input:
mov r7,#3
mov r0,#0
adr r1,userinput
mov r2,#20
svc #1
How do I "combine" the three digits into one and then store it in a single byte?
If that is not the way, what is the correct way to do it? Is it possible to do it without the use of external libc functions?
.
I have a school project, recoding a strace-like command on a x86_64 OpenSUSE. (Intell i7)
For this purpose we are, of course, using ptrace system call but it is forbiden to use PTRACE_SYSCALL. We have to use PTRACE_SINGLESTEP and detect systems calls thanks to PTRACE_PEEKTEXT and opcodes corresponding to system calls instructions (0x80CD for int0x80, 0x050F for syscall and 0x340F for sysenter).
Until there, I'm good. But then we have to fetch the parameters of the system call. For syscall and intx80 it's kind of easy, I look into rax to know which system call it is, then I look into rdi, rsi, rdx, etc.
But for sysenter I cannot find how it's really working. So I tried to code a little assembly program to test those 3 instructions.
BITS 64
global main
section .text
main:
push rbp
mov rbp, rsp
mov rdi, 1
mov rsi, FormatStr
mov rdx, 30
mov rax, 1
syscall
leave
ret
section .rodata
FormatStr db 'Hello World ! Sysenter Test !',0Ah,0
Which works perfectly fine !
Now for the int 0x80 version I just change the number of the system call in rax from 1 to 4. (In 32, dunno why but the system calls numbers aren't the same)
BITS 64
global main
section .text
main:
push rbp
mov rbp, rsp
mov rdi, 1
mov rsi, FormatStr
mov rdx, 30
mov rax, 4
int 0x80
leave
ret
section .rodata
FormatStr db 'Hello World ! Sysenter Test !',0Ah,0
Which works at 50%. A string is displayed but it's garbage.
Now if I put a sysenter I get a SIGILL signal. I tried with 1 and 4 in rax.
My project just has to run on my computer but I have to be able to detect and analyse binaries who are using sysenter
Can someone give a little explication on those things ?
Thank you !
Ps : sorry for my bad english