assembly

问题 For a long time I had not programmed with C and Assembler (about 2 years). Now I have decided to start again but I would like to do something much more complicated. I thought about creating a simple kernel. Now I found this source code on the internet: boot.asm: global loader extern kernel_main MAGIC equ 0xbad FLAGS equ 0x3 CHECKSUM equ -(MAGIC+FLAGS) section .text align 4 dd MAGIC dd FLAGS dd CHECKSUM loader: call kernel_main cli quit: hlt jmp quit kernel.c: void print(char *text) { char

问题 My code: .section .data name: .string "/bin/sh" args: .string "-c" .string "ls" .section .text .globl _start _start: pushq $0 pushq name movq $59, %rax movq %rsp, %rdi pushq $0 pushq args movq %rsp, %rsi movq $0, %rdx syscall I know that the second argument of execve is array of chars. How to do this in assembly avoiding this: execve("./payload", ["./payload"], 0x7ffc291fd160 /* 40 vars */) = 0 execve("/bin/sh", [0x736c00632d], NULL) = -1 EFAULT (Bad address) --- SIGSEGV {si_signo=SIGSEGV, si

问题 I am trying to hook a function within a application compiled with microsoft visual studio 2010, with __fastcall enabled from a delphi 2010 dll, but I am not to skilled to figure out how to detour the following problem: The C++ function is: void __fastcall function(int arg1; char* arg2); I was trying something like that (using uallHook): var FTextMessage : procedure(Modo: integer; Msg: pchar); register; procedure onTextMessage(Modo: integer; Msg: pchar); register; begin ShowMessage(inttostr

问题 In the following compiler output: a: .long 4 b: .byte 99 x: .zero 4 c: .byte 12 f: .zero 4 What does the .zero directive mean? It seems to be the only one not listed in the gas directives. Just from looking at the above, long is four bytes, .byte is one byte, and I'm guessing .zero means zero-for-four-bytes (or whatever the number is after the directive). Is that correct? If so, why not just do .long 0 . Does this put it in a different section or something? 回答1: No, it doesn't put it in a

问题 The Cortex-A57 Optimization Guide states that most integer instructions operating on 128-bit vector data can be dual-issued (Page 24, integer basic F0/F1, logical F0/F1, execution throughput 2). However with our internal (synthetic) benchmarks, throughput seems to be limited to exactly 1 128-bit neon integer instruction, even when there is plenty of instruction parallelism available (the benchmark was written with the intention to test whether 128-bit neon instructions can be dual-issued, so

问题 In NASM assembly, there are db and dw pseudo instructions to declare data. NASM Manual provides a couple of examples but doesn't say directly what's the difference between them. I've tried the following "hello world" code with both of them, and it turned out that no difference is observable. I suspect the distinct has something to do with internal data format, but I don't know how to inspect that. section .data msg db "hello world",10,13,0 msg2 dw "hello world",10,13,0 section .text global

问题 I'm working with interrupts and I'm facing this problem while running my code: DATA SEGMENT INPUTV DW 0035H, 0855H, 2011H, 1359H OUTPUTV DB 4 DUP(0) DIVIDER DB 09 ERROR_FLAG DB 0 DATA ENDS _STACK SEGMENT STACK DW 100 DUP(0) TOP_STACK LABEL WORD _STACK ENDS CODE SEGMENT ASSUME CS:CODE, DS:DATA, SS:_STACK MAIN: MOV AX, _STACK MOV SS, AX MOV SP, OFFSET TOP_STACK MOV AX, DATA MOV DS, AX MOV AX, 0000H MOV ES, AX MOV WORD PTR ES:0002, SEG INT_PROC ;PUSHING CS TO STACK MOV WORD PTR ES:0000, OFFSET

问题 I'm working with interrupts and I'm facing this problem while running my code: DATA SEGMENT INPUTV DW 0035H, 0855H, 2011H, 1359H OUTPUTV DB 4 DUP(0) DIVIDER DB 09 ERROR_FLAG DB 0 DATA ENDS _STACK SEGMENT STACK DW 100 DUP(0) TOP_STACK LABEL WORD _STACK ENDS CODE SEGMENT ASSUME CS:CODE, DS:DATA, SS:_STACK MAIN: MOV AX, _STACK MOV SS, AX MOV SP, OFFSET TOP_STACK MOV AX, DATA MOV DS, AX MOV AX, 0000H MOV ES, AX MOV WORD PTR ES:0002, SEG INT_PROC ;PUSHING CS TO STACK MOV WORD PTR ES:0000, OFFSET

问题 Intel's System Programming Guide, section 8.3, states regarding MFENCE/SFENCE/LFENCE: "The following instructions are memory-ordering instructions, not serializing instructions. These drain the data memory subsystem. They do not serialize the instruction execution stream. " I'm trying to figure out why this matters. In multi-threaded code, writes/reads to memory are exactly what need to happen in a well-defined order. Of course, the order which I/O happens in might matter, but I/O

问题 Which is generally faster to test the byte in AL for zero / non-zero? TEST EAX, EAX TEST AL, AL Assume a previous "MOVZX EAX, BYTE PTR [ESP+4]" instruction loaded a byte parameter with zero-extension to the remainder of EAX, preventing the combine-value penalty that I already know about. So AL=EAX and there are no partial-register penalties for reading EAX. Intuitively just examining AL might let you think it's faster, but I'm betting there are more penalty issues to consider for byte access