Non-sensical operand primary reference in Listing

[ubitux]

Describe the bug Sometimes the operand primary reference makes no sense in the Listing view.

To Reproduce Steps to reproduce the behavior:

1. gunzip cm001.gz and load+analyze cm001 into Ghidra
2. Jump to 0x401703
3. Observe RSI referring to some random string

This function is the init function of the glibc (__libc_csu_init) and has nothing to do with the password string displayed here. In doubt, this can be verified with the source code of the crackme available at https://github.com/JCWasmx86/Crackme/tree/main/001 (it's simply using a constructor attribute, causing the creation of a 2nd init function).

Workaround: go to options, Listing Fields → Operands Fields, uncheck "Always Show Primary Reference"

Expected behavior The operand primary reference should not be inferred here.

Screenshots

Attachments cm001.gz

Environment (please complete the following information):

• OS: Archlinux
• Java Version: 11.0.16.1
• Ghidra Version: 10.1.5
• Ghidra Origin: Archlinux official packages

[emteere]

The reference most likely came from a flow into this function from the validate.s routine which loads RSI with the string reference.

Does the last syscall of the validate routine immediately precede this function, such that it would flow into this function? The syscall is currently implemented to not to fall through to the next instruction.

If this is the case you can modify the flow of the syscall to be non-flowing into this function, and re-run analysis. With the flow removed, the reference should not be created. There is some current work on syscalls, however I'm not sure they would take care of this issue.

The references are not normally random, and can come from flow that either exists or existed earlier when the particular section of code was analyzed. It does occasionally make mistakes from overzealous propagation of constants, or incorrect internal flow assumptions.

[ubitux]

You are correct, the previous function flows into that one because of the syscalls (last one being an exit). I used the recommended x86 syscalls script, which seems to adjust the flow overrides:

-- CALLOTHER(syscall) Call Override: exit (syscall::0000003c)
-- Flow Override: CALL_RETURN (FALL_THROUGH)

Unfortunately, re-running the analysis (a) didn't update the operand reference. If I clear the instruction (c) then decompile it again (d) the reference goes away, but that works without the flow override as well, and re-running the analysis restores the wrong reference.

I tried to override the flow manually but the interface was kind of confusing to me, I wasn't exactly sure how to proceed.

[emteere]

Overriding psuedo-ops is not easy. It is mainly useful on instructions that already have some sort of flow.

If you clear it, the instruction is analyzed in the function it currently resides. It might actually come back if you clear an instruction in the validate() function above init, or if you reanalyze the whole program without changing the flow of the instruction.

You can override the FallThru on the syscall as well.

[ubitux]

You can override the FallThru on the syscall as well.

Yeah (and I believe that's what the x86 syscall script does), but unless I misunderstood something that's not enough to prevent flow fall-through into the next function.

[emteere]

I don't think the X86 syscall overrides the fallthru, as a syscall can return after the syscall.

If you simply clear the instruction at the with the bad reference, it shouldn't come back. We don't always clear analysis references, although we will be clearing some with re-analysis in the near future.

Hope this clears up the issue for you. Not ideal, but not an unexpected type of issue to occur in SRE.

[ubitux]

Ah, clearing the padding instructions following the syscall does prevent the fallthrough, and the reference doesn't come back. But I guess I'm lucky there is padding in the first place.

I still don't get why the "Flow Override: CALL_RETURN (FALL_THROUGH)" generated by the script doesn't seem to be enough. Am I misunderstanding its meaning?

https://user-images.githubusercontent.com/34467/198743797-8d257d88-3f06-4965-9297-374758d09e22.mp4

[emteere]

The script should be enough, but you would still need to clear the bad reference. When constant analysis happens again on the function the reference shouldn't come back, if I'm understanding correctly.

[ubitux]

The script should be enough, but you would still need to clear the bad reference. When constant analysis happens again on the function the reference shouldn't come back, if I'm understanding correctly.

It does come back if the padding instructions between the 2 functions is decompiled (the NOP after the syscall, at 004016b8 which you can see at t=12s in the video)

[ubitux]

Here is a demo with + without the padding to show that it impacts analysis even though the script has adjusted the fallthrough:

https://user-images.githubusercontent.com/34467/201049848-5890fca5-f87c-4903-baa1-5a4426a6e63d.mp4

[emteere]

OK, I finally see the issue you are bringing up.

Modifying the flow of an instruction can technically only occur if the instruction actually has flow. A call to a pseudo-op like syscall() doesn't count. Only a GOTO or CALL pcode op would count as flow.

I'll have to think about that. I think the way it is done now the SYSCALL is assumed to return, even with the script to calculate the call system function.

[emteere]

You can set the Fallthrough to NULL using Fallthru->Set... in the popup menu on the instruction. You can do this after running the syscall resolving script.

The decompiler doesn't consider the fall-thru overrides, however normal flow analysis does.