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.