Assembly Programming videos

[H@CK3R_ADI]

Do u have any good IDE for Asm

[marc_kriss]

Thats correct ADI. It is a simple trick but along with it I am trying to break the assembly code also completely. Actually I disassembled the C program written for being tested, I could not completely understand the assembly code prepared from that C program when we assemble it. Some segment registers also get involved. So i want to completely breakdown the disassembled code. And moreover I am learning by myself. The only support for this poor guy is Youtube, internet & great vivek ramachandran videos.

[marc_kriss]

Do u have any good IDE for Asm

Nothing, I am using only nano editor , then assembling & then linking it. I dont have any environment other than included in videos.

[sebas_phoenix]

Thats correct ADI. It is a simple trick but along with it I am trying to break the assembly code also completely. Actually I disassembled the C program written for being tested, I could not completely understand the assembly code prepared from that C program when we assemble it. Some segment registers also get involved. So i want to completely breakdown the disassembled code. And moreover I am learning by myself. The only support for this poor guy is Youtube, internet & great vivek ramachandran videos.

Hey mark, thanks for the videos. Btw, if you have any trouble understanding BoF, post the code in the forums, we will help you out!

Best Regards.

[marc_kriss]

thanks sebas_phoenix. I am trying to break down code for a BOF program in C:-
#include<stdio.h>
void display()
{
char buff[8];
gets(buff);
puts(buff);
}
main()
{
display();
return(0);
}
### And the disassembled code for main:-
Dump of assembler code for function main:
0x080484ae <+0>: push %ebp
0x080484af <+1>: mov %esp,%ebp
0x080484b1 <+3>: call 0x8048474 <display>
0x080484b6 <+8>: mov $0x0,%eax
0x080484bb <+13>: pop %ebp
0x080484bc <+14>: ret
End of assembler dump.
### Disassembled code for display:-
Dump of assembler code for function display:
0x08048474 <+0>: push %ebp
0x08048475 <+1>: mov %esp,%ebp
0x08048477 <+3>: sub $0x10,%esp
0x0804847a <+6>: mov %gs:0x14,%eax
0x08048480 <+12>: mov %eax,-0x4(%ebp)
0x08048483 <+15>: xor %eax,%eax
0x08048485 <+17>: lea -0xc(%ebp),%eax
0x08048488 <+20>: mov %eax,(%esp)
0x0804848b <+23>: call 0x8048374 <gets@plt>
0x08048490 <+28>: lea -0xc(%ebp),%eax
0x08048493 <+31>: mov %eax,(%esp)
0x08048496 <+34>: call 0x80483a4 <puts@plt>
0x0804849b <+39>: mov -0x4(%ebp),%eax
0x0804849e <+42>: xor %gs:0x14,%eax
0x080484a5 <+49>: je 0x80484ac <display+56>
0x080484a7 <+51>: call 0x8048394 <__stack_chk_fail@plt>
0x080484ac <+56>: leave
0x080484ad <+57>: ret
End of assembler dump.

There are no issues in understanding BOF. Basically I am trying to figure out, exactly whats going on in assembly code. How the stack values are getting shifted to where. Perhaps almost done. Just some hickups remaining.

[H@CK3R_ADI]

aha vuln detected see at line char buff[8]
it reads from:
0 1 2 3 4 6 7 8 9

this can be used for malicious code execution

[b0nd]

aha vuln detected see at line char buff[8]
it reads from:
0 1 2 3 4 6 7 8 9

this can be used for malicious code execution

gets() is the culprit here and depreciated function to use.

Cheers!

[H@CK3R_ADI]

And regarding function main the assembled code do the following:

<+0>Value of ebp is pushed on stack
<+1>Value of ebp is pushed on esp
<+3>Then it calls the Display
<+8>Before telling this please tell me you are on IA-32 or AT&T
<+13>it pops/take out the contents from the stack
<+14>Val ret

[sebas_phoenix]

thanks sebas_phoenix. I am trying to break down code for a BOF program in C:-
#include<stdio.h>
void display()
{
char buff[8];
gets(buff);
puts(buff);
}
main()
{
display();
return(0);
}
### And the disassembled code for main:-
Dump of assembler code for function main:
0x080484ae <+0>: push %ebp
0x080484af <+1>: mov %esp,%ebp
0x080484b1 <+3>: call 0x8048474 <display>
0x080484b6 <+8>: mov $0x0,%eax
0x080484bb <+13>: pop %ebp
0x080484bc <+14>: ret
End of assembler dump.
### Disassembled code for display:-
Dump of assembler code for function display:
0x08048474 <+0>: push %ebp
0x08048475 <+1>: mov %esp,%ebp
0x08048477 <+3>: sub $0x10,%esp
0x0804847a <+6>: mov %gs:0x14,%eax
0x08048480 <+12>: mov %eax,-0x4(%ebp)
0x08048483 <+15>: xor %eax,%eax
0x08048485 <+17>: lea -0xc(%ebp),%eax
0x08048488 <+20>: mov %eax,(%esp)
0x0804848b <+23>: call 0x8048374 <gets@plt>
0x08048490 <+28>: lea -0xc(%ebp),%eax
0x08048493 <+31>: mov %eax,(%esp)
0x08048496 <+34>: call 0x80483a4 <puts@plt>
0x0804849b <+39>: mov -0x4(%ebp),%eax
0x0804849e <+42>: xor %gs:0x14,%eax
0x080484a5 <+49>: je 0x80484ac <display+56>
0x080484a7 <+51>: call 0x8048394 <__stack_chk_fail@plt>
0x080484ac <+56>: leave
0x080484ad <+57>: ret
End of assembler dump.

There are no issues in understanding BOF. Basically I am trying to figure out, exactly whats going on in assembly code. How the stack values are getting shifted to where. Perhaps almost done. Just some hickups remaining.

Ok lets do it one step at a time for more clarity.

0x080484ae <+0>:	push   %ebp
0x080484af <+1>:	mov    %esp,%ebp

Typical function prologue. esp is not subtracted indicating no local variables are involved(useful when you don't have the source not now).

0x080484b6 <+8>:	mov    $0x0,%eax
0x080484bb <+13>:	pop    %ebp
0x080484bc <+14>:	ret

Typical function epilogue..returns 0x0 (always eax holds the return value). Now let's look at the disassembly of display()

0x08048474 <+0>:	push   %ebp
0x08048475 <+1>:	mov    %esp,%ebp
0x08048477 <+3>:	sub    $0x10,%esp

Again standard prologue of a function except that local variables are involved. Compiler allocates 0x10(16) bytes of memory for the local variables. Now there is something that you should note here, the 16 bytes may/may not be completely used by the local variables. Compiler can use some padding bytes to align dwords @ addresses that are multiples of 4 (I am assuming a 32-bit machine) for optimized access. Short story, dont take the 0x10 as the size of the local vars.

 0x0804847a <+6>:	mov    %gs:0x14,%eax
 0x08048480 <+12>:	mov    %eax,-0x4(%ebp)

gs is a segment register @ offset 0x14 you can find a global cookie value. Read about GS cookies, basically they prevent buffer overflows. How they work is that, they are inserted between the local variables and the saved frame pointer at the function prologue with a unique value that cannot be guessed by the attacker(hopefully!). Incase of a buffer overflow, the cookie value gets overwritten. The value of the cookie is check @ the function epilogue and if it is corrupted, the application crashes by calling
this code.

0x080484a7 <+51>:	call 0x8048394 <__stack_chk_fail@plt>

This is where the check happens at the function epilogue

0x0804849b <+39>:	mov -0x4(%ebp),%eax
0x0804849e <+42>:	xor %gs:0x14,%eax
0x080484a5 <+49>:	je 0x80484ac <display+56>

what this does is that it compares the stack cookie in our stack frame with the one that is stored in gs:0x14 and xor's them. Note that A (xor) A is 0. So if they both are the same, then the program proceeds as usual. Else it crashes.

I am assuming you are using a version of gcc that has stack protector enabled. To disable it , compile using -fno-stack-protector flag.

Hope that helps. Best Regards. I hope you got the buffer overflow part.

~peace

[sebas_phoenix]

And regarding function main the assembled code do the following:

<+0>Value of ebp is pushed on stack
<+1>Value of ebp is pushed on esp
<+3>Then it calls the Display
<+8>Before telling this please tell me you are on IA-32 or AT&T
<+13>it pops/take out the contents from the stack
<+14>Val ret

AT&T is not a processor, it is a syntax for assembly. As you can obviously see,it is AT&T considering the %(register) and <opcode> <source> <destination> format!