-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to disassemble Fatal Racing / Whiplash #9
Comments
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:
I'll have to investigate further why this specific EXE causes this. |
Finally another EXE file with debug info, awesome! I used For now, as a workaround, please patch file wcdatool/Wcdatool/modules/main_disassembler.py Lines 2291 to 2292 in b4981ad
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,
is caused by data within the code object (which is currently not detected automatically by
by instructing Find the log of my test run and a sample hints files attached to this comment: |
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 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. |
You should, I think it might help you a lot with the work that lies ahead!
I know the tool, it was initially created to help RE Syndicate Wars, I was in touch with the author a few years back.
Not wanting to brag, but
Functions names, variable names, original source file names, mapping of sources to original source files. |
😮 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. |
You may also want to patch the following line in Replace this: wcdatool/Wcdatool/modules/main_disassembler.py Line 2394 in b4981ad
With this (make sure to keep the original indentation): file_name = module["name"].replace(":", "").replace("\\", os.path.sep) |
Hi Simon,
I mapped out FATAL's code object, i.e. identified all data regions. If you like, give the current development version of |
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. |
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. |
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. I'm using Fedora in WSL on Windows for this, which shouldn't make a difference. |
Nevermind, I got it. My executable was lowercase |
Yeah, that's it. The wrapper script looks for a hints file of exactly the same name as the executable + For the next release, I'll remove the additional scripts and rewrite the README to instruct users to use |
Regarding debugging (our discussion via email): In the video below, I open NOTE:
|
I just remembered what kind of setup I used to debug Mortal Kombat a few years back. OpenWatcom on Windows + DOSBox + virtual serial connection for remote debugging: Setup guide (Google Translate is your friend): Again, only seems to work with OpenWatcom v1.9. OpenWatcom v2.0 builds seem to be broken lately. |
There is an English version of that guide you linked on the OW2 wiki here: https://github.com/open-watcom/open-watcom-v2/wiki/Debugging |
Ok so it is trying to call The address where the path should be found is address 0x356698 but there is nothing there. So it seems that there is some important code that runs in the 16bit section that loads some values into memory? |
Good find, thanks.
No, I was not, also crashed during my tests. I did not investigate further - that's your job :) - but here are my thoughts on that:
|
IIRC, all 16-bit code is handled by DOS4GW, that's its main job. So probably an incompatible DOS4GW version? Not sure though. Could also be one of the other things I listed. |
BTW you could also try to build OpenWatcom yourself per the instructions given in wcdatool's README - IIRC, this builds everything (i.e. Linux + DOS + Windows executables). Maybe that works better than the builds provided by the project itself. |
I've considered it. I did try to build OW in WSL but was missing some dependencies and gave up. |
Built it myself from the latest working commit - no change, OpenWatcom v2 sources seem to be broken. |
I got it working with OpenWatcom's remote debug setup. Breakpoints work, I set one on `copypic_' and it breaks for the intro pictures. Not really sure what makes it work, though. I did not change the setup. But what I did do is open DOSBox, run FATAL's Weird... Got no idea what's going on there... |
Hey, I'm having some trouble with my remote debugging watcom setup. I made a video showing what I have done. https://youtu.be/Fe_GHhgqUzA Do you know what I am missing? Thanks! |
Hi there! Great idea regarding the video, that makes it a lot easier to figure out what might be wrong. Also, you're in luck, I actually still have a backup of the VM with the remote debugging setup, and it's still working as it did back then. Right of the bat, I can tell that you mixed up your As for Which exact COM ports are being used should be irrelevant as long as both DOSBox and Open Watcom are configured accordingly (DOSBox gets one, Open Watcom gets the other one). That part seems fine on your system. I'll attach screenshots of my configuration below. DOS4G(W): |
Also, in your Other than that, the COM setup seems fine to me. |
Gave it a try, no luck unfortunately. https://youtu.be/5Pnj590gmfI |
Ok, so lets dig deeper. What happens in the DOSBox window when you try to start remote debugging? Also, do you have the files Additionally, check Windows' device manager, section Ports (COM & LPT). If the setup is correct, com0com's virtual ports should show up there. If all else fails, try using precompiled Open Watcom v1.9 and normal DOSBox v0.74-3 (not staging). That's what's installed within my VM. Could be an incompatibility issue related to the newer versions. |
Success! Switching to DOSBox v0.74-3 did the trick. https://youtu.be/BO4V30Ij0NE I'm sure I'll have more questions later but I'm rolling now. |
Nice! If your focus actually is Fatal Racing / Whiplash, you might want to get in touch with @deevus - I happen to know that he's still interested in continuing the reverse-engineering effort he started. |
Already did! :) Got a couple other guys helping too. |
Nice, let me know how things are progressing. |
@ninjatobob got @samunders-core's unmangling algorithm adapted from "sound.c.asm" working. We can access most of the game resources now. Check it out over here: https://github.com/ninjatobob/Whiptools |
Wow that was quick. It took me so long to get that working 99%. |
It's kind of weird what they did there - looks like an RLE algorithm on steroids. They were likely aiming for compression and obfuscation at the same time. |
Working on a track editor. Not much to it at the moment but many more features and improvements are planned. https://github.com/Zizin13/Roller |
I made a video so others can get rolling with the debugger easily: https://www.youtube.com/watch?v=bG9tEZOSrQg |
Very nice & helpful for other users! "can get rolling" -> pun intended? |
https://www.youtube.com/watch?v=8qC2jOHXGRo |
Awesome, seems like you guys are making excellent progress. |
I figured out how to apply textures and now have all major track surfaces rendering in the opengl context. |
Made another video on the current state of the track editor. I got all the models from the game in it thanks to this disassembly tool. https://youtu.be/-uRBRUaSn3Y?feature=shared |
Oh wow, that's quickly becoming a fully-fledged editor. I'm curious, can you already save edited tracks and play them in the original game? |
Yep, that has been possible since version 0.1.0 when it was just a crappy text editor. The reason I pushed out releases so frequently is so others who are less technical could help by manipulating track values and seeing what they did in game. A way to do that on a mass scale is better than manually changing each chunk in Notepad. |
Good call, I bet that helped a lot. |
I've added support for exporting tracks and cars to FBX format. |
Hi :)
This looks really interesting as I am trying to RE Fatal Racing/Whiplash and there were WATCOM when running
strings
onFATAL.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:
The text was updated successfully, but these errors were encountered: