How to disassemble Fatal Racing / Whiplash

[deevus]

Hi :)

This looks really interesting as I am trying to RE Fatal Racing/Whiplash and there were WATCOM when running strings on FATAL.EXE.

It did look promising but it crashed

FATAL.EXE_zzz_log.txt

The error isn't in the log file but here is a snippet copied from the terminal:

Building data maps for data objects:
Building initial data maps from object and modules...
Data map for object 2 has 1 entries
Extending data maps based on size information in structure...
Traceback (most recent call last):
  File "/home/deevus/projects/reverse-engineering/wcdatool/Scripts/../Wcdatool/wcdatool.py", line 241, in <module>
    retval = main()
  File "/home/deevus/projects/reverse-engineering/wcdatool/Scripts/../Wcdatool/wcdatool.py", line 210, in main
    disasm = disassemble_objects(wdump, fixrel, cmd_args.objdump_exec, outfile_template)
  File "/home/deevus/projects/reverse-engineering/wcdatool/Wcdatool/modules/main_disassembler.py", line 2290, in disassemble_objects
    insert_data_map_item(object["data map"], OrderedDict([("start", sitem["start"]), ("end", sitem["end"]), ("type", type_), ("mode", mode), ("source", "structure")]))
  File "/home/deevus/projects/reverse-engineering/wcdatool/Wcdatool/modules/main_disassembler.py", line 1372, in insert_data_map_item
    raise TypeError("ins_item[\"%s\"] must be type %s or None, not %s" % (key, key_type.__name__, type(ins_item[key]).__name__))
TypeError: ins_item["end"] must be type int or None, not NoneType

[fonic]

Thanks for reporting this. That is both a mistake within the code and an issue caused by that specific EXE.

The code in line 1371/1372 should be:

if (not isinstance(ins_item[key], key_type)):
	raise TypeError("ins_item[\"%s\"] must be type %s, not %s" % (key, key_type.__name__, type(ins_item[key]).__name__))

I'll have to investigate further why this specific EXE causes this. ins_item["end"] must never be NoneType, that's why that check is there and aborts execution.

[fonic]

Finally another EXE file with debug info, awesome!

I used FATAL.EXE, size 1129239 bytes, SHA-256 checksum 7789768c0a6cdc213eaf7b1ad8cc125531eb3fe7c213eccac6188e58f428687e for testing.

For now, as a workaround, please patch file Wcdatool/modules/main_disassembler.py at line 2291 by replacing this:

wcdatool/Wcdatool/modules/main_disassembler.py

Lines 2291 to 2292 in b4981ad

	except DataMapInsertError as dmie:
	logging.warning("%s: sitem: type: %s, start: 0x%x, end: 0x%x, length: 0x%x (%d), name: %s, label: %s" % (str(dmie), sitem["type"], sitem["start"], sitem["end"], sitem["length"], sitem["length"], sitem["name"], sitem["label"]))

with this (make sure to keep the original indentation):

except Exception as exception:
	logging.warning("[FIXME]: %s: sitem: %s" % (str(exception), str(sitem)))

This will skip the one faulty fixup item that causes the issue.

With this patch, wcdatool will continue and eventually finish processing the executable. After that, you might want to create your own object hints to refine the output further, e.g. warning

Failed to match fixup target offset 0x3b01:     3824:   01 3b                   add    DWORD PTR [ebx],edi

is caused by data within the code object (which is currently not detected automatically by wcdatool). A hint file with an entry like this fixes it:

                                 Object Hints
==============================================================================

Object 1:
1) start = 00003824H, end = 00003A10H, type = data, mode = dwords, comment = DWORDs

by instructing wcdatool to decode that specific part as data (specifically as DWORDS). Continue adding hints for similar warnings until most of them are eliminated.

Find the log of my test run and a sample hints files attached to this comment:
FATAL.EXE_zzz_log.txt
FATAL.EXE.txt

[deevus]

Thanks for the quick response! I will definitely try this out tonight.

Since part of the process was successful and the LE payload of the executable was split out, what I did do was use https://github.com/samunders-core/le_disasm to disassemble the LE payload which worked great, which you might find interesting.

I have spent a bit of time already in Ghidra documenting the code and naming functions and labels, so I have updated the labels in the le_disasm output from Ghidra by navigating to their addresses.

I'm still very new to reverse engineering, but I'm learning a lot. What can be gathered from the debug info in the EXE that might be useful to me?

I'm likely going to be using the ASM for reference only, and implementing an engine in another language.

[fonic]

Thanks for the quick response! I will definitely try this out tonight.

You should, I think it might help you a lot with the work that lies ahead!

Since part of the process was successful and the LE payload of the executable was split out, what I did do was use https://github.com/samunders-core/le_disasm to disassemble the LE payload which worked great, which you might find interesting.

I know the tool, it was initially created to help RE Syndicate Wars, I was in touch with the author a few years back.

I have spent a bit of time already in Ghidra documenting the code and naming functions and labels, so I have updated the labels in the le_disasm output from Ghidra by navigating to their addresses.

Not wanting to brag, but wcdatool does that automatically for you.

I'm still very new to reverse engineering, but I'm learning a lot. What can be gathered from the debug info in the EXE that might be useful to me?

Functions names, variable names, original source file names, mapping of sources to original source files. wcdatool makes use of all these. Here's what the unedited output looks like for FATAL.EXE:

Files:

Sample from loadtrak.c.asm:

[deevus]

😮 OMG ok yep this is an insane amount of information that will definitely help. Perhaps we can chat more via email

simon@simonhartcher.com

[fonic]

OMG ok yep this is an insane amount of information that will definitely help. Perhaps we can chat more via email

It is, isn't it :) I'll gladly drop you a line via email later today.

[fonic]

You may also want to patch the following line in main_disassembler.py to get the original sources structure:

Replace this:

wcdatool/Wcdatool/modules/main_disassembler.py

Line 2394 in b4981ad

file_name = ntpath.basename(module["name"])

With this (make sure to keep the original indentation):

file_name = module["name"].replace(":", "").replace("\\", os.path.sep)

Results:

[fonic]

Hi Simon,

FATAL.EXE was a really good find! Its structure is SO different from the Mortal Kombat executables (likely because it was originally written in C) and helps me a lot with further development.

I mapped out FATAL's code object, i.e. identified all data regions. If you like, give the current development version of wcdatool a try (hint file for FATAL.EXE with aforementioned mappings included):

wcdatool_v22.7_devel.tar.gz

[deevus]

Ohh this does look interesting.

Found this in the diff with the old version. The old version had labels for these jumps:

[fonic]

Found this in the diff with the old version. The old version had labels for these jumps

This is not right, that part should be data, not code. Are you sure you actually applied the hints file? Doesn't look like it.

If in doubt, please provide the log file.

[fonic]

For comparison, this is how that part should look if everything is applied correctly:

[deevus]

It probably went haywire with my existing wcdatool installation. I just copied your tarball over the top. I'll create a fresh installation and try again.

[deevus]

Ok I tried this again with a fresh wcdatool installation and I'm still not getting output that matches your screenshot. Note the lack of "Hint xxx" comments.

fatal.exe_zzz_log.txt

I'm using Fedora in WSL on Windows for this, which shouldn't make a difference.

[deevus]

Nevermind, I got it. My executable was lowercase fatal.exe whereas your hints file was uppercase FATAL.EXE.txt