.fidb File Support

[JCWasmx86]

Description

At the moment, the output of decompiling has the types "wrong". (E.g. uint64_t instead of FILETIME).
Ghidra has support for .fidb files with more information. Could this be integrated into r2ghidra?

Here a side-to-side comparison:

r2ghidra:

void fcn.140006654(void)

{
    uint32_t uVar1;
    uint64_t var_10h;
    uint64_t lpSystemTimeAsFileTime;
    uint64_t lpPerformanceCount;
    
    lpSystemTimeAsFileTime = 0;
    if (*(uint64_t *)0x14001b000 == 0x2b992ddfa232) {
        (*_sym.imp.KERNEL32.dll_GetSystemTimeAsFileTime)(&lpSystemTimeAsFileTime);
        var_10h = lpSystemTimeAsFileTime;
        uVar1 = (*_sym.imp.KERNEL32.dll_GetCurrentThreadId)();
        var_10h = var_10h ^ uVar1;
        uVar1 = (*_sym.imp.KERNEL32.dll_GetCurrentProcessId)();
        var_10h = var_10h ^ uVar1;
        (*_sym.imp.KERNEL32.dll_QueryPerformanceCounter)(&lpPerformanceCount);
        *(uint64_t *)0x14001b000 =
             (lpPerformanceCount << 0x20 ^ lpPerformanceCount ^ var_10h ^ (uint64_t)&var_10h) & 0xffffffffffff;
        if (*(uint64_t *)0x14001b000 == 0x2b992ddfa232) {
            *(uint64_t *)0x14001b000 = 0x2b992ddfa233;
        }
    }
    *(uint64_t *)0x14001b008 = ~*(uint64_t *)0x14001b000;
    return;
}

ghidra:

void FUN_140006654(void)

{
  DWORD DVar1;
  _FILETIME local_res8;
  _FILETIME local_res10;
  uint local_res18;
  undefined4 uStackX28;
  
  local_res10 = (_FILETIME)0x0;
  if (DAT_14001b000 == 0x2b992ddfa232) {
    GetSystemTimeAsFileTime((LPFILETIME)&local_res10);
    local_res8 = local_res10;
    DVar1 = GetCurrentThreadId();
    local_res8 = (_FILETIME)((ulonglong)local_res8 ^ (ulonglong)DVar1);
    DVar1 = GetCurrentProcessId();
    local_res8 = (_FILETIME)((ulonglong)local_res8 ^ (ulonglong)DVar1);
    QueryPerformanceCounter((LARGE_INTEGER *)&local_res18);
    DAT_14001b000 =
         ((ulonglong)local_res18 << 0x20 ^ CONCAT44(uStackX28,local_res18) ^ (ulonglong)local_res8 ^
         (ulonglong)&local_res8) & 0xffffffffffff;
    if (DAT_14001b000 == 0x2b992ddfa232) {
      DAT_14001b000 = 0x2b992ddfa233;
    }
  }
  DAT_14001b008 = ~DAT_14001b000;
  return;
}

As you can see, the output of ghidra has more information.

For more information/fidb files see here:
https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/FunctionID/data and https://github.com/NationalSecurityAgency/ghidra-data/tree/master/FunctionID

[trufae]

I assume this fidb thing is just a list of symbols that you need to generate signatures for and then apply the signatures in the target binary to get those symbols to work. Because those files contain no metrics to detect the symbols. So i think in that case whatever fidb support needs to be done should be implemented in r2 instead of r2ghidra, because that's not part of the decompiler logic.