x86-64

问题 I've been trying to understand assembly language code generated by GCC and frequently encounter this instruction at start of many functions including _start(), but coudn't find any guide explaining it's purpose 31-0000000000001040 <_start>: 32: 1040: f3 0f 1e fa endbr64 33- 1044: 31 ed xor ebp,ebp 回答1: It stands for "End Branch 64 bit" -- or more precisely, Terminate Indirect Branch in 64 bit Intel has a document about this instruction. Here is the operation: IF EndbranchEnabled(CPL) & EFER

问题 Question What are some ideas for cross-modifying code that could trigger unexpected behavior on x86 or x86-x64 systems, where everything is done correctly in the cross-modifying code, with the exception of executing a serializing instruction on the executing processor prior to executing the modified code? As noted below, I have a Core 2 Duo E6600 processor to test on, which is explicitly mentioned as a processor that is prone to issues regarding this. I will test any ideas shared with me on

问题 From Intel's SDM, section 2.2.1 specifies that the REX prefix is used to: Specify GPRs and SSE registers. Specify 64-bit operand size. Specify extended control registers But what do the letters REX stand for in the acronym? 回答1: This 2002 Hot Chips presentation by AMD expands the acronym on slide 10: "REX (Register Extension)". Kevin McGrath and Dave Christie, "The AMD x86-64 Architecture: Extending the x86 to 64 bits", Hot Chips 14, August 2002. 来源： https://stackoverflow.com/questions

问题 I'd like to instrument syscall brk (and other calls but this in first order, it's most important to me) in given binary (preferably on actual syscall/sysenter level (x86-64 and x86) of making sys_brk call). Main goal: A part of sandbox which gives fixed amount of memory to jailed process So, I'd like to get rid of brk system calls (and most preferably others in next order) and simulate memory allocations under fixed limit . Fixed limit is memory space, available to program. (You can think

问题 Suppose I want to do a short jump using the following opcodes: EB CB or JMP rel8 "Jump short, RIP = RIP + 8-bit displacement sign extended to 64-bits" (where CB is a byte signed value representing the relative offset relating to direction in EIP register) Maybe always the offset will be offset+2 because the EIP in execution time (the reference direction) in this short jump is the base of the twobyte instruction, but the addend occurs always eb 30 = jmp 0x00000032 (+30) eb e2 = jmp 0xffffffe4

问题 Suppose I want to do a short jump using the following opcodes: EB CB or JMP rel8 "Jump short, RIP = RIP + 8-bit displacement sign extended to 64-bits" (where CB is a byte signed value representing the relative offset relating to direction in EIP register) Maybe always the offset will be offset+2 because the EIP in execution time (the reference direction) in this short jump is the base of the twobyte instruction, but the addend occurs always eb 30 = jmp 0x00000032 (+30) eb e2 = jmp 0xffffffe4

问题 Suppose I want to do a short jump using the following opcodes: EB CB or JMP rel8 "Jump short, RIP = RIP + 8-bit displacement sign extended to 64-bits" (where CB is a byte signed value representing the relative offset relating to direction in EIP register) Maybe always the offset will be offset+2 because the EIP in execution time (the reference direction) in this short jump is the base of the twobyte instruction, but the addend occurs always eb 30 = jmp 0x00000032 (+30) eb e2 = jmp 0xffffffe4

问题 Well I've found something that interests me and I didn't manage to find an answer for it.... how does the va_arg \ va_start \ va_list \ va_end macros work under the hood in x64? calling convention in i386 passes parameters on the stack hence the macro just increments some pointer that points to the stack base and forwards it however in x64 all parameters are passed by registers.... so what happens there? how does the called function know which registers were used to pass arguments and doesn't

问题 I'm experimenting with ELF executables and the gnu toolchain on Linux x86_64: I've linked and stripped (by hand) a "Hello World" test.s: .global _start .text _start: mov $1, %rax ... into a 267 byte ELF64 executable... 0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ 0000010: 0200 3e00 0100 0000 d400 4000 0000 0000 ..>.......@..... 0000020: 4000 0000 0000 0000 0000 0000 0000 0000 @............... 0000030: 0000 0000 4000 3800 0100 4000 0000 0000 ....@.8...@..... 0000040: 0100

问题 I'm experimenting with ELF executables and the gnu toolchain on Linux x86_64: I've linked and stripped (by hand) a "Hello World" test.s: .global _start .text _start: mov $1, %rax ... into a 267 byte ELF64 executable... 0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ 0000010: 0200 3e00 0100 0000 d400 4000 0000 0000 ..>.......@..... 0000020: 4000 0000 0000 0000 0000 0000 0000 0000 @............... 0000030: 0000 0000 4000 3800 0100 4000 0000 0000 ....@.8...@..... 0000040: 0100