PLT stands for Procedure Linkage Table which is, put simply, used to call external procedures/functions whose address isn't known in the time of linking, and is left to be resolved by the dynamic linker at run time.
GOT stands for Global Offsets Table and is similarly used to resolve addresses. Both PLT and GOT and other relocation information is explained ...
I will try to answer from the kernel perspective, covering various OS's.
Memory segmentation is the old way of accessing memory regions.
All major operating systems including OSX, Linux, (from version 0.1) and Windows (from NT) are now using paging which is a better way (IMHO) of accessing memory.
Intel, has always introduced backward ...
Here's the official documentation for gas, quoting the relevant section:
In AT&T syntax the size of memory operands is determined from the last
character of the instruction mnemonic. Mnemonic suffixes of b, w,
l and q specify byte (8-bit), word (16-bit), long (32-bit) and
quadruple word (64-bit) memory references. Intel syntax accomplishes
Let me summarize the links given at https://reverseengineering.stackexchange.com/a/1993/12321 without going into serious disasembly analysis for now.
When the Linux kernel + dynamic linker is going to run a binary with exec, it traditionally just dumped the ELF section into a known memory location specified by the linker during link time.
So, whenever ...
FS points to the exception handling chain, CS and DS are filled from the OS with code and data segment. SS is the battery/stack segment. From what I remember, GS and ES are free.
It shouldn't matter much if kernel or user mode (they are used by some instructions like XLAT, MOVS, and some others, so you have to use them in the same way), but just in case I'm ...
Not really an optimization, but one gotcha that you must be aware of when coming from x86 is this:
Any operation on a 32-bit register zeroes out the top half of the 64-bit one
For example, the following:
mov eax, 3
Is actually equivalent to:
mov rax, 3
This also applies to the new registers r8-r15, e.g.:
also zeroes out the top half of r8.
movabs is used for absolute data moves, to either load an arbitrary 64-bit constant into a register or to load data in a register from a 64-bit address.
i wrote a windows specific answer to a question that was marked as duplicate and closed and the close flag referred to this thread so i post an answer here
os win7 sp1 32 bit machine
kernel dump using livekd from sysinternals
a 16 bit segment register contains
13 bits of selector
1 bit of table descriptor
2 bits of requester_privilege_level
if I pass an argument to an function it should be translated in
assembly language into push something
That's true for some 32-bit calling conventions, but your program is a 64-bit program and thus follows the System V Application Binary Interface for AMD64.
The calling ...
As Igor mentioned, it's GAS specific.
git log --reverse -Smovabs
tells us that it was introduced in 2000 commit c0d8940 and:
git tag --contains c0d8940
says that it was present as early as binutils-2_11.
Don't worry, the shellcode is executing properly, just that the debugger "skipped" past the execution.
Remember that rip is the instruction pointer and whatever code present at the rip is executed. If the code is invalid however, something will go wrong (for example a SIGSEGV will be raised)
In this particular case, a S (byte \x53) corresponds to a push ...
First of all, you have to understand that there is a specification for all these things. These specifications differ from one assembly language to another and from one operating system to the other.
These global specification are called Application Binary Interface (ABI) and define, among other things, what we call the 'calling conventions' of functions. ...
To move a number into an XMM register, you'll first need to move that number into a memory address since you can't move an immediate into an XMM register (meaning, you can't do something like mov XMM1,9).
If need be, you can allocate your own memory to store a number in, or in your scenario, if it's feasible, you could inject code to put your own value into ...
movabs is just a GAS-specific way to enforce encoding a 64-bit memory offset or immediate. It's still the same standard MOV opcode.
I'm not sure where you got the notion that it was introduced before x64, it's obviously not correct. For example, the Solaris x86 manual mentions: "movabs valid only under –m64".
I noticed that GAS translates
movq $0x80000000, %rax
movabs 0x80000000, %rax
But values smaller than 0x80000000 movement is not translated into movabs.
That is, movq $0x7fffffff, $rbx is NOT translated into movabs $0x7fffffff, %rbx. You can verify with disas disassemble command within GDB.
Maybe the reason is that $0x80000000 is over the signed ...
It is possible to rebuild the whole binary if you can leak any address in the process address space. As an example here is a memory map of a process
00400000-0040c000 r-xp 00000000 08:01 10223630 /bin/cat
0060b000-0060c000 r--p 0000b000 08:01 10223630 /bin/cat
0060c000-0060d000 rw-p ...
So this answer only focuses on the second question of @Efe:
How is +eax*8 constructed.
You can determine the SIB-offsets with the following steps. We analyze the first two bytes 04 c5 of the whole instruction:
dd 04 c5 60 40 08 08
First, we only focus on the MOD-REG-R/M Byte (look here for details)
MOD-REG-R/M Byte = 04
According to the documentation Page 1320
The result is stored in register AX, register pair DX:AX, or register pair EDX:EAX (depending on the operand size),
with the high-order bits of the product contained in register AH, DX, or EDX, respectively. If the high-order bits of
the product are 0, the CF and OF flags are cleared; otherwise, the flags are set.
The code is buggy. rax is used to store the original value of rsp and restore it at exit, but it’s also used as a temporary register in the loop in the middle of the function.
I suspect that this function was written manually in assembly but not actually tested on real hardware so the bug went unnoticed or, possibly, modified after initial testing and ...
You can use the OllyDbg software (http://www.ollydbg.de/). This software is for debug and dissasembler binary programs.
One of feature is search all referenced string, you can see this image:
So, in the next window, you can see all strings with an address. Like this:
You did not give any details about your machine's processor. Does it support 64-bit architecture? Does it implement the x86-64 instruction set?
This is only a problem if your machine's Intel processor does not support 64-bit architecture and/or does not does not implement the same instruction set as AMD64 processors.
However, AMD64 processors and most 64-...
Well, while it's definitely possible to jump to the entrypoint of the program to try restarting it, there may be various consequences preventing correct execution, e.g.:
library initialization has been run already, and running it a second time is not something most libraries expect
various resources may have been allocated and variables initialized, so ...
fldl is just the AT&T syntax for the "FLD" instruction involving a long (4 bytes) register. This is equivalent to
fld qword ptr [eax*8 + 8084060h]
in Intel syntax.
You could instruct objdump to emit Intel syntax with the -M intel flag.
While i386 does not support 64-bit addresses, it certain can read 64 bits out given an address. The "FLD m64fp" ...
This sounds like the process has allocated a page for itself, in which it has placed code to run. It might be a form of obfuscation, or if the file was packed, then the unpacker code might be in that page. If you're able to step into the code, then it can't be PAGE_NOACCESS, so perhaps the debugger is confused. The call through fs[0c0h] is the interface ...
Ok, I had a few e-mails with Fabrice Desclaux (aka serpilliere), one of the main contributor of miasm.
In fact, miasm (version 1) cannot disassemble amd64 opcodes (but do not issue any error if such executable is encountered). What is really misleading, is that the elf-64 is handled but the disassembler fail to recognize the amd64 opcodes.
So, this ...