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>
|
||
|---|---|---|
| .builds | ||
| .github | ||
| .woodpecker | ||
| binrz | ||
| dist | ||
| doc | ||
| examples | ||
| librz | ||
| LICENSES | ||
| patches | ||
| subprojects | ||
| sys | ||
| test | ||
| .appveyor.yml | ||
| .clang-format | ||
| .dockerignore | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .prettierignore | ||
| .pylintrc | ||
| .travis.yml | ||
| AGENTS.md | ||
| BUILDING.md | ||
| CODE_OF_CONDUCT.md | ||
| codecov.yml | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| COPYING.LESSER | ||
| DEVELOPERS.md | ||
| Dockerfile | ||
| Doxyfile | ||
| meson.build | ||
| meson_options.txt | ||
| README.md | ||
| REUSE.toml | ||
| SECURITY.md | ||
| snapcraft.yaml | ||
| travis-extract-var.sh | ||
| travis-script | ||
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 formatsrz-ar- list and extract members from static archives (.a and .lib)rz-asm- a command-line assembler and disassemblersrz-diff- a tool to compare two binaries as raw data or analyzed executablesrz-hash- allows to calculate different hashes or even encrypt datarz-gg- a small "eggs" code generator useful for exploitation purposesrz-find- binary analog offindtool, allowing to search patterns and bit masksrz-sign- tool to create, convert and parse FLIRT signaturesrz-ax- a calculator and number format converterrz-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: