Is Ghidra misinterpreting a function call?

user_12173257 0
Viewed 701

When analyzing the assembly listing in Ghidra, I stumbled upon this instruction:

CALL dword ptr [EBX*0x4 + 0x402ac0]=>DAT_00402abc

I assumed that the program was calling a function whose address was inside DAT_00402abc, which I initially thought it was a dword variable. Indeed, when trying to create a function in the location where DAT_00402abc is in, Ghidra wouldn't let me do it.

The decompiler shows to me this line of code to translate that instruction:

(*(code *)(&int2)[iVar2])();

So I was wondering, what does it mean and what's the program supposed to do with this call? Is there a possibility that Ghidra totally messed up? And if so, how should I interpret that instruction?

ghidra decompiling x86 reverse-engineering c
1 Answers

I'm not at all familiar with Ghidra, but I can tell you how to interpret the machine instruction...

CALL dword ptr [EBX*0x4 + 0x402ac0]

There is a table of function addresses at 0x402ac0; the EBX'th entry in that table is being called. I have no idea what DAT_00402abc means, but if you inspect memory in dword-sized chunks at address 0x0402ac0 you should find plausible function addresses. [EDIT: 0x0040_2abc = 0x0040_2ac0 - 4. I suspect this means Ghidra thinks EBX has value -1 when control reaches this point. It may be wrong, or maybe the program has a bug. One would expect EBX to have a nonnegative value when control reaches this point.]

The natural C source code corresponding to this instruction would be something like

extern void do_thing_zero(void);
extern void do_thing_one(void);
extern void do_thing_two(void);
extern void do_thing_three(void);

typedef void (*do_thing_ptr)(void);
const do_thing_ptr do_thing_table[4] = {
  do_thing_zero, do_thing_one, do_thing_two, do_thing_three
};

// ...

void do_thing_n(unsigned int n)
{
   if (n >= 4) abort();
   do_thing_table[n]();
}

If the functions in the table take arguments or return values, you'll see argument-handing code before and after the CALL instruction you quoted, but the CALL instruction itself will not change.

You would be seeing something different and much more complicated if the functions didn't all take the same set of arguments.

user_3885200
Related