[BUG]The offset of the RUST STRINGS is misaligned.
pinksawtooth opened this issue · 7 comments
Description
The offset of the "FLOSS RUST STRINGS" item in "FLOSS" is different from the actual value.
The following is an excerpt of the results of running floss on a Rust program I created.
──────────────────────────
FLOSS RUST STRINGS (529)
──────────────────────────
0x01d590 invalid args
0x01d5b0 /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1\library\core\src\fmt\mod.rs
0x01d618 /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1\library\core\src\alloc\layout.rs
0x01d680 attempt to divide by zero
0x01d699 February
0x01d6a1 March
0x01d6a6 April
0x01d6ae June
0x01d6b2 July
0x01d6b6 August
0x01d6bc September
0x01d6c5 October
0x01d6cc November
0x01d6d4 December
0x01d6dc January
0x01d6e3 initial contents
0x01d6f3 to string:
0x01d720 Hello,
0x01d727 world!
0x01d72d add string:
0x01d760 global static:
0x01d790 global const:
0x01d7c0 This is const variableA
0x01d7e8 This is const variableB
0x01d810 This is const variableC
0x01d838 month:
0x01d860 This is static variableA
0x01d888 This is static variableB
0x01d8b0 This is static variableC
(snip)
This time I will focus on this string. (The problem is the same for all strings.)
0x01d720 Hello,
But the actual offset is 0x1e520
as shown in the image below.
>>> hex(0x1e520-0x01d720)
'0xe00'
The other strings are offset by the same amount. Verify with the following string
0x01d760 global static:`
Add 0xe00 to this offset.
>>> hex(0x1d760+0xe00)
'0x1e560'
Then the actual offset value will be displayed as follows.
14001e560
I believe it is a bug in Rust Strings because the offset in static strings is normal.
+------------------------------------+
| FLOSS STATIC STRINGS: ASCII (2336) |
+------------------------------------+
0x00004d !This program cannot be run in DOS mode.
To Reproduce
Run floss with the -v option for the Rust program.
Environment
floss version
.\floss.exe --version
floss.exe v3.0.1-0-g3782dc9
Rust version
rustc --version
rustc 1.74.1 (a28077b28 2023-12-04)
Hi @pinksawtooth, thanks for reporting this. I've checked the code on my system, and it seems to be working fine without any offset issues. Additionally, it passes CI tests successfully. Could you please provide the executable you are working with so I can investigate further? Thanks!
OK
strings.zip
But the actual offset is
0x1e520
as shown in the image below.
Ah, I understand now. The reported offset might not be 0x1e520. Please verify the 'Current offset in the input file' as follows:
Current offset in the input file (from floss) = Offset (as observed) - Section_RawOffset + Section_VirtualAddress + ImageBase
I hope this clarification helps.
Hey @Arker123
OP provided a lot of detailed information in order for us to reproduce the issue. If there's the possibility that we're reporting some data incorrectly, let's go out of our way reproduce and understand the issue. (OP may not have much extra time so we should minimize the burden on them.)
If we can reproduce, please acknowledge here and suggest a fix and/or PR. Otherwise, please explain why the behavior is correct and/or figure out how the output is unintuitive to our users. Sometimes we get so caught up in the implementation that an "outsider" doesn't follow our train of thought.
Of course, if you don't have time right now, go ahead and unassigned this issue and I'll grab it after New Years!
Hey @williballenthin ,
I appreciate your thorough consideration. I want to clarify that the reported behavior is not a bug; we intentionally designed it to provide the current offset in the input file as output from the beginning. I acknowledge that this may be non-intuitive to users.
Considering user expectations, my suggestion is to enhance the output for better user understanding. One approach could be to include this offset in the output. What are your thoughts on this? Open to suggestions.
Thanks!
Hey, thanks for the report and sample!
I get the following output on the sample you've provided.
...
──────────────────────────
FLOSS RUST STRINGS (530)
──────────────────────────
0x01d190 invalid args
0x01d1b0 /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1\library\core\src\fmt\mod.rs
0x01d218 /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1\library\core\src\alloc\layout.rs
0x01d280 attempt to divide by zero
0x01d299 immutable data
0x01d2a7 immutable!:
0x01d2d8 mutable data
0x01d2e4 mutable!:
0x01d310 update data
0x01d31b Hello,
...
Browsing to that address in a hex editor shows the string.
Can you double-check your output, please? I realize there may be confusion around virtual address vs. file offset. We opted for the latter since that is how most strings tools work by default.
Please reopen if this is still an issue.