Help disassembling a simple 16-bit NE function

Question

I am currently attempting to reverse engineer a simple function from within a 16-Bit Windows 3.1 (NE) DLL, which from what I can tell is used to display a message box when required.

I would assume that the two arguments of the ShowMessageBox function are used to set the Title and Message (this is a DLL so I assume it doesn't bother with a HWND?). I can see that those two parameters get passed in and are pushed to the stack, but can't quite work out how they are passed into the system call.

Ghidra seems a little confused as the C source ignores the two parameters and passes in the two other values that are added into the stack (0x41 and 0x41b).

I have added the following function signature into the MessageBox system call:

int MessageBox (HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, uint uType)

An example of the message box produced by this function is:

Any suggestions would be greatly appreciated.

The assembly and Ghidra generated C source are included below.

**************************************************************
*                          FUNCTION                          *
**************************************************************
void __cdecl16far ShowMessageBox(undefined param_1,undefined param_2)
                       assume DS = 0x1008
             void              <VOID>         <RETURN>
             undefined         Stack[0x4]:1   param_1
             undefined         Stack[0x6]:1   param_2                                  
       1000:001c c8 00 00 00     ENTER      0x0,0x0
       1000:0020 57              PUSH       DI
       1000:0021 56              PUSH       SI
       1000:0022 6a 00           PUSH       0x0
       1000:0024 ff 76 08        PUSH       word ptr [BP + param_2]
       1000:0027 ff 76 06        PUSH       word ptr [BP + param_1]
       1000:002a 1e              PUSH       DS
       1000:002b 68 1b 04        PUSH       0x41b
       1000:002e 6a 41           PUSH       0x41
       1000:0030 9a 5c 00        CALLF      USER::MessageBox
                 18 10
       1000:0035 e9 00 00        JMP        LAB_1000_0038

void __cdecl16far ShowMessageBox(undefined param_1,undefined param_2)
{
  HWND unaff_CS;
  
  MessageBox(unaff_CS,(LPCTSTR)0x41,(LPCTSTR)0x41b,0x1008);
  return;
}

Thanks, James.

Answer 1

I've not looked at 16-bit windows in a while but I'd interpret the assembly as follows -

void ShowMessageBox( LPCSTR text )
{
    MessageBox( NULL,     // no owner window
                text,     // text to display in box
                DS:041B,  // caption
                MB_ICONINFORMATION | MB_OKCANCEL /* 0x41 */ );
    ...
}

Answer 2

A Typical listing in ghidra of USER!MESSAGEBOX in a 16 Bit NE Exe post analysis

   LAB_1000_07f0                        XREF[2]:     1000:0770(j), 1000:0775(j)  
   1000:07f0 ff 76 0e               PUSH       word ptr [BP + param_3]
   1000:07f3 1e                     PUSH       DS
   1000:07f4 68 c4 01               PUSH       0x1c4
   1000:07f7 1e                     PUSH       DS
   1000:07f8 68 c0 01               PUSH       0x1c0
   1000:07fb 6a 00                  PUSH       0x0
   1000:07fd 9a 9c 00 50 10         CALLF      USER::MESSAGEBOX     undefined MESSAGEBOX()

and its decompilation

uVar7 = param_3;
MESSAGEBOX((int)&DAT_1008_1050,0,0x1c0,(int)s_run-time_error_1008_1001 + 7,0x1c4,
           (int)s_run-time_error_1008_1001 + 7);

as you can see the MESSAGEBOX is undefined()

Right click on the MESSAGEBOX (in decompiled window or in listing) and edit the function signature as shown in screen shot and see the Decompiled output

that is far better but it still misses the Caption String
double click the 32bit addres 100801c0

you will see this an undefined ascii string (probably coz ghidra default str length is > 3)

   1008:01c0 53                     ??         53h    S
   1008:01c1 50                     ??         50h    P
   1008:01c2 59                     ??         59h    Y
   1008:01c3 00                     ??         00h

define it as a string using right click -> Data ->Terminatedcstring

to make the listing

   1008:01c0 53 50 59 00            ds         "SPY"

and the decompilation will be

  if ((local_8[0] < 1) || (0xfa < local_8[0])) {
    MESSAGEBOX(0,s_SPY_1008_01c0,s_Window_lines_should_be_between_1_1008_01c4,param_3);

ANOTHER EXAMPLE WHERE THE STRING IS DYNAMIC and cant be found statically MESSAGEBOX that shows the concat of seg:offset

listing and decompilation

   LAB_1020_2b78                   XREF[1]:     1020:2b6f(j)  
   1020:2b78 57                     PUSH       DI
   1020:2b79 ff 76 12               PUSH       word ptr [BP + param_7]
   1020:2b7c ff 76 10               PUSH       word ptr [BP + param_6]
   1020:2b7f ff 76 0e               PUSH       word ptr [BP + param_5]
   1020:2b82 ff 76 0c               PUSH       word ptr [BP + param_4]
   1020:2b85 ff 76 0a               PUSH       word ptr [BP + param_3]
   1020:2b88 9a 54 02 c0 1b         CALLF      USER::MESSAGEBOX  

   MESSAGEBOX(param_3,CONCAT22(param_5,param_4),CONCAT22(param_7,param_6),wVar1);

Answer 3

As per the comment made by @blabb on his answer, I looked at the Win16 WINDOWS.H header file (from the Windows 3.1 Driver Development Kit (DDK)) to see which calling conventions were used for the Win16 API functions at the time.

At the beginning of the file, the following macro is defined:

#define WINAPI _far _pascal

This macro is then appended to the beginning of most of the functions in the file, for example:

int WINAPI MessageBox(HWND, LPCSTR, LPCSTR, UINT);

UINT WINAPI GetPrivateProfileInt(LPCSTR, LPCSTR, int, LPCSTR);

LPSTR WINAPI lstrcpy(LPSTR, LPCSTR);

So it seems as though most of the Win16 API functions were defined with the Pascal calling convention, which explains why I can see the parameters being PUSHed backwards onto the stack before the CALL instruction is utilised.

So by implementing the function this way:

The parameters are pulled in correctly and the decompilation is accurate.

Currently, I'm having to setup the parameter storage manually as Ghidra does not support the Pascal calling convention, an issue on GitHub has been opened here: https://github.com/NationalSecurityAgency/ghidra/issues/496