LLIL lifted to MLIL strangely for an architecture plugin

[turbocool3r]

I'm writing an architecture plugin and I'm struggling to make BN lift indirect calls from LLIL to MLIL correctly. For calls where the destination is a LLIL_CONST_PTR BN produces correct MLIL_CALL_UNTYPED ops where all MLIL_CALL_PARAM operands have a single operand which is the corresponding call argument, but for cases where a function address is first loaded from constant memory into a register (the call destination is LLIL_REG) BN produces MLIL_CALL_PARAM ops without any operands (op.operands == [[]]) although the call destination is determined correctly. The call destination in the latter case is correctly lifted as MLIL_CONST_PTR. The first operand of MLIL_CALL_UNTYPED (MLIL_CALL_OUTPUT) does not have operands as well for indirect calls.

Here is the function that is the destination of the problematic call:

The call:

How it's lifted:

An example of a direct call and the generated MLIL:

[turbocool3r]

Also seems like BN doesn't create functions at call destinations for such calls. It correctly creates functions for direct calls.

[plafosse]

Could you perhaps share the code you're using to lift these call instructions? Also it would be helpful if we saw how you wrote your GetInstructionInfo function.

[turbocool3r]

Here is the code that lifts these instructions (using Rust bindings):

JumpSubroutine(rn) | JumpSubroutineNoDelay(rn) => {
    il.call(il.reg(4, rn)).append();
}

Here rn is the register of type that implements Into<Register<...>>. GetInstructionInfo ignores these instructions since there is no way to make an indirect call branch there (at least in Rust bindings).

[rssor]

Generally speaking solved-for call destinations would result in functions being created at the destination, barring circumstances like mismatches in section/segment permissions at the destination vs. the call site. For one example, if we had a call from a rx segment in a ReadOnlyCodeSectionSemantics section, a call to a solved for destination in an rwx segment lacking section information would prohibit function creation — this is by no means exhaustive.

Other possible factors could include what the BranchInfo for the call site is, which might result in not taking the desired function call translation path despite seeing constants propagating as expected during MLIL generation.

Seeing MLIL_CALL_UNTYPED on a direct call seems like it might be problematic in its own right. Definitely interested in digging deeper into what you’re seeing here. That’s often seen when we’ve lost track of the stack pointer at a given position in the function, so getting more of them isn’t desired. We generally attempt to use a call with explicit params, even in situations where we have to rely purely on heuristics (e.g. indirect calls with no type info or call type override available are still translated into MLIL_CALL with params).

[turbocool3r]

The target segment of the call is marked as read-only, so this is not the cause (also functions are correctly created for direct calls).

These instructions have no BranchInfo since I ignore them in get_instruction_info as you advised. Since these instructions do not have a destination address available before analysis they do not affect the control-flow analysis.