No description
Find a file
NOT XVilka 1a0c5c655a
librz/type: fix orphan '*' when emitting pf format for typedef'd void*/char* (#6420)
When type_to_format / type_to_format_pair encounter a pointer field whose
pointee is reachable only through a typedef chain that ends at the
atomic 'void' or 'char' (e.g. PVOID -> VOID -> void, LPSTR -> CHAR ->
char, HANDLE -> ... -> void in some platform headers), they emit a bare
'*' and recurse into the pointee.  The recursion produces nothing for
'void' (no format) and emits the legacy 'c' for 'char', so the
generated pf string ends up with either an orphan trailing/internal '*'
or the sequence '*c', which the new pf parser introduced in the
recent rewrite rejects: it requires '*' to be followed by a complete
dereferenceable spec ('z', a sized integer like 'd4'/'x2'/'u8', or
'?').  The result is parser warnings and dropped fields during 'tp':

  rizin -k windows -c 'tp _OBJECT_ATTRIBUTES'
    WARNING: pf: unknown specifier '*' at position 4, skipping
    WARNING: pf: unknown specifier '*' at position 4, skipping
    [only 4 of 6 fields rendered]

  rizin -k windows -c 'tp _SYSTEM_INFO'
    [11 fields collapse to 4]

  rizin -k windows -c 'tp _STARTUPINFOA'
    [three LPSTR fields render as '*c' which the parser cannot
     usefully follow]

The top-level rz_type_as_format() already special-cases 'void *',
'char *', and callable pointers, mapping them to 'p' and 'z'.  But the
inner walkers do not, because rz_type_is_void_ptr / rz_type_is_char_ptr
compare the literal identifier name and so do not see through typedefs
like VOID->void or CHAR->char.

Fix it by adding ptr_pointee_resolves_to(), a small static helper in
format.c that walks the typedb to find the canonical atomic name for
the pointee (bounded depth so a circular typedef cannot send the
resolver into an infinite loop), and using it in both POINTER branches
before the '*'+recurse fallback.  Pointers whose pointee resolves to
'void' (or a void-aliased typedef) now emit 'p'; pointers whose pointee
resolves to 'char' (or a char-aliased typedef) emit 'z'.  Everything
else continues to emit '*<inner>' unchanged, so single-level
LPBYTE -> BYTE -> unsigned char still renders as the perfectly valid
'*x1', and pointer-to-struct '*?' chains are untouched.

After the fix, the same upstream structs produce well-formed pf
strings:

  ts _OBJECT_ATTRIBUTES   -> 'x8p**x1x8pp ...'         (two PVOID -> pp)
  ts _SYSTEM_INFO          -> 'x2x2d4ppx8d4d4d4x2x2 ...' (two LPVOID -> pp)
  ts _STARTUPINFOA         -> 'd4zzzd4...*x1ppp ...'   (three LPSTR -> zzz;
                                                       LPBYTE still '*x1')

Add a regression test in test/db/cmd/cmd_pf that exercises both shapes
via 'ts _SECURITY_ATTRIBUTES' (single LPVOID) and 'ts _STARTUPINFOA'
(three LPSTR + one LPBYTE).  Without this commit the test catches the
bug -- the LPVOID field becomes orphan '*' inside the format and the
LPSTR fields render as '*c'; with the commit both render cleanly as
documented above.

Also update one existing EXPECT in test/db/cmd/types: the 'td with
comments' test had encoded the legacy 'pf "d4[5]*c b foo"' shape for
'char *foo[5]'.  With the fix this becomes 'pf "d4[5]z b foo"', which
is both well-formed under the new DSL and a more accurate description
(an array of zstrings rather than an array of pointers to a single
char).

Co-authored-by: Anton Kochkov <anton.kockov@gmail.com>
2026-05-29 09:06:28 +08:00
.builds NetBSD: Upgrade to Python 3.10 (#5686) 2025-12-27 00:02:58 +08:00
.github Apply patches/fix_zydis_amalgamated_riscv32_build to subproject 2026-05-11 11:54:02 +08:00
.woodpecker Run tests on woodpecker but be verbose. 2024-09-23 14:24:41 +08:00
binrz fix: remove windows debugger compilation warnings (#6140) 2026-04-05 16:27:46 +08:00
dist ci: fix macOS package creation 2026-02-01 20:29:59 +08:00
doc Rewrite the pf parser and rework the grammar (#6410) 2026-05-29 03:58:58 +08:00
examples Rename rz_list_first() / rz_list_last() to rz_list_first_val() / rz_list_last_val() (#5654) 2025-12-20 17:08:59 +08:00
librz librz/type: fix orphan '*' when emitting pf format for typedef'd void*/char* (#6420) 2026-05-29 09:06:28 +08:00
LICENSES
patches Apply patches/fix_zydis_amalgamated_riscv32_build to subproject 2026-05-11 11:54:02 +08:00
subprojects Bump demangler to latest commit + fix useless code (#6381) 2026-05-18 23:20:19 +08:00
sys add RISC-V 32-bit env to CI (#6109) 2026-04-14 15:39:39 +08:00
test librz/type: fix orphan '*' when emitting pf format for typedef'd void*/char* (#6420) 2026-05-29 09:06:28 +08:00
.appveyor.yml log.level help: Don't show 0:DEBUG on Release builds (#6319) 2026-05-07 22:33:46 +08:00
.clang-format Remove Language from .clang-format to reuse config for C & Cpp 2025-11-22 12:33:15 +08:00
.dockerignore Drop libuv dependency 2022-08-06 13:20:52 +02:00
.git-blame-ignore-revs linter: update clang-format entries in .git-blame-ignore-revs (#5453) 2025-10-12 12:07:13 +08:00
.gitattributes
.gitignore hash: add jenkins non-cryptographic hash (#6121) 2026-04-02 01:42:23 +08:00
.lgtm.yml
.prettierignore
.pylintrc Add leak check in CI (#5553) 2025-12-04 11:02:01 +00:00
.travis.yml Fix endianness issues on s390x (#5940) 2026-02-19 23:13:18 +08:00
AGENTS.md Add AGENTS.md with requirement to disclose agent authorship and flag PRs with detected AI usage. (#6025) 2026-03-13 15:00:14 +00:00
BUILDING.md doc: fix various typos and documentation issues (#5771) 2026-01-10 21:33:54 +08:00
CODE_OF_CONDUCT.md
codecov.yml refactor: remove unused mpc subproject (#6091) 2026-03-25 20:30:15 +08:00
CODEOWNERS Simplify CODEOWNERS (#6040) 2026-03-15 15:52:16 +00:00
CONTRIBUTING.md Forbid usage of AI tools for good-first-issues. (#5829) 2026-01-23 13:06:24 +08:00
COPYING
COPYING.LESSER
DEVELOPERS.md Document allowed macro usage. (#6060) 2026-03-22 11:46:14 +00:00
Dockerfile docker: update to Debian 11 (Bullseye) (#5277) 2025-07-18 12:27:28 +08:00
Doxyfile
meson.build librz/arch: check if M680X HSC12X/RS08 is present in Capstone (#6318) 2026-05-06 11:53:40 +08:00
meson_options.txt blake2 hash support (#5995) 2026-03-06 22:17:59 +08:00
README.md rz-ar: add archive extraction utility (#6036) 2026-03-18 03:51:18 +08:00
REUSE.toml refactor: remove unused mpc subproject (#6091) 2026-03-25 20:30:15 +08:00
SECURITY.md Add AI tool guidelines (#5474) 2025-10-21 20:53:17 +08:00
snapcraft.yaml Bump version to v0.9.0 2025-04-23 16:49:14 +08:00
travis-extract-var.sh
travis-script Use meson setup <dir> instead of meson <dir> 2023-04-26 20:01:47 +08:00

Rizin logo

Rizin

Rizin is a reverse engineering framework, born as a fork of the radare2, with a focus on usability, features and cleanliness.

Rizin is portable and it can be used to analyze binaries, disassemble code, debug programs, as a forensic tool, as a scriptable command-line hexadecimal editor able to open disk files, and much more!

To learn more on Rizin you may want to read the official Rizin book.

How to install

Look at install instructions on our web page.

How to build

Use meson to compile and install Rizin. Please make sure to get an updated meson (e.g. get it with pip install meson if your system does not provide one that is at least version 0.55.0).

Clone this repository:

$ git clone https://github.com/rizinorg/rizin

Then compile and install with:

$ meson setup build
$ meson compile -C build
$ sudo meson install -C build

Now you can use rizin:

$ rizin
 -- Thank you for using rizin. Have a nice night!
[0x00000000]>

To uninstall rizin, execute sudo ninja -C build uninstall.

Please have a look at BUILDING.md for more information about building Rizin.

Contributing

We very much welcome any kind of contributions, from typos, to documentation, to refactoring, up to completely new features you may think of. Before contributing, we would like you to read the file CONTRIBUTING.md, so that we can all be on the same page.

Tests

Look at test/README.md.

Supported features

Supported Operating Systems

Windows 7 and higher, Apple macOS/iOS/iPadOS, GNU/Linux, [Dragonfly|Net|Free|Open]BSD, Android, QNX, Solaris/Illumos, Haiku, GNU/Darwin, GNU/Hurd.

Supported Architectures

i386, x86-64, ARM/ARM64, RISC-V, PowerPC, MIPS, AVR, SPARC, System Z (S390), SuperH, m68k, m680x, XAP, XCore, CR16, HPPA, ARC, Blackfin, Z80, H8/300, Renesas (V810, V850, RL78), CRIS, XAP, PIC, LM32, 8051, 6502, i4004, i8080, Propeller, Tricore, CHIP-8, LH5801, T8200, GameBoy, SNES, SPC700, MSP430, Xtensa, NIOS II, TMS320 (c54x, c55x, c55+, c64x), Hexagon, DCPU16, LANAI, MCORE, mcs96, RSP, C-SKY(MCore), VAX, AMD Am29000.

There is also support for the following bytecode formats:

Dalvik, EBC, Java, Lua, Python, WebAssembly, Brainfuck, Malbolge

Supported File Formats

ELF, Mach-O, Fatmach-O, PE, PE+, MZ, COFF, OMF, NE, LE, LX, TE, XBE, BIOS/UEFI, Dyldcache, DEX, ART, CGC, ELF, Java class, Android boot image, Plan9 executable, ZIMG, MBN/SBL bootloader, ELF coredump, MDMP (Windows minidump), DMP (Windows pagedump), WASM (WebAssembly binary), Commodore VICE emulator, QNX, Game Boy (Advance), Nintendo DS ROMs and Nintendo 3DS FIRMs.

Tools

Apart from the main tool rizin, there are also other tools tailored for specific purposes and useful for shell scripting or as separate standalone tools:

  • rz-bin - provides all kind of information about binary formats
  • rz-ar - list and extract members from static archives (.a and .lib)
  • rz-asm - a command-line assembler and disassemblers
  • rz-diff - a tool to compare two binaries as raw data or analyzed executables
  • rz-hash - allows to calculate different hashes or even encrypt data
  • rz-gg - a small "eggs" code generator useful for exploitation purposes
  • rz-find - binary analog of find tool, allowing to search patterns and bit masks
  • rz-sign - tool to create, convert and parse FLIRT signatures
  • rz-ax - a calculator and number format converter
  • rz-run - a tool that allows to specify running environment and arguments for debugged file

Scripting

We provide a way to interact with Rizin from Python, Haskell, OCaml, Ruby, Rust, and Go languages through rzpipe. Other languages although not currently supported could be easily added.

Community

Our website and blog: https://www.rizin.re/

Join our Mattermost community to discuss Rizin, its development, and general topics related to the project.

We also provide the following partial bridges to other messaging platforms: