Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDB/ltrace errors when debugging drow payloads #7

Open
ghost opened this issue Jan 3, 2023 · 2 comments
Open

GDB/ltrace errors when debugging drow payloads #7

ghost opened this issue Jan 3, 2023 · 2 comments

Comments

@ghost
Copy link

ghost commented Jan 3, 2023

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

@zznop
Copy link
Owner

zznop commented Mar 10, 2023

Sorry for the late response: I noticed the same and have not dug into exactly why. My best guess is it doesn't like some of the mods that drow is making to program headers.

As for your assembly, drow injects shellcode payloads. When the example payload is built, only the .text section is objcopy-ed out of the ELF to the shellcode bin file (see here). Therefore you can't use imports, such as libc functions, without knowing / resolving the address yourself. All code needs to be self-contained and position-independent, as there is nothing that will fix-up relocations for you.

@Risminator
Copy link
Contributor

Risminator commented Apr 30, 2024

I think I've found the root of the problem. At least it stopped crashing gdb for me.

The problem is adjusting the elf headers: e_shoff and e_phoff in expand_section(). It's written like this:

printf(INFO "Adjusting ELF header offsets ...\n");
if (ehdr->e_shoff > tinfo->base)
	ehdr->e_shoff = ehdr->e_shoff + patch_size + stager_size;
if (ehdr->e_phoff > tinfo->base)
	ehdr->e_phoff = ehdr->e_phoff + patch_size + stager_size;

However, it shouldn't adjust ELF header offsets if nothing was expanded beforehand. In other words, the adjustment should only come when the inject method is METHOD_EXPAND_AND_INJECT. For example, like this (not the best look, but works as an example):

if (sinfo->inject_method == METHOD_EXPAND_AND_INJECT) {
	printf(INFO "Adjusting ELF header offsets ...\n");
	if (ehdr->e_shoff > tinfo->base)
		ehdr->e_shoff = ehdr->e_shoff + patch_size + stager_size;
	if (ehdr->e_phoff > tinfo->base)
		ehdr->e_phoff = ehdr->e_phoff + patch_size + stager_size;
}

After this change (accounting for this condition the same way the other parts of expand_section() are), the problem with gdb and other ELF utilities saying "file format not recognized" disappeared. Maybe this should help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants