zznop / drow Goto Github PK

From @EMCELLY:

I did some quick testing here are the results.

Centos 8.1 - works as expected.
Ubunutu 18 - segfault in drow
Ubuntu 16 - segfault in drow
Centos 7.-0 - segfault in drow
Centos 6.0 - segfault in drow

Attaching some gdb logs and a core file since they all seem to be the same issue on line 103 of find_exe_seg_last_section function.

core.15948.gz
ubuntu-18.crash.txt
ubuntu-16.crash.txt
centos-7.0.crash.txt
centos-6.0-crash.txt

Originally posted by @EMCELLY in #2 (comment)

build 2 asm file to elf when inject shellcode , eventlually coredumped
wish there is some imporement .

The tool works great on Ubuntu however we're experiencing crashes on CentOS and Debian. I've included 2 patched binaries one created under latest Debian and another created under Centos 6.10. Let us know if there is anything we can do to help.
debian-ls-patched-crashing.gz
centos-ls-patched-crashing.gz

[root@localhost drow]# cp /bin/ls ./
cp: overwrite `./ls'? y
[root@localhost drow]# ./build/drow ls ./build/rappers_delight.bin ls-bd
____ ____ _____ _ _
( _ ( _ ( _ )( // )
)() )) / )()( ) (
(__/()_)(___)(/_)

[] Mapping file: ls
[] Mapping file: ./build/rappers_delight.bin
[] Finding last section in executable segment ...
[+] Found executable segment at 0x00000040 (size:000001c0)
[+] Found executable segment at 0x00000000 (size:0001851c)
[+] Found .eh_frame at 0x00016540 with a size of 8156 bytes
[] Expanding .eh_frame size by 8192 bytes...
[] Adjusting Section Header offsets ...
[] Adjusting Program Header offsets ...
[] Adjusting ELF header offsets ...
[] Modifying ELF e_entry to point to the patch at 0x0001851c ...
[] Exporting patched ELF to ls-bd ...
[] Writing first part of ELF (size: 99612)
[] Setting old and new e_entry values in stager ...
[] Writing stager stub (size: 49) ...
[] Writing patch/payload (size: 289)
[] Writing pad to maintain page alignment (size: 7854)
[*] Writing remaining data (size: 9596)
[+] ELF patched successfully!
[root@localhost drow]# ./ls-bd
Segmentation fault (core dumped)

        |------------------| <-- shtable[j].sh_addr
        |                  |                     ↑
        |                  |                     |
        |    content of    |              shtable[j].sh_size
        |     section      |                     |
        |                  |                     ↓
        |------------------| <-------------------|
        |      vacuum      |
        |    for  payload  |
        |      inject      |
        |------------------| <-- shtable[j+1].sh_addr

patch_size and stager_size together represent the total size of the payload. Therefore, I believe that the correct condition would be shtable[j+1].sh_addr - shtable[j].sh_addr - shtable[j].sh_size >= patch_size + stager_size. However, please let me know if I have misunderstood the implementation or if there are any errors in my statement."

Hey zznop.

• While trying to figure something out I noticed that GDB and other tools like ltrace don't like the binaries produced by drow. I've included the original target binary and the backdoored one.
  ls.gz
  ls-bd.gz

"0x7ffc14b4cce0s": not in executable format: file format not recognized
------- tip of the day (disable with set show-tips off) -------
Use the canary command to see all stack canary/cookie values on the stack (based on the usual stack canary value initialized by glibc)
pwndbg>

ltrace ./ls-bd
Couldn't get section #1 from "/proc/994604/exe": invalid section index

• While I have you I might as well ask - Are we supposed to be able to call libc functions from drow payloads? I've been experimenting with different payloads like the one below and haven't been able to figure it out. You can see I'm just trying to call libc puts. I've tried various ways like puts@PLT. Do I have to find the address of libc functions my self and then call them or is the an easier way? Thanks!

.intel_syntax noprefix

jmp past

message:
.string "See, I am drow, and I'd like to say hello,\n"

past:
lea rdi, [rip + message]
call puts
ret