rizinorg
`ps` doesn't print long strings by default, because it depends on `core->block`.
Work environment
| Questions | Answers |
|---|---|
| OS/arch/bits (mandatory) | All |
| File format of the file you reverse (mandatory) | All |
| Architecture/bits of the file (mandatory) | NA |
rizin -v full output, not truncated (mandatory) |
rizin 0.8.0-git @ linux-x86-64, ee74d37 |
Expected behavior
ps (and psW, psM etc.) print a full string in a file by default.
Actual behavior
It prints only a string of sizeof(core->block) by default. Which is apparently by default 256 bytes.
Steps to reproduce the behavior
rizin -qc "psW" test/bins/cmd/search/string_encodings/Georgian-Lipsum.utf32le
ლორემ იფსუმ დოლორ სით ამეთ, ილლუმ ელაბორარეთ ად ჰას, ილლუმ იისყუ
But should be way longer.
(Binary from PR: https://github.com/rizinorg/rizin-testbins/pull/167)
Additional Logs, screenshots, source code, configuration dump, ...
The implementation of rz_str_stringify_raw_buffer() to detect the strings, should use RzBuffer. Not a raw char * buffer. This way it can get the RzBuffer of the current RzIO.
Shouldn't be too complicated to refactor. At least not for the commands.
Related: https://github.com/rizinorg/rizin/issues/2695
I am creating a RzBuffer of RzIO length in rz_str_stringify_raw_buffer()
but then i would also need to refactor the different functions used to get the rsize correct?
@well-mannered-goat Please wait with addressing this issue until https://github.com/rizinorg/rizin/pull/4762 is merged. I made some changes there.
Generally though we should refactor RzStrStringifyOpt, core_print_string_in_block() and core_print_raw_buffer() to work on the RzBuffer. Then Probably by using rz_buf_get_whole_hot_paths() on the buffer of RzIO.
Ok sure
Yea I thought refactoring RzStrStringifyOpt would be a better option. Would look into it.
Ok sure
Yea I thought refactoring
RzStrStringifyOptwould be a better option. Would look into it.
Just for the record, all necessary changes were merged.
Just for the record, all necessary changes were merged.
Unfortunately not yet. I think I reverted the changes, because they were part of the new "guess string encoding" logic.
The ps command still uses ut8 * everywhere and uses none of the new search code.
@notxvilka This is technically not a problem, because the command now has the option to print a string until a certain terminating character (NUL or invalid char).
But the refactoring can still be done.