Tech File Limitations

[Hooman]

There can be at most 255 techs in a tech file.

The reason being, an array of tech pointers with 256 elements is used to store each tech as it is processed. As each tech is processed, it allocates memory to hold the tech. But since it doesn't know when the end of a file is, it allocates one extra, and tries to parse the file and fill in the tech fields. When the end of file is detected, it deallocates the memory for that last tech. Hence, there is room for 255 real techs, and then a dummy entry that is filled in briefly while it tries to parse another one, only to find it's hit the end of the file.

To make things worse, the array is not bounds checked at all, and it resides on the stack. It's doubly bad since the array is an array of pointers, so by purposefully overflowing this array, you'll overwrite the return address on the stack with a pointer to the tech data. If you setup the tags just right in the tech file, you have control over what data is put where in that structure, so a keen assembly/machine code nut could potentially write a virus in a tech file. They would also have complete control over what goes into the first 28 bytes of that structure (provided there's no hidden error checking I don't know about). If that isn't enough space, they could always chain to code written into another tech structure, which would be easily accessible through the other pointers in the array, which are easily found off the stack. Such a virus would be activated when the tech file is loaded. I would also seriously doubt that any virus scanner would be able to pick up on this, since the only time a virus scanner could realiably scan the data, was while it's still in text format, before it gets parsed and assembled.

Or maybe by thinking all this, it just shows I have too much time on my hands.  <_<

Come to think of it, I sort of feel a need to try this out now.  


Parsing stops "gracefully" if a BEGIN_TECH token can't be found (because it's hit the end of the file, or other read error). Once the BEGIN_TECH token is found, any errors before the END_TECH is found generate a Parse Error and informs the user. The "graceful" stopping is one way in which garbage at the end of compressed streams from the .vol files can be ignored.
 

[Hooman]

Ok, so there was a slight complication in that the easily usable space is really 8 bytes, followed by a 4 byte break, and then 16 bytes of easily usuable space.

Still, it didn't take too much effort to work around that and generate a tech file with executable code in it to accomplish the following test.




And considering how much space I didn't use in all the dummy techs I used to overflow the buffer, it really wouldn't be hard to extend this to do something more powerful. Or more sinister.  :ph34r:  

[Mcshay]

Would it be possible to use that to create a second 'Game Setup' window? It could be useful for missions that have many extra features.

[Hooman]

This is not the way to go about doing that. If you want extra setup for a mission just put it in the DLL.
 

[BlackBox]

Yeah, it's more of a buffer overflow exploit (there isn't some magic way to create message boxes or whatever, but the fact that you could put executable code into a techtree file).

Maybe this can partly explain why Arklon was having weird things happening (like other players suddenly needing 150+ workers to run their buildings after player 1 researched a certain tech).

As far as a game options window is concerned, just pop up a modal dialog box at the beginning of the InitProc. In the case of a multiplayer game, pop it up only for the host (player 1)... the only thing to be said with this is, there might be some sort of timeout at the other end (since the other players will just sit at "waiting for scenario to load" until the host finishes).
Maybe pop up modal dialog boxes on the other end that say "Host is setting game options."
As far as transmitting the choices to the other players, custom command packets could be generated by the host and intercepted by the other players (maybe not even needing to have a custom type -- a ctGameOpt packet with a custom variable identifier (something that the game isn't already using) could be enough, provided that you intercepted ctGameOpt packets at the other end).

And yeah, Hooman, you have a bit too much time on your hands if you are writing buffer overflow exploits to pop up message boxes. (Although amusing).

[Hooman]

There's a slight problem with using ctGameOpt CommandPackets. All the variable identifiers essentially have a meaning. Plus, the second problem being that any ctGameOpt packet that's processed after tick 0 will generate that "CHEATED GAME!" message.

Btw, the variable identifiers that aren't special cased for the usual ctGameOpt settings are used to set TethysGame variables. I've considered that a long time ago actually when the thought of potential exploits came to mind. The one thing that didn't make it quite so easy though, was that only 2 data bytes were used to set the new value. It signed extended those 2 bytes to a dword. Hence, it was somewhat difficult to get a useful pointer written anywhere.  :whistle:


Also, I don't think this limitation explains what Arklon brought up. This would overwrite the return address when the file is being loaded, and thus you wouldn't properly return from that function call, and you'd never get into a game. (Unless exploit code was used to patch up the return address after the overflow thrashed it, but it's extremely unlikely that this would be done by accident). I think it's much more likely that a wrong UNIT_PROP tag was used. Different unit types have different sizes of data for each player, so using the wrong tag could make the offset jump past the end of shorter data stuctures, into the following stucture for the next player. Hence why Player 1 getting an upgrade might have strange effects on Player 2. I doubt the offsets are large enough to get beyond one extra player, and very unlikely it would get all the way to the next unit type info. In other words, if you have an issue where Player n gets an odd number of scientists required at their university then Player n-1 probably just researched a tech that modified a property of their universities. It wouldn't likely be caused by say, Player n+1, nor by a modification to a tech other than the university.
 

[BlackBox]

Oh yeah, good point, forgot about the Cheated Game crap with the ctGameOpt packets.

In that case, just generate a packet with a type that isn't used yet.

[Arklon]

I think it's much more likely that a wrong UNIT_PROP tag was used.

We've both looked at it and couldn't find any incorrect UNIT_PROP tags.

[Hooman]

Yeah, but I didn't look too closely. You have just way too many new techs in that file, and I didn't feel like giong through them one by one.
 

[Sirbomber]

Actually, there are only 8 or so that actually do anything involving UNIT_PROP, aside from some that were in the campaign but not available in multiplayer that I added back in.

But I don't think we're here to talk about an individual techtree file?
Tell us about some of the less sinister possibilities (and give us examples/demos if you can).

[Hooman]

I don't really see any less sinister uses. It'd be much easier to put code in a level DLL than to encode it into the tech tree file. I was mostly just proving a point that it can be done. Hence, be somewhat weary of the txt files, and not just executable code. Flawed software that doesn't bounds check can make any data file potentially harmful. That's particularly true of buffer overflows of stack variables, and even more so in this case where that buffer contains pointers, and especially so when the pointed to data is easily filled in with any value an attacker might want. The only thing that I can think of that would be worse, is if the flaw was in network code, and just anybody on the net could send data to it. At least with this flaw, it requires a tech file to be manually downloaded and used.


I think I should leave out the example on this one though. I only see potential for misuse, not new features. I gave Hacker a copy of the file, but that's it.
 

[Sirbomber]

When you put it that way, I guess you're right.
It's probably for the best if only a select few know about this.



Now, if you'll excuse me while I try to trick Hacker into sending me that file.