Typhoon

[bored]

Going off topic on the very first post...

For a change of scenery, I thought I'd take a another look at Typhoon. Last time the game was <10 years old, so felt a bit guilty trying to take it apart to see if it contains any F22 heritage.
While the game has been available on Steam since 2014, nothing has been done to improve the game as far as I can tell, and the data file is identical to that of the original game.
The exe is a bit different though.
From my original install CD, the game exe was built in March 2001 according to its header info.
The Steam exe has a date of 1970, so has been manipulated in some way. It is also smaller, and from what I see using 'CFF Explorer's Dependency Walker', that difference could be explained by some Windows statically linked libraries being removed.

So, I'm wondering if there is some 'steamification tool' which takes an old game exe and 'relinks' it to maybe perform better on later Windows.

typh_dll.PNG (64.29 KiB) Viewed 10097 times

That's the only explanation I can think of. If somebody spent the time to do it manually, they'd might as well improve the game at the same time.

[Krishty]

Great stuff 👍

Just 4048 bytes into the original EXE, you’ll find this:

00 00 00 00 42 6F 47 5F 20 2A 39 30 2E 30 26 21   ....BoG_.*90.0&!
21 20 20 59 79 3E 00 00 00 00 00 00 00 00 00 00   !  Yy>..........
00 00 00 00 02 00 00 00 0A 00 00 00 1E 00 00 00   ................

Search for BoG_ reveals a copy protection named SafeCast 2.4 and an article on how to crack it: http://www.reversing.be/article.php?sto ... mode=print

So the original EXE is encrypted. Starting it extracts the payload to TEMP after some DRM shit, and this payload is the actual game.

I suppose they removed the copy protection for Steam and shipped the payload directly. There should be warez out there to circumvent the copy protection, but I trust my intuition that it’s probably identical …

[Krishty]

If you start Visual Studio > Continue without code > File > Open > File …, then you’ll see three dialog resources coded into the EXE:

image.png (3.04 KiB) Viewed 10088 times

image.png (2.65 KiB) Viewed 10088 times

image.png (2.48 KiB) Viewed 10088 times

This technique has also been used in ADF/TAW, albeit with a single, almost empty dialog. Looks like fantastic surprises waiting!

[Krishty]

Out of interest, I searched for strings containing .c.

.\didlemul\didlemul.c(26)
ADF/TAW contains the string didlib in a few places, because that seems to be the internal name of the 3D engine used back then. didlemul could be a didlib emulator …

\f22code\afterf22.c(341)
f22code also appears in the ADF/TAW EXE because f22 was the codename for ADF/TAW, and afterf22 could mean “the game after f22”.

\f22code\aid.c
This path can also be found in the ADF/TAW EXE and to my knowledge implements SmartView – aid for AI Director.

campaign\coll.dat […] \f22code\coll.c(183) […] Fatal Error […] Cannot open %s
We all remember the error code that ADF & TAW spit out when they are started from the wrong directory, don’t we? It’s exactly that.

\f22code\avbuffer.c
\f22code\bases.c
\f22code\callsign.c
\f22code\cg_targ.c
\f22code\collev.c
\f22code\f22veclib.c
\f22code\genview.c
\f22code\initgam.c
\f22code\kots.c
\f22code\message.c
\f22code\para.c
\f22code\waypoint.c
\f22code\wpalien.c
\f22code\wptasks.c
\f22code\zone.c
\hudlib\hudint.c
\hudlib\ladders.c
\hudlib\tokenise.c
\f22code\flights.c
\f22code\taxiing.c
\f22code\groupai.c
\f22code\turret.c
\f22code\turtype.c
\mission\newmiss.c(119)
I don’t bother looking it up, but I feel like having seen almost all of those source file names in the ADF/TAW EXE before.

Typhoon is definitely built on TAW source code. No way of denying this.

[Krishty]

The Steam exe has a date of 1970, so has been manipulated in some way.

This made me curious.

For one, the dateTimeStamp is no longer used as a timestamp nowadays. But the EXE is from 2000, so this should not be a concern.

If we look at the timestamp, it has the hex value 31313931. This is definitely manipulated.

If we express the four bytes as ASCII codes, we get 1191. This is weird, to say the least. It can’t mean 1.1.9.1 because the version information resource says 1.0.4.4 …

Furthermore, the header contains the string nofear inside of a padding region. It’s enclosed in spaces instead of zeros, so it hasn’t landed there by accident. I’m beginning to think that this version has been cracked by a warez group; nofear may be the cracker’s signature, and the version string may be an easter egg …?!

(This is not the first time a cracked executable is distributed officially; half of the games on GoG come in cracked executables for the very reason we know so well: Developer has filed for bancruptcy or has lost the source code, but the publisher needs to get rid of the copy protection somehow.)

[bored]

Aha, so what I thought was some smart 'steamification tool' is likely an ugly 'warez hack'.
If I do a quick search for 31313931, it's mentioned a couple of times as being in the header of 'Heroes of Might and Magic' and 'Command & Conquer', so maybe the same operator. I don't really want to look into this further.

Come to think of it, years ago I couldn't run the game in the IDA debugger, so it must have been SafeCast stopping that So, this should be helpful but it's not much better now, as the PC locks up totally if I try to set a breakpoint.

[bored]

So, leaving the exe for a moment to look at the big data archive 'typhoon.dat'...
The files from the Steam release and original are exactly the same size, and while I haven't done a byte comparison, I expect them to be identical.
Some time ago, there was a discussion on Discord about this file, and while there are a lot of unknowns about its structure, the payload of 13920 files can be extracted and partially categorized by the following Python script:

Code: Select all

import numpy as np

def MightBeAChar(c):
    if c >= 9 and c <= 13 or c >= 32 and c <= 126 or c == 255:
        return True
    return False

raw=open("typhoon.dat","rb").read()
numfiles=0x3660 # start at 0x50
i=0x50
e=0
while e<numfiles:
    size=raw[i]+raw[i+1] * 256+raw[i+2] * 256 * 256+raw[i+3] * 256 * 256 * 256
    outbuffer=np.zeros(size,dtype=np.ubyte)
    f=0
    is_text = True
    while f<size:
        outbuffer[f]=raw[i+8+f]
        if f < 64 and not MightBeAChar( outbuffer[f] ):
            is_text = False
        f+=1
    ext = ".dat"
    w_filter = True
    if size >= 4:
        if is_text:
            ext = ".txt"
        if outbuffer[0] == ord('B') and outbuffer[1] == ord('M'):
            ext = ".bmp"
        elif outbuffer[0] == ord('R') and outbuffer[1] == ord('I') and outbuffer[2] == ord('F') and outbuffer[3] == ord('F'):
            ext = ".wav"
        elif outbuffer[0] == ord('D') and outbuffer[1] == ord('D') and outbuffer[2] == ord('S'):
            ext = ".dds"
    if w_filter:
        outbuffer.tofile("unknown\\unk"+"{0:04x}".format(e)+ext)
    print("Completed: {0:04x}".format(e))
    i+=size+8
    e+=1 

Thanks to duc_ttm for tidying up my initial script.

I've only just started looking at the extracted files, but we see some interesting things already:

Code: Select all

;	Copyright   : Digital Image Design Ltd
;	File        : gbvtypes.txt
;	Author      : tim preece
;	Date        : April 1997
;	Format      : PC
;	Description : gbased, ships, tanks etc.. data
;
;	$Revision: 1.1.1.1 $
;	$Log: gbvtypes.txt,v $
;	Revision 1.1.1.1  1998/10/21 11:11:20  russ
;	copied over from TAW code
;

So, some evidence m'lud that Typhoon is reusing at least some TAW code.

[bored]

'typhoon.dat' has certain similarities to the 'did.dat' of earlier games, but a couple of notable differences.
The file can be considered to contain a 'header', the 'payload' files, then 3 blocks of data with each one starting at an address given by 3 pointers in the 'header'.
The first block is just 16 bytes, and contains the number of files (13920) plus some padding.
The second block is ~250kB in size, and seems compressed apart from the first 4 bytes giving the size of the block.
For the earlier 'did.dat's, this area would be occupied by the lists of folders and file extensions, so this data block may have something to do with that.
Finally, the third block contains a list of what looks like filename hashes and start addresses for each file in the archive with 4 bytes each for the hash and address. The 'did.dat's had 4 bytes in this list for the size of each file, but in 'typhoon.dat' the first 8 bytes addressed by the destination given in the list contains each file size.

I suspect the hash algorithm will be something similar to TAW's, and since I think we know some file names, it might be worth trying some guessing to see if we get a match. Even if it is exactly the same algorithm, we don't know the bytes used by the folders and extensions (if used at all) and that 'magic number' that differs for EF2000 V2.0, ADF and TAW. Plenty of permutations to try...

[bored]

I suspect the hash algorithm will be something similar to TAW's...

Well, I don't suspect that anymore.

The hashes are arranged in the dat file in a similar order, ie those starting with 0x80 first, but for EF/ADF/TAW the first 4 bits gives the length of the filename being hashed. So, in practice, that means the lowest first number will be 2 assuming a one character filename plus extension. With the DOS limit of 8 chars plus extension and folder symbols, the largest hash might be 10(0xA) and that's what we see for TAW's hash list at the point where we go from the largest to the smallest:
affeb949 3\ctscnl_3.3
affeed49 3\ctscnl_4.3
201a9b00 UNK\noname10820.UNK
300bb001 fonts\MICRO\8.fnt

but at the corresponding transition in typhoon.dat, we have:
ee6304de
ee64f367
0001f2a9
000324aa

So, the hash function is definitely different.

[bored]

Back to typhoon.exe, and surfing for strings, we see a lot of things like this:

tawinty.PNG (17.28 KiB) Viewed 10052 times

Those names don't look very Icelandic.

I was led to believe that Typhoon was based on the amazing 3dream engine, but maybe it's just a re-skinned TAW but a bit dumbed down.

[bored]

If I run the game with a -menu command line option, one of the dialogs posted earlier gets activated:

tmenu.PNG (5.78 KiB) Viewed 10046 times

...it crashes if I select anything though.

There's a whole bunch of command line options, although -nointro is the only useful one I've seen so far.

[Krishty]

FANTASTIC! 🚀

[Krishty]

A few other strings in the Typhoon EXE that prove that TAW’s source code was at play:

• F-22 ADF Demo Mode
• Total Air War is already running.
• #F-22 SYSTEMS REPORT ------------------- F-22 SYSTEM BIOS V%d.%d#

And here’s a string that needs special mentioning:

Code: Select all

Plane Debug

ID: %d TYPE: %d  %s  %s  %d
ALTITUDE %5.0f FT  TRUE AIRSPEED: %4.0f KTS  RATE OF CLIMB: %5.0f FT PER MIN
ALPHA: %3.1f DEGS  SIDESLIP: %3.1f DEGS
YAW RATE: %3.1f DPS  PITCH RATE: %3.1f DPS  ROLL RATE: %3.1f DPS
HEADING: %4.1f DEGS  PITCH: %3.1f DEGS  BANK: %4.1f DEGS
THROTTLE : %1.2f FUEL : %6.1f KG

GROUND SPEED: %4.0f KTS  GROUND TRACK: %4.1f DEGS GROUND FLAG %1d
FLIGHT NUMBER: %3d MODE: %s
MISSION: %s ROLE: %s
WAYPOINT NUMBER: %3d WAYPOINT TASK: %s GROUND HEIGHT: %5.0f
WAYPOINT NUMBER: %3d WAYPOINT TASK: %3d WAYPOINT ALT: %5.0f

It is almost identical to TAW’s debug output (seen here on an old snapshot from DKD):

F222013-10-2821-54-15-09_zps4de27511.png (234.25 KiB) Viewed 8239 times

This holds a special place in my heart. I’ll try to find out where it’s used. Should Typhoon happen to use TAW’s flight model – which we already reverse-engineered and re-implemented for TFXplorer – then getting the Typhoon flight model to work in TFXplorer could be a matter of hours …

[Scorpion82]

Would be interesting, albeit there are several differences. You have no rudder control for example and the engines are at least severly overpowered, there is no separate engine control for left/right either, albeit modelling does seem closer to F-22 than to EF2000.

[Krishty]

Would be interesting, albeit there are several differences. You have no rudder control for example, […] there is no separate engine control for left/right either

In the code, everything is still there. It actually seems vastly enhanced compared to what TAW does.

and the engines are at least severly overpowered

I read exactly opposite complaints, that the Typhoon is too slow and you can hardly reach Mach 1.6 in the game.

I’m not far enough to comment on these specific issues; I just don’t know yet. But here’s what’s sure:

• This time, they used an optimizing compiler with inlining and fast floating-point math. I.e. the assembly is much harder to dissect than TAW’s.
• The flight model code is at least 75 % equal to TAW’s.
• They fixed two obvious bugs that I found in TAW’s code. I.e. there were actual enhancements! They also did the “move everything from global variables to a class” thing and removed the same useless variables as I did. In fact, their cleanup is so similiar to my own that I can better compare the disassembly to my own code than to the direct TAW translation!

Here’s three capital differences that I found so far; more to come:

1. The lift/drag computation for wings has been altered drastically. This may account for Typhoon’s strict delta wings as opposed to F-22’s almost-delta ones.
2. Flap computation is more complex. They possibly implemented Typhoon’s canards as flaps as opposed to ailerons? I don’t know yet.
3. Many computations have the Mach number 0.75 hard-coded. This is really weird. Maybe their model got unstable at high speeds and that’s their quick hack around it?! Seems like an obvious step back from TAW and doesn’t fit the other enhancements.

Anyway. As I said, the code is veeery close to TAW’s, but harder to decipher. This will take a while.

[Krishty]

Tail fin coefficients are multiplied by two as if the EF2000 had two of them.

I start to think that Typhoon’s flight model may be programmed and compiled better than TAW’s, but is ultimately more arcade-y. Maybe this applies to all of the game.

[Scorpion82]

Yes that has been my feeling from that FM. Somewhat acardish.

The FM is overpowered in terms of acceleration and climb performance at subsonic speeds. EF2000 was in this respect a little bit more realistic. In terms of general handling and maneuvering characteristics Typhoon is more realistic than EF2000.

[Krishty]

Something interesting about the EXE: It’s no debug version, *but* they forgot to strip unused symbols before shipping. So we get to see a few unoptimized/unused functions.

As an example: At 004b2020, we find a function to compute the drag force:

image.png (21.91 KiB) Viewed 8214 times

A bit deeper, at 004b2270, we find it again. With the small modification that the result is written to a variable instead of being returned by value:

image.png (22.79 KiB) Viewed 8214 times

But neither of these is used – they are nowhere referenced. In fact, if we look even deeper down at 004b2590, then we find that the second version has been inlined and merged into its caller:

image.png (15.88 KiB) Viewed 8214 times

Only the third occurence is actually used. The other two were forgotten to be thrown away by the linker. They probably forgot to set the /OPT:REF switch in Visual C++.

This means two things:

1. Before spending time disassembling a function, make sure that it is actually called!
2. If you have trouble understanding a function, look at the “garbage” further up. There might be a less optimized copy that is easier to understand!

Regarding the flight model: It differs from TAW’s in that it doesn’t use elevators. The canards are modelled as flaps instead. I have trouble telling left/right canard-flap apart from leading-edge flap and trailing-edge flap of the main wing. But that’s normal and will resolve itself when I uncover more variables.

There is an initialization function that assigns physical dimensions to all surfaces (e.g. “flap #3 goes to X 123 Y 456 Z 789 and is 10 meters wide”) but Ghidra has trouble with it because it assings literally more than thousand values …

[bored]

Interesting indeed. I don't think I'd have checked for unused functions...

Since you've brought Typhoon up again, I had a look at its expansion's ('Operation Icebreaker', 'OI' from now on) data set.
This has 500 or so extra files compared to the original game.
As opposed to Typhoon, this uses RA compression so I had to rewrite my parser.

Anyway, while we still don't have names, I have done some filtering based on known file types but it's not the treasure trove that Wargasm was...

It would be good to work out how the file names are hashed, so will probably look at that next.

[DrJester]

I have been delving on this too. I'm looking for the FOVs on the Typhoon game and trying to change it a bit. I managed to change the FOV to 100... but only worked when the tutorial popups would show up. hahahaha

But I found something interesting, either they planned a map editor or it was part of the game somehow.

Opening control.ctl on Notepad++ one can change the keybinds. I tried going beyond the opening screen using the -debug_on(and its variants that open an blank window) but it crashes as soon as I start a flight. So I don't know how much these keys work.

Code: Select all

;
;	Edit landscape controls
;
INPUT	EDITLANDSCAPE 		DIGBUT KEY FULLSTOP
INPUT	SQUASHLANDSCAPE 	DIGBUT KEY COMMA
INPUT EDITLANDZOOMIN		DIGBUT KEY BACK_SLASH
INPUT EDITLANDZOOMOUT	DIGBUT KEY Z
INPUT EDITLANDSETHEIGHT DIGBUT KEY H
INPUT EDITLANDRADIAL 	DIGBUT KEY A
INPUT QUITEDITLANDSCAPE DIGBUT KEY Q

INPUT	EDITRANGE DIGBUT KEY SLASH

;INPUT XSIZE	NCNLA		MOUSE 0		YAXIS
;INPUT ZSIZE	NCNLA		MOUSE 0		XAXIS

;INPUT YGROW	NCNLA		MOUSE 0		YAXIS
;INPUT YSHIFT	NCNLA		MOUSE 0		YAXIS

; Debug Keys
INPUT DEBUG			DIGBUT		KEY		INSERT
INPUT DEBUG_NEXT	DIGBUT		KEY		HOME

INPUT RESET_EFFECTS	DIGBUT		KEY	    S
INPUT TEST_EXPLO		DIGBUT		KEY	    X

INPUT BOXALL		DIGBUT		KEY		E
INPUT RADII			DIGBUT		KEY		R
INPUT BORDERS 		DIGBUT		KEY		B

; debug browse views
INPUT NEXTGBASED	DIGBUT		KEY		F
INPUT NEXTPLANE		DIGBUT		KEY		G
INPUT BROWSE_EXTERN	DIGBUT		KEY		H

INPUT WIREFRAME		DIGBUT		KEY		W
;INPUT LOAD_WORLD		DIGBUT		KEY		L

INPUT REARMPLAYER        DIGBUT          KEY             Y
INPUT REREAD3DAUDIO      DIGBUT          KEY             O
INPUT PLAYAVI        	 DIGBUT          KEY             I

And something about second aircraft and turrets and choppers.

Code: Select all

; Keyboard controls script file
;
;NB 1. You MUST specify a joystick number (0 implemented so far)
;   2. when specifying keys by letter always use capitals
;   3. multiple devices may be assigned to functions
;
; INPUTS AVAILABLE
;		   DRIVE		CAM_ZOOM
;		   TURN			CAM_ROTX
;		   FIRE			CAM_ROTZ
;		   BRAKE			INTERNALCAM
;		   TURRET_ELEV		EXTERNCAM
;		   TURRET_TURN		OVERHEADCAM
;		   					TOWERCAM
;		   TURRET_RESET		SEL_WEAPON
;		   CHOPPER_ALT		SEL_ARMAMENT

Code: Select all

; second aircraft
;INPUT ROLL_2	NEGD2A		KEY		LEFT
;INPUT ROLL_2	POSD2A		KEY		RIGHT

;INPUT PITCH_2	NEGD2A		KEY		UP
;INPUT PITCH_2	POSD2A		KEY		DOWN

;INPUT ACCEL_2	DIGBUT		KEY		EQUALS
;INPUT BRAKE_2	DIGBUT		KEY		MINUS

Obviously, I am trying to change a few things here to help on the FOV for Ulrawide(which I failed) both on Typhoon, Ef2000 and TAW. Has anyone found anything related to that?

Hope what I found is useful to someone.