More i386 xrefs #899
More i386 xrefs #899
Conversation
floss/language/utils.py
Outdated
| @@ -465,6 +465,34 @@ def get_struct_string_candidates(pe: pefile.PE) -> Iterable[StructString]: | |||
| # dozens of seconds or more (suspect many minutes). | |||
|
|
|||
|
|
|||
| def get_raw_xrefs_rdata_i386(pe: pefile.PE, buf: bytes) -> Iterable[VA]: | |||
| """ | |||
| scan for raw xrefs in .rdata section | |||
There was a problem hiding this comment.
what are raw xrefs? can you add an example disassembly listing and add some comments, please?
There was a problem hiding this comment.
from the screenshots in #885 (comment) I don't see if these are strings and it would help to have some comments explaining what the algorithm looks for
There was a problem hiding this comment.
Raw xrefs refer to unprocessed xrefs in the binary file, indicating points where strings can be divided. I'll add an example with comments.
There was a problem hiding this comment.
Thanks, can you share a few example binary hashes?
There was a problem hiding this comment.
| @@ -465,6 +465,48 @@ def get_struct_string_candidates(pe: pefile.PE) -> Iterable[StructString]: | |||
| # dozens of seconds or more (suspect many minutes). | |||
|
|
|||
|
|
|||
| def get_raw_xrefs_rdata_i386(pe: pefile.PE, buf: bytes) -> Iterable[VA]: | |||
There was a problem hiding this comment.
please add a few tests for these strings
| .rdata:004D6240 dd offset unk_4C85B3 | ||
|
|
||
| From the disassembly, they are called as follows: | ||
| .text:00498E56 push ds:off_4D61E0[ecx*4] |
There was a problem hiding this comment.
where does the length get stored?
There was a problem hiding this comment.
It's not; the raw xrefs are stored without explicit length information. Lengths are not included in this context. Do we need them, or is there a specific reason for considering length storage?
There was a problem hiding this comment.
no, I don't think we need them. but I wondered how Go is able to use the string data without an associated length.
There was a problem hiding this comment.
Currently, I couldn't find any specific information for Go, but I did come across a similar approach in Rust. I've kept it in the utils.py file, considering the possibility that we might encounter a similar scenario in the future when exploring other languages.
Referring to #885 (comment), this PR supplements additional xrefs discovered separately. For #885, the focus is solely on the UTF-decoder segment. 馃槃