Breakpoint on api call

[orenbenya1]

is there an option to do BPX at edb? For example using BPX malloc to breakpoint on every call to malloc func

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[eteran]

Not explicitly. However, if the binary isn't stripped and has symbols for malloc, you can find the malloc function and place a breakpoint on it using the symbol viewer.

Having a more streamlined interface to do this kind of thing would be a good idea though.

[10110111]

If the binary uses malloc from libc, then it doesn't even need symbols. The function can be found using the Symbols dialog. On my system it's called libc-2.27.so!malloc.

[orenbenya1]

If the binary uses malloc from libc, then it doesn't even need symbols. The function can be found using the Symbols dialog. On my system it's called libc-2.27.so!malloc.

I understand, but what if a program is using some kind of a packer (UPX for example)? anyway, I reverse a lot with X64dbg and the option to just run a simple command like "bpx virtualalloc" is really nice and good to have.

[10110111]

How is being packed related to setting a breakpoint? Do you mean dynamically set breakpoint on a symbol when a shared library is loaded (like GDB's break command can)?

[orenbenya1]

For example, if you use the flag challenge from pwnable.kr (http://pwnable.kr/bin/flag) then you get a packed ELF file with UPX, it is calling after it's unpacked to malloc and strcpy functions. you won't see them at symbol viewer so it will be nice if you had option to create a breakpoint on those functions once they are loaded using bpx malloc/strcpy.

[10110111]

Well, it won't help you with this flag. This binary doesn't load any libraries, so what you really need is to catch system calls.
I don't remember whether EDB can do this though. GDB definitely can (see help catch syscall in GDB command line). So can strace (well, it's its main objective :) ).
If EDB can't yet (@eteran, can it?) it's worth implementing. ptrace has special continuation mode PTRACE_SYSCALL.

[eteran]

We've discussed adding a "step until the next system call" function to edb a while ago, and I like the idea. We could even make it only trap on specific system calls.

Unfortunately, that won't help too much for things like malloc as they call brk to acquire large chunks of system memory on an as-needed basis and don't need to do this on most calls.