Writing buffer overflow exploits without NUL terminated strings

Question

I have the below assembly code global _start

section .text

_start:
    jmp call
pop:
    pop ecx                     ; ECX = address of hello
    xor eax, eax                ; EAX = 0
    xor al, al                   ; EAX = 4 (int 0x80 sys_write)
    inc al
    inc al
    inc al
    inc al
    xor ebx, ebx
    inc ebx                    //Does not work inside exploit
    xor edx, edx
    mov dl, hellolen            ; EDX = length of hello string
    int 0x80

    ; Terminate program
    xor eax, eax
    inc eax                    //Does not work inside exploit
    xor ebx, ebx                ; EBX = return value of 0
    int 0x80
call:
    call pop
    hello: db "Hello World!Ho are you!!!!!"
hellolen equ $-hello

The above code works properly and gives the proper output when run independently.

But when I take objdump of the same and if I try to run through buffer overflow I get the following issues.

Here inc al increments al value properly but inc eax or inc ebx

Could be because in the objdump it shows inc al --> fe c0 inc ebx --> 43 //some one byte number

I also tried the following methods to update eax and ebx

xor ebx, ebx
xor bl, bl
inc bl
movsx ebx, bl
;inc ebx

But here movsx opcode is 0x0f and it does not work as I encounter null terminated string(\x0x\x0f ).

"[...]here movsx opcode is 0x0f[...]". Luckily you don't need that instruction because it doesn't change anything: `EBX` is `1` and a sign-extend does not have any effect. — zx485, Mar 10 '19 at 19:22
I need to increment ebx somehow. What do you mean by I don't need that instruction? — srccode, Mar 10 '19 at 19:24
`MOVSX` does not increment `EBX` at all - it sign-extends its value - which is `1` - from `BL` to `EBX`, and so it does nothing, because sign-extending `1` just fills the upper bits with zeroes that are already there due to the `XOR EBX,EBX`. — zx485, Mar 10 '19 at 19:26
I mean `EBX` already contains value `1`, because of the `INC BL` instruction. — zx485, Mar 10 '19 at 19:31
@srccode: Are you using this exploit in a 64-bit program? This code will not run properly in 64-bit code. Your exploit program would have to be compiled with `-m32` (your GCC compiler by default will be generating 64-bit code without `-m32`). If you want to make a 64-bit exploit you will have to look at the link I provided in my last answer to you which directed you here: https://stackoverflow.com/a/50690339/3857942 . At that linkt he answer has an example `shellcode.asm` (and how to build it) that uses 64-bit `syscall` — Michael Petch, Mar 10 '19 at 19:36
But there they use ```syscall``` and it has opcode '0f'. When I write shellcode it stops when it encounters \x0. — srccode, Mar 10 '19 at 19:44
@zx485 But it is not updating to ebx I think. I commented out ```movsx```, the program will be printing the message indefinitely. — srccode, Mar 10 '19 at 19:47
I want you to do me a favor.Tell me the output of this command `file ./programtoexplot` where `programtoexploit` is the name of the executable with the buffer overflow you are trying to take advantage of. — Michael Petch, Mar 10 '19 at 19:49
I suspect that the output of that will include something like `ELF 64-bit`.If that is the case this exploit you are using will not work. I actually said as much in my other answer to you. — Michael Petch, Mar 10 '19 at 19:51
@MichaelPetch It says this ```./victim: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=119ee081c1562845e1bfc87f935325ad025ffc1c, not stripped``` — srccode, Mar 10 '19 at 19:59
Great, I said I bet it contains `ELF 64-bit` . The exploit you wrote is specifically for 32-bit. Your encountering odd behaviour because the instruction encoding of a 32-bit program is different than 64-bit. The instructions are being misinterpreted by the CPU and yielding odd behaviour. Let me know how you make out with the `shellcode.asm` example in the other answer that uses `syscall`. Also note it uses `-f elf64` when assembling with NASM (That is important) — Michael Petch, Mar 10 '19 at 20:03
I'm curious. Do you have the source code to the program `./victim` or are you doing this as part of an exploit challenge where you don't have the source code for the program being exploited? — Michael Petch, Mar 10 '19 at 20:06
Actually, I don't have the source code. This is a part of my course work. And I'm trying to explore buffer overflow exploits. — srccode, Mar 10 '19 at 20:11
Okay, so regarding 0x0f the program may have been designed to not accept 0x0f deliberately. Until you told me this was for course work and you don't have the source (of `./victim`) I was unsure about anything related to the target. In that other answer I linked to you will want to work off the second `shellcode.asm` example that eliminated the 0x00(NUL bytes).If you can't use 0x0f you will have to get creative to find instructions that don't use that byte as well. — Michael Petch, Mar 10 '19 at 20:14

Writing buffer overflow exploits without NUL terminated strings

0 Answers0