assembly

问题 Each thread has its own stack to store local variables. But stacks are also used to store return addresses when calling a function. In x86 assembly, esp points to the most-recently allocated end of the stack. Today, most CPUs have stack grow negatively. This behavior enables arbitrary code execution by overflowing the buffer and overwriting the saved return address. If the stack was to grow positively, such attacks would not be feasible. Is it safer to have the call stack grow upwards? Why

问题 Each thread has its own stack to store local variables. But stacks are also used to store return addresses when calling a function. In x86 assembly, esp points to the most-recently allocated end of the stack. Today, most CPUs have stack grow negatively. This behavior enables arbitrary code execution by overflowing the buffer and overwriting the saved return address. If the stack was to grow positively, such attacks would not be feasible. Is it safer to have the call stack grow upwards? Why

问题 Each thread has its own stack to store local variables. But stacks are also used to store return addresses when calling a function. In x86 assembly, esp points to the most-recently allocated end of the stack. Today, most CPUs have stack grow negatively. This behavior enables arbitrary code execution by overflowing the buffer and overwriting the saved return address. If the stack was to grow positively, such attacks would not be feasible. Is it safer to have the call stack grow upwards? Why

问题 It seems both JS and JL can implement the comparison in below code snippet ( var >= 0 ), then what's the difference of using these 2 to implement if/else? BTW: the EFLAGS they check are a little difference, so I am also wondering why different EFLAGS are tested for similar statement. int var; if (var >= 0) { ... } else { ... } 回答1: JS jumps if the sign flag is set ( SF=1 ), while JL jumps if the sign flag doesn't equal the overflow flag ( SF != OF ). There are situations where one of these

问题 So an executable contains of different sections and headers. At the ELF Header we can see some metadata about them like the size of different headers, Starting point etc. Are the different parts of an executable get loaded into memory all at once? If yes, how / when it is defined and where we can see the information about that because the ELF Header doesn't seem to have any parameter in that matter. Thanks in advance. 回答1: With ELF binaries, sections are not what decides how the binary is

问题 I was going through a binary file corresponding to a C program. I have a very large address stored in %eax . When tried to see the value via gdb , it prints a negative value (reason here). Now when mov %eax, 0x4c(%esp) is performed, the resulted value in 0x4c(%esp) is sometimes positive and sometimes negative. This effect cmp $0, 0x4c(%esp) statement that follows! Can someone please explain this behavior? If this helps: core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style

问题 I'm trying to write kind of exploit and have a problem with making my asm code run anywhere on the stack. Here's it: BITS 64 global _start _start: mov rax, 59 jmp short file c1: pop rdi jmp short argv c2: pop rsi mov rdx, 0 syscall ret file: call c1 db '/bin/sh',0 argv: call c2 dq arg, 0 <- problem arg: db 'sh',0 This code won't work anywhere on the stack due to selected line because this code can be executed anywhere on the stack so nasm can't correctly compute arg's address. (This is a

问题 I find that in RISC-V, ra is caller saved, in MIPS, ra is callee, which means in RISC-V callee can directly change the value in ra without save, but since ra has changed, how callee return back to caller? 回答1: The usage of RISC V ra and MIPS $ra is effectively the same regardless of the designation. Since both caller (who needs to return to their caller) and (a non-leaf) callee need to repurpose the return address register, the value in that register needs to be preserved. The only logical

问题 After using IDA Pro to disassemble a x86 dll, I found this code (Comments added by me in pusedo-c code. I hope they're correct): test ebx, ebx ; if (ebx == false) jz short loc_6385A34B ; Jump to 0x6385a34b mov eax, [ebx+84h] ; eax = *(ebx+0x84) mov ecx, [esi+84h] ; ecx = *(esi+0x84) mov al, [eax+30h] ; al = *(*(ebx+0x84)+0x30) xor al, [ecx+30h] ; al = al XOR *(*(esi+0x84)+0x30) jnz loc_6385A453 Lets make it simpler for me to understand: mov eax, b3h xor eax, d6h jnz ... How does the

问题 ... so that browsing the disassembly won't immediately expose the password (declared as a static variable). As an example, imagine a program that has a zip file attached that it must open for assets but is not easily accessible to prying eyes. I know that it is impossible to completely hide or protect that zip but I'm curious what means are available to at least hold off a casual snooper. Thanks! 回答1: No but there are things you can do to make it harder. Store the password as a series of