rizinorg/rizin

Is your feature request related to a problem? Please describe. In the default assembly browsing view (Vp) it is very easy to get lost about where in the binary you are currently. In Cutter and all the other GUI frameworks we have this bar at the top, which has a cursor to show you were you are in the binary (the absolute location). But I think this is not the optional solution. Because I think it could be more helpful to know, where you are in respect to a certain fix point. For example: You know where main() is. While browsing you want to keep an eye on how "deep" you are into the programs CFG. Or "how many jumps/calls you are away from main". This is especially useful for firmware boot code (few indirect jumps). To track how deep you are currently in the boot procedure. Describe the solution you'd like Adding some indicator of how many jumps/calls the user is away from a predefined fixed location (like an firmware entry point). Here a mockup: ┌────────────

Work environment Questions Answers OS/arch/bits (mandatory) Debian arm 64, Ubuntu x86 32 File format of the file you reverse (mandatory) PE, ELF etc. Architecture/bits of the file (mandatory) PPC, x86/32, x86/64 etc. rizin -v full output, not truncated (mandatory) Current dev (e008136) Expected behavior If two new maps are created with om, the writes with wx should not write to the same buffer. Actual behavior wx writes to the same one. Steps to reproduce the behavior Here the example to reproduce > rizin = -- Use `rizin -B 0x123456 /bin/ls` option to set the base address of a PIE file. [0x00000000]> oml 1 fd: 3 +0x00000000 0x00000000 * 0x000001ff rwx [0x00000000]> px 0x30 - offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x00000000 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00000010 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00000020 0000 0000 0000 0000 0000 0000 0000 0000 ................ [0x00000000]> om- 1

Currently the debugger works fine when only read or write permissions are passed dbw r, dbw w work correctly. But dbw rw does not hit the watchpoint. Can be tested with a simple counter incrementing program. Add the watchpoint for the counter. Tested it on Debian-x86_64 machine. Check this suggested fix (VERIFY FIRST): librz/debug/p/native/drx.c, drx_set(): add case 6: rwx = 3; break; (RZ_PERM_RW → DR_RW_READ); also handle perms 3 and 7 explicitly. librz/debug/p/native/linux_x86_64.c rz_debug_native_reg_write (RZ_REG_TYPE_DRX): propagate PTRACE_POKEUSER failures so a failed debug-register program surfaces as an error instead of a phantom "enabled valid" watchpoint.

The assembly search is not really in a good shape currently. But it is blocked on the RzArch refactor (see #5352). Nonetheless, it would be nice to have a very simple "disassemble all instructions and match them against this regex". There is /ao already and it should be refactored. In its current state it is not useful anymore. That would be helpful and super straight forward to implement. It can copy one of the modern searches like the string search and do it. The command should be of the form /ao <extended-regex> It should definitely make use of the multi threading. And it should abortable. I marked this as "good-first-issue" but it is only one for people who are familiar with C. It is too hard for programming beginners.

In eval_pure for RZ_IL_OP_ITE, if the condition does not evaluate to a constant, it evaluates the entire result to top. But it could easily be more precise by evaluating both branches and joining the results instead. rizin/librz/inquiry/absint/interpreter.c Lines 828 to 847 in 8a7dd55 case RZ_IL_OP_ITE: { EVAL_SUB_OR_RETURN(pure->op.ite.condition, out); RzBitVector cond_bv; rz_bv_init(&cond_bv, 64); if (!val_domain(ctx->inst)->to_concrete_const(out, &cond_bv)) { // Can't decide which pure to evaluate. // TODO: must eval both and join instead! rz_bv_fini(&cond_bv);