More delinking fun
(…continued from Part 1)
If there’s anything life has taught me, it’s got to be that submitting a question publically is a surefire way of figuring out the answer myself within an hour or so… unless it actually takes a couple months.
For context, I am trying to find parts of the game’s data segment which can be attributed to linking in the Microsoft C library. In the first part, I figured out initialized data as the easier task, but was left stumped with the layout of the uninitialized (BSS) data section, which contains a little over 1500 bytes of unaccounted-for data:
dseg:0346 db 0FFh dseg:0347 db 0FFh dseg:0348 db 0FFh 🟢 libc initialized data ends here, BSS begins dseg:0349 db 407h dup( ?) ; what is this? dseg:0750 word_11CD0 dw ? ; my program's data dseg:0752 word_11CD2 dw ? ; dseg:0754 db 20Ch dup( ?) ; what is this? dseg:0754 dseg ends
I started approaching this with the idea I had at the end of the previous part - removing all the libc function references from my experiment and readding them one by one, to figure out what makes these mysterious areas appear and narrow down where they are coming from. Soon enough, I had my culprit - any of the file I/O-related functions such as fopen/fread/fflush/… would result in these appearing. It looks like it might be some buffer area related to file I/O? Makes a lot of sense, but what doesn’t is that there were no references to these areas from the libc code. I looked over the code of all libc functions in a minimal executable file reproducing this result (just the startup code and main() calling fflush()), paying special attention to immediate values which could be offsets into the BSS – no luck. The only reference same from the startup code:
seg000:0064 start proc near
[...]
seg000:00C9 assume es:dseg
seg000:00C9 cld
seg000:00CA mov di, 349h ; beginning of BSS area
seg000:00CD mov cx, 960h ; data segment end
seg000:00D0 sub cx, di ; _end - _edata = BSS size
seg000:00D2 xor ax, ax
seg000:00D4 rep stosb ; zero out the BSS
[...]This code performs zeroing out of the BSS before control passes to main(). But there was no code using the BSS!
I started opening the individual object files for file I/O routines extracted (using objconv) from the slibce.lib library like fflush.obj, fopen.obj etc. in IDA, hoping to find some BSS data inside. No such luck. Where is this crap coming from?!
Then I get an idea. I was using the /M switch to the linker this whole time, which creates a human readable “map file” of the linked executable. Let’s look inside:
Start Stop Length Name Class 00000H 0157DH 0157EH _TEXT CODE 0157EH 0157EH 00000H C_ETEXT ENDCODE 01580H 015C1H 00042H NULL BEGDATA 015C2H 017DFH 0021EH _DATA DATA 017E0H 017EDH 0000EH CDATA DATA 017EEH 017EEH 00000H XIFB DATA [...] 017F0H 017F0H 00000H CONST CONST [...] 018CAH 018CAH 00000H _BSS BSS 018CAH 018CAH 00000H XOB BSS 018CAH 018CAH 00000H XO BSS 018CAH 018CAH 00000H XOE BSS 018D0H 01ED3H 00604H c_common BSS 01EE0H 026DFH 00800H STACK STACK Origin Group 0158:0 DGROUP Address Publics by Name 0158:0250 STKHQQ 0000:0788 _abs 0158:0050 _barfoo 0000:14BA _brkctl 0000:0E3E _close 0158:034A _edata 0158:0960 _end [..]
This is surprising. I was expecting all my uninitialized data to be part of the _BSS segment, meanwhile it looks like the bulk (0x604 == 1540 bytes) lies in c_common, and the size of _BSS is actually zero. It takes a web search into some long forgotten corners of the Web to figure out what c_common is:
LINK also generates default segments into which it places communal variables declared in COMDEF records.
Near communal variables are placed in one paragraph-aligned public segment named c_common, with class name BSS
(block storage space) and group DGROUP. Far communal variables are placed in a paragraph-aligned segment named FAR_BSS,
with class name FAR_BSS.
An another search defines “communal variables”:
Communal variables are uninitialized variables that are both public and external. They are often declared in include files.
(…) C variables declared outside functions (except static variables) are communal unless explicitly initialized; they are the same as assembly-language communal variables.
OK, so we are looking for communal variables, but where are they? The smoking gun is hidden further in the map file, where all the public symbols are listed (“Publics by Name”). It seems like the data segment is represented by the segment prefix of 158 in the map file, so let’s take a look at it while introducing some ordering:
ninja@dell:eaglestrike$ cat build-f15-se2/HELLO.MAP | grep 158: | sort -u 0158:0 DGROUP 0158:0042 _foobar 0158:0050 _barfoo 0158:0052 _foobaz 0158:0062 __asizds 0158:0064 __atopsp 0158:0066 __aexit_rtn 0158:0068 __abrktb 0158:00B8 __abrkp [...] 0158:034A _edata 0158:0350 __bufout 0158:0550 __bufin 0158:0750 _x 0158:0752 _y 0158:0754 __buferr 0158:0960 _end
Gotcha! _edata is a handy tag assigned by the linker to the location where the initialized data ends, so it seems my troublemakers are named __bufout, __bufin and __buferr (x and y are sentinel values from my code, which I wrote in Part 1). Whare did y’all come from?
ninja@dell:slibce$ for f in *.obj; do echo "==== $f"; dmpobj $f | grep bufout; done
[...]
==== _file.obj
3 - '__bufout' Type 0, NEAR, Size:00000200h
==== _flsbuf.obj
5 - '__bufout' Type:0
[...]
Looks like these came from the object file _file.obj, so let’s inspect it:
ninja@dell:slibce$ dmpobj _file.obj
[...]
COMDEF(b0) recnum:13, offset:000000b0h, len:002ah, chksum:f7h(f7)
2 - '__bufin' Type 0, NEAR, Size:00000200h
3 - '__bufout' Type 0, NEAR, Size:00000200h
4 - '__buferr' Type 0, NEAR, Size:00000200h
[...]
Three buffers of size 0x200 make 0x600, i.e. 1536 bytes. Now I smell blood. But how come I couldn’t find any references to these? No code is using it, and without having some reference to grab onto, I will not be able to locate their equivalent locations in the actual game executable. This time, the key lies in the other object file that references this symbol, _flsbuf.obj. I open it in IDA:
_TEXT:0010 __flsbuf proc near
[...]
_TEXT:00A8 jnz short loc_100E0
_TEXT:00AA mov ax, offset __bufout
_TEXT:00AD jmp short loc_100E3
_TEXT:00AF align 2
_TEXT:00B0 loc_100E0:
_TEXT:00B0 mov ax, offset __buferrMy minimal example does not have __flsbuf. But when I add all the other libc functions that the game is using, it is also pulled in by the linker. Apparently, these three buffer areas are placed in the executable by the linker even if nothing is referencing them! Damn, those old linkers sure acted weird. I could not find references to the problematic areas because I was looking at a minimal example which had the data, but not the code using the data, which I thought was not possible. But now I can locate __bufout and __buferr by looking at this specific location in __flsbuf. That still leaves __bufin though.
ninja@dell:slibce$ for f in *.obj; do echo "==== $f"; dmpobj $f | grep bufin; done
[...]
==== _file.obj
2 - '__bufin' Type 0, NEAR, Size:00000200h
This symbol is only referenced in _file.obj, so let’s open it in IDA again:
_DATA:0000 ; FILE _iob[]
_DATA:0000 __iob dw offset __bufin
_DATA:0002 align 4
_DATA:0004 dw offset __bufin
_DATA:0006 db 1
_DATA:0007 db 0
_DATA:0008 db 0
_DATA:0009 db 0
_DATA:000A db 0
_DATA:000B db 0
_DATA:000C db 0
_DATA:000D db 0
_DATA:000E db 2
_DATA:000F db 1
_DATA:0010 db 0
_DATA:0011 db 0
_DATA:0012 db 0
_DATA:0013 db 0
_DATA:0014 db 0
_DATA:0015 db 0
_DATA:0016 db 2
_DATA:0017 db 2
_DATA:0018 db 0
_DATA:0019 db 0
_DATA:001A db 0
_DATA:001B db 0
_DATA:001C db 0
_DATA:001D db 0
_DATA:001E db 84h ; you will be usefulBy searching for the value of 0x84 in the executable’s initialized data section, then going back counting the bytes, I can locate the offset containing the pointer to __bufin. Now it all comes together beautifully:
dseg:0346 db 0FFh
dseg:0347 db 0FFh
dseg:0348 db 0FFh
dseg:0349 db ? ; probably alignment
dseg:034A bss_start db ? ; crt0 data ; DATA XREF: start+66
dseg:034B db ? ;
dseg:034C db ? ;
dseg:034D db ? ;
dseg:034E db ? ;
dseg:034F db ? ;
dseg:0350 bufout db 200h dup( ?) ; DATA XREF: __flsbuf+9A
dseg:0550 bufin db 200h dup( ?) ; DATA XREF: dseg:012E
dseg:0750 word_11CD0 dw ? ; x
dseg:0752 word_11CD2 dw ? ; y
dseg:0754 buferr db 200h dup( ?) ; DATA XREF: __flsbuf:loc_10BBA
dseg:0954 db ? ; probably more alignment to end on paragraph boundary
dseg:0955 db ?
dseg:0956 db ?
dseg:0957 db ?
dseg:0958 db ?
dseg:0959 db ?
dseg:095A db ?
dseg:095B db ?
dseg:095C db ?
dseg:095D db ?
dseg:095E db ?
dseg:095F db ?
dseg:095F dseg endsIt was trivial to find the corresponding areas in the game’s executable by examining the equivalent telltale locations. I now have all the data regions introduced by libc identified and marked in the disassembly. It may not be much, but it’s always an extra piece of information and a necessary step if I ever aim for a near-perfect recreation (I’ll explain why a fully perfect one is not feasible another time). If it ever comes to that, this post will have a Part 3, but I’m pretty satisfied with what I got right now.
If that’s the good news, the bad news has got to be that I’m officially out of excuses to continue the reconstruction of a nasty game routine that ostensibly has to do with mission generation, consists of multiple nested loops and conditions, with an occasional goto sprinkled in, and nothing it does makes sense on the surface - just reading and writing of random-looking numeric data all over the place. But I’ll figure it out. Some day.