gravelbones / ghidradostoolbox Goto Github PK

Hi! This is a really awesome and very helpful toolbox, and has made my janky python script to insert 0x21 handlers totally unnecessary!

I was wondering if there was a way to automatically handle stack pointers to syscalls. It's entirely possible I'm doing something incorrect, but when looking at a syscall-wrapping function (which I assume comes from a stdlib of sorts for my executable) I am getting Ghidra disassembly that looks like:

/* WARNING: Unable to track spacebase fully for stack */

word __stdcall FUN_1c6f_3e99(void)

{
  word wVar1;
  byte in_CL;
  undefined2 unaff_BP;
  undefined2 in_SS;
  undefined2 in_DS;
  undefined in_CF;
  
  *(undefined2 *)((short)&stack0x00000000 + -2) = unaff_BP;
  swi(0x21);
  wVar1 = DosOpenFile((char *)CONCAT22(in_DS,*(undefined2 *)((short)&stack0x00000000 + 4)),0,in_CL);
  if ((bool)in_CF) {
    wVar1 = 0xffff;
  }
  return wVar1;
}

It's correctly getting the DosOpenFile reference, but it's unable to see that the second half of the pointer ((short)&stack0x00000000 + 4) is part of the function call. All of the storage for DosOpenFile seems correct, and it's definitely working with that, but somehow the function call isn't matching up and it's trying to turn it into a full char* rather than the custom storage one. (I think?)

I recognize it might be out of the purview of GhidraDosToolbox to address this, but is this an issue you've encountered before and might have an idea of how to solve? Thanks again for your hard work on this, and any tips you might have.

The current ghidra_10.0.4_PUBLIC_20211229_GhidraDosToolbox.zip is not compatible with the current Ghidra version 10.2.2.

What would be needed to create a new compatible version?